Welcome!

Java Authors: Pat Romanski, Liz McMillan, Elizabeth White, Andreas Grabner, Brad Anderson

Related Topics: Java

Java: Article

What Is SDO?

Part 2 - A standardized approach to data programming particularly well suited to SOA

In Part 1 of this article we introduced SDO, looking at its origins and then reviewing some of its features through a scenario based on medical investigations. In Part 2 we'll go on to examine further features of SDO in such a way as to add property values to a data object beyond those explicitly defined by its type, the ability to record changes made to the data graph, a more elegant way to create types programmatically, and the ability to extend datatypes at runtime.

Our examples will depend on two XML Schema definition files that we'll reproduce here. The full details of the scenario they represent were presented in Part 1. These listings are available at http://gemsres.com/story/dec06/313547/source.html.

Part 1 of this article was published when version 2.01 of the SDO specification was current. Since then v2.1 has been released, however, in this article we'll continue to use version 2.01 for consistency.

Adding Open Content
The scenario begun in Part 1 now unfolds a little further. In particular, we'll examine the addition of values to a DataObject by virtue of the DataObject's type being open; that is to say, the property values in addition to those defined by its type. Joe Johnson has been found to have the rare condition, Panarr Syndrome. The designers of the test's data model have made use of the generic People model described in the first XML Schema from Part 1 and this design decision was only possible because the designer of the People model made the Person type open.

Note how in the schema for the medical test there are two global elements defined, one for the test itself and one for the medical condition. When the schema is read into the SDO runtime, these elements are translated into SDO global properties, scoped in the namespace URI of the schema. They're global properties, because they're not logically part of a type. It's this kind of global property that can be used to add information to an instance of an open type.

   Property conditionProperty = XSDHelper.INSTANCE.getGlobalProperty(
     "www.example.org/MedicalTest", "condition", true);
   DataObject condition = DataFactory.INSTANCE.create(
     "www.example.org/MedicalTest", "Condition");
   condition.setString("name", "Panarr Syndrome");
     List conditions = person1.getList(conditionProperty);
   conditions.add(condition);

In this code, SDO's XSDHelper has been used to look up the global property, and the DataFactory has been used to create a DataObject of the appropriate type. The interesting part of this code snippet is that when asked for the list of values associated with the "condition" property of the person DataObject, even though that property doesn't belong to the Person type and was never associated with the Person instance, the call to getList(conditionProperty) resulted in an empty list being created and returned. If the type of Person hadn't been open, this call would have resulted in an exception being thrown. Now we can simply add the condition to the list and any further serialization of this person instance will look like this:

   <person gender="male" id="1" name="Joe Johnson Snr.">
     <Test:condition name="Panarr Syndrome"/>
   </person>

It's worth noting that the SDO 2.1 specification adds to the SDO's capability for handling open content metadata and instance data.

Complex Graphs and Non-Containment References
In part 1 we examined one kind of relationship between data objects, that of containment. Every data object other than the root has exactly one parent data object that's its container. However, what if we want to express other relationships? In SDO these are represented by non-containment references.

We've already seen how SDO handles containment. We'll now explore adding complexity to the data graph by using non-containment links. Given the likelihood of members of Joe's family exhibiting Panarr Syndrome we'll add a list of Joe's relatives to the test set:

DataObject relatives = test.createDataObject("relatives");
DataObject person2 = relatives.createDataObject("person");
person2.setString("id", "2");
person2.setString("name", "Joe Johnson Jnr.");
DataObject relation = person1.createDataObject("relative");
relation.set("target", person2);
relation.set("relationship", "child");

This code snippet demonstrates the building of a complex graph using a non-containment link. We've created a new person in the test's set of relatives and made a link to that person from a new "Relative" property value for person1. So now our test looks like this:

<Test:Test xmlns:Test="www.example.org/MedicalTest"
   <referrals/>
   <patients>
     <person gender="male" id="1" name="Joe Johnson Snr.">
       <relative relationship="child" target="2"/>
       <Test:condition name="Panarr Syndrome"/>
     </person>
   </patients>
   <relatives>
     <person gender="male" id="2" name="Joe Johnson Jnr."/>
   </relatives>
</Test:Test>

Observe how the target attribute of the relative element has a value of "2," which is the id attribute value of the person "Joe Johnson Jnr" thus establishing the relationship from father to son. Looking back at the schema for Person, note how the use of the XML Schema "ID" attribute in the definition of the Person type and the "IDREF" attribute in the "Relative" type's target element lets us make this non-containment link. Having made the link, SDO needs a bit of help from the schema author to know what kind of value to expect the non-containment link to resolve to and so the "target" attribute is qualified by an sdoxml:propertyType attribute to indicate that any referenced objects will be the type Person.


More Stories By Kelvin Goodson

Kelvin Goodson is based at IBM Hursley in the UK as part of the Open Source SOA team. He is a committer to the Apache Tuscany incubator project, and works primarily on development of the Tuscany Java implementation of SDO. He gained a Ph.D. in image analysis and artificial intelligence in 1988, and has previously worked in the areas of medical imaging, weather forecasting and messaging middleware.

More Stories By Geoffrey Winn

Geoff Winn is based at IBM Hursley in the UK, as part of the Open Source SOA team. He is a member of the SDO specification group and currently works on development of the Apache Tuscany C++ implementation of SDO. He has degrees in Mathematics and Computation, and has previously worked in the areas messaging and brokering middleware.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.