[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] ISSUE 66: Moving Data Between Contexts
I agree that we need to talk use-cases, I have said exactly that on the
03/04 call. After all, BEA doesn't really have use-cases that need
either the "cast" operation or the "containment on/off" proposal. What
we do have is the JPA integration use-case, but I am still unconvinced
that "cast" helps with that. But it is very valid, so we need to add it
to the list of use-cases.
I also agree that the way you are describing your "shipping SDOs between
components" use-case, "cast" seems the natural solution to it.
Radu
On Tue, 2008-03-04 at 22:15 +0100, Barack, Ron wrote:
> Hi Radu,
>
> I think it's a good idea to start talking use-cases. Let me repeat mine, which I described a little at the F2F. On the one side I have an application that gets SDOs from a relational database. A deep integration with JPA is one of the things we want to lead up to, but for now lets think of the SDOs as coming from a local DAS (not a formal, remotable DAS, which might have to be WSDL-izable, just something that creates a net of SDOs based on the RDB schema). Now lets consider the SDOs returned by this service. I would say that it is very unnatural and artificial to impose a containment structure on them. After all, the nature of RDBs is that all relationships are bi-directional, therefore, half the relationships must be non-containment. You could make rules, eg, that 1:m relationship represent containment of the "m" side by the "1", but as soon as you get to m:n relationships, picking one side to be containment is completely arbitrary.
>
> Now we throw a second application into the picture, one that does use containment in ist SDOs. Lets say it is a BPEM engine that is built using SDO as an internal data representation. Or we can simply imagine that we want to ship out some view of our RDB database over a webservice. In any case, we have a second component that is XML oriented.
>
> The use-case is, we want to ship SDOs between these components.
>
> Here's where I don't like the terminology "turning containment off-and-on". Because it implies that the two components have agreed beforehand which relationships are containment and which are not. The RDB-based component simply ignores this information. There must be some sort of handshaking between the components, where the RDB component sync's up with the WSDL component, agrees that the "real" types come from the WSDL, but the RDB will ignore the containment structure. I think this is pretty impractical in a SOA architecture. I think that the containment information in such an architecture must be ADDED IN... It cannot be TURNED ON.
>
> I disagree that the 2 metamodels will be identical modulus containment. The XML oriented component may have alot of XML details that the RDB side is ignoring (eg, which properties are elements and which are properties, etc). Conversely, the RDB side may have some information the the XML side wants to ignore. For instance, the RDB side may use static SDOs, which the generically programed XML component. The only way I can imagine shipping SDOs around is that we are adding in and removing metainformation as the objects go over the wires.
>
> Ron
>
> -----Ursprüngliche Nachricht-----
> Von: Radu Preotiuc-Pietro [mailto:radup@bea.com]
> Gesendet: Montag, 3. März 2008 22:39
> An: Barack, Ron
> Cc: Blaise Doughan; Frank Budinsky; sdo@lists.oasis-open.org
> Betreff: RE: [sdo] ISSUE 66: Moving Data Between Contexts
>
> Thanks for your comments, Ron.
>
> 1. This is what I mean.
>
> 2. What I had in mind was JAXB rather, whose emulation was one of the goals for SDO 3 designs. Agreed that you may have only one of the two "halves" of the round-trip at any one time, this doesn't change anything. I would argue that, even though you could have many different containment realtionships defined, in at least 90% of cases you are only interested in one of them. And since SDO metadata already has the ability to represent containment, by attaching SDO metadata to POJOs you get both the ability to use the dynamic API and the ability to "turn containment on" without having multiple sets of metadata.
>
> 3. I am actually not convinced that this is the only way to implement it, but, the important thing is that it does give one way to implement it and to think about it; I personally have struggled with finding a coherent way of thinking about change summaries with some of the changes that are being proposed in this area for SDO 3.
>
> 4. I should have said that I am not imagining doing this at the HelperContext level. I avoided saying what it is exactly because this is related to the question of how to define a "graph of DataObjects". I am not using the term "data graph" in order to allow for ways to define a "graph of DataObjects" in the absence of containment. If we come up with such a way, I would say that the "containment on" operation is defined on such a "graph of DataObjects": you use the containment information to "trace" references and hopefully end up with a tree (one and only one DataObject that is not referred by any other etc.) Or we may say that there is no way to define a "graph of DataObjects" in the absence of containment and so the "containment on" operation would be defined on a DataObject. It's not any more difficult than casting from a context that doesn't have containment to one that does. Certainly, we wouldn't allow "half-contained and half-uncontained" "data graphs" I don't see how that would help.
>
> In a way, I can see how one could think of "containment on/off" as a special kind of cast. I just think that once we start looking through the use-cases, the case where there are just two contexts which are identical except for the fact that one has containment and the other one doesn't would turn out to be a very common case and we need to acknowledge that by designing for it. Also, for me at least, thinking in terms of "containment on/off" made the picture a little bit clearer.
>
> Radu
>
> > -----Original Message-----
> > From: Barack, Ron [mailto:ron.barack@sap.com]
> > Sent: Wednesday, February 27, 2008 8:26 AM
> > To: Radu Preotiuc-Pietro
> > Cc: Blaise Doughan; Frank Budinsky; sdo@lists.oasis-open.org
> > Subject: AW: [sdo] ISSUE 66: Moving Data Between Contexts
> >
> > Hi Radu,
> >
> > Thanks for the interesting ideas. Let me add my comments
> > point by point.
> >
> > 1. AFAIK, Java, also Java Serialization does not have any
> > sort of containment relationships. Unless you want to look
> > at the heap, or the "ser" byte stream as being the container
> > for all java objects. Which is a valid viewpoint and more or
> > less motivates the "technical root" (I used to call it
> > "domain object") idea exposed by Xcalia.
> >
> > 2. In this use case, where the data is coming from XML, and
> > eventually will be serialized back into the same form, what
> > is the motivation for "turning off" containment? It seems
> > like the main motivation here is to allow the user to put the
> > objects, at least temporarily, in illegal states (e.g., where
> > the object has 2 containers). Of course, by the time the
> > object is serialized back to XML, it must be in a legal
> > state. Your use case is that the data comes in as XML, and
> > goes out as XML, too. Very AquaLogic. This is somewhat
> > different from the usecase I'm thinking about. I was
> > thinking that the data is being delivered from some source
> > (such as an RDB) in which the idea of containment is not
> > natural. In my use-case we are not turning containment off
> > and on, we are adding it in. One of the main differences
> > here is that, when adding containment information in, you can
> > add it in in different flavors. For instance, an RDB DAS
> > that delivers SDOs for a School, with Students and Courses
> > can be used to generate XML in which the Students "contain"
> > Courses or one in which Courses "contain" Students, depending
> > on which containment information is added in.
> >
> > But back to your use-case. I want to point out that it is
> > extremely difficult to derive the value of "getContainer" if
> > you are not maintaining it all along. Having played with
> > different ways of dealing with containment, I can definitely
> > say that this method places a very big limitation on our
> > options. Remember, that the object may not (and objects
> > defined by XML typically don't) have any property that points
> > back to ist container. From looking at an object, or even
> > analysing the type system, you still can not definitely
> > deduce the type of the containing object. Basically, I'm
> > saying you can only turn containment on at the root of a
> > tree. (This is also true for the cast operation, BTW:
> > O2.getContainer() will be null unless it was already casted into C2).
> >
> > 3. The only way to implement change summary in this scenario
> > is as a "diff" between the before and after states. We are
> > loosing the option to implement change summary by tracking changes.
> >
> > 4. I'd like to explore the "containmentOn" operation a little
> > deeper. At which level do you imagine doing this? At the
> > context level, something like helperContext.setContainmentOn(true)?
> > Or on the dataObject? If it's on the helperContext, I think
> > you're asking for problems regarding the calculation of
> > getContainer(), which I assume you're doing when setting
> > containmentOn. Depending on which root you start from, you
> > could get very different graphs. If on the other hand it's
> > on DataObject, then effectively, you are "casting" the object
> > into a identically defined (modulus containment) context,
> > except that, I suspect, you're going to start getting into
> > ugly situations as soon as you start mixing data objects with
> > containment "on" with others with containment "off" in a
> > single data graph.
> >
> > Ron
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Radu Preotiuc-Pietro [mailto:radup@bea.com]
> > Gesendet: Mittwoch, 27. Februar 2008 00:08
> > An: Barack, Ron
> > Cc: Blaise Doughan; Frank Budinsky; sdo@lists.oasis-open.org
> > Betreff: Re: AW: WG: [sdo] ISSUE 66: Moving Data Between Contexts
> >
> > Hi all,
> >
> > This is my thinking on the issue. It's merely putting
> > together different ideas that have been discussed on the
> > calls and at the face-to-face in an order that made most sense to me.
> >
> > Let me start by reiterating some of the observations that I
> > may or may not have completely expressed on the call.
> >
> > 1. Containment is useful for any kind of serialization. The
> > difference between XML serialization and Java serialization
> > is of course that Java serialization infers its containment
> > relationship at serialization time, while in XML, it is predefined.
> > 2. When creating POJOs from serialized form (let's say XML)
> > and saving them to XML, conceptually we can see the process as:
> > a) create a graph of objects with a containment
> > relationship given by the containment relationship in the XML text
> > b) turn the containment "off" before returning the object
> > graph to the user
> > c) turn the containment back "on" after receiving the
> > object graph back from the user, according to XML metadata on
> > hand; this process may produce errors
> > d) serialize the object graph with containment to XML 3.
> > Containment is useful for ChangeSummary; mainly because it
> > helps establish the scope of change summary; SDO "knows" how
> > to do ChangeSummary with containment.
> >
> > Those "observations" led me to believe that it would be
> > useful to have an ability to "turn containment off" on a
> > graph of DataObjects. The obvious purpose being to allow
> > modifications to the DataObjects without side-effects and
> > without the need to worry about breaking the containment
> > restrictions in those applications which do not care about
> > them. Let me, for lack of better terms, call "containment
> > off" the state of a graph of DataObjects where the
> > containment information in the SDO metadata is "turned off"
> > (ignored) and "containment on" the opposite state. In SDO
> > 2.1, all graphs of DataObjects are in "containment on"
> > state. Note that we would still need to define what a graph
> > of DataObjects is in the absence of containment, but let's
> > leave that aside for now.
> > More precisely:
> >
> > 1. In a "containment on" state, getContainer() works
> > according to SDO metadata (returns non-null except of course
> > for the root). That means, in a "containment on" state,
> > containment is managed. Otherwise, we can end up with two
> > parents for a node and getContainer() breaks.
> > 2. In a "containment off" state, getContainer() returns null.
> > Containment is not managed.
> > 3. XML serialization works on graphs of DataObjects that are
> > in "containment on" state 3. Regarding ChangeSummary
> > interaction, we define the Change Summary in terms of diff
> > between two "containement on" states of a graph of
> > DataObjects. That means, in order to get a ChangeSummary and
> > start logging, the graph of DataObjects must be in a
> > "containment on" state.
> > In order for other ChangeSummary methods to return "defined"
> > results, the graph of DataObjects must also be in a
> > "containment on" state. That however, makes it possible to
> > move to a "containment off" state right after calling
> > beginLogging(), make modifications, move back into a
> > "containment on" state and get a meaningful ChangeSummary.
> > Users would need to understand that moving into a
> > "containment on" state when there are changes being tracked
> > is a potentially expensive operation and could throw
> > exceptions, but implementations would be free to innovate.
> > All that the spec requires is that conceptually, it behaves
> > as a diff. This way we would also make a step toward
> > resolving the problem of defining ChangeSummaries more precisely.
> >
> >
> > So then, in relation to the "Cast" proposal, we have:
> >
> > 4. When casting a non-SDO POJO to a DataObject graph, the
> > resulting graph of DataObjects would be in a "containment
> > off" state. Because of that, writes can be done without
> > side-effects using either "view".
> > 5. One DataObject would have a single "view" in one context.
> > 6. If a certain "piece of data" (undefined term alert!) has
> > multiple "containment on" views, then the data is read-only
> > in all "views". If there is only one "containment on" "view",
> > the data can be modifed only "through" that view. If there
> > are no "containment on" views (only POJO views and DataObject
> > "containment off" views), there are no restrictions. This is
> > so that we don't have to reconcile containment with arbitrary
> > modification of data by a POJO view: getContainer() would be
> > broken, ChangeSummary impossible to maintain in a incorrupted
> > state, what was a DataObject graph at the time of the
> > projection would turn into a collection of unrelated graphs
> > after a few sets.
> > 7. It should be easy to restrict bullet 6 further to not ever
> > allowing more than one "containment on" view at the same
> > time; I don't see what use-case would that prevent. We could
> > also restrict "read-only" to mean "inaccessible; no reads":
> > even better but less clear that it would also cover
> > sufficient use-cases (I'd be happy if it does from the
> > perspective of it being easier to write a crisp spec) 8. If
> > we allow modification to be made through a "containment on"
> > view, then potentially a POJO "view" would see side-effects,
> > but that shouldn't be a problem, it the sense that it is
> > clear that if you have a "view" to modifiable data, then,
> > well, you'll see the data changing.
> > 9. I am still considering whether something like a
> > "copy-on-write" would be desireable when sharing data using
> > the "Cast" mechanism, but for that I would say we do need use-cases.
> >
> > That's it from me for now, hopefully it will turn out to be a
> > worthwhile (though long) read... :-)
> >
> > Radu
> >
> > On Tue, 2008-02-26 at 15:48 +0100, Barack, Ron wrote:
> > > Hi,
> > >
> > > 1. What is the state of O1 after casting to O2?
> > > Imagine that O1 and O2 have diffent containment structures,
> > or that O1
> > > has containment relationships, and O2 does not. One reason for
> > > suggesting that O1 should be invalid is the side effects due to
> > > containment (that is, putting something in one container has the
> > > side-effect of removing it from the other container) will be
> > > inexplicable to users who are only aware of O2. We will
> > bring forward
> > > a proposal to replace the side-effects with exceptions... but the
> > > unexpectedness of the result remains the same. If we invalidate O1
> > > after the cast, then we can ignore O1s containment
> > constraints for as
> > > long as the user is working with O2. When the user
> > reactives O1 (by
> > > casting from O2), SDO can check if all of O1 containment
> > constraints
> > > (e.g., that objects are not in 2 containers) are met, and throw an
> > > exception then. This is at least a point in time when the
> > exception
> > > would be expected. Also, the illegal state may have been only
> > > temporary.
> > >
> > >
> > >
> > >
> > >
> > ______________________________________________________________________
> > > Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
> > > Gesendet: Montag, 25. Februar 2008 22:20
> > > An: Barack, Ron; Frank Budinsky
> > > Cc: sdo@lists.oasis-open.org
> > > Betreff: Re: WG: [sdo] ISSUE 66: Moving Data Between Contexts
> > >
> > >
> > >
> > > Hello All,
> > >
> > > In my opinion the following answers are most consistent
> > with the Java
> > > cast concept, or moving entities between JPA contexts.
> > This isn't an
> > > endorsement yet, just my current thinking.
> > >
> > > 1. What is the state of O1 after casting to O2?
> > > a) We require both O1 and O2 to be live views of the same
> > underlying
> > > data.
> > >
> > > 2. Does cast create objects, even if there are the underlying data
> > > already has a DataObject in the context?
> > > Is C1.cast(C2.cast(O1)) == O1? Yes
> > >
> > > 3. How is the value of O2.getChangeSummary() related to
> > the value of
> > > O1.getChangeSummary()?
> > > * O1.getChangeSummary().isLogging() ==
> > > O2.getChangeSummary().isLogging()
> > > * O1.getChangeSummary().getOldSequence(aDataObject) ==
> > > O2.getChangeSummary().getOldSequence(aDataObject)
> > > Note identity might be too strong a requirement here, the
> > > returned Sequence may only need to be equivalent.
> > > * O1.getChangeSummary().getOldValue(aContext1Property) ==
> > >
> > O2.getChangeSummary().getOldValue(theCorrespondingContext2Property)
> > > Note that although the dataType=true properties would be
> > > identical, the dataType=false propertie values would be the
> > > equivalent from the other HelperContext.
> > > * O1.getChangeSummary().getOldValues(aDataObject) ==
> > > O2.getChangeSummary().getOldValues(aDataObject)
> > > * O1.getChangeSummary().isCreated(aContext1DataObject) ==
> > >
> > O2.getChangeSummary().isCreated(theCorrespondingContext2DataObject)
> > > * O1.getChangeSummary().isModified(aContext1DataObject) ==
> > >
> > O2.getChangeSummary().isModified(theCorrespondingContext2DataObject)
> > > * O1.getChangeSummary().isDeleted(aContext1DataObject) ==
> > >
> > O2.getChangeSummary().isDeleted(theCorrespondingContext2DataObject)
> > > * O1.getChangeSummary().getDataGraph() !=
> > > O2.getChangeSummary().getDataGraph()
> > > * O1.getChangeSummary().getRootObject() !=
> > > O2.getChangeSummary().getRootObject()
> > > * O1.getChangeSummary().getOldContainer(aDataObject) !=
> > > O2.getChangeSummary().getOldContainer(aDataObject)
> > > *
> > O1.getChangeSummary().getOldContainmentProperty(aDataObject) !
> > > =
> > O2.getChangeSummary().getOldContainmentProperty(aDataObject)
> > > ---
> > >
> > > For the following:
> > >
> > > 1. What is the state of O1 after casting to O2?
> > > c) We say that the state of O1 is undefined. In order to
> > > "reactivate" O1, we would have to cast it back from O2, that is we
> > > would have to explicitly say O1=C1.cast(O2), which would make O2
> > > invalid, but bring
> > > O1 back into a valid and consistant state.
> > >
> > > I agree with Frank that simply changing the DataObject's Type is
> > > another way to move a DataObject from one HelperContext to
> > another. I
> > > wouldn't categorize this as a cast though, and if this became our
> > > agreed upon approach I would suggest a different API such
> > as "move" or
> > > "adopt" (from DOM APIs). Also instead of stating that the
> > state of O1
> > > being undefined, I would state that C2.cast(O1) would cause the
> > > following operation to happen (O1.detach).
> > >
> > > ---
> > >
> > > Role of the Cast Operation (Motivation)
> > >
> > > Moving Between Helper Contexts
> > > A cast/move operation appears necessary to move DataObjects
> > from one
> > > HelperContext to another.
> > >
> > > Applying Containment Information "on-the-fly"
> > > A cast/move operation as a mechanism to apply containment
> > information
> > > for the purposes of mapping a DataObject to XML is too
> > cumbersome as
> > > it requires many changes on the DataObject before the XML
> > > marshalling/unmarshalling operation can take place.
> > Compare this with
> > > a object-to-XML mapping tool such as MOXy which is part of
> > EclipseLink
> > > (Eclipse Persistence Services) project which can apply many XML
> > > mappings to an object without any modifications to that object.
> > >
> > > ---
> > >
> > > DataObject cast(Object object)
> > >
> > > In my opinion:
> > > The ability to cast Objects other than DataObjects is a
> > possible next
> > > step, but I feel should be discussed in detail on its own before
> > > changing the proposed cast API.
> > >
> > >
> > > -Blaise
> > >
> > > ----- Original Message -----
> > > From: "Frank Budinsky" <frankb@ca.ibm.com>
> > > To: "Barack, Ron" <ron.barack@sap.com>
> > > Cc: <sdo@lists.oasis-open.org>
> > > Sent: Monday, February 25, 2008 1:50 PM
> > > Subject: Re: WG: [sdo] ISSUE 66: Moving Data Between Contexts
> > >
> > >
> > > Hi Ron,
> > >
> > > Thanks for kicking off this discussion. I agree it's a very
> > important
> > > issue.
> > >
> > > For question #1, I think the answer needs to be c) O1 becomes
> > > invalid/undefined. I think this is necessary to allow for the
> > > possibility of O2 being the same instance as O1. I think the most
> > > efficient implementation of cast() would return the same object if
> > > possible, just with the type changed. For example, the
> > > HelperContext.cast() method might do something like the following:
> > >
> > > DataObject cast(DataObject input)
> > > {
> > > Type inputType = input.getType();
> > > Type resultType = getTypeHelper().getType(inputType.getURI(),
> > > inputType.getName());
> > >
> > > // check if types are compatible
> > > ...
> > >
> > > // Unrelated question: do we need to recursively call cast() on
> > > the rest of the reachable objects ???
> > > ...
> > >
> > > // change the type
> > > ((DataObjectImpl)input).setType(resultType);
> > >
> > > return input;
> > > }
> > >
> > > This may not be always possible, but if the spec doesn't
> > say that the
> > > original object becomes suspended, there is no way we could ever
> > > implement cast this way - it would always require at least
> > a wrapper
> > > DataObject.
> > >
> > > For question #2, I think that C1.cast(C2.cast(O1) should == O1. It
> > > certainly would be the case if cast() is implemented as
> > above. If, on
> > > the other hand, a proxy is returned, I still think their
> > can only be
> > > one DataObject instance representing the same object in a given
> > > context.
> > > Otherwise, we're talking about a copy - not a cast.
> > >
> > > Which brings me to a question. Do we really think that
> > cast() should
> > > ever return a disconnected copy. In Java, cast and copy are very
> > > different
> > > -
> > > one changes the type, the other changes the instance. I
> > think that for
> > > copy cross-scope copy we should allow/use cross scope
> > CopyHelper. For
> > > example:
> > >
> > > O2 = C2.getCopyHelper().copy(O1);
> > >
> > > This would create a copy of O1 in the context C2 (the same
> > > compatibilty requirement as cast() would need to apply).
> > >
> > > O2 = C2.cast(O1):
> > >
> > > This returns the same conceptual object, just represented
> > in the new
> > > metadata (type) scope.
> > >
> > > This way, cross-scope cast and copy are two different things with
> > > clear APIs for both.
> > >
> > > One more thought I had about cast() is that the argument to
> > the cast
> > > method should maybe be Object - instead of DataObject. That
> > way, you
> > > could use it to cast a POJO (or JAXB) object to a DataObject:
> > >
> > > DataObject cast(Object object)
> > >
> > > Now, if the input object is not already an instance of
> > DataObject then
> > > the default mapping rules (maybe there are also
> > annotations) are used
> > > to check compatibility, etc., before returning a DataObject
> > proxy, for
> > > example.
> > >
> > > That's all for now.
> > >
> > > Frank.
> > >
> > >
> > >
> > >
> > >
> > > "Barack, Ron" <ron.barack@sap.com>
> > > 02/21/2008 05:20 AM
> > >
> > > To
> > > <sdo@lists.oasis-open.org>
> > > cc
> > >
> > > Subject
> > > WG: [sdo] ISSUE 66: Moving Data Between Contexts
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Everyone,
> > >
> > > OK, here we go... defining the cast method. I think the concept is
> > > actually simple, but it was hard for me to write down
> > without having
> > > to resort to this quasi-mathematical language. Sorry about that.
> > > Maybe,
> > > once the concepts are clearer, someone else can do a better job.
> > > Anyway,
> > > we decided at the F2F that is was a high priority issue, and to get
> > > started on it right away. Please spend a few cycles on
> > this topic, so
> > > we can begin discussing it.
> > >
> > >
> > > I've been trying, but I don't think it's possible to describe this
> > > functionality without some definition of what it means for
> > types to be
> > > compliant. So let me start out with the following
> > definition, which I
> > > believe to be too restrictive, but which at least allows us
> > to speak
> > > concretely about proposals. The concept can always be
> > loosened up in
> > > a separate step.
> > >
> > > Definition: Compliance
> > >
> > > A data type DT1 is compliant with a data type DT2 if they have the
> > > same instance class A complex type T1 is compliant with a type T2.
> > > The types are compliant iff
> > >
> > > 1. The URI and name of both types are equal.
> > > 2. For every property P1 in T1 there is a property P2 in
> > T2 such that
> > > a) P1.getName() is equal to P2.getName()
> > > b) P1.getType() is compliant with P2.getType()
> > > c) P1.isMany() is identical to P2.isMany()
> > > d) if P1.opposite() is non-null, the P2.opposite is also
> > > non-null.
> > >
> > > Of course, the key point is what is not looked at in determining
> > > compliance. This includes
> > >
> > > 1. The instance class (static SDO of the complex type) 2. Whether
> > > the value of P1.isContainment() is identical to the value of
> > > P2.getContainment()
> > > 3. The XML or Java names of the properties.
> > >
> > > I believe we will someday be able to loosen this definition, for
> > > instance, that the URI-Name pair does not have to match, or we can
> > > allow the properties in T1 to be a subset of those in T2.
> > But we can
> > > already do some pretty useful things with the definition.
> > > ____________________________________
> > >
> > > Definition: CAST
> > >
> > > Using this definition of compliance, I would like to define the
> > > following operation in the HelperContext interface
> > >
> > > DataObject cast(DataObject)
> > >
> > > with the following characteristics
> > >
> > > 1. If there is no type in the current HelperContext that
> > is compliant
> > > with the type of the argument, an exception is thrown.
> > > 2. If there is such a compliant type, the object returned
> > will have
> > > this type.
> > > 3. The values of data type properties in the returned
> > object have the
> > > same value as the corresponding properties of the original data
> > > object.
> > > 4. The value of complex typed properties in the returned
> > data object
> > > are data objects whose types are compliant with the type of
> > the data
> > > object returned by retrieving the corresponding property on the
> > > original data object.
> > >
> > > This is maybe clearer using the following semi-mathematical
> > > formulation.
> > >
> > > Consider object O1, where O1.getType() is T1 and where
> > > T1.getHelperContext() is C1.
> > > Consider a context C2, having a type T2 that is compliant to T1.
> > > Now
> > > DataObject O2 = C2.cast(O1)
> > >
> > > For each property P1 in T1 there is a property P2 in T2 such that
> > > P1.getName().equals(P2.getName() )
> > > If P1.getType().isDataType() is true then O1.get(P1)==O2.get(P2) If
> > > P1.getType().isDataType() is false, then if O1.get(P1) is null,
> > > O2.get(P2) is null, otherwise
> > > O2.get(P2)==C2.cast(O1.get(P1))
> > >
> > >
> > ______________________________________________________________________
> > > ____
> > >
> > > Now for some details I'd like to discuss:
> > >
> > > 1. What is the state of O1 after casting to O2?
> > >
> > > In our implementation, and also in the description of the cast
> > > operation that I gave at the F2F, each data object (O1 and O2) was
> > > depicted as a
> > > "view" of the same underlying data. The actual motivation
> > for this
> > > implementation was performance, that is, we wanted to avoid a copy
> > > step.
> > > This has the effect that both O1 and O2 are "live", that
> > is, changes
> > > to O2 are immediately visible in the O1. This *could be*
> > useful, but
> > > I would also say that the vast majority of time, either O1 or O2 is
> > > active, not both.
> > >
> > > I see three possibilities for what we say in the spec:
> > > a) We require both O1 and O2 to be live views of the same
> > underlying
> > > data.
> > > b) We say that O1 is unchanged by operations on O2. This more or
> > > less requires a copy step, which would make the cast operation
> > > expensive.
> > > c) We say that the state of O1 is undefined. In order to
> > > "reactivate"
> > > O1, we would have to cast it back from O2, that is we would have to
> > > explicitly say
> > > O1=C1.cast(O2), which would make O2 invalid, but bring O1 back
> > > into a valid and consistant state.
> > >
> > > 2. Does cast create objects, even if there are the underlying data
> > > already has a DataObject in the context?
> > >
> > > Is C1.cast(C2.cast(O1)) == O1? Or, more fundamentally, does a data
> > > object
> > > have only one ?view? in a particular context. Imagine that the
> > > object
> > > that is casted is the root of a complex graph, and that there are
> > > multiple paths (i.e., through non-containment references)
> > to some node
> > > in the
> > > graph: do we get the same object, no matter which path we take? I
> > > would say that all three of these behaviors are important.
> > To achieve
> > > them, the mental model is that the underlying data representation
> > > ?knows? which data object represents in which context.
> > >
> > > 3. How is the value of O2.getChangeSummary() related to
> > the value of
> > > O1.getChangeSummary()?
> > >
> > >
> > > Ron
> > >
> > > Von: Barack, Ron [mailto:ron.barack@sap.com]
> > > Gesendet: Montag, 18. Februar 2008 11:27
> > > An: sdo@lists.oasis-open.org
> > > Betreff: [LIKELY JUNK][sdo] ISSUE 66: Moving Data Between Contexts
> > >
> > > http://www.osoa.org/jira/browse/SDO-66
> > >
> > > Von: Barack, Ron [mailto:ron.barack@sap.com]
> > > Gesendet: Mittwoch, 13. Februar 2008 14:47
> > > An: sdo@lists.oasis-open.org
> > > Betreff: [LIKELY JUNK][sdo] New Issue: Moving Data Between Contexts
> > >
> > > Motivation:
> > > HelperContexts were motivated principally by the need to allow JEE
> > > applications to maintain independent type registries,
> > protected from
> > > possibly conflicting types that may be defined in other
> > applications.
> > > In
> > > an SCA environment, we can imagine HelperContexts being associated
> > > with contributions, since these normally define the boundries of
> > > artifact resolution, which includes the XSDs, java classes, or
> > > whatever else is being used to define types.
> > > If we envision SDO being used as data transport in a SOA,
> > for example,
> > > in SCA wiring, then it becomes clear that SDO must also
> > provide some
> > > mechanism for moving data between contexts. This is, in my
> > mind, the
> > > most common use-case for moving data between contexts. On
> > the other
> > > hand, it is completely possible for a single application to want to
> > > manage multiple contexts, and to want to move data between
> > contexts.
> > > In the discussion that follows, moving data between applications
> > > should be considered as a common use-case for a
> > functionality that can
> > > also be used within a single application.
> > > More specifically along the lines of our charter, the
> > ability to move
> > > data between contexts is the central concept behind our approach
> > > towards relaxing containment requirements. We are envisioning that
> > > some applications within the SOA environment will not have
> > need for or
> > > interest in signifying some relationships as being
> > containment, while
> > > other relationships are references. Other applications
> > will require
> > > containment, perhaps because they will serialize to XML, perhaps
> > > because they use some other feature, such as ChangeSummary,
> > > CopyHelper, or EqualityHelper that relies on containment.
> > If we are
> > > going to relax containment requirements, then we must
> > either redefine
> > > these features (which would break backwards compatibility),
> > or we must
> > > find a way to add containment information on the fly, so that this
> > > operations will still be available for data objects that come from
> > > contexts where containment does not make sense. This operation,
> > > adding containment information "on-the-fly", is, in this proposal,
> > > implemented as moving data objects from a context where the
> > types are
> > > defined without containment information to a context where
> > the types
> > > do have containment information. As previously stated, this could
> > > mean moving the data objects between applications, or
> > between contexts
> > > in a single application.
> > > The cast() method, which I want to introduce with this issue, was
> > > discussed at the F2F, and identified as a high priority for SDO 3.0.
> > > For
> > > more information on where this is all headed (slowly, with baby
> > > steps)
> > > please see:
> > >
> > http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26723/Co
> > > ntainment%20in%20SDO%203.ppt
> > > and
> > >
> > http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26711/SD
> > > O3%20Java%20Projections.ppt
> > >
> > > Description:
> > > Consider a DataObject O1, with Type T1, defined in context
> > C1. Define
> > > an operation that will "cast" from O1 to a DataObject O2, with Type
> > > T2, defined in context C2. The data objects O1 and O2
> > would provide
> > > alternative views of the same data. The Types T1 and T2 may differ
> > > slightly, for instance, in how containment is defined. In
> > order for
> > > casting to make sense, it will be necessary to define some
> > concept of
> > > "compatibility" of types, that is, what must T1 and T2 have
> > in common,
> > > in order for the cast operation to make sense. I would,
> > however, like
> > > to leave the exact definition of compatibility for a later
> > issue, and
> > > discuss the operation in principle first. The details of the
> > > relationship between
> > > O1 an O2, for instance, if changes to O2 are visible in O1,
> > however,
> > > should be determined as part of the resolution of this issue.
> > > Proposed Assignment JIRA Components:
> > > Topic 10: Containment
> > > Topic 7: TypeSystem and Helpers
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > 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
> > >
> >
> > Notice: This email message, together with any attachments,
> > may contain information of BEA Systems, Inc., its
> > subsidiaries and affiliated entities, that may be
> > confidential, proprietary, copyrighted and/or legally
> > privileged, and is intended solely for the use of the
> > individual or entity named in this message. If you are not
> > the intended recipient, and have received this message in
> > error, please immediately return this by email and then delete it.
> >
> > ---------------------------------------------------------------------
> > 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_workgr
> > oups.php
> >
> >
>
> Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]