7C3EF93EEBC6EB4A8B4470853DE865665A2551@dewdfe18.wdf.sap.corp"
type="cite">
Hi Blaise,
Over the year, I've personally
become less convinced of the wrapping approach, as opposed to providing
some kind of optimized data transfer. What do you see as the advantage
of wrapping over some kind of convert operation? Instead of wrapping
the POJOs, I could mashal them in JAXB, and load them using XMLHelper.
Does wrapping give me something here I could not get through such a
mechanism (modulus performance)? And of course because of the second
point below, the getters and setters could become significantly more
expensive, offsetting the gains made in avoiding a conversion step.
There is a third approach, and
that is for the framework to weave the POJO classes, so that "new
Customer()", or at least ObjectFactory.createCustomer() returns an
object that already implements DataObject. It seems to me this is a
straightforward extension of JPAs approach. In our JPA integration,
you turn on this bytecode enhancement with a flag in persistence.xml.
Do you think it would be possible to get to this level of integration
with JAXB?
Either way, I have some
questions to the details:
Why is the call to
XSDHelper.define() necessary? Couldn't the metadata be introspected
from the POJOs (ala generateSchema())? Isn't there a danger of the XSD
being out of sync with the classes (similar to your comment regarding
the @schemaLoc annotation?
Does
DataObject customerDO = hc.wrap(customer); always
return the same DataObject? It's maybe a implementation detail,
but does wrap create the DataObjects lazilly or all at once? If you do
it lazilly, you need
to maintain a map from the POJO object to the DataObject wrapper,
right? Otherwise as we navigate around, we could wind up with the same
POJO having 2 DataObject wrappers. And such a map raises a bunch of
ugly lifecycle issues. This is where I thought something like a binder
could come come in handy, as a way of putting the lifecycle in the
hands of the client.
What happens if a wrapped POJO
is modified? Obviously, calls to DataObject.get() would see the
changes, but what about things like change tracking, containers, and
bi-directional properties, that, in SDO happen implicitly when a setter
is called? Are you "weaving" the byte code of the JAXB POJO?
Is there any way to start with a
DataObject, and generate a JAXB from it? Ie, can I unwrap something
that hasn't been wrapped? When I create a DataObject using
DataFactory.create(), does it automatically create an underlying POJO?
Regarding the StAX and JAXB
dependencies. I guess it will be 2010 before any SDO 3 implementations
are released as products... I imagine by that time pretty much
everyone will be on JSE 6. Maybe we should consider raising the
minimum compatible JSE to JSE 6. What do you think?
You
mention that customers have expections about the XML representation of
POJOs. What about POJOs that are not organized into a containment
structure? Eg, my example:
class School {
List<Student> getStudents() {...}
List<Course> getCourse() {...}
}
class Course {
School getSchool() {...}
List<Student>
getStudents() {...}
}
class Student {
School getSchool() {...}
List<Course> getCourses() {..}
}
what
do your customers expect from the XML representation of School? AFAIK,
the programmer has to specify the XML containment structure as part of
the model, He must annotate give the object ID properties, and he must
use @XmlID to indicate non-containment. I don't think SDO is competing
with JAXB if it specifies a mechanism through which such graphs can be
marshalled to XML. SDO 3 offers 2 such mechanisms: the graph could be
placed inside an container with orphan properties, and the containment
structure (or alternate structures) can be imposed on the model through
the project method. Offering this kind of fuctionality is one reason
to include an SDO-POJO binding in SDO 3.
Best
Regards,
Ron
Hi Ron,
I'm glad you raised this email thread. Integration with JAXB (POJOs)
is also an important use case to Oracle and in particular the
EclipseLink SDO implementation.
Both SDO and JAXB have an XML schema representation of their metadata.
For us this is the join point between these two technologies.
EclipseLink DataObjects are capable of wrapping POJOs, actions applied
to the DataObjects (set/unset/detach/etc.) are automatically applied to
the underlying POJO. I have included some code below to demonstrate:
// JAXB - Create the JAXB Context
JAXBContext jaxbContext =
JAXBContext.newInstance("com.example.customer");
// SDO - Create the JAXB aware HelperContext
HelperContext hc = new JAXBHelperConext(jaxbContext);
hc.getXSDHelper().define(customerXSD);
// SDO - Wrap the POJO in a DataObject
Customer customer = new Customer();
customer.setLastName("Doe");
DataObject customerDO = hc.wrap(customer);
// SDO - Create and modify DataObjects
customerDO.getString("last-name"); // returns "Doe"
customerDO.setString("first-name", "Jane");
DataObject addressDO customerDO.create("address");
addressDO.setString("street", "123 Any Street");
// SDO - Unwrap the POJOs
// Note: customer == hc.unwrap(customerDO)
Customer customer2 = (Customer) hc.unwrap(customerDO);
I would prefer to not invent a POJO to SDO binding. Our customers have
expectations about the XML representation of POJOs. As JAXB is
included in Java SE 6, I imagine many people share these expectations.
If Java objects save to XML one way, the act of wrapping them in (or
converting them to) DataObjects should not change the XML
representation. Of course if users choose to make use of concepts such
as ChangeSummary then the XML representation begins to diverge but in
predictable and explainable ways. For us it is imperative that SDO
provides a compatible value add to Java EE, and not become a competitor
to any of its technologies.
Other Points:
- I agree JAXB annotations do not contain enough metadata to
reproduce all SDO metadata. For example JAXB cannot represent the
property index of attribute properties.
- JAXB classes generated from XML schema can contain properties
that are different from SDO class generation. Especially wrt choices
and substitution groups.
- JAXB is primarily concerned with Java classes, while SDO is
concerned with Java interfaces.
- More load/save targets (such as StAX) would be great. Of
course StAX is not included with Java SE 5, and would introduce a new
dependency jar. JAXB has this same requirement and goes away with Java
SE 6, so this may not be a big concern.
- The JAXB Binder maintains a link between POJOs and DOM nodes.
Once linked you can make changes on one side and then make an explicit
call (it doesn't happen automatically) to apply the changes to the
other side. While useful the default JAXB algorithm isn't always what
users expect. Our implementation provides the user with the choice of
3 different "binding" algorithms.
-Blaise
Barack, Ron wrote:
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