JiBX: Hibernate for XML?
November 21, 2005
I'll admit, it isn't a perfect comparison, but there is no question that JiBX, one of the newer programs to enter the XML data binding space, certainly brings to the source code a lot of the same benefits as Hibernate. The fundamental similarity between these two frameworks is that they both allow you to develop classes following the common idiom of object-oriented design (POJO classes that use associations, inheritance, polymorphism, composition and collections). The mantra of the JiBX project is that data binding should be fast and data binding frameworks should allow for the divergence and evolution of the domain model from its XML storage mechanism. Sure sounds a lot like the O/R mapping portion of Hibernate, doesn't it?
Before I continue, I have to just get something off my chest. I loathe code generation! It just smells. In most cases it ends up bleeding all over your classpath with layers and layers of abstracted objects. XMLBeans is especially notorious for this problem. I want my day-eh-ta! Code generation often results in both code bloat and an overly complex data model for your application (thanks, in a large part, to the complexity of XML Schema). The application becomes tightly coupled with the XML schema and evidence of the domain model's XML heritage is propagated throughout all the layers of the application. In addition, you are forced to use the generated classes, which serve as no more than primitive information holders without any behavior. After beating my head against the screen trying to work around complications with using XMLBean generated classes inside of a JSF view, I finally hit the open road in search of a new data binding framework. It wasn't long before I came across JiBX, and I am now a true believer in mapped bindings for XML.
Mapped bindings (such as those implemented by JiBX) offer far more flexibility than code generation. You work with true object classes, which synthesize data and behavior. You can also decouple your object classes from the actual XML to a large extent. Modifying the mapping definition, rather than requiring changes in application code, often handles minor changes in the XML document structure. JiBX even supports the flattening of XML to conform to your data model, so a nested hierarchy in the document is not necessarily imposed on your domain structure.
When you need even more flexibility than the mapping behavior delivers out of the box, you can use either custom data converters for a single field or you can go so far as provide entire implementation classes to handle the marshalling and unmarshalling of the XML document. In the later case you are essentially providing a mapping implementation in Java rather than being confined to a fixed set of binding controls in the mapping file.
The best part about JiBX is that it opens the door for substitute persistent mechanisms down the road. For instance, if you are prototyping an application, or the requirements are narrow, you might decide that reading and writing data from an XML document is sufficient. However, if you do want to later move to an object-relational mapping framework such as JDO or Hibernate and begin persisting the data in a relational database, all that is necessary it to rewrite the mapping layer. The rest of the application should be ignorant to the fact that the method of saving and restoring data has changed.
While JiBX may be younger than some of the other data binding frameworks available, such as Castor and XMLBeans, it is decidedly complete. There is a plugin for Maven 2 and for Eclipse that makes configuring JiBX practically painless. With the growth of XML-based web services, dealing with XML data binding is becoming increasingly more crucial. The fact that JiBX is the most flexible AND the fastest framework on the web makes it a clear winner.