SOA & Web Services - What Is SDO?

Part One: The value of many of the facets of SDO

  Service Data Objects (SDOs) simplify and unify Service Oriented Architecture (SOA) data access and code.

SDO complements the strength that SCA (Service Component Architecture) offers for simplifying development of SOA-based solutions. SCA handles the composition of service networks and SDO focuses on simplifying data handling. These technologies are getting significant support in the industry. The development of the SDO and SCA specifications is in the hands of the Open Service Oriented Architecture collaboration (www.osoa.org) and open source implementations of these specifications are being developed in the Apache Tuscany incubator project (http://incubator.apache.org/tuscany).

In this two-part article we use a scenario to demonstrate the value of many of the facets of SDO.

 Some History

The first SDO specification was published in November 2004 as a result of collaborative between IBM and BEA. The Eclipse Foundation developed an open source implementation of this SDO 1 specification. SDO primarily addressed the lack of general applicability of the existing technologies such as JAXB and JDO. Around that time Microsoft entered this space with ADO.NET, offering a slightly different technical perspective. The SDO 2.0.1 specification appeared late in 2005 and is continuing to evolve, with wider industry involvement; at the time of writing revision 2.1 is imminent and revision 3.0 is in the pipeline.

 

SDO provides flexible data structures that allow data to be organized as graphs of objects (called data objects) that are composed of properties. Properties can be single or many valued and can have other data objects as their values. A data object can maintain a change summary of the alterations made to it, providing efficient communication of changes and a convenient way to update an original data source. SDO naturally permits disconnected data access patterns with an optimistic concurrency control model.

SDO offers a convenient way to work with XML documents. SDO implementations provide helpers to populate a data graph from both XML documents and relational databases and to read SDO metadata from an XML Schema Definition (XSD). Data objects can be serialized to XML and the metadata can be serialized to an XSD file (see Figure 1).

Data Objects can be introspected using the SDO metadata API to get information about types, relationships, and constraints.

SDO delivers unified and consistent access to data from heterogeneous sources. This provides both a simple programming model for the application programmer and lets tools and frameworks work consistently across those heterogeneous data sources.

SDO offers a single model for data across the enterprise.

The diagram below shows a WebUI client accessing data from a variety of sources, mediated by SDO. Web applications typically operate in a semi-connected fashion and rely on optimistic-concurrency. SDO is well suited to this environment, where data can be manipulated remotely and then a summary of the changes can be delivered back to the data sources (see Figure 2).

The following sections will introduce SDO in more detail.

A Scenario
This example is based on an imaginary project inspired by some real-world scenarios. A hypothetical group of universities, hospitals, and companies have embarked on a long-term collaboration to study some family of diseases that has both a genetic and environmental component. They will need to exchange the medical histories of the people they're treating and studying, and also exchange the medical histories of relatives. The data will likely come from disparate sources; basic patient data will probably be in a relational database; data from medical investigations conducted as part of this research project will be in XML documents; other medical data may come from less well known formats or custom sources. The amount of data about any given person will vary greatly. A long-standing patient may come with an extensive medical history. A relative might have little beyond name and relationship. This data has to be assembled into a coherent manageable whole, and SDO is an attractive option for representing a complicated mix of data about each person and potentially maintain a graph of such entities. For this example, we can't even assert that the graph is a (family) tree because with adoption, re-marriage, fertility treatment, and so on, one person's associations with others can be quite intricate.

The various institutions involved may not want to give unrestricted access to their data sources, although they've agreed to supply pieces of it as needed. A hospital may be willing to provide the medical data associated with one patient as part of an investigation, but they won't permit open access to their entire patient record database. Similarly, a company will want to limit access to commercially sensitive material. SDO provides a convenient way for the owner of the data to deliver to outsiders a subset of that data of their own choosing.

We'll now show some of the key values of SDO through this scenario.

To illustrate where an SDO feature helps, consider a scenario where a hospital refers a patient to a university for further investigation. Relevant data will have to flow from the hospital to the university, and it may well come from a variety of different sources. Assume that name, age, records of visits, and so forth comes from an SQL database, while specific medical data (the results of tests) are in XML documents. Using standard SDO features it's straightforward for the hospital to combine these various sources into a data object and send that, letting users of the data access it via SDO's unified API.

The university does whatever it does with the patient, and then updates the SDO and sends it back. The change history in the SDO lets the hospital apply the updates to its various data repositories without the university ever needing to know the detail of those repositories.

It's unlikely that these updates will clash with other updates made independently by the hospital, but if they do, the use of an SDO change summary ensures that this is detected and sorted out (probably manually in this case). The software component responsible for moving data between the data source (for example, a relational database in this case) and SDO is called a Data Access Service (DAS). A DAS can typically also handle conflicting updates.¹

Using SDO as the data exchange format makes the system tolerant of the considerable variation to be expected in such a loosely coupled system. It's inevitable that, sooner or later, the versions of the applications that are sending and receiving data will get out-of-step. In fact, this may be usual. However, the fact that an SDO can arrive with its own metadata means that an older application can always retrieve what it wants from a newer (and presumably richer) input SDO - ignoring anything that it doesn't recognise. In the reverse case, a newer application can similarly recognise that the information it has received is from an older version and compensate accordingly.

In the previous scenarios, we've concentrated mostly on XML and SQL data sources. Now, let's suppose that in one hospital the results from the biochemistry lab are delivered in HL7 message format. This message format is widely used in the healthcare industry but is virtually unknown outside it, and so there's no off-the-shelf way to read such messages into an SDO. At this point there are several choices. We could use some broker-style product to reformat the HL7 into XML and then read it into an SDO or we could pay someone to write a new DAS that would populate an SDO directly from HL7. Since our collaborators are using an open source implementation of SDO, however, they opt to write their own DAS and donate it to the Apache Software Foundation's Tuscany project.

Other approaches exist to linking these various organisations, such as putting some software intermediary in the middle and using that to convert the data as needed. To do so though requires knowledge of all the possible input and output formats and how to convert between them. In such a loose collaboration there simply is no such central authority.

We now turn our attention to presenting the details of SDO using some code fragments.