Reading an XML Configuration File

To allow our XML-RPC classes to use our configuration file, we must create a helper class that parses the information and then makes it available to the server and clients. Although we could build this behavior into methods within the XML-RPC classes (similar to how the getHandlers( ) method was used in our LightweightServer class), using a separate class allows this class to be shared by both the clients and server, reducing duplication of code. We have already determined the information that needs to be obtained and can begin by writing a skeleton class with accessor methods for that data. The actual contents of the member variables we use will be populated by the parsing behavior we write in a moment.

Getting the Configuration Information

We could add code directly to the com.oreilly.xml.LightweightXmlRpcServer class to parse a configuration file; we could then add similar code to our XML-RPC clients that performed the same task. However, this results in a lot of duplicate code. Instead, another com.oreilly.xml utility class is introduced here: XmlRpcConfiguration. The beginnings of this class are shown in Example A; a constructor takes in either a filename or an InputStream to read XML configuration data from. Simple accessor methods are also provided to access the configuration data once it has been loaded. By isolating the input and output of the class from specific XML constructs, we can change the parsing mechanism (which we look at next) without changing our XML-RPC server and client code; this is a much more object-oriented approach than embedding XML parsing code within our server and client code.

 

Example A. The XmlRpcConfiguration Class to Read XML Configuration Data

package com.oreilly.xml;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.InputStream;
import java.io.IOException;
import java.util.Hashtable;
/**
* XmlRpcConfiguration is a utility class
* that will load configuration information for XML-RPC servers
* and clients to use.
*
* @author
* This email address is being protected from spambots. You need JavaScript enabled to view it.
* @version 1.0
*/
public class XmlRpcConfiguration {
/** The stream to read the XML configuration from */
private InputStream in;
/** Port number server runs on */
private int portNumber;
/** Hostname server runs on */
private String hostname;
/** SAX Driver Class to load */
private String driverClass;
/** Handlers to register in XML-RPC server */
private Hashtable handlers;
/**
* 

* This will set a filename to read configuration
* information from.
* 

*
* @param filename String name of
* XML configuration file.
*/
public XmlRpcConfiguration(String filename)
throws IOException {
this(new FileInputStream(filename));
}
/**
* 

* This will set a filename to read configuration
* information from.
* 

*
* @param in InputStream to read
* configuration information from.
*/
public XmlRpcConfiguration(InputStream in)
throws IOException {
this.in = in;
portNumber = 0;
hostname = "";
handlers = new Hashtable( );
// Parse the XML configuration information
}
/**
* 

* This returns the port number the server listens on.
* 

*
* @return int number of server port.
*/
public int getPortNumber( ) {
return portNumber;
}
/**
* 

* This returns the hostname the server listens on.
* 

*
* @return String hostname of server.
*/
public String getHostname( ) {
return hostname;
}
/**
* 

* This returns the SAX driver class to load.
* 

*
* @return String - name of SAX driver class.
*/
public String getDriverClass( ) {
return driverClass;
}
/**
* 

* This returns the handlers the server should register.
* 

*
* @return Hashtable of handlers.
*/
public Hashtable getHandlers( ) {
return handlers;
}
}

With this skeleton in place, we can add JDOM parsing behavior to load the member variables with configuration data. To ensure that this information is ready when needed, we call the parsing method in the class constructor. The intent of providing these basic accessor methods is to hide the details of how the configuration information is obtained from the classes and applications that usethe information. Changes to JDOM version, or even to using an entirely different method ofaccessing the XML data, affect only this class; changes do not have to be made to the XML-RPC clients and server. This provides a highly maintainable method of getting configuration information.

 

Loading the Configuration Information

With our class skeleton created, we can begin outlining the details of the parsing behavior we need. In this situation, we have a simple task because we know the structure of the XML document coming in (thanks to our DTD and its constraints). Thus we can directly access the elements in the document for which we need to obtain values. The best way to think about this is as a hierarchical

tree structure; we can then "walk" the tree and obtain values for the elements we need information from. Figure B shows our XML configuration file represented in this fashion With this model in mind, it is simple to use the getChildren( ) and getChild( ) methods that JDOM provides to navigate to each of the XML elements we want to obtain data from; we can then invoke getContent( ) on the resultant elements and use those values in our application. We need to import the needed JDOM classes (and the Java support classes), create a new method to parse our configuration, and then invoke that method from the XmlRpcConfiguration constructor.

 

The Real World

As we continue through our topical discussions, the line between a realistic use of XML and our examples is becoming thinner. Our XML-RPC server in this article is close to being ready for production use; it has a flexible configuration file format, it registers handlers dynamically, and

maintains a lightweight structure for handling XML-RPC requests. However, the use of XML for pure data, as discussed in this article, is as new an idea as most of our other XML topics. As with RMI versus RPC, it is possible to overuse the technology. In this section, we compare XML as a data storage medium with other more traditional formats, discussing when one format is preferable over the other, as well as comparing JDOM with other solutions for accessing our underlying XML data.

 

XML Versus Directory Services and LDAP

Another fairly recent upstart in the technology and data space is the Lightweight Directory Access Protocol (LDAP) and directory services. From the first steps in research at Berkeley and Michigan to Netscape's now widespread Directory Server (http://www.netscape.com), LDAP has become a hot topic in its own right. With the rise of XML, there has been a fair bit of confusion as to when directory services are appropriate to use instead of XML. While directory services are well recognized as useful for company directories and integration of company-wide mail, addressing, and calendaring services, using the LDAP protocol has become popular for configuration information. Storing information about application configuration as well as about how to respond to key application events (such as authentication) is commonly handled with a directory server. This provides faster search and retrieval than a database, and the hierarchical format of most directory servers lends itself well to configuration information. With this article on XML for storing the same type of data, the question of when to use LDAP and when to use XML is particularly pertinent.

The surprising answer to this query is that the question itself is not valid! There is really not a comparison between LDAP and XML, as the two serve orthogonal purposes. Where LDAP and directory services are about making technology or components available by some specific name,

XML is about the storage and transmission of the data involved with those components. In fact, a more appropriate question is "When will LDAP and XML integrate?" The answer lies in the same technologies for XML data binding that we mentioned in regards to databases; the Castor project actually has a complete XML-to-LDAP binding. Additionally, directory services are moving towards a uniform data storage medium; XML certainly could be this medium. As the hierarchical structures of LDAP and XML are close matches, don't be surprised to see a marriage between LDAP services and XML storage.

 

We all use mobile phones predominantly for making / attending calls and sending / receiving messages. I have listed below some other uses also.

Alarms

We can keep wake up alarms. Most of the mobiles have option to set different time for weekdays and weekends. So if we set it once it will

wake us up for ever.

Reminders

We can keep reminders for doing important things like attending a meeting, going to hospital etc. Also we can store the birthdays and

anniversaries of our dearest ones in calendar and set reminder for that so that we won't miss / forget to wish them on the occasion

Email & Internet

Most of the mobile service providers are providing the internet facility in minimum cost. Nowadays mobile versions for many applications

are available like gmail, yahoo mail, icici bank, citibank etc. We can check our mails and browse the internet also.

Photos

Almost all mobiles come with a camera. Only the pixel size differs. We can take photos and videos using our mobile whenever we need it.

We don't have to worry about digital cameras. Also we can transfer the photos easily to computer using bluetooth or USB.

Music

We can store all our favourite songs into the memory card and hear it whenever we think. We can create different playlists according to our need.

Also we can hear music from FM radio stations.

Data sharing

Using bluetooth we can easily copy images, music etc from/to our friend's mobile phone.

Finance management

Lot of softwares are available for keeping track of our expenses. We can download them to our mobile and can track our daily expenses very easily.

Professional usage

Mobile versions of microsoft word, excel, powerpoint etc are available. We can copy our office documents to our mobile and read that while travelling

or at home.

Games

We can download different categories of games like adventure, puzzle, racing etc and  enjoy playing it in our mobile.

Maps

We can use the Maps feature available in mobiles to find out the route for the places we travel.

Data storage

We can store our important personal information in the mobile and protect it with a password so that it is accessed by only us.

Calculations

We can make use of the calculator for making simple calculations. Even scientific calculators  and curreny converters are also available.

Power source

We can use it as source of power in darkness. Some mobiles have the facility of using the camera lights as torch lights also.

Calendar

Almost all mobiles have the calendar for atleast next 10 years. It will be very useful if we get the list of holidays for the year in it also.

I don't know whether it is already available.

Utility Softwares

Many utility softwares related to health, beauty, travel etc are available. We can download that and use it.

 

 

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