7C3EF93EEBC6EB4A8B4470853DE86566564AD6@dewdfe18.wdf.sap.corp"
type="cite">
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