ISSUE 5 and ISSUE 22: Discussion of JAXB

["Barack, Ron" <ron.barack@sap.com>]

Title: ISSUE 5 and ISSUE 22: Discussion of JAXB

Hi Everyone,

The idea of using JAXB annotations as a solution to ISSUE 22, even of consolidating static SDO and JAXB, has come up repeatedly in the calls.  I think we may be able to make better progress in this regard by discussing the ideas per email, so that there is a permament record of the arguments.  Having this discussion now will hopefully make the discussion during the F2F more productive.

First I want to say that integration with JAXB is a high priority issue for us, but this integration may take several forms:

1.  Transfering data between the representations
2.  JAXB annotations as a source of SDO metadata
3.  JAXB classes as static SDOs

Of course, it is desireable to have as deep and integration as possible.  When I first started thinking about the problem, I set out to achieve all three types of integration.  After long consideration, I arrived at the conclusion that only the first is really possible.

About the first point I hope there is general agreement: Applications that use SDO as a data representation must be able to transfer data with applications that use JAXB. In some ways, this is already possible in 2.1:  all you need to do is mashall to XML. This approach introduces some performance costs, and I think we should address steamlining the process in SDO 3.  One approach that we've found to be very helpful is for SDO to be able to produce an XMLStreamReader which in turn can be fed into a JAXB marshaller.  For maintaining an active map between the representations, I believe a DOMBinder is a very promising approach, and possibly we could go a step further and have a JAXB binder.  (Unfortunately, I believe the JSE implementation of JAXB still has an incomplete version of the DOMBinder functionality).

Similarly, clients can already use JAXB annotations as a source of SDO metadata under SDO 2.1, at least whereever JAXBContext.generateSchema works it is possible to use XSD as an intermediate metadata format. However, it is important to realize that JAXB does not provide the level of details we expect to see in a resolution to ISSUE 22.  JAXB annotations capture exactly the information necessary to correctly marshal and unmarshal to XML.  Restrictions (facets), and all reference to the original simple type is lost.  JAXB creates String properties for xs:NCName, xs:AnyURI, etc., and there is no way to get back to the original type through reflection on the JAXB object.

JAXB objects reflect the purpose of JAXB, which is to create an XML binding for Java.  XML models, and therefore JAXB, do not contain (as a rule) bi-directional or non-containment references.  It's true that XML and JAX can represent non-containment relationships using @XmlID, but in SDO non-containment relationships are not limited to objects that have ID properties (or even keys).

If we were to use JAXB annotations as the standard way to represent SDO metadata in Java, then we are also accepting the default behaviour associated with the *absence* of these annotations.  In JAXB, an unannotated POJO class that references a second POJO class is intepreted as there being a containment relationship between the associated types.  I would argue that this should not be the default behaviour for SDO.  If it were, then we loose the ability to to take an arbitrary model based on unannotated classes, pack them in a DataGraph (or anything else that has an orphan property) and being able to generate XML for the model.  The assumption of containment relationships means that we will get cycles and other problems, making the whole approach unworkable.

A further problem is that I think we would probably be misusing the JAXB annotations.  Static SDOs may be interfaces or generated classes.  JAXBs are annotated POJOs (JavaBeans).

Finally, very pragmatically, the JAXB spec is large and complex.  Expecting implementations to make sense of the annotations and their many combinations is a very high bar indeed, even more so when we expect to enrich the annotation set with some of our own annotations.

Having rejected the second point, perhaps the discussion of the third point is moot, but I want to discuss it because the appeal of the approach is so strong.  The appeal can be summarized as follows:  "The JSE already defines a standard XML to Java binding.  By defining static SDOs, we are defining a competive functionality that is therefore doomed to be rejected by the java community.  The problem with this argument is that static SDOs do not represent an XSD, they represent SDO metadata.  Although a large part of the SDO spec contains the mapping between the metamodels, the models are not the same, not is the SDO metamodel a subset of the XSD metamodel (multiple inheritence, bi-directional relationships being two examples of constructs that do not exist in XSD).

On a more practical level, although for very simple XSDs the classes generated by JAXB and the static SDOs defined in SDO 2.1 are compatible, we very quickly come to places where the models diverge.  SDO represents choices as several parallel properties, and we expect the user to fill one or the other.  JAXB generates a sort of combined property (using the pattern "getAorB"), and the user must create an JAXBElement and use this value to set the property.  It would be very odd to have this structure reflected in the static SDO when it is missing from the SDO metamodel.  In cases such as those where we create a sequenced DataObject, JAXB creates an class with a single getContent() method.  Static SDOs, like SDO itself, maintains in such cases a property oriented view of the data in addition to the sequenced view.

I hope this gets the discussion going so that we can decide what sort of integration with JAXB we are aiming for, whether or not we we need to define our own annotations, etc.  Blaise, as a member of the JAXB EG, I'm particularly interested in your comments.

Best Regards,
Ron