OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: AW: [sdo] ISSUE 119: Projection and Keys


Hi Ron,

I may also be willing to vote with you on this one :-)

I like the way Bryan positions it. The only part that confused me was the 
part about project() returning null pointers. That seems kind of awkward, 
since after project(), we will have lost the keys. Users would need to 
save the keys, or look-up the corresponding objects, before calling 
project() and then set the null pointers to the right values, after 
project(). I think your approach of creating new objects with the keys 
set, is at least a little easier to work with.

Frank




"Barack, Ron" <ron.barack@sap.com> 
10/08/2008 04:26 PM

To
"Bryan Aupperle" <aupperle@us.ibm.com>, <sdo@lists.oasis-open.org>
cc

Subject
AW: AW: [sdo] ISSUE 119:  Projection and Keys






Hi Bryan,
 
If I understand you, you are actually agreeing with what I'm proposing for 
SDO-119, in that you agree that the project method should be able to 
project from entities to keys and back, you just don't like the way I 
motivated it in terms of SCA and interface compatibility.
 
I was actually attempting to motivate the project method, but it seems 
like the effect was exactly the opposite.  I still think the discussion 
was valuable, but I guess it's important that we separate the proposed SDO 
functionality from how it could be applied in a SOA architecture.  It's 
not for us to decide if a component implementation or the SCA framework 
calls project().  From SDO's point of view, both are simply our clients.
 
Just to be clear, and at the risk of alienating the one guy who seems to 
be willing to vote with me on this, the much harder direction of going 
from keys to entities doesn't leave null pointers, but rather creates 
entities, one entity for every distinct key value, and inserts them into 
the projected graph.  I certainly want to build on this, and allow the 
user the option to hook in some logic for resolving keys to entities...in 
earlier drafts of this proposal I had an EntityResolver, but I dropped it 
from this proposal because I wanted to get the default behavior defined 
first, and I suspect that the API for the EntityResolver will be influence 
by the resolution of SDO 134.
 
Ron
 
 

Von: Bryan Aupperle [mailto:aupperle@us.ibm.com] 
Gesendet: Mittwoch, 8. Oktober 2008 19:02
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] ISSUE 119: Projection and Keys


So staying focused on the use case of sharing DataObjects between services 
we need to differentiate between local services, that can pass data by 
reference, and remote services, that are constrained to pass data by 
value. 

The remote case is, at least in my view, clearer.  If data has to be 
passed by value, it is not possible to pass a DataObject that has 
non-containment references without explicitly passing  all of the 
referenced DataObjects and even then, the references have to be replaced 
with something like a key.  In this case the service providing the data 
needs to explicitly prepare DataObjects that do not have non-containment 
references.  Project to a DataObject with keys is one way to do this, and 
I think a good one.  Similarly, if the client service receiving the 
DataObject wants internally to use a DataObject that has non-containment 
references, then it needs to be possible to Project from the received 
DataObject with keys to the internal DataObject.  Project() could use the 
key data to retrieve the referenced DataObjects from the appropriate DAS 
or, better in my opinion, simply leave NULL pointers that the client 
service replaces with references to objects explicitly retrieved from the 
DAS. 

What makes the local case less clear is under what circumstances it is 
possible or desirable to share a DataObject with non-container references. 
 But this is really application design, and not something we have to 
invent special interfaces for.  The key is that each service interface 
will have parameters with specific data types and those types will be 
clear as to if non-containment references are used or not. 

So the constraints I see are that the SDO specification does not define 
interface compatibility nor does it define or even imply any implicit type 
conversion or projection.  It does need to define compatibility rules when 
keys are involved. 

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 


Frank Budinsky <frankb@ca.ibm.com> 
10/08/2008 10:35 AM 


To
sdo@lists.oasis-open.org 
cc

Subject
Re: AW: [sdo] ISSUE 119:  Projection and Keys








Hi Brian,

Your constrained use of keys sounds really good to me, but I'm wondering 
how that could be controlled. If we specify key projection in the 
project() method, how do we limit where it will be used? Are we just 
talking about how we advertise it?

Frank




Bryan Aupperle <aupperle@us.ibm.com> 
10/07/2008 02:04 PM

To
sdo@lists.oasis-open.org
cc

Subject
Re: AW: [sdo] ISSUE 119:  Projection and Keys







Binding is a very overloaded term these days. 

From the SCA view, right now a binding is effectively a transport protocol 

and its associated headers.  SCA has also identified the need to be able 
to describe the conversion between the format of data on the wire (which 
is strongly influenced by the binding) and the format needed by a 
component implementation (this is sometime called a data binding). 
Independent of all of this are interface definitions and SCA is not 
addressing the specifics of complex data types, deferring to things like 
SDO or JAXB. 

Having said that, I view the role of SDO as a storage and technology 
independent way of representing data in memory and as a way for different 
implementation technologies to access the same data structure.  The 
project idea we adopted in issue 66 is very consistent with this view 
since cooperating local services are very likely to be developed at 
different time and with compatible but independent definitions of the data 

model. Adding keys to this in a constrained manner makes sense.  The 
constraint is that like any other projection, it happens explicitly within 

a service, i.e. a service projects between the type used in the interface 
and the type used internally.  It makes sense because there are clearly 
cases where you want to share an object that references other objects, but 

not share the referenced objects explicitly.  Using the course 
registration example, the main registration service may want to share 
course enrollment information with another service, but that other should 
not have access to full student data - it could access data for a specific 

student via a request to the DAS (providing proper credentials).  So the 
main service would project from the full representation to a 
representation using keys before providing an object over a service 
interface. 

This keeps us away from SDO being used for interface compatibility or 
implicit mapping over an SCA wire.  Of course if the main service only 
exposes the fully inflated set of objects, then an ESB transformation 
would be added to do the explicit mapping using the two separate SDO type 
definitions. 

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 


Blaise Doughan <blaise.doughan@oracle.com> 
10/07/2008 11:40 AM 


To
"Barack, Ron" <ron.barack@sap.com> 
cc
radu.preotiuc-pietro@oracle.com, Frank Budinsky <frankb@ca.ibm.com>, 
sdo@lists.oasis-open.org 
Subject
Re: AW: [sdo] ISSUE 119:  Projection and Keys








Hi Ron, Frank, Radu, and All,

Below are a couple of use cases I have to express my opinions. 

Use Case #1 - SOA Message Compatibility Beyond Identical WSDLs

This is a very compelling use case.  Speaking as someone who represents a 
SOA binding product (EclipseLink MOXy), this could make service 
development easier, reducing the amount of transformation necessary to 
link services.  However I would rather not have this issue addressed as 
part of the SDO spec.  I would suggest having a separate binding spec.  In 

this way SDO and JAXB perspectives on the topic could both be represented, 

instead of trying to give all this responsibility to SDO.   Also Frank 
mentions that additional mapping functionality is required as soon as 
different names are used for properties, the addition of a new spec could 
be expanded to handle these scenarios. 


Use Case #2 - Projection and Keys and Undefined States

Assume in this scenario SDO is being used to deal with a persistent data 
store such as a large database.  The data model is very connected with no 
containment relationships and the SDO type model has been designed 
accordingly.  Working in a SOA I want to respond to queries with messages, 

that are pruned down versions of the data.  To implement this I could use 
the "projection and keys" approach.  Wrt projection we have said a data 
object is in an undefined state until the data is projected back.  Ideally 

I could carve off many pruned messages to respond to service requests 
without waiting for the previous request to respond (if it ever does), but 

it is not clear this can be done (am I allowed to project an object that 
is already in an undefined state?).  Obviously there are mechanisms that 
could be put in place such as optimistic locking to ensure that the 
changes made by multiple projections are compatible, but here I agree with 

Radu that this aspect of projection and keys feels like a DAS 
responsibility.

-Blaise


Barack, Ron wrote: 
Hi,

Each company of course has its own perspective on what SDO 3 should be, 
and I hope everyone will speak out at today's meeting.  I just want to 
point out that it is not a choice between DAS oriented and SOA oriented 
architectures - these two functionalities are very much complimentary to 
each other.  In a SOA architecture, the data has to come from somewhere, 
and there is even more reason that usual to for client not to care about 
the technology of the datasource:  DAS's fit very well into a SOA. 
Conversely, DAS technology becomes even more important when there are more 

consumers of the data:  SOA expands the client base for DAS's.

We already resolved to support the project method, at the F2F as a 
concept, and then in the resolution to SDO-66. To me, that means SDO is in 

the business of moving data between contexts, therefore, we are already in 

the business of specifying the rules about when this is possible.  All 
this proposal adds to the picture is the question of whether or not the 
data must always be the transitive closure, the reachability graph, or 
whether SDO will allow is to "prune" the graph.  I would argue that such 
pruning is a necessary part of moving data between object oriented and 
document oriented technologies.  And that is central to the SOA and the 
SDO stories.

Guess Obama and McCain won't be the only debate today.

Best Regards,
Ron


-----Ursprüngliche Nachricht-----
Von: Radu Preotiuc-Pietro [mailto:radu.preotiuc-pietro@oracle.com] 
Gesendet: Dienstag, 7. Oktober 2008 04:19
An: Barack, Ron; Frank Budinsky; sdo@lists.oasis-open.org
Betreff: RE: AW: AW: [sdo] ISSUE 119: Projection and Keys

Hi Frank, Ron,

First, I can confirm what Frank said about me worrying about the "multiple 

incompatible views" scenario. If you do have a universe which can be 
represented conceptually as a set of interconnected Java interfaces and 
you want to "slice" it into "views", then the solution presented works, 
even though it feels like DAS-level functionality to generate the data 
graphs. If your universe is anything else, then the solution doesn't work 
because it requires extra mapping, which is why I think in last week's 
call, none of the participant companies indicated that this was a feature 
that they would actually make use of.

I also have given some thought to Ron's closing comment that passing off a 

"projected" or live copy of a DataObject to another data service is like a 

pass-by-reference of data; in fact, the idea of a change summary that gets 

passed between DAS and client and which records changes is like an 
"optimistic", loosely coupled pass-by-reference. And if the contract 
between two DASes is WSDL and Schema-driven, SDO's XML serialization 
mechanisms (which need to be better specified by the way, to ensure change 

summary interoperability between vendors) fit perfectly as a conceptual 
model. Everybody understands that if the two services are co-located, 
ample optimization is possible, but from a conceptual point of view, SDO 
already fits the bill.

I agree that access to the same data by different technologies (like POJOs 

without containment and JAXBs with containment) is an interesting problem, 

but aren't we actually starting to talk about modifying the data now for 
different users? That's the slippery slope of going down the route of 
mapping. The other slippery slope is to move to a "connected" model for 
SDO where calling a set to an SDO object backed by a JPA object might 
trigger an update right then and there, before getting the chance to 
complete the modifications. I think we are taking a bit of risk of 
promoting SDO for a use-case it might not be well-suited for, thus eroding 

its credibility, and that's a worry for me. Especially since the proposal 
does not seem to fit most companies' use cases for SDO, as evidenced by 
the fact that it doesn't have enthusiastic support from at least one other 

member. As much as I hate having to disagree with Ron on this issue that 
he worked so dilligently on and made such good jo
b of presenting, I do disagree that this is a problem that SDO needs to 
solve.

Thanks,
Radu 

 
-----Original Message-----
From: Barack, Ron [mailto:ron.barack@sap.com] 
Sent: Monday, October 06, 2008 4:35 PM
To: Frank Budinsky; sdo@lists.oasis-open.org
Subject: AW: AW: [sdo] ISSUE 119: Projection and Keys

Hi Everyone,

The question Frank poses is whether or not the project 
operation is simply an optimized copy operation, adding 
convenience and perhaps reusing memory, sort of an optimized 
CopyHelper.  I could argue that this optimization would be 
difficult for someone outside of the SDO implementation to 
provide, but I think there's a more important misunderstanding here.

Forget, for a moment, the implementation.  What's most 
important here is what we are defining.  SDO projection 
*defines* the when 2 types are compatible.  This is a central 
problem when building any SOA.  Imagine a service that exposes

       Customer getCustomer();

Under what circumstances does this match a WSDL with XSD

      <complexType name="Customer"/>

Does it match only when JAXB says it would, namely, when the 
structure of the Customer object match the containment 
structure of the XSD type.  Are we going to impose the 
clients containment structure on our service's data model? 
Or are we going to allow a looser definition, one that will 
allow the data representations to differ in some ways. 
Projection, the definition of projection, is intended to 
bring us to the point where SDO type compatibility will give 
the SOA world this definition. 

In order for SOA to work, especially in the case of SCA, but 
also SOA generally, one of the main points is defining 
"compatibility of interfaces".  Right now, standard SOA 
declares that the WSDLs have to match (BTW, it's not clear 
exactly what this means).  SCA allows different interfaces to 
be used on the client and server side of the wire, but the 
argument types must match exactly.  This is a major 
obsticle...actually, I always felt that data representation 
is the first of the SOA problems that needs solving, and that 
the SCA groups really needed to address this first, not last, 
but that's another rant.  The point is, SDO is the spec I 
know of that is looking at data from a SOA perspective.  It's 
fallen to us to solve this problem, and in fact, SDO, as a 
technology neutral data representation is uniquely positioned 
to actually solve it well.

And of course, SDO will not only define projection, but 
implementations will provide it.  So SDO becomes an important 
part of SOA infrastructure, providing the functionality to 
move data between representations.

One of the most important ways that data representations 
differ is the containment structure.  I've written somewhere 
on this thread that the proposed projection of keys is a 
fundamental part of moving data from document to object based 
representations.

Obviously, in this functionality, we are not talking about an 
arbitrary client calling an arbitrary service, with 
absolutely no agreement on how the data is represented. 
That's a problem you can only solve with some kind of mapping 
framework.  What we are defining are the cases where mapping 
will not be necessary (and avoiding mapping has major 
benefits).  Getting two types to match closely enough that 
they will be projectable is not something I suppose will 
happen by accident.  I imagine either the XSD or the object 
model will come first, and one will be derived from the 
other.  We can't do magic, and we can't replace a mapping 
framework.  We *can* allow all components to use a data 
representation that is natural to their technology, and we 
*can* provide very efficient communication between them.  And 
that's not a small thing.

Best Regards,
Ron



________________________________

Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Mo 06.10.2008 22:56
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] ISSUE 119: Projection and Keys



Hi guys,

Given that the discussion of this topic consumed almost all 
of the previous call, I was hoping to see some email 
discussion. Given the lack of input, let me summarize my own 
thoughts and where I think last weeks discussion left off.

One thing that is still not clear to me is how would one 
implement Ron's scenario if we didn't allow key projection? I 
think the answer is that it would need to be done by the SCA 
binding that would manage the keys and do a 
mapping/translation step (copying objects). If that's true, 
then having
project() do it is really just an optimization (no copy), as 
opposed to a critical function (not that I don't personally 
think it would be a good thing regardless). The second 
question is, how convinced are we that this function will be 
usable in a typical scenario. Isn't it possible that the 
different "views" will usually be incompatible anyway 
(different naming, for example), so some higher level way of 
mapping the views (e.g., in an SCA binding) will often be 
needed anyway?

I think these are the kinds of things that Radu was also 
getting at. I was hoping that Ron could answer these 
questions, after which we'd all understand exactly what key 
projection is good for and what it isn't good for.

Thanks,
Frank.




Frank Budinsky/Toronto/IBM@IBMCA
09/19/2008 06:21 PM

To
sdo@lists.oasis-open.org
cc

Subject
Re: AW: [sdo] ISSUE 119:  Projection and Keys






Hi guys,

I think I agree with Ron, that it is important to spec out 
the behavior when projecting between keys and entities, but I 
also think that this may be an easier sell if all SDO 
implementations were not required to support it. I think it's 
a good example of something that should be an optional 
compliance point, since it may involve a lot of work to 
handle scenarios that some implementations may not be 
interested in supporting.

That said, I think Ron's proposal for how key projection works (if
supported) is good. If an implementation doesn't support key 
projection, I

would say that it should throw UnsupportedOperationException (or maybe
InvalidArgumentException) when called with arguments that 
have key types, rather than do something that simply ignores 
the key metadata. Otherwise, as Ron mentioned, there could be 
two incompatible (non error) behaviors that are both 
considered compliant.

Frank.




"Barack, Ron" <ron.barack@sap.com>
09/10/2008 04:20 AM

To
<sdo@lists.oasis-open.org>
cc

Subject
AW: [sdo] ISSUE 119:  Projection and Keys






Hi Everyone,

As suggesting in yesterday's meeting, I'm sending out some 
mails, refereshing everyone's mind on the state of these discussions.

There was actually some discussion of 119 during the call on 
Sept. 2, and maybe it is a good idea  to have the discussion 
reflected in an email thread, so I will repeat it here.

There question was (from Blaise on behaf of Radu), why we 
need to specify this behavior, why can't it be left as a 
vendor extension?  After all, the

resolution to SDO-66 defined strict compatibility rules, but 
allowed implementations to weaken them.  Can't the 
compatibility between keys and entities be allowed under this 
clause, without requiring vendors to implement this behaviour?

I would argue the answer is "no", and I'll give 2 reasons. 
First of all, the proposal includes more than just the rule 
that entities are compatible

with their key types, there is a certain amount of behavior 
that goes along with it, eg, changes to the values of keys do 
not change the value of the key field in the underlying 
entity, but change the target of there reference.  It's 
difficult to imagine that this behaviour would be 
"compatible" to the behavior of an implementation that did 
not support projection between keys and entities.

The second reason is that this behavior is necessary for 
projection to achieve its primary goal, allowing different 
containment structures to be imposed on object oriented 
models.  For instance, consider the m:n relationship between 
students and courses in the example.  When generating

the XML, we want to produce a document in which Student 
contains (a reference to) Course.  The projection works 
exactly because of the special

behavior associated with keys.  If Student contained the 
entity "Course", then we'd get an illegal graph, because each 
"Course" would have multiple containers.

Moving data between object-oriented and document-oriented 
applications, for instance, between JEE and BPEL, is perhaps 
*the* central problem we are looking at SDO 3 to solve. 
Achieving this goal requires that the proposal (or one like 
it) be accepted.  As such, the proposal is too important to 
be left as a vendor extension.


Ron


Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Dienstag, 26. August 2008 11:21
An: sdo@lists.oasis-open.org
Betreff: [sdo] ISSUE 119: Projection and Keys

Hi Everyone,
Moving a discussion from another thread to this thread, for 
clarity, and so we can remember the issues:
Blaise asked:
* What is the impact of relaxing the SDO name uniqueness 
requirement on projection?
* What is the impact of SDO-82 on projection?
Right now, the projection algorithm matches by name only. It 
could be that

we need to make this a little more precise when considering 
that property names may not necessarily be unique, and type 
names (in the case of XSD anonymous types) may not even be 
defined. It's also possible that we can say that projection, 
like static SDO generation, has some additional constraints, 
such as name uniqueness These are all valid questions to 
consider, but what exactly is the relationship with the 
proposal being discussed here?  Does having the compatibility 
rule regarding keys and entities make the above issues any 
worse or better?
* Is SDO-119 useful without an identity concept? Currently my 
thinking is that identity management is required here.
There actually is some identity management within the 
proposal, the scope in which the identity is meaningful is 
the graph being projected.  SDO doesn't have any sense of a 
scope that is smaller than the HelperContext yet bigger than 
a DataGraph.  Other frameworks, notably JPA and similar 
persistence frameworks, do.  For example, in JPA, you have 
the users persistence context, in which the scope of the 
mapping between objects and

identity can be managed on a per-thread basis.  In SDO, 
however, the next larger scope for the identity is the 
context, and I think we agree that the context can shared 
between threads, at the enterprise application level.  It 
could be that we need to add something like a persistence 
context to SDO, but I've been trying to avoid this, and 
instead to allow the user to inject his own flavor of entity 
management by specifying an EntityResolver... please see my 
emails to Bryan in this thread, and my
earlier proposals in SDO-125.   The current proposal 
regarding keys and
projection is meant to define a default behavior and a 
baseline on which
the future EntityResolver functionality can be built.   Would 
you be more
willing to resolve this issue if I added the EntityResolver back in?
* Alignment with SDO-135. I believe the spirit of SDO-119 & 
projection in general is to enable alignment with other 
standards. I believe these issues should be worked on in 
parallel, for example the Binder proposal could be enhanced 
to unify SDO-135 and projection.
There were some proposals in this direction, which we moved 
away from based on your previous wish that the 
functionalities be separated.  For the earlier discussion, 
please see 
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archive
 
s/200808/msg00001.html
 
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archive
 
s/200807/msg00034.html
 
The question where I was hanging is whether or not Binder is 
allowed to wrap the POJO or DOM structure, or must copy 
involve a copy step.  Up to now, we've always though of 
projection as not requiring a copy step.  If we want to bring 
the concepts together then we must either say Binder allows 
wrapping, or Projection does not allow wrapping.  I'd be willing to

further pursue these proposals, but I need some guidence from 
the TC as to

which direction is appropriate.  I actually started work on 
this proposal in 119 once I had the impression that we had a 
better chance of making progress by separating Binding and 
Projection.  Now the opposite opinion is being expressed.  I 
usually do not propose something without first prototyping, 
so that it is a significant effort to make a proposal.  It is

difficult to make progress without stakes in the ground, such 
as this one,

that provide foundations upon which futher proposals can be based.
That said, opinions on wrapping/ copying are more than 
welcome (but in the

appropriate thead, please)

Ron


Von: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Gesendet: Freitag, 15. August 2008 17:40
An: sdo@lists.oasis-open.org
Betreff: Re: AW: AW: AW: [sdo] ISSUE 119: Projection and Keys


I would be happy to address it separately since I think it 
opens some interesting questions that have DAS implications, 
(Questions like: Does SDO know what DAS is associated any 
given type?  Does SDO retrieve entities from the DAS 
directly, or is that the responsibility of client code? )

Perhaps the best way to handle it would be to make sure we 
open a separate

issue as we resolve this one.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution 
Architect Master Inventor

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com


"Barack, Ron" <ron.barack@sap.com>
08/15/2008 11:05 AM


To
Bryan Aupperle/Raleigh/IBM@IBMUS, <sdo@lists.oasis-open.org> cc

Subject
AW: AW: AW: [sdo] ISSUE 119:  Projection and Keys








Hi Bryan,

In th current proposal, the implementation would create one 
entity for each distinct key value.  The entity would have 
all default values, except

for the key properties, which would of course match the key.

In earlier versions of the proposal, I defined a second 
projection method that took a second argument.  I called this 
argument an "EntityResolver"
and the idea was exactly to allow the client (probably in 
this case a DAS)

to provide some special logic to manage the reference 
objects.  In the SAP

prototype, for instance, we have an implementation that 
basically wraps a JPA EntityManager.

This is certainly something I want to address before we go 
final, but I don't think we necessarily have to define it as 
part of this issue.  It seems to me that the current proposal 
is clear enough that it can be accepted as is...we've been 
unable to make progress on this proposal for weeks now, and I 
thought it might go easier if we added things piece by piece.

One of the things holding me back from making a proposal with 
an EntityManager is that even though I think the 
functionality is clear and clearly needed, I'm not sure about 
how the API should look.  Specifically,

depending on how ISSUE 134 is resolved, we may get some kind 
of "Projector" object, which would be a much better place it 
parameterize projection...with an entity manager, or anything 
else.  I'm not very enthusiastic about having a second 
"project" method.

It also sort of disturbed me in our implementation that the 
application would get back a graph in which the entities at 
the edges were attached, but the real SDO content was still 
detached.  It might be better to allow other hooks into the 
projection process, eg, one for normal objects, so that the 
implementation can call "merge" or something.

It seems you agree we need an EntityResolver, do you need to 
see it as part of the resolution of this issue, or do you 
think we can solve it seperately?


Ron


Von: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Gesendet: Freitag, 15. August 2008 16:38
An: sdo@lists.oasis-open.org
Betreff: Re: AW: AW: [sdo] ISSUE 119: Projection and Keys


Ron,
I must not have been sufficiently clear about the scenario I 
am concerned about.
I understand the case where you start with the context with 
entities and project to the context with keys.  The mapping 
between entities and keys can be created and maintained.  I 
agree there is no problem projecting back tot he context with 
entities.
Now consider the opposite case.  Start with an object 
containing keys and the mapping between entities and keys has 
not yet been created  (perhaps the object was received via a 
service call).  Now project to a context with entities. 
Those entities have to be retrieved from the data store.
Or am I missing something here?

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>
08/15/2008 09:58 AM


To
Bryan Aupperle/Raleigh/IBM@IBMUS, <sdo@lists.oasis-open.org> cc

Subject
AW: AW: [sdo] ISSUE 119:  Projection and Keys










Hi Bryan,

good to know that someone is reading the proposals...

I didn't mean located within the backend store, I meant 
within the graph reachable from Oe, called Gk in the text.

Projection maintains identity (one reason why I think it can 
be unified with binding).  That is,  if I have an object O in 
HelperContext hc1, and I project it to HelperContext hc2, then

O == hc1.project( hc2.project( O ))

What I really what to say in the proposal is that the same 
must hold true for keys.  That is, if the O has a property p, 
that is a DataObject in hc1, and a key in hc2, then

o.get(p) == (hc1.project( hc2.project ( O ))) .get(p);

Moreover, whereever I set the value of a property in the 
transitive closure reachable from hc2.project(O) (Gk in the 
text), to the value of hc2.project(O).get(p), then, when I 
project back into hc1, I will always get the same instance, 
namely O.get(p).

It's actually easy, it's just hard to say it.

Basically, it means that when you project from a context with 
entities to a context with keys, the user has implicitly 
defined a map from entities to keys based on the objects in 
the projection.  This map is not universal... it's based 
solely on the graph being transfered.

Did that help or make things worse?

Ron


Von: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Gesendet: Freitag, 15. August 2008 15:25
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] ISSUE 119: Projection and Keys


This is a tangential question, and perhaps one that I should 
already know the answer to, but here goes.  In your example 
with context Ce and Ck, if I have object Ok and project it 
into Ce, then for each key in Ok the corresponding entity has 
to be located.  Since we have agree that entity management is 
a DAS responsibility and not an SDO library responsibility, 
are we laying any new requirements on DASs, or has the DAS 
group already agreed that there has to be a standard API for 
returning an entity given a

key?

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>
08/14/2008 07:20 AM


To
<sdo@lists.oasis-open.org>
cc

Subject
AW: [sdo] ISSUE 119:  Projection and Keys












Hi Everyone,

I've modified the proposal a bit, based on Frank's suggestion 
that projection from keys to entities be made more 
intelligent.  In fact, I think that the behavior is now 
intelligent enough so that a second project

method giving a "restoreContext" is no longer required.  New 
text is in blue.

Comments of course are very welcome.

Ron

Use Cases for Keys and Projection
We begin with a motivating use case.
Domain models tend to be larger and complex than the views 
used by individual clients. Moreover, when going from a large 
server-side model, it is necessary to define the scope of the 
data which should be transmitted to a remote client. The 
boundaries of the data which should be

transmitted in a single packet must somehow be defined. On 
the other hand,

the door must be left open for clients to further explore the 
model in succeeding calls to the server.
Imagine a service that returns an Employee object. In the 
domain model, Employee has a refence to Department, and 
Department in turn has a list of

all Employees. If we define the transmission packet to be the 
transient closure reachable from Employee, then we can never 
send a single employee,

we will always send the complete list of employees in the department.
Our approach is to use keys to represent the boundary points 
in a transmission packet. It is assumed that clients that 
wish to explore the model beyond these boundaries will be 
able to use the keys to somehow perform lookups, but the API 
through which this is done is out-of-scope for SDO (being 
more of a DAS issue).
As an example, we can imagine that the server has a SDO type 
system in which Employee has a property with type Department. 
In the client's type system, however, the corresponding 
property has type {commonj.sdo}string.
This value would represent the identity of the Department. 
The basic functionality we wish to achive is to allow 
projection between these two HelperContexts.
Keys and Projection
A type and its keyType are compatible with each other.  That 
mean, an object with a reference to an entity in one context 
can be projected onto an object with a reference to the key 
type in another context.
We illustrate this with an example.
HelperContext #1

Type Employee
* property - id (Integer) - KEY
* property - name (String)
* property - direct-report (List of Employee) is compatible 
with the metamodel HelperContext #2

Type Employee
* property - id (Integer) - KEY
* property - name (String)
* property - direct-report (List of Integer) Here we see the 
type of the direct-report property has been replaced in the 
second HelperContext with the corresponding key type.
The projection from an entity to its key has some important 
semantic differences when compared with projection between 
entities.  Projection between entities creates a new view of 
the same underlying data.  By contrast, a key does not 
represent a view, but rather a reference to an entity in the 
underlying data model.  When working with different views of

the same underlying data, it is natural that changes in one 
view are reflected in all other views.  By contrast, changing 
the value of a key changes the target of the reference rather 
than the value of the key property in the referenced data 
object.  When projecting from an entity to

a key, a new instance of the key is always created.  By 
contrast, when we project from entity to entity, we get the 
same number of objects in the target HelperContext that we 
had in the source HelperContext.
Conversely, when projecting from a key to an entity then for 
each distinct

key value within the graph being projected, all references to 
that key must resolve to the same entity.
In many scenarios data will round-trip between contexts, 
including between

contexts in which entity map to keys.  Let us consider two 
context Ce and Ck, representing the entity and the key 
context, respectively, and a DataObject Oe, in context Ce. 
Projecting Oe into Ck returns a DataObject,

Ok.  The transitive closure reachable from Ok is Gk.  Every 
key value in Gk maps to an single entity in Ce, and it is 
this entity is that is found when Ok (and effective, all of 
Gk) is projected back into Ce.  In cases where the user has 
set a key property to a value that is not found in Gk, then, 
as a result of projecting Ok into Ce, a new entity will be created.
The created entity has default values for all properties 
other than the key fields.
We illustrate with an example.  Note that the example uses 
containment relationships in both contexts.  This is done for 
clarity, since it allows

an XML representation of the data.  The use-case, however, is 
stronger when the contexts have different (or perhaps no) 
containment structures.
Imagine the following data in HelperContext #1 <employee id="11">
   <name>Foo Bar</name>
   <direct-report id="21">
           <name>Jane Doe</name>
   </direct-report>
   <direct-report id="31">
           <name>Jim Jones</name>
   </direct-report>
   <direct-report id="22">
           <name>John Smith</name>
   </direct-report>
</employee>
After projecting to HelperContext #2, we have the following 
data <employee id="11">
   <name>Foo Bar</name
   <direct-report>21</direct-report>
   <direct-report>31</direct-report>
   <direct-report>22</direct-report>
</employee>
If we imagine the client changes the list of direct reports, 
so that the second item in the list has value ?41? instead of 
?31?, then the meaning of the change is not that the employee 
with name ?Jim Jones? now has a new

ID, but that ?Jim Jones? has been replaced by another employee.
On projecting from context 2 back into context 1, the 
instance of Employee

with id="22" would be detached from the Employee with 
id="11".  Also a new

Employee with id="41" would be created and added as a direct 
report to the

Employee with id="11".  If the graph in context 1 were in 
scope of a ChangeSummary, then because the "direct-report" 
property in context1 is a containment property, the change 
would be tracked as a delete or a create.

If the relationship were non-containment, the change would 
be tracked as a modification to the employee with id=11, not 
as a delete to the employee

with id=22 or as the creation of a new employee with id=41; 
semantically, it is only the reference to entity 22 that has 
changed, the entity itself
still exists, and is unaltered.   Projecting this data from context 2:
<employee id="11">
   <name>Foo Bar</name
   <direct-report>21</direct-report>
   <direct-report>41</direct-report>
   <direct-report>22</direct-report>
</employee>
Into context 1 yields:
<employee id="11">
   <name>Foo Bar</name>
   <direct-report id="21">
           <name>Jane Doe</name>
   </direct-report>
   <direct-report id="41"/>
   <direct-report id="22">
           <name>John Smith</name>
   </direct-report>
</employee>
Projection between entities and keys becomes more powerful 
when the relationship through which the entities tie into the 
graph are non-containment.  The following example shows how a 
complex model that lacks containment relationships can be 
projected onto a context that requires a specific XML 
serialization, which implicitly prunes the orignal

domain to the requirements of a specific client.
HelperContext #1

Type School
* property - name (String) - KEY
* property - students (Student) - many=true
* property - courses (Course) - many=true  Type Student
* property - name (String) - KEY
* property - courses (Course) - many=true, containment=false, 
opposite=students
* property - school (School) - containment=false, 
opposite=students Type Course
* property - name (String) - KEY
* property - students (Students) - many=true, 
containment=false, opposite=courses
* property - school (School) - containment=false, 
opposite=courses Notice the m:n relationship between Student 
and Course.  If we imagine a service that should expose this 
domain model to clients, it is possible that some clients 
will wish to obtain the list of students participating in a 
particular course, while other clients may wish to obtain the list of

courses in which a particular student is enrolled.  The 
application cannot

determine based on the structure of the data which of the two 
possible containment structures is "correct".  Notice also 
that returning the transitive closure would return all the 
data associated with the entire school.
In this example the client wants the data structured 
according to the following XSD <?xml version="1.0" 
encoding="UTF-8"?> <schema 
xmlns="http://www.w3.org/2001/XMLSchema"; targetNamespace= 
"http://projection <http://projection/> " 
xmlns:tns="http://projection <http://projection/> "
elementFormDefault="qualified">
<complexType name="School">
      <sequence>
          <element name="students" type="tns:Student"
maxOccurs="unbounded"/>
      </sequence>
      <attribute name="name" type="string"/>
</complexType>
<complexType name="Student">
      <sequence>
            <element name="courses" type="string"
maxOccurs="unbounded"/>
      </sequence>
      <attribute name="name" type="string"/>
</complexType>

<element name="school" type="tns:School"/> </schema> Notice 
that we are imposing a containment structure on the original 
context, as well as pruning it by replacing the course entity 
by the corresponding key.  The following code illustrates the 
behavior of the project method.
 DataObject cal = 
_helperContext.getDataFactory().create(School.class);
// Create the SDO graph
cal.set("name","Berkeley");
DataObject billy = cal.createDataObject("students"); 
billy.set("name", "Billy Bear");  DataObject bob = 
cal.createDataObject("students");  bob.set("name", "Bobbie 
Bear");  DataObject basketWeaving = 
cal.createDataObject("courses");  basketWeaving.set("name", 
"Basket Weaving");  DataObject algol = 
cal.createDataObject("courses");  algol.set("name", "Algol"); 
DataObject revolution = cal.createDataObject("courses"); 
revolution.set("name", "Revolution");  // hook things up 
billy.getList("courses").add(basketWeaving);
billy.getList("courses").add(algol);
bob.getList("courses").add(basketWeaving);
bob.getList("courses").add(revolution);
// Create a second context defined by an XSD  HelperContext 
hc2 = HelperProvider.getNewContext();

hc2.getXSDHelper().define(getClass().getClassLoader().getResou
rceAsStream("com/sap/sdo/testcase/internal/pojo/ex/projection.xsd"),

null);
// Project from the java context to the XSD context 
DataObject projection = hc2.getDataFactory().project(cal);
// Produce XML based on the XSD
String xml = hc2.getXMLHelper().save(projection, 
"http://projection <http://projection/> ", "school");  // I'm 
imagining here that sending the XML out over the wire (eg, 
using it as a response to a  // WebService request. On the 
client side, we go from the XML back to SDO. We use the 
context  // based on the XSD.
DataObject projection2 = 
hc2.getXMLHelper().load(xml).getRootObject();
// We can make some changes. We can add a new course...
projection2.getList("students.0/courses").add("Fortran and 
You");  // So, now the trip back to the server?
//I'm skipping the XML step, and simply projecting the modified (XML
oriented) data back into
// my java context
DataObject cal2 = 
_helperContext.getDataFactory().project(projection2);

// Test that there is one entity per key value  DataObject 
billy2 = (DataObject)cal2.getList("students").get(0);
DataObject basketWeavingBill = (DataObject)billy2.getList("courses")
                                             .get(0); 
DataObject bob2 = (DataObject)cal2.getList("students").get(1);
DataObject basketWeavingBob = 
(DataObject)bob2.getList("courses").get(0);


assertSame(basketWeaving2, basketWeavingBob);



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS 
TC that generates this mail.  Follow this link to 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.  Follow this link to 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.  Follow this link to 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.  Follow this link to 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.  Follow this link to 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]