Sunday, December 17, 2006

Java XML Data Binding

I don't recall the last time I used DOM or SAX to process XML documents. Things have evolved and processing XML seems more and more an unnecessary low-level work. And that's because of the superior XML Data Binding. XML Data Binding is all about mapping objects to XML, and back again. It's not document-centric, but data-centric. After all, isn't XML a way of representing data ? The data is what matters. For example, if I have the following XML:


<customer>
<code>128682</code>
<name>Mr. Smith</name>
</customer>

I don't want to mess around with DOM objects or SAX events if I just need to get the data into Java objects. I just want to pass the XML to some method and get a Java Bean named Customer with properties code and name (of course the real advantage it's when the XML is a lot more complex). That's what XML Data Binding frameworks are for. And there's plenty of them. They typically work by generating classes from some provided XML Schema. You'll normally get the Java Beans that hold the data and a few classes responsible for the marshalling/unmarshalling of XML.

I tried a few when developing Axis2 web services. Axis2 supports several data binding frameworks and also provides its own implementation: ADB. For what I've seen of ADB I don't like it much. By default it generates Java Beans with strange looking code filled with inner classes. And although it claims that it can generate plain POJOs, I couldn't get them to work well.
There's also XMLBeans, which is known to be the most comprehensive out there. But it also generates a lot of classes and a lot of code.
A third, and in my opinion a better choice, is JibX. With JibX you can do things a little differently. Instead of letting JibX generate the Java Beans, I prefer to create them myself and then configure a short XML mapping file (in the simplest case, just to tell which class is the root element). JibX then generates only 2-3 classes responsible for mapping the XML to the Java Beans. This way my Java Beans stay clean and I have much less generated code.

But there are even more alternatives. I've used XStream several times and it's great. It doesn't generate any code, it's all done in runtime. It's similar to JibX : you also have to provide the Java Beans and some mapping configuration, but instead of generating code to handle the XML, it does everything in runtime. You could argue that XStream is better that JibX, but actually XStream also has some disadvantages: doesn't support XML namespaces, which is essential for web services development. I've used it in other situations, when I don't need XML namespaces.

I should also mention JAXB, Sun's official specification for XML Data Binding (JAXB is only a specification, but there's at least two implementations: JAXB RI and JaxME), but I still haven't tried it.

2 comentários:

Anonymous said...

Actually XStream has namespace support, but currently only with its StaxDriver.

Carlos said...

Thanks, I'll look into that