Containment and XML Projections in SDO 3.0

Ron Barack - SAP…

Agenda

Why is containment such a problem?

Proposal: Exceptions, not side-effects

Proposal: XML Projections and Containment

Towards the Liberation of Data GraphsIn 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 containmentNon-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 itContainment 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.

Agenda

Why is containment such a problem?

Proposal: Exceptions, not side-effects

Proposal: XML Projections and Containment

Problem: Containment Side-EffectsSDO 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-effectsRather 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);

What about Bi-directional properties?

The same side-effects can also occur in 1:n bi-directional properties.

We should fail early there, too!

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!

Requirments for Relaxing 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

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 Coursem:n

School

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

School

Student

Course

Context2

School

Student

Course

DataObject: ron

DataObject: cal

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.

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)

API: Applying a Projection with HelperContext.castDataObject 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.

By supplying another XSD, we could just as easilly

create another document, in which courses

contained students!

<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><complexType name=‚CourseType‘> <attribute name=‚name‘ type=‚xs:string‘ /></complexType>

<tns:School> <student> <name>Ron</name> <courses name=‚Basket Weaving‘/> <courses name=‚Algol 68‘/> </student></tns:Student>

HelperContext xmlContext = …xmlContext.getXSDHelper().define();DataObject cal = das.get(„berkeley“);DataObject projected = xmlContext.project(cal);xmlContext.getXSDHelper.save(projected);

Student Coursem:n

School

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

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.

Option: Default Containment Objects that are not contained by other data objects

are contained by a default object, which can be found by helperContext.getDefaultContainer()

The default container has one (multivalued) property „objects“ with type {commonj.sdo}DataObject.

We still need a mechanism like HelperContext.cast, to add „real“ containment data. So this is at best an addition to the projection proposal

Advantage: Default XML representation even when no containment

information is present.. Questions:

What is the lifecycle of DataObjects? When will they be garbage collected?

How is the container managed? Per-thread?

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

Summary of Proposals

Text stating that „closure is the normative state for data graphs“ should be removed.

Objects should never be silently removed from their container as a side effect.

HelperContext.cast(DataObject)

Thank you!

Questions?