AW: [sdo] ISSUE 134: Integrating SDO and standard representations

Subject: AW: [sdo] ISSUE 134: Integrating SDO and standard representations

Hi Everyone,

I wanted to write up some use-cases for comparing the Binder and Projector APIs, but I think that there is a more fundamental issue that must be addressed first: should we allow vendors to implement integration with POJOs and other standard data representations by creating DataObjects that are simply wrappers for the POJOs, that use the POJOs as the underlying data representation? It’s something that needs to be considered quite seriously, because in some ways it violates SDO’s model of detached data access (in this case, the POJOs are the back-end store, from which we should be detached). On the other hand, when dealing with large POJO models, using DataObjects as wrappers may provide efficient performance when the cost of using SDO would otherwise be prohibitive.

I see the use cases for this integration mainly in terms of making calls to SOA-like services. This does not necessarily imply some kind of SCA-like framework as an infrastructure. Rather, it means we have rather loosely coupled software modules that make service calls to other modules, with little or no sharing of data between the components. Data is passed as method arguments and results, but not used as common storage. The use-case I see is that there is a lot of existing code, and code that is currently being developed, upon which we cannot impose an SDO programming model, we can’t make all applications “SDO-aware”. If we could, then static SDOs would be a sufficient solution. But the different modules will always be loosely coupled, with structured calls between them. If we agree that there is some structure between the modules that are SDO aware and the modules that use other representations, then we have a chance of defining reasonable rules for accessing data, and the user has a reasonable chance of following these rules. Without such rules, there is no way to get any sort of defined behavior without detaching the external representation from the DataObject representations, that is, without a copy step.

There are two dangers to allowing unrestricted access to both the DataObject and the underlying POJO object.

The change summary could miss the change. Note that this depends on how the change summary is actually implemented. If change tracking is implemented using some kind of property change listener then clearly we will miss the change if the POJO is accessed directly. On the other hand, if some kind of snapshot is used, if we make a copy of the data at the time change logging was enabled, and use this as the basis of the change summary, then the change summary could be created even if the user has accessed the POJO objects directly.

The DataObject infrastructure will be unable to track changes in containment or to manage “opposite” properties. That is, if “child” is a containment relationship, calling parent.setChild(child) on the POJO object will not set childDataObject.getContainer().

Note that both these dangers are themselves use-case driven. Change Summaries are not necessarily relevant for the SDO as data representation for SOA use-case.

The question I would like to put forward to the group is whether or not it is an acceptable restriction to say (in terms of the binder API) that the user should not access the POJO objects after a call to Binder.load() and before the call to Binder.save().

Best Regards,

Ron

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

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.

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.

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.

sdo message