sdo message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [sdo] ISSUE 130: New DataObject method: cast()
- From: "Barack, Ron" <ron.barack@sap.com>
- To: "Bryan Aupperle" <aupperle@us.ibm.com>, <sdo@lists.oasis-open.org>
- Date: Mon, 7 Jul 2008 21:17:44 +0200
Hi Bryan,
This seems to suggest another possibility for the API for
translating between SDO and POJO or DOM objects: we could define a
Pojo or Dom helper with a similar set of functions. We now have 3, the
project method as proposed by Frank, HelperContext<Object>, and
PojoHelperContext. Before talking about the API, we should maybe first
focus on the semantics...
I have some questions. The signature of the
doLoadData method suggests that the client is the one to create the target data
object... is the implication that the buffer contains a single data
object? Also, the signature of doExtractToSturct suggests that the user
knows exactly how much buffer space to allocate, another indication that only
relatively simple data objects can be used, is that correct?
Also, from the implementation: is this functionality
build over the public SDO API, or did you need to use internal functions,
special to your SDO implementation?
Ron
We confronted the topic of
converting between native structures and SDOs in our work for C and COBOL
(recognizing that this would be essential to allowing existing code to be
extended to take advantage of SDO functionality). The approach we took was
to define load and extract APIs. Here is the set for C:
void doLoadData(DATAOBJECT pdo,
void *buffer);
Basic load
– Useful for the initial loading of a data object after existing code has filled
a language structure.
void
doLoadCompare(DATAOBJECT pdo, void *buffer);
Load and compare – Useful after an extract where
the contents of the language structure may have been changed. This allows
the change summary to be maintained.
void *doExtractData(DATAOBJECT pdo);
Extract to newly allocated memory – The data
factory owns the memory and is responsible for releasing it
void doExtractToStruct(DATAOBJECT pdo, void
*buffer);
Extract to
provided memory – The client code owns the memory. This may work well when
the language structure contains no pointers.
I realize the functionality is a bit more primitive than
what is being proposed here as part of project (and that Java does not have to
deal with issues like who owns memory), but the thought process may be helpful.
You have code that is SDO aware and code that is not. Explicit APIs
are used to convert between the domains and one does not try to cross apply any
of the concepts.
Note the
doLoadCompare() API is particularly important since any changes made by the
non-SDO aware code would otherwise be lost. These API's have to be used
with care - i.e. the language structure and the SDO have to be compatible.
While we did not explicitly add these to DataHelper (not particularly
important to do so in C) , that would be the logical place for them.
Bryan Aupperle, Ph.D.
STSM, WebSphere
Enterprise Platform Software Solution Architect
Research Triangle Park,
NC
+1 919-254-7508 (T/L 444-7508)
Internet Address:
aupperle@us.ibm.com
"Barack, Ron"
<ron.barack@sap.com>
07/04/2008 04:54 AM
|
To
| "Frank Budinsky"
<frankb@ca.ibm.com>, <sdo@lists.oasis-open.org>
|
cc
|
|
Subject
| AW: [sdo] Re: ISSUE 130: New
DataObject method: cast() |
|
Hi Frank,
We agree on the main point, which is that projection
should be possible in both directions. Do you also agree to the semantics,
that calling
helperContext.project(pojo) always returns the same DataObject,
and that calling (in your API) dataObject.project(Pojo.class) always returns the
same object? That is, whatever the API, in this sense projecting to and
from the POJO world works just like projecting between SDO
contexts?
Putting all POJOs in a virtual HelperContext gives you two
things:
1. It allows you to determine the rules of the projection.
For instance, we could have a JaxBHelperContext that projects to JaxB
using a different algorithm than is normally used to project to POJOs.
(Note: JaxB classes are not necessarily annotated).
2.
It gives you a place to manage the mapping between POJOs and DataObjects.
Otherwise, the only way I can think of managing the association is by
using weak hash maps. Maybe there's nothing wrong with managing such an
association through weak hash maps...that's what hash maps were invented for.
But it seems like a poor design to me.
Maybe we should start
talking use-cases. As usual, I'm thinking about local wires in an SCA
composite. I'm thinking about a SOA landscape where some components are
written in Java and use POJO data objects, there is some kind of XML based
process engine (say BPEL), and some components are written using SDO data
objects. Maybe there are some components that are also DOM based.
Anyway, we don't want to say that in order to attach your application into
the landscape you have to write it so that it uses static SDOs. This would
mean that every "new" has to be replaces with a
DataFactory.create().
We've established HelperContext.project as the way
to move data between two SDO based applications. That is, each application
has ist own HelperContext, and we project the data representation from one to
the other. The question is, why should it be different when an application
uses POJOs? By having POJO helper contexts I can say that each application
has it's own HelperContext. Even the POJO application has a HelperContext,
just a HelperContext<Object> instead of a HelperContext<DataObject>.
But the way to move data between them is consistent, through
HelperContext.project.
Plus the idea of taking a POJO and calling
HelperProvider.getPojoContext().getXMLHelper().save(pojo) is just really cool.
;-)
Best Regards,
Ron
-----Ursprüngliche
Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet:
Donnerstag, 3. Juli 2008 23:58
An: sdo@lists.oasis-open.org
Betreff: Re:
[sdo] Re: ISSUE 130: New DataObject method: cast()
Hi Ron,
Thanks
for your reply ... some interesting ideas.
As you may have guessed, I'm
very much in favor of changing the argument
of HelperContext.project() to
Object and using it as the API to convert
from POJO to
DataObject.
I'm not so sure, however, about using HelperContext.project()
as the API
to go from DataObject to POJO. I've given it quite a bit of
thought and I
can't convince myself that it's the right way to handle this.
In my mind,
it seems too complex to try to think of every Java Object as
being in an
SDO context. It seems simpler to me to think of a POJO as being
in "no
context", but by using HelperContext.project(), you can "bring it
into a
context" and then work with it as a DataObject.
Your generic
POJO HelperContext, below, helps to highlight what I mean:
HelperContext<Object> getPojoContext();
As you've
realized, the only class that can be used for the generic
HelperContext
argument is java.lang.Object, since it's the only base class
for any
arbitrary POJO class (e.g., Company, Employee, Department, etc.).
Given
this, it seems quite odd to think that any java class is
conceptually in the
"Object" context - for example, java.lang.Integer
would fall into this
category. Given that the generic POJO context is
really only capable of
working with "proper SDO-capable objects", the
various SDO helper methods,
e.g., XMLHelper.save(), CopyHelper.copy(),
would need to fail, if the Object
passed in isn't really an SDO-capable
object. If instead, we said that POJOs
are in no context, but you can
project() them into a context if you want to
use them with SDO helpers,
then the only possible failure would be if
HelperContext.project(someObject) fails. For example
someContext.project(new Integer()) would probably fail - because it's not
really a SDO-capable POJO. On the other hand, someContext.project(new
Company()) would probably succeed. Once you have the DataObject in the
target context, you can then use SDO helpers, e.g., CopyHelper, XMLHelper,
and know that they will work.
Whether or not we can convince
ourselves that HelperContext.projsec() is a
good way to convert an SDO to a
POJO, it seems that it still isn't as user
friendly as the API I've
proposed. It would still require a Java cast:
Company company =
(Company)HelperProvider.getPojoContext().project(myDataObject);
I
would think that the DataObject method I suggested would still be a
cleaner
API:
Company company =
myDataObject.cast(Company.class);
Even if, the implementation of this
method would simply delegate to a POJO
context (although, as I said above,
I'm not sure that's the right way to
do it anyway).
This discussion,
has however, made me start to think that the
DataObject.cast() method I've
proposed would be better named
DataObject.project(), for consistency with
HelperContext.project() which I
think is the right API for the reverse
operation.
I hope my thoughts are clear enough here. This is a fairly
complicated
topic to discuss in
email.
Thanks,
Frank
"Barack, Ron"
<ron.barack@sap.com>
07/01/2008 04:38 AM
To
Frank
Budinsky/Toronto/IBM@IBMCA,
<sdo@lists.oasis-open.org>
cc
Subject
[sdo] Re: ISSUE 130:
New DataObject method: cast()
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]