1. Containment and XML Projections in SDO 3.0 Ron Barack - SAP …

2. Agenda n Why is containment such a problem? n Proposal: Exceptions, not side-effects n Proposal: XML Projections and Containment

3. Towards the Liberation of Data Graphs In SDO 1.0 : a graph of DataObjects were always wrapped by a commonj.sdo.DataGraph envelope object Since SDO 2.0 : a graph of DataObjects can exist outside of a commonj.sdo.DataGraph, but it still true that the normal state for a data graph was to have l A single root DataObject. l A tree of DataObjects that can be reached by recursively traversing the containment l Non-containment references point to DataObjects within the tree In SDO 3.0: our objective is to liberate data graphs from the containment tree. A data graph is just that, a connected set of DataObjects, with no root, no tree-like structure.

4. Containment: Can‘t live with it, Can‘t live without it Containment violates core ideas of SDO! l DataSource independence: SDO should be independent of it‘s backend. Many applications don‘t care about XML representation. Sequenced and mixed(!) map poorly to non-document models. l Simplicity: „setters“ have side-effects, poorly understood by Java programmers which can be the source of bugs. Containment is the solution to many core problems! l Defines the „bag“ of objects to be transported. l Defines scope for operations like n ChangeSummary n CopyHelper l Give the default „identity“ through which objects can be addressed. l Language neutral wire-format l XML Use-Cases are too important to be ignored.

5. Agenda l Why is containment such a problem? l Proposal: Exceptions, not side-effects l Proposal: XML Projections and Containment

6. Problem: Containment Side-Effects SDO 2.1 specifies that when setting a containment property, the argument is implicitly and silently removed from ist old container. Imagine that propA is a containment property and that a, b, and x are DataObjects, then a.set(„propA“,x); b.set(„propA“,x); Afterwards, a.get(„propA“) returns null. This is not what java-oriented users expect, and is very hard to debug. Usually, they get a NPE long after and far away.

7. Proposal: Fail-early for containment side-effects Rather than allowing a „set“ operation to produce a side- effect, throw an exception when the object already has a container. a.set(„propA“,x); b.set(„propA“,x); // throws exception When the user really wants to move the object, he must do a „detach“: a.set(„propA“,x); x.detach();// same as a.set(„propA“, null); b.set(„propA“,x);

8. What about Bi-directional properties? n The same side-effects can also occur in 1:n bi-directional properties. n We should fail early there, too!

9. Agenda l Why is containment such a problem? l Proposal: Exceptions, not side-effects l Proposal: XML Projections and Containment

10. Problem: Containment is „foreign“ to Java-Oriented Apps n Java applications make frequent use of m:n, bi- directional, and/or otherwise cyclic relationships, which make the mapping to containment and non- containment properties not straightforward. n There is no way to use existing JavaBean like interfaces directly as SDO metadata except in very trivial cases: the programmer must „artificially“ annotate the interface with containment information. In many cases, this is the only thing preventing this re-use scenario. n If the user fails to correctly specify containment, change summary and serialization will not work!

11. Requirments for Relaxing Containment n Maintain backwards compatibility with 2.1. n Continue to support XML oriented use-cases. n Applications can ignore containment as long as they don‘t perform any operations (such as marshalling to XML, or limiting the scope of a ChangeSummary) that rely on it. n When an operation needs containment (or scoping) information, the information can be bound to a data model „on-the-fly“. n Allow for different projections in the same application space (e.g. a component providing 2 web services, with different schemas) We want to allow users to ignore containment, and making it less restrictive, but still support containment where it is needed.

12. Sample Code: Programming without containment DataObject cal = das.get(„berkeley“); DataObject ron = cal.get(„student[name=‚ron‘]“); DataObject course = cal.get(„course[name=‚math‘]“); ron.getChangeSummary().beginLogging(); // transitive closure? XMLHelper.INSTANCE.save(cal); // throws a graph-not-closed exception … Student Course m:n School

13. The same type, different contexts n HelperContexts may hold contrasting definitions of the same type (as identified by its (URI, Name) pair. n The type definitions may come from different sources. One may be defined by parsing an XSD, the other by inspecting a Java interface. n The type definitions may vary slightly. E.G, the type defined through an XSD will always contain containment info, but the type generated from a Java Interface may out leave this information. Context1 School Student Course Context2 School Student Course DataObject: ron DataObject: cal

14. n If the types are somehow (to be defined) consistent with each other, it should be possible to cast DataObjects from one context to the other. n Casting a data object into a different context returns an object with the following characteristics l The type of the created object is the corresponding type from the other context. l Both data objects reflect the same underlying data. Changes to one are visible in the other. No copy step is necessary. l By inspecting the data objects, there is no way to tell which is the projection, and which is the original. Projecting between contexts Context1 School Student Course Context2 School Student Course DataObject: ron DataObject: projection Name: Ron Major: Computer Sci Year: Junior … projection = context2.cast(ron)

15. API: Applying a Projection with HelperContext.cast DataObject helperContext.cast(DataObject original) n This method projects a DataObject from one context to another, returning a new DataObject whose Type definition is registered in the TypeHelper associated with the helperContext. The returned object ( returnValue ) is an additional view of the same underlying data. Setters called on the original DataObject are reflected in the casted object and vice-versa. Navigating from returnValue returns objects that are casted, ie, are in the same helperContext as returnValue. n There is at most one „cast“ of any data object into any helper context. Subsequent calls to cast on the same helperContext, giving the same DataObject, or any „cast“ of the the original object, always returns the same object. n The name „Cast“ comes from the Java concept. In both cases, casting returns a reference to the same underlying data, with a different interface.

16. By supplying another XSD, we could just as easilly create another document, in which courses contained students! <element name=‚student‘ type=‚tns:StudentType‘ maxOccurs=30000/> <element name=‚courses‘ type=‚tns:CourseType‘ maxOccurs=100/> Ron HelperContext xmlContext = … xmlContext.getXSDHelper().define(); DataObject cal = das.get(„berkeley“); DataObject projected = xmlContext.project(cal); xmlContext.getXSDHelper.save(projected); Student Course m:n School

17. Use-Case from SCA RDB DAS EJB On this side, no XML/ containment metadata is needed or desirable JBPM BPEL On this side, a DOM Element is required SCA Wiring SCA Wiring applies the projection, and converts to DOM

18. Alternative: Defining a current projection The proposal currently involves creating a projected datagraph. This has a downside in that objects are generated (although all projections should reference the same underlying data). The possibility of setting a current projection was also considered: void dataObject.setProjection(Projection p); This idea was rejected as leading to conflicts, eg n What is the effect on objects that are somewhere lower in the tree with root dataObject? The application may already be holding such references when setProjection is called. l Implementations would have to eagerly (as opposed to lazilly) update the entire datagraph. l The same object could be part of 2 graphs, which value does getContainer() return. l Applications would have to trust libraries to undo any changes to the current projection, and this could lead to bugs.

19. Option: Default Containment n Objects that are not contained by other data objects are contained by a default object, which can be found by helperContext.getDefaultContainer() n The default container has one (multivalued) property „objects“ with type {commonj.sdo}DataObject. n We still need a mechanism like HelperContext.cast, to add „real“ containment data. So this is at best an addition to the projection proposal n Advantage: l Default XML representation even when no containment information is present.. n Questions: l What is the lifecycle of DataObjects? When will they be garbage collected? l How is the container managed? Per-thread?

20. Open Questions… n What is the behavior of CopyHelper, ChangeSummary when no projection metadata is available? l Shallow? l Transient-closure? n Can a default XML serialization be defined, even in the absence of any projection metadata? l Depth-first? l Use a reference if the DataObject has already been serialized? n How are SDOs serialized (in the java.io sense)? l Does this need to be specified? n Is the ChangeSummary associated with a projection, or with the „underlying data“. That is, is there only one ChangeSummary, or one per projection. n Does each projection have its own, sequence, or is there only one?

21. More Questions: l What are the rules associated with mapping types/properties during projections? l Do URI/ Name have to match? Could also be based on the „shape“ of the type. l The order of the properties may be different. We should handle this. l Must the properties match up 1:1? It certainly works if the projected object has fewer properties, what happens if it has more? n In particular, I can imagine „filling in“ opposite properties, in case the projection has them and the original doesn‘t

22. Summary of Proposals n Text stating that „closure is the normative state for data graphs“ should be removed. n Objects should never be silently removed from their container as a side effect. n HelperContext.cast(DataObject)

23. Thank you! Questions?