Database Configuration, the XML Alternative
When creating software, it is a wise decision to separate business logic from information used to configure that software. Over the years, developers have used a number of techniques to externalize configuration. The goal is to make it possible to customize the functionality of a program without changing code. Today, a majority of business applications use a relational database to store data. This article will look at some common ways to store configuration data. Then, it will demonstrate how to use a database to accomplish this task.
The XML Craze
I was inspired to mention XML (Extensible Markup Language) in this article's title because XML seems to have become the configuration 'language' of choice for many software developers. XML was created to exchange data, in a platform-neutral way, between disparate systems. However, XML's use is not strictly limited to data exchange. For example, though small in number when compared to database-driven programs, some applications use XML as a primary storage medium. Another way in which XML can be used is of direct relevance to our topic at hand: software configuration.
In the world of J2EE, let's look briefly at how XML is used for configuration. Applications built with Java Servlets use a web.xml file to wire various software components together. In its most basic form, a web.xml looks like this:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>My Web App</display-name> <description>Here is my web app.</description> </web-app>
A Servlet Container validates against a DTD (Document Type Definition), and then parses web.xml upon application startup. To define a specific servlet for use in your program, you would add the following:
<servlet> <servlet-name>MyServlet</servlet-name> <servlet-class>MyServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>MyServlet</servlet-name> <url-pattern>/MyServlet</url-pattern> </servlet-mapping>
Many popular frameworks are available for J2EE applications. One of the most popular is Apache Struts. In addition to the web.xml file, Struts requires you create a struts-config.xml file. Struts-config.xml maps URLs to Java classes that will process user requests. Using XML files is a good choice here. Configuration data is often hierarchical in nature and the value of an element may be dependent on its context within the larger document. Defining nested relationships is difficult to do using a properties file, but XML does the job quite well. Also, just because you are building a Struts-based, J2EE application, for example, does not mean you will use a database to store program data.
But what if the application does use a database, as an overwhelming number of them do? Are XML files the best way to store all types of configuration? This seems to be the preferred approach for many developers.
Consider a scenario where one might use XML to configure a user interface. In reality, user interface customization is only one of many ways to make use of external configurations, but we will use it as an example. In a fictitious HR system, there is a customizable interface that allows users to view and potentially modify (yikes!) employee salary history. Interface settings are defined in a file called emp_sal.xml. Here is a snippet of that file:
<employee-salary-form title="ABC Employee Salary History" show-delete-link="false" show-edit-link="false" > <salary-history-table show-edit-link="true" show-delete-link="true" max-rows-to-display="5" default-sort- column="Entry Date"/> </employee-salary-form>
And, if you were to use a properties file for this:
employee-salary-form.title=ABC Employee Salary History employee-salary-form.show-delete-link=false employee-salary-form.show-edit-link=false employee-salary-form.salary-history.table-show-edit-link=true employee-salary-form.salary-history-table.show-delete-link=true employee-salary-form.salary-history-table.max-rows-to-display=5 employee-salary-form.salary-history-table.default-sort-column=Entry Date
Figure 1 shows what this interface might look like. It displays a title, employee ID and name, and a table with records containing salary history. Each detail record contains links to edit or delete this data. The form can be configured to display n number of rows with a default sort column. Because the salary-history-table element is a child of employee-salary-form, specifying such information with XML is more appealing than using a properties file, which is harder to read. To customize this form, the user could modify the XML file by hand. However, this approach can be prone to error. More likely, the user will be shown a configuration screen. When saved, the operating system file is updated.
ABC Employee Salary History
|ID: 4949448||Name: John Eads|
There is nothing inherently wrong with using XML to configure this interface. However, in this situation we have another option. More than likely, this system's data resides in a database. So, let's look at how we can use a database to configure the application.