In this chapter, we look at the use of XML for configuration data. This differs from our XML coverage in other chapters in 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 Java-centric 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. With one XML configuration file or
hundreds, from one format to many, this same application could
provide an interface for administration. Compared to the variety of
password, shadow, user and group, initialization script, and other
files on servers today, this is a significant improvement in
simplicity and ease of use.
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 chapter 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. We then create a configuration file for our XML-RPC server and clients that we built in Chapter 10. 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.
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 book 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 platform- and vendor-independent.
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:
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 1.1//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<description>
This ejb-jar file contains assembled enterprise beans that are
Part of the employee self-service application.
</description>
...
</ejb-jar>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.
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:
<enterprise-beans>
<session>
<description>
The EmployeeServiceAdmin session bean implements the session
used by the application's administrator.
</description>
<ejb-name>EmployeeServiceAdmin</ejb-name>
<home>com.wombat.empl.EmployeeServiceAdminHome</home>
<remote>com.wombat.empl.EmployeeServiceAdmin</remote>
<ejb-class>com.wombat.empl.EmployeeServiceAdmin-Bean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Bean</transaction-type>
<resource-ref>
<description>
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.
</description>
<res-ref-name>jdbc/EmployeeAppDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
</enterprise-beans>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.
A larger grouping not as immediately evident is the
enterprise-beans
element. This would allow information
specific to the container that does not apply to beans to be included
without being mixed in with information specific to EJBs. This is an
important distinction, and we will use it to separate configuration
information from our XML-RPC server and our XML-RPC clients later in
this chapter. Finally, any number of beans can be added to this
“parent” element; although we only looked at one session
bean here, multiple elements can be added of type
session and entity,
representing multiple beans in the jar file that would be created.
Although we have only briefly looked at this XML file, you should be starting to think about what sort of naming and organization should be used in your own applications as well as our XML-RPC example. Hopefully, you have some ideas of your own about structuring configuration files; almost every application has different needs and will require a unique XML document structure and set of constraints. Now that you have seen an example use of configuring an application server in XML and have started thinking about creating a configuration file of your own, let’s do just that for our XML-RPC classes.