Hi Folks,
Most of this thread is really more relevant to ISSUE 134,
and I'm going to re-title and continue the discussion of JaxbHelperContext
there. I want to bring the discussion in this thread back
to thhe discussion of annotations, specifically annotations that are
directed at "adjusting the schema representation", that is, that are XML
specific.
What EclipseLink's approach shows is that a very good
integration between SDO and JAXB is possible without using JAXB
annotations as a source of SDO metadata. I think the implication is that
if we define XML specific anotations, we run the risk not only of doing a lot of
unnecessary work, but also, when we're done, having something that (trys to)
competes with JAXB.
I'm assuming that there is general agreement that
annotations that relate directly to SDO metadata, mapping more or less 1:1 with
the properties of {SDO_URI}Type and {SDO_URI}Property do not fall into this
category. Things like URI and Name, and even the "containment" flag on
Property might determine what XMLHelper produces, but they are not XML specific
in the way that having an annotation that determines whether a property is
rendenderd as an element or attribute would be.
When it comes to adding XML specific information to our
annotation set, the following approaches have been
discussed.
1. No XML specific annotations. If the user
want to annotate something as a way of saying how he wants a Java class
serialized to XML, he should use JAXB.
(+) Avoids competition with
JAXB
(+) Consistent with the idea that SDO
should be data source independent
(-) Solution applies to POJO classes
only. Static SDOs can also be defined through
interfaces.
(-) Static SDO will not be suitible for
many use-cases.
(-) I think there will be pressure for
vendor extensions here.
2. Use @schemaLoc annotation
(+) Avoids competition with
JAXB
(+) XML specific information is held in
an XML-friendly format (an XSD).
(+) The complete XSD is availaible, not
the subset we would make available though annotations.
(-) Problems with maintaining 2
sources of metainformation, handling inconsistencies, finding the classes that
match a XSD, etc.
(-) Static SDO still not a complete
solution
3. Use a subset of JAXB annotations
(+) avoids definining new
annotations.
(+) more programmer
buy-in.
(-) We would effectively be
redefining JAXB annotations, this is an even more offensive "competition with
JAXB".
4. Define a simple annotation to handle this use
case, and promise not to go any further down "the slippery
slope".
(+) a large number of cases can be
covered with a few simple annotations.
(-) in the case of POJOs, we are
competing with JAXB.
I'd be interested in hearing what everyone thinks about
these options, or any other alternatives. From my perspective, I certainly
prefer the second option, though options 1 and 4 are also acceptable. I
think the third options is a bad choice.
Ron
Von: Barack, Ron
[mailto:ron.barack@sap.com]
Gesendet: Montag, 26. Januar 2009
23:45
An: Blaise Doughan
Cc:
sdo@lists.oasis-open.org
Betreff: AW: AW: [sdo] ISSUE 5 and ISSUE 22:
Discussion of JAXB
Hi Blaise,
comments inline
Hi Ron,
From our perspective JAXBHelper context is the POJO Helper
Context.
Since
you acknowledge that not all POJO models can be marshalled using JAXB, I don't
see how you can say that JAXBHelper is *the* POJOHelper. I think that a
JAXBHelperContext is perhaps one of several contexts that we might
specify...more on this later
Assuming the POJOs are also JPA entities, then wrapping
(as opposed to copying via an XML step) need not trigger all the lazy
relationships (of course this could be implementation dependent). With
regards to wrapping and the performance of getters/setters, there are some ways
to do this with reasonable performance.
But
this is a performance win, right? There's no functional
difference. It's not like you are relying on change in the DO being
immediately visible in the POJO. Consider your sample, in
you're implementation, you don't really need the call to unwrap. This
is a functional difference between the 2 approaches. A translation
would require a "translateBack". Is this an important difference to
you?
The POJO as a DataObject, this is an interesting
concept. One problem I see with this is that DataObjects do a lot of
relationship management that most POJOs don't do (i.e. adding a DataObject to a
new container automatically removes it from the old container). Here the
weaving is not invisible to the user and may not match the users
expecations.
It's
realy the POJO as static SDO. You would want to deliver a static SDO where
ther user thinks it is a java bean. Obviously, this is something
that users have to request.
The
XSDHelper.define() call is necessary, because as you have previously mentioned
XML schemas generated from POJOs do not contain all the information required by
SDO. One example is specifying datatype=false/containment=false
properties, that require SDO annotations on the XML schema.
We've
defined rules in SDO for how non-containment references
are represented in XML. In SDO 3.0 we've added keys, but I
would say the same applies to SDO 2.1, with the AnyURI representaion.
No JAXB marshaller generates anything like them. Are we ruling on
non-containment references from our PojoHelperContext?
What
does your implementation do where there is an inconsistency in the model in
respect to SDO metadata, for instance, when bidirectional properties are not
consistent?
Does DataObject customerDO = hc.wrap(customer);
always return the same
DataObject?
In our
implementation wrap always returns the same DataObject. This does require
some management, but with proper attention to object identity, and avoiding hard
references it is doable. Not sure how a "binder" solution avoids this as
something JAXB like would require a one-to-one correspondence between a POJO and
a DataObject.
Since the customer object doesn't have a reference to
customerDO, I guess you must somewhere have
a Map<Object,DataObject>. The problem I have, is who owns this map, and when to I purge
objects out of it. Moreover, the map can be very large, and I'm not
guarenteed reasonable hashCode or equals methods on the POJOs. A
Binder is mainly such a map. And by creating an API object that contains
this map, I put the maps lifecycle in the hands of the
programmer.
What happens if a wrapped POJO
is modified?
Our customer base is not interacting with both the POJO and the
DataObject at the same time. If they were you are correct that weaving
could be used to apply the changes made to the POJO back to the DataObject.
Then you would pretty much have the POJO as static
SDO solution, like we have
from JPA.
Is there any way to start with a DataObject,
and generate a JAXB from it?
Yes, this was the main reason for making the
entry point its own HelperContext. DataFactory.create() creates
DataObjects that wrap POJOs, and XMLHelper loads DataObjects that wrap
POJOs.
Usage
of StAX
The usage of StAX does not automatically create a Java SE 6
dependency. JAXB 2.0 based on Java SE 5 makes use of these APIs, it just
requires implementors to ship the StAX (JSR 173) API jar. I think SDO
should offer the same marshal/unmarshal options as JAXB. But the decision
to change the base Java SE version is independent from our inclusion of
StAX.
OK, we should either move to JSE 6 or have a similar clause
in our spec.
User Expectations of the XML
representation of POJOs
You are correct in your model that the user must
specify JAXB information to get the desired XML representation. This is
exactly the role of JAXB in the larger world of Java EE. Today users are
retrieving data from relational databases as POJOs using JPA, and exposing this
data through services as XML using JAXB.
Yes,
ours too. The process (at least from my perspective) could stand some
improvement. If you are seriously proposing JAXB as a POJO binding
for SDO, then it's a pretty limited POJO model. I won't even be about to
have non-containment relationships in my model unless I'm lucky enough to have a
suitible @XmlID field, and in any case, I will have to hardwire the the
containment structure of my domain as part of my code. In the POJO
representation of SDO, I wont be able to have multiple inheritence, even though
in SDO I have it. Why these limitations? We have use cases
that don't even involve a conversion to XML. In fact, that's one of the
main advantages of SDO, that it allows the different layers of my achitecture to
pass data between them without making web service calls. SDO is supposed
to be independent of the datasource. Having JAXB, something XML specific
as the POJO representation seems to make SDO much more XML
specific.
SDO competing
with JAXB
If SDO takes a POJO graph and has its own XML representation
then yes it is competing with JAXB. Regardless of the algorithm it is
impossible to guess the XML schema representation of a set of POJOs, as such
annotations are required fix it. With your proposal SDO annotations would
be required to adjust the XML Schema representation of a set of POJOs, again
this competes with JAXB.
Obviously I want to avoid duplicating JAXB, or compete with
it in any way. This is why the annotation proposal contained a
@schemaLoc annotation, and avoided any XML specific annotations. But
I really don't think defining SDO annotations means that we compete with JAXB,
at least not more than static SDOs already do. In a lot of SDO use
cases, there is no XML involved at all. Why would our POJO model be
something so XML specific?
Advantages of our
Approach
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