1 / 23

Containment and XML Projections in SDO 3.0 Ron Barack - SAP

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 Graphs.

mthompson
Download Presentation

Containment and XML Projections in SDO 3.0 Ron Barack - SAP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Towards the Liberation of Data Graphs In SDO 1.0 : a graph of DataObjectswere 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.

  4. 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.

  5. Agenda • Why is containment such a problem? • Proposal: Exceptions, not side-effects • 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? • The same side-effects can also occur in 1:n bi-directional properties. • We should fail early there, too!

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

  10. 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!

  11. 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.

  12. School Student Course m:n 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 …

  13. Context2 Context1 School DataObject: cal School Student Student DataObject: ron Course Course 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.

  14. projection = context2.cast(ron) Context2 Context1 School DataObject: ron DataObject: projection School Student Student Name: Ron Major: Computer Sci Year: Junior … 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.

  15. 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.

  16. School Student Course m:n <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> By supplying another XSD, we could just as easilly create another document, in which courses contained students! 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>

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

  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 • 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.

  19. 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?

  20. 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?

  21. 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

  22. 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)

  23. Thank you! Questions?

More Related