Service Data Objects

One of the projects i'm involved in requires us to design and implement a generic "data container" such that any client could use it to store and retrieve data. Thats not all, if required, the data in the data container should be serializable in the form of either XML or some other defined format. In addition to that, the data container should be inter-operable, that is once serialized a different client (c++ or java) should be able to de-serialize it and use the data within. Pretty interesting stuff.

While performing my initial research for the design and implementation, i came across 2 strong technology contenders. JaxB and SDO. Ideally you cannot compare the two as they serve two different purposes. But i will explain why i used those names in the next section.

JaxB provides a very easy way to bind data to XML in a static manner. That is, the objects have to be generated before hand and included in the classpath. Once an XML document is received the JaxB api allows us to deal with objects rather than xml elements. However, we had to provide the client the flexibility to create objects dynamically - on the fly. Therefore, for dynamic object creation, there was no way we could have the classes ready before hand. Therefore static binding will not satisfy this flexibility requirement.

This is when i came across the Service Data Object spec. SDO's are built for this purpose - to contain data. And after more research, i found out that all SDO implementations (IBM, Apache and a few others ) are based on EMF (Eclipse Modelling Framework). EMF provides the facility for both static and dynamic binding. Therefore with SDO, a client could create an object on the fly, generate an XML out of it (no XSD required) and vice versa. Pretty cool.