Skip to main content

XML and Java technology: Data binding in 1,000 varieties

What data are you binding, and how are you using it?

Brett D. McLaughlin, Sr., Author and Editor, O'Reilly Media, Inc.
Photo of Brett McLaughlin
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.

Summary:  Beyond using XML as a simple data format, data binding is one of the most popular uses of XML. It allows even beginner programmers to work with XML in a native programming language, and in many cases doesn't require any XML expertise at all. This article doesn't present a solution, instead Brett introduces some discussion topics to start you thinking about how you use XML and data binding. You're encouraged to share your thoughts with others on the XML and Java technology discussion forum.

Date:  13 Mar 2007
Level:  Intermediate
Activity:  2037 views
Comments:  

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:

  1. The way that data is represented through the data binding API.
  2. The usage of the data once its treated as business data.

Representing XML 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.

So which is it?

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.


How are you using your 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).

Short-term, one-use data

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.


In conclusion

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.


Resources

About the author

Photo of Brett McLaughlin

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.

Comments



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=XML, Java technology
ArticleID=201809
ArticleTitle=XML and Java technology: Data binding in 1,000 varieties
publish-date=03132007
author1-email=brett@newInstance.com
author1-email-cc=dwxed@us.ibm.com

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers