Java & XML Data Binding

High-Level APIs

So far, the APIs I’ve discussed have been driven by the data in an XML document. They give you flexibility and power, but also generally require that you write more code to access that power. However, XML has been around long enough that some pretty common use cases have begun to crop up. For example, configuration files are one of the most common uses of XML around. Here’s an example:

<?xml version="1.0"?>
  
<ejb-jar>
  <entity>
    <description>This is the Account EJB which represents
    the information which is kept for each Customer</description>
  
    <display-name>TheAccount</display-name>
    <ejb-name>TheAccount</ejb-name>
    <home>com.sun.j2ee.blueprints.customer.account.ejb.AccountHome</home>
    <remote>com.sun.j2ee.blueprints.customer.account.ejb.Account</remote>
    <ejb-class>com.sun.j2ee.blueprints.customer.account.ejb.AccountEJB</ejb-class>
    <persistence-type>Bean</persistence-type>
    <prim-key-class>java.lang.String</prim-key-class>
    <reentrant>False</reentrant>
    <env-entry>
      <env-entry-name>ejb/account/AccountDAOClass</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>
        com.sun.j2ee.blueprints.customer.account.dao.AccountDAOImpl
      </env-entry-value>
    </env-entry>
  
    <resource-ref>
      <res-ref-name>jdbc/EstoreDataSource</res-ref-name>
      <res-type>javax.sql.DataSource</res-type>
      <res-auth>Container</res-auth>
    </resource-ref>
  </entity>
</ejb-jar>

In this case, the example is a deployment descriptor from Sun’s PetStore J2EE example application. Here, there isn’t any data processing that needs to occur; an application that deploys this application wants to know the description, the display name, the home interface, and the remote interface. However, you can see that these are simply the names of the various elements.

Instead of spending time parsing and traversing, it would be much easier to code something like this:

List entities = ejbJar.getEntityList(  );
for (Iterator i = entities.iterator(); i.hasNext(  ); ) {
    Entity entity = (Entity)i.next(  );
    String displayName = entity.getDisplayName(  );
    String homeInterface = entity.getHome(  );
    // etc.
}

Instead of working with XML, the Java classes use the business purpose of the document rather than the data. This approach is obviously easier and has become quite popular. Remember, though, that the high-level approach works only in the situation shown here. If you have to perform more complex processing, are filtering data, or have to perform one of a thousand other less-than-routine tasks, these higher-level APIs become less useful. As a result, you’ll want to pair the APIs mentioned in this section with the lower-level APIs from the last, thus forming a complete set of tools.

Mapped Data

The most common high-level API, and the one that seems to be gaining the most momentum, is mapping data from an XML document to Java classes. This is the case I just showed you: an XML document is represented by business-driven Java classes, and the data is mapped from the document into the member variables of these Java classes. This mapping of data is generally known as data binding. When working from an XML data store, it is referred to as XML data binding.^[1] I won’t spend too much time on this topic here, as you’ve got the rest of the book to get the nitty-gritty on mapping-based solutions.

You should realize that under the hood of these low-level APIs, SAX (and sometimes DOM, JDOM, or dom4j) is used to parse XML data. You still have to have parsing and processing; however, data binding hides these details and delivers data to you in a nice, business-driven package. To fully utilize these sorts of APIs, you’ll probably need to at least know basic SAX concepts like entity resolution and validation. As with any other API, the more you know about what occurs beneath the public interface, the better you can use the API and the more performance you can squeeze out.

Messaged Data

I don’t want to open too big a can of worms by getting into web services, but you should know about an entirely different type of higher-level API. In a message-based API, XML is used as the interchange medium for data. For example, a Java array that needs to be sent to another application might normally use RMI or something similar. However, if network traffic is prohibited except via HTTP (usually on port 80), or if the data must be sent to a non-Java application, XML can provide a data format for exchanging the contents of that array. For example, here’s an XML representation of an array with four elements, all of various types:

<array>
  <data>
    <value><i4>12</i4></value>
    <value><string>Egypt</string></value>
    <value><boolean>0</boolean></value>
    <value><i4>-31</i4></value>
  </data>
</array>

This data can then be sent as a message, and any application component that is set up to receive XML messages can use this data. If this sort of communication interests you, check out the Simple Object Access Protocol (SOAP) (http://www.w3.org/2000/xp), and XML-RPC (http://www.xml-rpc.com). Both offer XML-based messaging and allow you to interact with XML data at a higher level than SAX or object-based APIs.

If you want to find out more about web services, you can pick up O’Reilly’s Java and Web Services, by Tyler Jewell and David Chappell, or Programming Web Services with XML-RPC, by Simon St.Laurent, Joe Johnston, and Edd Dumbill. Additionally, a variety of resources on the Web deal with these technologies. You’ll also want to check out Universal Description, Discovery, and Integration (UDDI) registries and the Web Service Description Language (WSDL). I mention these to point out how many XML formats there are; for every format, you’ll need an API to access and manipulate the data within differing documents. You’ll want to be able to use both low- and high-level APIs to accomplish this. Now that I’ve run through the basic APIs, let me get to the business of talking about XML data binding.

---

^[1] Although they won’t get much attention in this book, there are also binding packages for converting JDBC rowsets to Java, SQL results to Java, or LDAP queries to Java—just about anything you can imagine. Future books from O’Reilly will cover many of these emerging technologies.