ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


Java and XML Data Binding

Why Data Binding Matters

by Brett McLaughlin, author of Java and XML Data Binding
05/15/2002

OK, I know what you're thinking: "So now I'm going to be told that I need another API for working with XML. Come on, give me a break!" Well, that's actually exactly what I'm going to tell you; however, I'm going to do it in the O'Reilly way, which is to give you the real story, and then leave you alone to decide for yourself. But first, let's back up a little bit.

Data binding is an API for working with XML. For the context of this article, I'm going to focus on implementations of the API written in Java. That's in line with my newest book, Java and XML Data Binding. The book is about how to use data binding, though, not why. This led me to write this lead-in article, which should answer the question, "Who cares?" In other words, you probably need a good reason to go out and spend your hard-earned money on another animal book, and hopfully I can provide you several in this article.

Data binding, in a nutshell (this is O'Reilly, after all), allows a mapping of data from an XML document to a Java object, and then back again. Of course, this is nothing new to the world of Java and XML, as there are numerous APIs that already allow some variant of this behavior: SAX, DOM, JDOM, dom4j, JAXP, etc. The list goes on and on; however, data binding has something unique that makes it worth delving into. Each of the APIs I just rattled off are document-centric. That means that you are dealing with data in some XML representation. In other words, you will get the content from an element, the value of an attribute, or the name of an entity reference. The problem with this approach is that it forces you to work within an XML structure.

Data binding starts with the assumption that your priority is business-driven, not XML-driven. Instead of elements and attributes, you want to work with people, names, addresses, and phone numbers. You want to dispense with XML and get to the data in the XML document, but you also don't want to have to wade through XML semantics to do it. For this reason, data binding allows a mapping from XML data (not structure) to business-driven Java classes. These classes are user-defined, so they could be things like a Person class, an Address class, or a string field named city. Data binding APIs take care of converting elements' and attributes' data into these custom, business-driven types. The result is that you invoke methods like setState(String state) and getAddress() instead of setContent(String elementContent) and getAttributes(). The difference, and advantages, should be obvious.

So now to the "why" of the matter: in case you don't see how this can help out, I'd like to provide some typical uses of data binding. It is certainly the case that you will want to use lower-level APIs like SAX and DOM for dealing with data that may change structurally, but for business-driven, stable documents, data binding may just be the solution you've been looking for. See if you don't have code that falls into at least one of the following categories:

1. Configuration Files

At some point, we've all had to write code to pull data from configuration files. Since these are almost universally moving to an XML format, you end up writing SAX handlers or DOM manipulation code to provide a helper to convert between XML and your actual data. However, this takes a rather annoying amount of time, especially since the configuration file format rarely changes.

Instead of staying with this rather antiquated approach, consider using data binding. You could take the following configuration file:

<?xml version="1.0"?>
<server-config>
  <hostname>middleearth.com</hostname>
  <services>
    <www port="80">
      <docRoot>/www</docRoot>
    </www>
    <www port="8001" admin="true">
      <docRoot>/admin</docRoot>
    </www>
    <telnet port="9769" />
  </services>
</server-config>

Instead of parsing this, manipulating it, and worrying about whitespace and a variety of other idiosyncrasies that have nothing to do with your data, imagine simply writing code like this:

// Convert XML to Java
ServerConfig serverConfig = ServerConfig.unmarshal(new File("config.xml"));

You're probably expecting a lot of other code. However, that single line handles data conversion. You could now perform operations like this:

System.out.println("Hostname: " + serverConfig.getHostname());
TelnetService telnetService = serverConfig.getServices().get("telnet");
telnetService.setPort(2010);

2. GUI Editors

One of the most common tasks of all time is that of trying to handle the problem of matching up events in a GUI editor with data on a disk. As in the case of configuration files, XML has become a preferred medium for much of this data. However, the problem continues to be creating a notification system between what is on the screen (and what the user types) and what is on disk.

It's actually quite a pain to have to write SAX or DOM code to fire off at every keypress, but it's equally expensive to hold onto a DOM tree in memory. Instead, data binding can again provide an answer:

// method to update the current buffer
public void onKeyPress(char key) {
    // Update the buffer object
    currentPane.getBuffer().append(key);
}

// Method to write current changes to disk on a save request
public void onSave() {
    // Use data binding to convert back to XML
    currentPane.marshal(someFile);
}

In the first method, the currentPane object is the representation of some XML format on disk. Because data binding is being used, it's not an XML-specific construct, but rather an IDE-specific one. It might have visual properties, state, and even a history of user actions, all corresponding to XML fields. In the onKeyPress() method, the buffer is updated, refreshing the in-memory version.

In the onSave() method, this representation is written to disk, and all preferences, buffers, and other data are updated. However, no XML knowledge was needed, and the currentPane object is not clogging up memory with lots of business-useless XML semantics.

3. XML persistence

So far, I've talked about two very general use cases. However, they are similar in that they both must write data to an XML file. Of course, the problem of XML persistence underlies both of these cases. Not only is XML useful for storing data in flat files, but it can also be utilized for converting data into an XML database, or an XML-accepting directory server. In all of these situations, you will have to write code that takes your application data and converts it to whatever format is applicable. Of course, this sounds a lot like what data binding does! So, in fact, anytime you need to quickly convert data into XML, data binding becomes a possible solution. You've already seen that with a simple invocation of the marshal() method, this conversion from Java to XML is possible.

Additionally, I discuss frameworks in my book that allow you to do this with any class, not just one created by data binding tools. In those cases, you use an external marshaller to convert an arbitrary object into XML:

Marshaller.marshal(myCustomObject, someFile);
Marshaller.marshal(anotherObject, myOutputStream);

In both cases, XML persistence becomes trivial, rather than a side project you have to spend weeks writing, debugging, and tuning.

Related Reading

Java & XML Data Binding
By Brett McLaughlin

4. Data Modeling

This is a little known, but very cool, means of dealing with application data in a visual way. There are very well-understood approaches for taking XML documents and formatting them visually; XSLT offers a simple means to do this, and FO (Formatting Objects) can bridge the gap between XML and PDF files. However, until now, there has been no clear way to easily (emphasis on "easily") convert your business data into XML. With data binding, though, this means is now available to developers.

Putting these pieces together, it is possible to use data binding to convert application or business data into an XML format. This XML format can then be processed via XSLT or a formatting-objects processor to produce graphical results, or convert the data into binary formats like Adobe's PDF. This means that in hours, rather than weeks, you could take all of the application objects in your system, convert them into an XML representation, run those representations through a translator, and distribute nicely-formatted PDF files to your entire team, a marketing quorum, or even your impatient CTO. Pretty slick!

5. Data Interchange

This particular use case is the one in which you have a larger team and must hand off responsibility for data to other portions of that team. It's common in these cases to have a requirement for obtaining data (again, from XML) and supplying that data in a usable format to other groups. This typically involves using SAX or DOM to load the data, and then wrapping or converting that data into a business-specific object, so that other groups can understand the data without having to also know the Java and XML APIs. Again, though, this task is competely handled by data-binding APIs.

In fact, the task of writing SAX, DOM, or conversion code is completely removed, and you can go on to more interesting tasks. Through marshalling (conversion to XML) and unmarshalling (conversion from XML), it is trivial to load XML data and operate upon it in a business-specific way.

I know these are just a few simple use cases, but I have a hard time believing that anyone cannot relate to at least one, if not several, of these examples. They appear time and time again, and with data binding they can be more easily dispensed with than ever before. Instead of spending your time with the lower-level APIs (at least in these situations), relax, take some time off, and whip out a few lines of data-binding code to take care of the problem.

And while you're at it, you may want to pick up Java and XML Data Binding. It shows you, in detail, how to handle these tasks, covers four different data-binding implementations, and will help you get your work done.

Brett McLaughlin had developed enterprise Java applications for Nextel Communications and Allegiance Telecom. When that became fairly mundane, Brett took on application servers. He then got hooked on open source software, and helped found several cool programming tools, like Jakarta turbine and JDOM.


Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.