Original URL: http://www.theregister.co.uk/2007/04/17/intro_service_data_objects/

What can service data objects do for your SOA system?

Data without frontiers

By John Hunt

Posted in Developer, 17th April 2007 09:33 GMT

Column In the last two columns, I looked at how you can build services within a Service Oriented Architecture (SOA) using the Service Component Architecture (or SCA) framework.

In the second of these two columns, I hinted that you could use another tool called Service Data Objects (SDO) in conjunction with SCA. In this column and the next, we will look at SDO, what it is, what it can offer, and why it is of interest if you are building SOA systems.

Data within services

So, you have read the last two columns and can now build SCA based services – great. So what is the interest in SDO then? Let us first review what goes on within a SOA system. In such a system, clients invoke the services that comprise the system over an appropriate mechanism (using protocols and transport mechanisms such as SOAP/HTTP or SOAP/JMS).

These services often take parameters and return results that are consumed by the clients. The way in which the data is passed into a service, and returned from that service, needs to be compatible with the invocation technology underlying the SOA system. For web service based SOA, this means being capable of transfer using SOAP over HTTP or JMS, which either requires marshalling/un-marshalling of data into an appropriate XML format; or the transmission of XML documents describing the data. Although these approaches are certainly feasible, they have their own drawbacks.

First off, let us consider the use of a marshalling service. This approach does have some practical drawbacks. For example, the marshalling/un-marshalling processes can be time consuming and memory hungry. They may also have issues when converting data between implementation platforms (such as Java and C++). It may also tie the implementation to a particular application server vendor or technology.

Secondly, the use of a plain XML document approach requires the processing of that XML document within the service and the client. This relies on knowledge and experience of XML, appropriate XML processing APIs (in the appropriate implementation languages), and related technologies such as XML schemas, XPATH etc. In addition, analysis of these XML documents may also involve additional memory or processing overhands. For example, if the XML document is loaded into memory as a DOM, which must then be searched.

An alternative approach is presented by Service Data Objects (or SDO). This is a specification (and implementation) that is designed to simplify and unify the way different applications, potentially implemented in different languages, handle data. The SDO specification is independent of any SOA related technology, and indeed was written as a general way to allow any application programmer to access and manipulate data without the need to have knowledge of where that data originated. However, SDO can be easily and simply used with the Service Component Architecture (SCA), which is one approach to the creation of services within a SOA system.

In the remainder of this column, we will look at SDO, what an SDO system might look like, what the elements that make up SDO are and present a simple SDO example. We will then consider how SDO can be, and should be, used within a SCA based SOA system.

Service data objects overview

As I mentioned above, Service Data Objects (SDOs) are intended as a unifying representation of data that can be obtained from a diverse range of data sources (such as relational databases, XML data sources, web services, files, etc) without the need for the developer to know about these diverse APIs. SDO allows data to be created, updated, and deleted and for these changes to (optionally) be transmitted back to the originator of the data.

SDO is currently an Open Service Oriented Architecture (OSOA) specification in version 2.1. However, it was recently announced (March 2007) that OASIS will now take over the non-Java SDO specification as a standard and that the Java version of SDO will move back into the JCP process (its previous home, back in 2003).

In the current OSOA SDO specification there are a number of features that are intrinsic to SDO which also make it suitable for use within a SOA system. These features include:

In the following sections, I will expand on the core concepts within SDO that aim to support the above.

Service data objects

SDO Architecture

Within SDO, there are two important concepts that work together to allow an application to use an SDO implementation. These are the SDO Core API and the Data Mediator Service (DMS). The relationship between these two elements and the user of SDO is illustrated in Figure 1. This diagram shows that application requesting a SDO DataGraph from a DMS.

Diagram of SDO Architectural Overview.

As you can see from this diagram, the DMS buffers the application from the underlying, or native, data source. The actual data source could be a custom API, a relational database accessed via JDBC, an EJB, flat files etc. All these data sources could provide the same SDO data model without the application ever being aware of them.

We will initially focus on the SDO Core API as this is the primary focus of the SDO specification. It also happens to be the most relevant part of SDO from a SOA system perspective. That is, the DMS is currently outside the scope of the SDO specification; although it is still a useful conceptual entity.

The SDO Core API is comprised of a number of components; these are the DataGraph, the DataObject and metadata around the data object. These areas will be covered in the next few sections.

The data graph within SDO

At the heart of the SDO Core API is the data graph concept. This is because a key aspect of SDO is that the data is represented in a graph of data objects. The data graph holds a reference to a root data object, from which all data objects in the graph can be accessed. Thus the data graph itself does not directly hold the data. Instead, the data is held within the data objects. The data objects in turn reference meta data that describes the data they hold.

Figure 2 illustrates the relationship between the DataGraph object, the DataObject, the ChangeSummary (used to represent changes such as additions, deletions and updates to the data graph).

Diagram of a Data graph model.

Within SDO, a data graph is expected to be passed between applications. Thus, a data graph would be taken as a parameter for a service or returned as the result of that service (although, in practice, individual data objects can also be used).

The data object

Within the data graph, the core element is the data object. This is the fundamental component within SDO, as this is the object that holds the actual data and references metadata that describes the contents of the data object.

Diagram of a Data Object model.

The above diagram illustrates the structure of the data object class and its related type information and properties. The data within a data object may be a primitive type (such as an integer or a string) or it may be a reference to other data objects (and hence a graph of data objects can be constructed). The data itself is held in the form of properties that can be accessed either directly by name, by a positional index or via the property object (referenced by the data object). In addition, it is also possible to use an XPATH expression to search a graph of data objects for required data. This is a particularly powerful feature of SDO.

Data Mediator Service

One of the interesting features of SDO is its assumption that an intermediary will be used to actually access the data from the underlying data source and supply this to the application using SDO. The data is obtained via an intermediary called a Data Mediator Service (also known as a Data Access Service).

The DMS provides a data graph for a given data source to an application. This application can then modify the data graph and send the updated data graph back to the DMS that will then apply the changes back onto the originating data source. Alternatively, an application may read from one DMS and write to another DMS etc.

At present the DMS is more conceptual than concrete as the SDO specification does not define the DMS mechanism. Within a SOA system, the application that consumes the results of a service invocation can view the service implementation as the DMS, although this may be of limited use. In general, it really provides more of a reusable pattern for accessing and storing SDOs within a service client or a service implementation, than an aid to the use of SDOs within, for example, SCA.

SDO Implementation

SDO is merely a specification – it is not an implementation. However, there are a number of SDO implementations available including those from IBM within the Feature Pack for SOA and BEA's AquaLogic. Alternatively, you can use the Apache Tuscany SDO implementation, which is the version used here.

To get an SDO implementation for use with the next article, you should download the Tuscany version appropriate for your platform.

Summary

Service Data Objects or SDO offers a platform and language independent format for exchanging data between applications. This standardised data format has been around for some time, however, and supports a range of languages including Java, PHP, and C++.

In the next column, we will look at a concrete example that uses the Tuscany implementation of SDO and consider how it can be used within an SOA service.

References

SDO OSOA Resources page.

IBM SDO Introduction.

An introduction to SDO for PHP.

BEA Introduction to SDO.