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

Title: NEW ISSUE: 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

   

Von: Barack, Ron [mailto:] 

Gesendet: Mittwoch, 16. Juli 2008 22:35
An: 

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

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

Von: Barack, Ron [mailto:] 

Gesendet: Mittwoch, 16. Juli 2008 22:20
An: 

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