ISSUE 134: Integrating SDO and standard representations

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

Title: NEW ISSUE: Integrating SDO and standard representations

http://www.osoa.org/jira/browse/SDO-134

---

Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Mittwoch, 16. Juli 2008 22:20
An: sdo@lists.oasis-open.org
Betreff: [sdo] NEW ISSUE: Integrating SDO and standard representations

Hi,

As agreed on last Tuesday's call, I'm starting a new issue to discuss integration of SDO and standard reperesentations.  None the less, the starting point proposal is continues the discussion of ISSUE 130 (http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200807/msg00026.html).  However, I'm going to start calling the main operation "project" instead of "bind".  In my opinion, this fits better, and makes the relation with SDO-66 clear.  But I'm not at all fixed on these names.  If we want, we can always rename th

Problem:

We need to address item 1.d in our scope, namely: "Consolidation with data objects from standard frameworks, e.g. JAXB".  Particularly interesting in this regard are besides JAXB, normal POJOs, JPA, and DOM nodes.  An API should be define that defines how data is transfered between SDO and these standard frameworks.

Proposal: 

As mentioned in ISSUE 130, this functionality is very similar to the "project" functionality (SDO-66).  It is advantagous to handle the projection between contexts, and to and from the different data representations in a consistent manner.  None the less, the different data representations are not really isomorphic, especially when it comes to the available metadata.  SDO has of course a HelperContext.  As Frank mentioned in the meeting, it's easy to see POJO objects as being in a "virtual HelperContext", to consider java classes to be a source of metadata from which a self consistent set of types could be defined.  Not so with DOM nodes.  These are functionaly equivalent to an XML stream, impossible to interpret without additional metadata (typically an XSD).  Unfortunately, this inconsistency between the different representations results in asymetries in the API.

We start with the concept of a DataRepresentation.   A DataRepresentation symbolises the API through which the data values can be accessed.  As described, the important DataRepresentations, for now are DataObject, JavaBean, DOM, JAXB.  We also want this to be extensible, so that implementations can define their own.  A DataRepresentation is a generic class, with a parameter indicating the class of the objects used in the data representation.

What can SDO do with a DataRepresentation?  SDO can project data to from the data representation.  In order to do this, though, we need a "projector", what in ISSUE-130 we were calling a "binder".  The DataRepresentation is effectively a factory for "projectors".  So the API is:

public interface DataRepresentation<TO> {
        <FROM> Projector<FROM,TO> createProjector(DataRepresentation<FROM> fromRepresentation);
}

public interface Projector<FROM,TO> {
        TO project(FROM source);
        Projector<TO,FROM> reverse();
}
Note that in contrast to the Binder concept, Project has 2 generic arguments.  Where Binder was hardwired to load from the external format to DataObjects, Project can go from any DataRepresentation to any DataRepresentation.  I think of project as more or less corresponding to Binder.load().  We don't need save(), all we need is getReverse().project().  I'm not sure if we need update().  For now, I'm leaving it out.

As we said, DataObjects are an allowed data representation.  Namely,

public interface HelperContext extends DataRepresentation<DataObject>

So that helperContext1.createProjector(helperContext2)).project(dataObject).  Creates the same functionality as the project method currently defined in SDO-66.

So now the only question is where we get the other DataRepresentations.  Here is where the asymetries I talked about earlier come into play.  Because a POJO or a JAXB representation is a virtual HelperContext, that defines ist own (virtual) types, it makes sense to get it just like we get real HelperContexts.

public class HelperProvider {
        public abstract DataRepresentation<Object> getPojoRepresentation(ClassLoader classLoader, Class[] classes);
        public abstract DataRepresentation<Object> getJAXBRepresentation(JAXBContext ctx);
}

As was discussed in ISSUE-130, integration with JAXB does NOT involve analysing the JAXB annotations.  Data is transfered with JAXB using "bound" DOM models, and, if metadata needs to be generated from JAXB, then the JAXBContext.generateSchema method should be used to produce an XSD that can then be fed into SDO's XSD helper.

By contrast, DataRepresentation<Node> requires an already defined HelperContext, therefore, I would put the method on HelperContext

public interface HelperContext extends DataRepresentation<DataObject> {
      ...
        DataRepresentation<org.w3c.dom.Node> getDOMRepresentation();
}

This proposal is really just intended as a starting point for discussion.  I must say that I think email is a better forum to discuss such a complex API and how to simplify it, so please respond in this thread.

Best Regards,
Ron