Internet is really a gift to us if we use it properly. There are so many good things for which we can use although few people misuse it. Nowadays i cannot

imagine a day without internet. I have listed below some common uses of internet. Almost i use internet for 90% of the below list.

1.  To pay utility bills like Electricity, Mobile, Landline, credit cards etc

2. To pay insurance premium ( E.g Life Insurance, Medical insurance, Vehicle Insurance )

3.  To plan our travel and to book tickets in bus, train or flights

4. To download our favourite songs , movies and videos

5.  To share pictures taken in important occasions with our friends and relatives

6. To do online shopping from websites like amazon.com, rediff.com etc

7. Net Banking - To view our account balance, transfer funds , order cheque book etc

8. To view the current and past statements of our credit card, mobile etc

9.  To talk with our friends and relatives residing in places outiside our city and foreign countries using yahoo messenger, google talk, skype etc

10.  To send greetings to our friends and relatives on their birthdays, anniversaries etc and for festivals like Diwali, Pongal, Christmas, Ramzan etc

11. To seek alliance for our friends or relatives using the matrimony websites

12. To download ringtones, wallpapers, themes, applications etc for our mobile phone

13. To read soft copy of the newspapers  ( Also called Epapers )

14. To watch TV programmes from websites like techsatish.net

15.  To recharge the prepaid mobile phones

16.  Online trading - To invest in shares, mutual funds and track it

17.  To view the PNR status of the train tickets

18.  E-mail - To share our thoughts, ideas and feelings with people

19. To search and apply for jobs using websites like naukri.com, monster.com etc

20. To know the latest scores of a cricket match

21. To search houses for rent or buying through real estate websites

22. To book rooms in hotels for our holiday trip

23.  To view the performance of the mutual funds in which we have invested money

24.  To view the performance of the shares we have bought

25. To read the story and reviews of newly released movies

26. To download tutorials of any technology  (  Eg. Bluetooth, WAP ) , programming languages (  Eg. C++, Java, SQL )  etc

27. To download all kind of softwares  ( Eg. Utility, Desktop, Multimedia etc ) for our computer.

28. Recipes -To read or download information on how to make different varieties of food recipes

29. To download or read the novels of our favourite authors

30.  To pay the income tax returns

31.  To meet our old friends  and to make new friends through social networking websites

32.  To send gifts or flowers to our friends / relatives in foreign countries

33. If we want to sell or buy anything ( Eg. House, Car etc ) we can place advertisements in websites like sulekha

34. To download wallpapers and screensavers for our computer

35.  To play online games and win prizes

36.  Health - We can read lot of information from web on this. Pregnant women can read tips on food, child growth etc. We can read about

any disease and its symptoms, cure etc. We can read about exercises to keep us fit, yoga postures etc. Even online consultation is

also available today

37. To clarify our doubts on discussion forms in various websites Eg. boddunan

38.  To read the review and description of any new product in any field Eg. Mobile

39.  To view the examination results ( Eg. SSLC, Plus Two ) and the marks scored

40. Travel - When we plan some trip, we can search the different tourist places and find all information about it

41. Online courses - We can take many online courses and certifications in net

42. To download application forms from banks , income tax office etc

43. We can work from home by using the internet. Lot of opportunities are available

44. To watch movies and videos online

45. To access our official mails from home

46. To listen to our favourite songs. There are many websites which allows us to listen songs at free of cost.

47. To know the status of our provident fund claim.

48. Beauty - We can find a lot of tips for beauty on the internet.

49.  File sharing - There are many file sharing websites available. So we can share big files which cannot be sent through email or too expensive

to be sent through post.

and last but not the least...

50. To read / write articles, create and vote polls, participate in discussion forums in boddunan :-)

XML for Configurations

In this article, we look at the use of XML for configuration data. This differs from our XML coverage  that we are not using XML to transfer data between applications, or for generating a presentation layer; we are simply using XML to store data. To understand the motivation for using XML for configuration data, you need only write an application that uses extensive properties files, or code a server that is configured via files on a filesystem rather than command-line arguments. In both cases, the format of the files to supply information to the application becomes arbitrary and usually proprietary. The developer working on configuration often decides on a format, codes a file reader, and the application becomes locked into that format forever. Certainly this is not the most long-term view of application programming and development. As developers and system engineers realized the maintenance problems that an approach like this can cause (forgetting where a comma belongs, being unsure what marks a comment, etc.), it became clear that a standard was needed to represent this type of data that would not immediately cause an application's configuration mechanism to become proprietary. One standard solution that is being used today, but is still lacking functionality, is Java properties files and the java.util.Properties class. Introduced in the Java Development Kit ( JDK) 1.0, these constructs provide a more Javacentric means of storing data and configuration information. However, they do not provide for any sort of grouping or hierarchy. A client application had just as much access and visibility into a server's information as the server did into the client's data, and developers were unable to perform any sort of logical grouping within these files. In addition, having hierarchical configuration parameters had become popular; this nesting of information was difficult to accomplish in other solutions without creating even more complex (and still very proprietary) file formats. XML nicely solved all of these issues and offered a standard, simple way to represent application configuration information. The format also lends itself to being a multi-purpose administration tool. Consider that XML allows a generic application to be coded that can load a DTD or schema and then a configuration file, and allows a user to add, update, delete, and modify information with such a tool. Because XML was being used in many applications already, it became a natural extension to add parsing and handling of configuration files that were converted to XML. Applications that do not utilize XML can easily begin to use XML by introducing XML configuration files; this is much easier to do than to add support for XML data transferal or XML transformations. All in all, it seemed an excellent fit for a variety of applications. When the Enterprise JavaBeans (EJB) 1.1 specification was released, dictating that all EJB deployment descriptors would be in XML format, the use of XML for configuration information exploded. Many who were concerned about introducing the overhead of an XML parser or worried about the longevity of XML suddenly found themselves having to use XML to deploy their business objects in EJB servers. This made a migration of all application configuration data to XML logical and even decreased the complexity of many applications. In this article we look at how you can use XML for configuration data within your applications.

First we spend some time looking at a current use of XML for configuration data. The EJB deployment descriptor is examined with an eye towards important design decisions made in the specification of that file. This will prepare us to write our own configuration files in XML. With this file built, we look at coding some utility classes to parse and load this information into our XML-RPC classes, adding flexibility to our server and clients. Using the JDOM interfaces for parsing, we can easily load the configuration information. Finally, we end with a look at XML in relation to other important data storage mechanisms, databases and directory servers. This will cast our use of XML for configuration data in the light of the "real world" and help you make wise decisions about when to use XML as a data source and when not to.

EJB Deployment Descriptors

Before we begin creating our own configuration files and programs to read and use those files, a look at existing formats and patterns in this area will help. Although this is not a article about EJB, spending some time investigating the EJB deployment descriptors can aid us in understanding how XML-based configuration files work, as well as suggest ideas on how to structure our file format and data. We discuss some of the most important design decisions here and relate them to the EJB deployment descriptor. Before looking at the design of the deployment descriptor itself, though, we should look at why its overall EJB design lent itself to using XML at all. The EJB 1.0 specification required serialized

deployment descriptors; unfortunately, that was the only guideline given. This resulted in each EJB vendor providing a proprietary format for their server's deployment descriptors, and then forcing the application developer to run a tool (or even write their own tool) to serialize the descriptor. EJB, and Java in general, had lost its claim to WORA, Write Once Run Anywhere. XML provided a standard means of handling the deployment descriptor, as well as removing the need for proprietary tools to serialize the descriptors. In addition, Sun provides an EJB DTD that ensures each vendor's deployment descriptors conform to the same specifications, allowing EJBs to be highly platformand vendor-independent.

The Basics

As with any XML document, the EJB deployment descriptor has a DTD to which it conforms. A schema, as we have already discussed, will probably replace this in future revisions of the specification. In either case, the important concept here is that XML documents used for configuration, even more so than for other purposes, must have a set of constraints put upon them. Without constraints, the information could be incorrect or useless to a server, often causing an entire application to fail as a result. Once the constraints have been identified, the deployment descriptor begins with its root element, ejb-jar . Although this may seem a trivial item to note, the naming of a root element is an important part of authoring any XML document. This element faces the rather enormous task of having to represent all the information within the XML document it belongs to. Particularly when others may have to use or maintain your documents, proper naming here can avoid confusion, and poor naming can cause it. The relevant portions of an XML deployment descriptor that adheres to the EJB specification are shown here:

JavaBeans 1.1//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">


This ejb-jar file contains assembled enterprise beans that are
Part of the employee self-service application.

...

Using namespaces (which were in their infancy when the EJB 1.1 specification was developed) can add clarity to the naming of your document's root and other elements. This aids in identification of the purpose of the document; consider the ambiguity removed by using a namespace such as DeploymentDescriptor or even simple EJB-DD in the EJB deployment descriptor. Any questions about the use of the document are removed when viewing these namespace prefixes on elements.

Organization

Just as naming is critical for document clarity, organization is crucial to the usability of your configuration files in XML. Not only do the organization and nesting of elements and attributes in your document help in understanding the purpose of a document, they can ensure that applications can share configurations and reuse similar information. It is equally important to know when not to try to store information across configurations. This is particularly relevant as we look at the EJB deployment descriptor; each EJB is intended to act independently of all others, knowing only the information supplied to it by its container. It is a problem if beans can operate with each other outside the strict confines designed by the bean developer, as performance and business logic can be subverted. For this reason, each EJB entry is completely independent of all others. In the following example, a session bean is described in XML:

The EmployeeServiceAdmin session bean implements the session
used by the application's administrator.

EmployeeServiceAdmin
com.wombat.empl.EmployeeServiceAdminHome
com.wombat.empl.EmployeeServiceAdmin
com.wombat.empl.EmployeeServiceAdmin-Bean
Stateful
Bean

This is a reference to a JDBC database. EmployeeService keeps a log of all the transactions being performed through the EmployeeService bean

for auditing purposes.

jdbc/EmployeeAppDB
javax.sql.DataSource
Container

In addition to the isolation of this session bean from any other beans, elements are used to logically group elements and data. The resource-ref element encloses information relevant to a particular environment entry. This makes it easy for the application parsing and using the data as well as developers and system administrators maintaining the application to locate and update information about the bean or EJB server.

Creating an XML Configuration File

To try to put some of this knowledge into use, we look at using an XML-based configuration file for the XML-RPC classes . Certainly this is an excellent example of using XML for configuration information; we already have an XML parser available (used in the XML-RPC server), and it is possible that we could use this same configuration file for both clients and servers. Additionally, this configuration could be edited by XML IDEs instead of our having to create a proprietary interface for editing the file in a proprietary format. This can reduce the code that needs to be written for complex applications. Before we start writing our configuration file, we need to define the information that will be in this file. The pieces of information we want to include are:

• Port for the XML-RPC server to start on

• Parser class for the server to use as a SAX driver

• Handlers for the XML-RPC server

• Class identifier

• Class name

• Hostname for the XML-RPC clients to connect to

• Port for XML-RPC clients to connect to

• Parser class for the server to use as a SAX driver

This provides all the information needed for both our clients and server to start without needing any user input other than the location of the XML configuration file itself. With these requirements in mind, let's begin writing the XML configuration file.

Getting Started

Just as in the case of the EJB deployment descriptor, our file must include the standard XML prolog information. This is simple enough, and the only other details we need to decide on are a namespace and root element for our document. Although in a production situation we might use a namespace indicative of the purpose of the document, such as XMLRPC or XmlRpcConfig, here we continue to use JavaXML to identify the configuration file with the examples in the rest of the article.The root element then becomes an identifier of what the document actually is used for; simply using xmlrpc-config seems a good choice for this. It is often the case, particularly in more complex XML documents, that the simplest solutions are the best ones. Naming XML elements and attributes is no exception to this rule.

With these initial determinations and decisions made, let's start creating our XML configuration file for our XML-RPC classes. The initial XML declaration and root element with namespace declaration are given here:

xmlns:JavaXML="http://www.oreilly.com/catalog/javaxml/"
>

Other options that can be added at this point include a reference to a DTD or schema to constrain the document as well as processing instructions to applications that might parse and use this configuration. For our example, we omit these, as our program will simply parse the document as is and return the needed configuration information to the XML-RPC server and clients.

Organization

With the skeleton of the configuration file set, organization of the file needs to be determined. This includes both grouping of elements and a determination of whether any configuration information will be shared across servers and clients. The best methodology for making organizational decisions is to group the file much as you would group the configuration information if writing it by hand. Our original information requirements are small, and this process is easy to perform.

The following pieces of information are simple, and we can consider them part of the information needed by our server:

• Port for XML-RPC server to start on

• Parser class for server to use as a SAX driver

The following pieces of information will be repeated numerous times, and can be grouped into a set

of handlers, with each handler within that set having a class identifier and a class name:

• Handlers for XML-RPC server

• Class identifier

• Class name

The XML-RPC client uses the last three pieces of information; however, the port used by the client is the same for the XML-RPC server, and the SAX driver is most likely the same as well. It makes sense to share this information so that changes only need to be made in one XML element, rather in separate elements for the client and server. With the port and SAX driver class being shared, it makes sense to also group the hostname into this set of shared information. Even though only the client uses it, it fits in well with the port number to use for XML-RPC requests.

• Hostname for XML-RPC clients to connect to

• Port for XML-RPC clients to connect to

• Parser class for client to use as a SAX Driver

By simply "talking through" the information to be included, we have determined that we have two basic groups of configuration information: "shared information" used by both the server and client, and " handler information," which has "handler" entries for each XML-RPC handler. This will result in two basic groupings in our configuration file, with the latter of these two having elements nested within it describing each grouping. We look at each in turn next.

Shared information

There is very little to note in adding a hostname, port number, and SAX driver class for our server and clients to use at startup and connection time. Even the element names for these three pieces of information are simple to arrive at: hostname, port, and parserClass. Again, simple solutions are generally the most effective. As an example of using attributes as well as elements, we add in an attribute for the port element named type. The idea is that the value of this element is either "protected" or "unprotected." When the port is protected, some additional actions would need to take place to connect, such as encoding the request through SSL. In our example XML-RPC classes, the server listens on an unprotected port; however, using this attribute adds flexibility if we want to use secure ports at a later point in the application's evolution:

newInstance
8585

org.apache.xerces.parsers.SAXParser

XML-RPC handlers

The first thing we want to do in defining our handlers is to ensure they are only used by our XMLRPC server. Although we have no other information besides the handler configuration applicable to only the server, it is possible and even probable that at some point, more server-specific information will be added to the configuration file. Rather than having our parser look for a specific set of elements (and adding to those elements when we add new configuration information), we can have it look for a server-specific element name, such as xmlrpc-server. Server applications can read this information, while clients can ignore it without having to know the specifics of the information contained within the grouping. It also makes the information's purpose easier to discern for human eyes. We use this element (xmlrpc-server) to enclose our handler information. We also should group all of our handlers together, and use an element simply named handlers to do this. Again, this grouping makes it simple to determine the purpose and use of the configuration information within the file. Add the configuration information needed for specifying the HelloHandler and Scheduler classes as XML-RPC handlers to the XML-RPC server

Types of Internet Protocols:

The Most commonly used internet protocols are as follows:
 * Transmission control Protocol/ Internet Protocol (TCP/IP)
                  * File Transfer Protocol (FTP)
                  * Hyper Text Transfer Protocol (HTTP)
                  * Telnet.
 * Gopher.
 * Wide area information service.

TCP is actually a collection of protocols, or rules, that govern the way data travels from one machine to another across networks. The internet is based on TCP and IP.
The TCP component breaks data up into packets that the network can handle eficiently, verifies whether all the packets have arrived at their destination and "reassembles" the data.

FTP is the protocol, which enables files to be transferred between computers. FTP is a powerful to, which allow files to be transferred from one computer to another.

HTTP is a set of rules, that governs the transfer of hypertext between two or more computers. The world wide web encompasses the universe of information that is available via HTTP.
It is based on client/Server principle.

Telnet is a protocol that enables one ocmputer to connect to another computer. This process is also referred to as remote login. Once connected, the user's computer emulates the remote computer. 
It also operates in client/ Server principle.

Gopher is a protocol designed to search, retrieve, and display documents from remote sites on the Internet. In addition to document display, document retrieval, it is possible to initiate on-line connections with other systems via Gopher.
Information accessible via Gopher is stored on many computers all over the Internet.

WAIS is based on Z39.50 standard.  It has the capability of simultaneously searching in more than one database. After the search phrase has been typed into the client interface, the user can then choose which databases shoud be used to compete the search.

Intro