XML for business rather than technology
As XML has become increasingly popular, more and more emphasis is put on usability. In other words, programmers and managers want to treat XML less as a technology, with all its own semantics and lexical constructs, and more like pure data, accessed without having to worry much about the specifics of the XML data format.
Arguably the easiest way to achieve this move from using XML as a technology to a business format is data binding. Data binding is when the data in an XML document is manipulated using an Application Programming Interface (API) that doesn't force the programmer to know much about XML, work with angle brackets, or think about things like CDATA sections or entity references. But even when it comes to data binding, you'll find lots of options, and plenty of important issues to think closely about before you charge ahead.
For the purposes of this discussion, I'll take on two basic issues related to data binding:
- The way that data is represented through the data binding API.
- The usage of the data once its treated as business data.
In the most generic case, data binding means that the data in an XML document is turned into an object in the programming language being used.
Object-based APIs for data binding
For example, take the following XML fragment:
<person> <firstName>Brett</firstName> <lastName>McLaughlin</lastName> <email>brett@newInstance.com</email> </person> |
You might turn this into an object, say in Java™ code, that is an instance of a Person class, with member variables firstName, lastName, and email. The instance would be filled with the data from the fragment, and you could access that data with method calls like myPerson.getFirstName().
Document-based APIs for data binding
While that's the most common approach to data binding, APIs that take an XML document and represent the entire document as an object are also a form of data binding. These APIs include the Document Object Model (DOM), JDOM, and dom4j, all of which create an object model of an XML document in Java coding.
In these models, you'd make calls like rootElement.getChild("firstName").getValue() (or something similar, depending on the specifics of the API). While this does require some basic knowledge of XML -- understanding what an element is and the basic structure of the document -- it still abstracts details about parsing from the programmer. That's the essence of data binding: being able to worry about the data more than the format that presents the data.
Easier for the programmer (sort of)
Once you move to a more common data binding solution, like Sun's JAXB, you have even less underlying XML syntax to worry about. You really can work entirely with Java (or your favorite programming language) objects and methods and variables. Even details about elements and the structure of the document become hidden in the objects created by the data binding process.
The key here, though -- and what is often not thought about -- is that you still have to either match your XML data structure to objects in your system, or create objects in your system that match the format of XML data that you work with. In both cases, the mapping to XML is a little less obvious, but it's still a part of the process.
I outline two basic approaches here, but both are not as different as they might first seem. When you use an API like DOM or JDOM, you work with the structure of the document continuously, both when you load the XML and when you access that data. In the second approach, when you use an API like JAXB, you work with the XML a little more extensively up front, modeling your objects (or sometimes you let a tool create the necessary classes and objects for you) to work with the XML. Then, at runtime, you work more with the data as business data, and can forget about the XML.
The first approach is great if your XML isn't in a very readable format, or if it's broken up differently than you might want to break it up for business purposes, or if the format might change from time to time. It's an approach that requires a bit more XML knowledge, and the ability to work with an API that is more technology-centric that business-centric.
On the other hand, if your XML is organized along the same lines as your business needs, and that XML structure rarely changes, then you can go through the one-time process of creating your classes and objects, and then work with your data at runtime as business data, without worrying much at all about the XML that underlies that data.
Many times, developers give little consideration to how they use the data from an XML document in terms of which data binding solution to chose. However, this turns out to be probably the single most important factor in making a good decision about your data binding approach.
Use objects for long-lasting data
The data binding approach that turns your XML data into object instances is really only appropriate for data that you will use more than one time... and potentially for ten or fifteen times. A lot of processing is involved to take the data in an XML document and convert it into member variable data in multiple objects. To really get an advantage from this approach, you need to use that data more than just once.
Take a close look at the number of times that you access a piece of data, but also consider how much of the data you use. If, for example, you store 20 pieces of data about each person in your XML, but only access one piece of data in your application, you've put a lot of resources into converting data so that you can access only one piece of that data. That's not a winning equation, no matter how you calculate it.
Use objects to mask XML from other components
Another good reason to use an object-based approach is when you want to hide your storage medium. So you might have a component in your application that does some particular processing of Person objects. You might read in people from a database, from an XML document, and from properties files, convert the data into Person objects, and then pass those objects into your processing component.
Even if you use the data only briefly, this is still a situation where using objects to represent your data makes a lot of sense. In this case, you get value if you represent your data in an object format that other parts of your application already know how to work with. You also avoid data conversion and loading for a component that really you just want to work with a certain type of object. That's a good segregation of concerns in your application, which is an important design principle to follow (you want each component in your application to do one thing and only one thing, and to do that one thing well).
If you don't have data that will be reused, and you don't pass that data in the form of an object to another component in your application, then you might consider an API like DOM or JDOM. You'll incur less resource consumption than if you convert XML into a non-document format, so you'll get an overall win. This is a much better idea than paying a high cost to convert data into business-specific objects, and then use that data only one or two times.
Even though this is an article on data binding, it's worth mentioning that in these cases, you might even want to consider an API like SAX, the Simple API for XML, which doesn't provide an object model at all (in the format of a document or objects). You'll use very little memory or time to process the XML, and if you really do only use a piece of data once or twice, you'll get huge benefits from this approach. You'll have to know a good bit about XML to use an API like SAX, but it's a valuable bit of knowledge to have.
This XML and Java technology series doesn't present solutions to problems, but hopes to make you think about how you use a particular technology and API -- in this case, XML and data binding. You might agree with some of these points, and disagree with others, but you should definitely think more deeply about how you use XML in your own applications.
This is meant to be a leaping off point as much as anything. You're encouraged to hop on over to the XML and Java technology forum, where these discussions will continue in a more interactive format. How do you use data binding, what APIs are your favorites, and have you come up with any creative uses of data binding technology in your applications? Let me know...I look forward to seeing you soon online soon.
- Participate in the discussion forum.
-
XML and Java technology forum: How do you use data binding? Share your thoughts and ideas with Brett McLaughlin on this XML and Java technology forum.

Brett McLaughlin has worked in computers since the Logo days. (Remember the little triangle?) In recent years, he's become one of the most well-known authors and programmers in the Java and XML communities. He's worked for Nextel Communications, implementing complex enterprise systems; at Lutris Technologies, actually writing application servers; and most recently at O'Reilly Media, Inc., where he continues to write and edit books that matter. Brett's upcoming book, Head Rush Ajax, brings the award-winning and innovative Head First approach to Ajax. His last book, Java 1.5 Tiger: A Developer's Notebook, was the first book available on the newest version of Java technology. And his classic Java and XML remains one of the definitive works on using XML technologies in the Java language.





