Re: ISSUE 130: New DataObject method: cast()

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

Hi Frank,

As you point out, for the case of getSequence() there is no loss of functionality here.  Not so wrt casting between DataObject and a static SDO. In this case, we would be taking a functionality that allows "conversion" in both directions with a functionality that allows "conversion" in only one direction.  I don't think we should consider a resolution of the issue that leaves SDO 3.0 weaker than SDO 2.1, and then hope that the missing functionality is added back in through the resolution of a seperate issue.

One of the selling points of SDO is that clients can use the (type safe, business logic oriented) static SDO to make changes, and then send the modified data, complete with change summary back to the server.  The server can then use the ChangeSummary, rich metadata model, XML serialization and other functionality provided by the SDO infrastructure.  In order to make this work in any sort of reasonable way, we need to maintain the association between the static SDOs and the corresponding DataObjects so that identity is maintained.  When we return the DataObject that corresponds to a particular POJO, we must always return the same DataObject.  (Note here the correspondence with the behavior when projecting between contexts...this supports the ideas that I will be proposing later in this email.)  In SDO 2.1, association between the static SDO and the DataObject is maintained because the instance implements both.  Potentially, we could weaken this to requiring that the association be maintained through references (that is, that the POJO could have a reference to the corresponding DataObject).  This doesn't help us when dealing with POJOs that are not "SDO-ready", that is, that are simple JavaBean data containers that are neither castable nor contain references to DataObject.  In this case, the association must be maintained externally.  The only way I can think of doing this is to have some sort of (weak) map from the POJO to the DataObject.  Of course, maintaining such a map introduces its own set of problems and costs, made more critical because the conversion between POJO and DataObject is probably something we want to do lazilly.  Clients that are in the position to work with static SDO should continue to work just as efficiently as before. Therefore, I wouldn't want to see the new functionality, the ability to move between POJO (and potentially also DOM) data representations and DataObjects, as a replacement for static SDO.  We are talking about a new functionality here:  converting from a POJO (or other) data representation to DataObject and back.

The most obvious API for converting from a POJO object to an SDO is to reuse the project method from SDO-66.  That is, to change the signature from project(commonj.sdo.DataObject) to project(java.lang.Object).  The behavior is simply to consider the POJO object as if it were a static SDO.  This is the key idea behind everything I will propose here.  Of course, to make this work we need something like what I proposed in SDO-5, a way to introspect the classes and generate an SDO metamodel.  If we have that, then we can consider every POJO object a potential SDO.  That is, the POJO behaves exactly like the DataObject for which it could be the static representation.
 
If we are going to consider the POJOs "potential" DataObjects, then I think it follows to consider them to be defined in some HelperContext.  If there is a HelperContext that manages the POJOs the way that normal HelperContexts manage DataObjects, then to get from a DataObject to a POJO is simply a matter of projecting from the DataObject into the POJO context.

I think the approach could be just as extensible as the proposed cast method.  For instance, we could have a DOM context.  Projecting into this context returns a Node.

The approach also give the user the chance to control the POJO -> DataObject map, in that he can control the HelperContext that maintains it.  In a way, the helperContext works like the JaxB Binder.

Users could obtain a POJO helper context from the HelperProvider.  Something like:  HelperProvider.getPojoContext(ClassLoader).  The user could then define types in this context using the API proposed in SDO-5.  Alternatively, we could be a bit more JAX-B like, and have HelperProvider.getPojoContext(Class ...) or HelperProvider.getPojoContext(Package).

What about the behavior of the Helpers within the HelperContext?  Logically, the behavior of CopyHelper, EqualityHelper, even XMLHelper are all clear from the concept stated above, the POJOs behave just like static SDOs.  The APIs, however, don't match... Everywhere where commonj.sdo.DataObject appears the API becomes unusable.  Here is a place where Generics could be used.  We could make all our Helpers generic, eg,

	XMLHelper<T> {
          ...
          String save(T dataObject, String uri, String localName);
          ...
      }

We would then have

      HelperProvider {
          HelperContext<DataObject> getDefaultContext();
          HelperContext<Object> getPojoContext();
          <T> HelperContext<T> getOtherContext(Class<T> t);  // Probably Node
          ...
      }

I think this approach has a lot of potential.  It would be pretty neat to be able to e.g. serialize POJOs to XML using the SDO rules (including orphan properties, etc).  Normally, I have a working prototype before I make a proposal like this.  In this case, I'd like to get a little feedback from the group first.  We don't have to go all the way to accepting the API changes to make this all work, in fact, I'd rather leave the API changes to a general refactoring of the API (for which we have an entire scope item).

What do you think?

Ron

    

-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Freitag, 13. Juni 2008 20:43
An: sdo@lists.oasis-open.org
Betreff: [sdo] Re: ISSUE 130: New DataObject method: cast()

Hi Ron,

Sorry I didn't provide the problem statement. This is what I had in mind:

<BEGIN DESCRIPTION>

An SDO Data Object is a data structure composed of named properties. The 
DataObject interface provides the primary standard Dynamic API for reading 
and manipulating the underlying data structure. However, a number of other 
interfaces provide alternate "views" of the same data structure:

1) Sequence.class - if the object's type isSequenced
2) a custom Java interface (e.g., Company.class) - if the type is static 
SDO

Another possible view of a data object (currently 
implementation-dependent, but a possible future addition to the spec) 
would be a DOM view:

3) Node.class - if one wants to provide a 100% XML fidelity view of the 
underlying XML structure using an XML standard API

The current approach for accessing alternate views is using specific APIs 
for each view:

1) DataObject.getSequence() to get the Sequence view
2) Java cast - e.g., (Company)myDO - for a static SDO view
3) If we want to get a Node view, then we'll need to add some new API for 
that - e.g., XMLHelper.getNode(myDO)

This proposal suggests to instead provide a single uniform API for 
accessing any alternate view. This will have the advantage of simplicity 
(1 method for all) as well as extensibility for future supported (or even 
implementation dependent) views.

<END DESCRIPTION>

Now, to answer your questions (from below) Ron:

1) I'm not sure if we need to cast back from every possible view - if so, 
then we may want to add one or more APIs for that as well, but I think 
it's a separate issue. Note that Sequence currently doesn't provide a 
method to get back to the DataObject view - i.e., there is no 
Sequence.getDataObject() method.

2) I'm just saying this will "probably" be useful when we want to 
integrate with JAXB/JPA. It opens up the possibility of implementations 
supporting static using DataObject proxies, or similar, instead of 
byte-code insertion or specialized code generation to make sure that 
everything is done in a single instance.

3) JAXB is a static solution. If we want Dynamic SDO with 100% XML 
fidelity, we need something like Node. Note that I said "something like" - 
I'm open to other suggestions, but I think that since Node is "the 
standard XML API", we should consider using it.

I hope this helps to clarify things.

Thanks,
Frank.




"Barack, Ron" <ron.barack@sap.com> 
06/12/2008 09:36 AM

To
Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
cc

Subject
ISSUE 130: New DataObject method: cast()






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

Hi Frank,

I had a little trouble entering this into the JIRA:  you make a proposal 
without stating what problem you would like to solve.  Casting to Node 
isn't part of the proposal, so XMLFidelity isn't addressed, so what is the 
problem we are trying to solve?  From your text I have extrapolated the 
following DESCRIPTION:

Under SDO 2.1, clients obtain a reference to the static SDO by casting the 
DataObject, that is, the static SDO must be the same instance as the 
DataObject.  This will be a problem when we do JPA/ JAXB integration.

Is this correct?

Now for some questions:

1) don't we need a symetric operation, one that allows you to go from the 
static SDO back to the DataObject (casting always worked in both 
directions)?

2) what is your justification is for the last assertion, that we need this 
for JPA/ JAXB integration?

3) Regarding casting to Node...Assuming we get JAXB integration to work 
(by the way, I think JAXB integration is much harder than JPA), doesn't 
that give us all the XMLFidelity we need?  Which technology should we 
focus on integrating?



Best Regards,
Ron

-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Donnerstag, 12. Juni 2008 00:06
An: sdo@lists.oasis-open.org
Betreff: [sdo] [NEW ISSUE] New DataObject method: cast()

Hi Guys,

I would like to propose adding the following method to the DataObject 
interface:

    <T> T cast(Class<T> targetClass)

I'm not sure if the name should really be "cast" or "project" or something 

else, but I'm thinking "cast" may be best, since the intent is to get some 

other interface to work with and view the DataObject.

An implementation of this method will look something like this:

    public <T> T cast(Class<T> targetClass)
    { 
        if (targetClass.isInstance(this)) return (T)this;
        if (targetClass == Sequence.class && getType().isSequenced() 
return getSequence();
        // TBD other required or optional casts (e.g., maybe Node.class)
        // TBD implementation specific casts
        return null; //TBD maybe instead we should throw 
ClassCastException
    }

The idea behind this method is that it provides a single API for 
converting a DataObject to any other possible interface "view".

To get the Sequence view of a DataObject, a user would call:

    Sequence sequence = myDO.cast(Sequence.class);

To get the interface of a static SDO, you would call:

    Company company = myDO.cast(Company.class);

Using this API instead of simply using Java cast - (Company)myDO - has the 

advantage that we've opened up the door for different implementations of 
static SDO (e.g., a corresponding POJO) in the future where the static 
object and the DataObject are not required to be the same instance. This 
will be important when we get to the JAXB/JPA integration discussions.

Once this API is in place, we can think about other (required or optional) 

uses for it, such as using it to cast to Node.class (or something else) as 

a catch all for the XML Fidelity corner cases that we don't want to handle 

in SDO directly.

If we agree to add this new method, I think we should also deprecate 
getSequence(), which will have the added benefit of this issue not 
actually increasing the number of methods in the DataObject interface.

Thanks,
Frank.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in 
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php