Home

Introduction

Xb4j, short for 'Xml Bindings for Java' is a library that supports making Java objects out of xml and visa versa, where Java objects describe a domain model and are the counter part of the domain entities described in xml.

Core concepts

Xb4j treats Java and Xml as equals and as independent. It does not assume one being derived from the other. Therefore, xb4j generates no Java classes from an xml schema and it generates no xml schema from Java classes. Xb4j requires that both are provided.

With xb4j, the Java developer writes a binding model in Java code, which describe how classes and class fields bind to the xml instances. These bindings can be used for both reading and writing xml. By writing multiple binding models, the developer can bind Java classes to multiple xml schemas or multiple Java classes to the same xml schema. This is the central problem that xb4j tries to solve.

Xb4j provides a limited level of validation of the xml: it requires that the developer describes all the xml elements that can or must occur in the xml in the order they may appear in the xml. An xml schema provides a good base for writing a binding model.

Xb4j does not want to impose restrictions and limitations on both the Java domain classes nor the xml schemas. Xb4j tries to solve this by providing rich binding functionality, E.g. bind xml elements or attributes to constructor parameters instead of demanding default constructors etc.

It is easy to envision tool support, E.g. via an IDE plugin, to visually support binding Java classes to xml, by reading an xml schema and the Java class path and provide a GUI to bind the two together, generating the binding model. Such tool support is currently no more than an idea for which time must be found.

Brief history

I started development of Xb4j in 2012. It is a spinoff product of an Enterprise Service Bus (ESB) that we were implementing at a Dutch semi government organisation which is active in the domain of work and income. The organisation enables exchanging information between different partners using SOAP messages. An XML dialect is agreed upon with all participating organisations and a set of rules around the exchange is put in place.

One set of those rules relates to meta data of the exchange. The meta data is put in a complex xml structure that is added as a custom SOAP header to each message. Over time, the meta data changed, and each change resulted in a new schema definition with a higher version number. The new version then is applied to new message definitions, but older messages still use the old meta data schemas. In 2012 the ESB needed to support around eight different versions of these meta data structures. We wanted to capture these in a set of Java classes and interfaces and let the ESB apply the rules on them, without needing to know which version it is dealing with.

The core requirement this imposes on the software that is converting XML to Java and vice versa, is that it must be capable of translating different xml schemas and namespaces to (partially) the same Java classes and interface implementations. After examening a number of open source frameworks, such as JAXB, Castor, JIBX, XStream and others, I could find no match. And so I created Xb4j.

Since then Xb4j handles the custom SOAP header of millions of SOAP messages in production per month without problems. Over time, Xb4j is used at more places within the organisation. E.g. when implementing web services where we wanted full control over the Java domain classes for various reasons. Every service resulted in expanding the capabilities of xb4j and the framework further matured. Most recent changes are adding nil-support as a result of processing cadastre data. The project is still at the state of "it works for me", but is slowly moving towards a more general purpose xml processing framework for Java.