Containment in SDO 3 XML Projections Ron Barack

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

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 A single root DataObject. A tree of DataObjects that can be reached by recursively traversing the containment 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.

Containment: Can‘t live with it, Can‘t live without it Containment violates core ideas of SDO! 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. 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! Defines the „bag“ of objects to be transported. Defines scope for operations like ChangeSummary CopyHelper Give the default „identity“ through which objects can be addressed. Language neutral wire-format XML Use-Cases are too important to be ignored.

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

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.

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“: x.detach(); // same as a.set(„propA“,null); b.set(„propA“,x);

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

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

Problem: Containment is „foreign“ to Java-Oriented Apps 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. 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. If the user fails to correctly specify containment, change summary and serialization will not work!

Approach to Weakening Containment Maintain backwards compatibility with 2.1. Continue to support XML oriented use-cases. 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. When an operation needs containment (or scoping) information, the information can be bound to a data model „on-the-fly“. 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.

Sample Code: Programming without containment School Student Course m:n 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 …

The same type, different contexts HelperContexts may hold contrasting definitions of the same type (as identified by its (URI, Name) pair. The type definitions may come from different sources. One may be defined by parsing an XSD, the other by inspecting a Java interface. 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 Context2 School DataObject: cal School Student Student DataObject: ron Course Course

Projecting between contexts 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. Casting a data object into a different context returns an object with the following characteristics The type of the created object is the corresponding type from the other context. Both data objects reflect the same underlying data. Changes to one are visible in the other. No copy step is necessary. By inspecting the data objects, there is no way to tell which is the projection, and which is the original. projection = context2.cast(ron) Context1 Context2 School DataObject: ron DataObject: projection School Student Student Name: Ron Major: Computer Sci Year: Junior … Course Course

API: Applying a Projection with HelperContext.cast DataObject helperContext.cast(DataObject original) 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. 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. The name „Cast“ comes from the Java concept. In both cases, casting returns a reference to the same underlying data, with a different interface.

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

SCA Wiring applies the projection, and converts to DOM Use-Case from SCA 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 EJB RDB DAS

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 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. Implementations would have to eagerly (as opposed to lazilly) update the entire datagraph. The same object could be part of 2 graphs, which value does getContainer() return. Applications would have to trust libraries to undo any changes to the current projection, and this could lead to bugs.

Generalizations of XMLInfo To define the scopes of ChangeSummary, CopyHelper, etc, full XMLInfo is not required, only the containment flag. In such cases, having the containment property in XmlInfo might be confusing. XmlInfo could be generalized by ContainmentInfo, to support cases where containment is required outside of XML use-cases. ContainInfo XmlInfo

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

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