Monitoring Change
A major capability of SDO is being able to provide a summary of the changes made to a data graph. In SDO 1 this behaviour was the responsibility of a special class, the DataGraph. In SDO 2 you can get this behaviour through the DataObject interface by including a property of the ChangeSummaryType in your type definitions. This new feature offers flexibility in choosing the scope of change monitoring. For example, you might want to monitor the changes to the body of a Web Services message without monitoring its containing envelope. Here we'll focus on the new style of achieving this result. For this we must return to the original XML Schema for the medical test and add an element to the "Test" type.

   <complexType name="Test">
     <sequence>
       <element name="referrals" type="people:PersonSet" />
       <element name="patients" type="people:PersonSet" />
       <element name="relatives" type="people:PersonSet" />
       <element name="changes" type="sdo:ChangeSummaryType" />
     </sequence>
   </complexType>

The SDO specification defines the rules about the definition of types that include ChangeSummaryType properties. It also defines rules about assembling a data graph that includes data objects of such a type. These rules are in place to avoid the possibility of a graph having multiple change summaries describing overlapping areas of the graph.

Once you have a data object containing a change summary property you can access the change summary using the getChangeSummary() method (on any data object within the scope of the change summary). You can then use this change summary object to alter the logging state or query the changes that have occurred.

Imagine that we had been using the above type definition throughout our example and immediately after creating the test instance DataObject we turned on change monitoring as follows:

DataObject test = DataFactory.INSTANCE.create("www.example.org/MedicalTest", "Test");
test.getChangeSummary().beginLogging();
test.set("referrals", referrals);

Having done this, at any subsequent point in the program we can make use of the interface to the ChangeSummary object to examine the alterations in state that have occurred since the change monitoring was started.

As an example, imagine a data entry panel for adding and editing patient data. The ChangeSummary's undoChanges() method can be used to roll back all the changes made since logging began, and could therefore be used to underpin a "cancel" operation in the data entry panel. Knowing that the changes made to a graph opens up many other possibilities, for example, the above data entry panel could highlight all the changes made as the data is updated, or it could provide for a "commit" phase, where the operator is given an opportunity to review the changes before committing them. It would also be possible to use the change summary information to reduce inter-process communication by serializing and transmitting only the changed objects between the application layers.

Creating Types Programatically
In Part 1 of this article we first adoped an Apache Tuscany implementation-specific approach to creating types programmatically so we could introduce the concept of types and then we relied on the XML Schema-to-SDO Type conversion to do the bulk of our type system creation. The reason for starting with the non-standard Tuscany approach to building types was that the official method requires knowledge of SDO so we have a "chicken and egg" situation where you need types to build data objects and you need to understand how to build data objects to create your own types. We are now equipped to revisit type creation and do it the official way.

SDO has a TypeHelper interface that can be passed descriptions of the desired types and will produce those types and make them available for lookup later. The format for description of the types is a graph of data objects. There are two TypeHelper methods that let you define types; in the first you can submit a data graph describing a single type to the type helper, while the second lets you submit a list of data graphs to be processed all together and thereby generate a list of types. This is more than just a convenience and we'll explain later why there's a compelling reason for using this second option.

In preparing the description of our types we'll be building a number of similar data objects into data graphs so we'll create a little helper method to create a basic description:

private DataObject createTypeDescription(
     String uri, String name) {
   DataObject typeDesc = dataFactory.create(
     "commonj.sdo", "Type");
   typeDesc.set("name", name);
   typeDesc.set("uri", uri);
   return typeDesc;
   }

We now have enough understanding of the SDO API to know that this method builds a little one-node data graph with a root data object of the "Type" type with two properties, name and uri, having been set to the values supplied to the method. The "Type" type is built into the SDO runtime and is there specifically to build type descriptions. Note that this data object isn't itself a type, just a description of a type.

The first step in creating our type system programatically is:

DataObject personTypeDesc = createTypeDescription(
    "www.example.org/people", "Person");
List typeDeclarations = new ArrayList();
typeDeclarations.add(personTypeDesc);