What can service data objects do for your SOA system?

Data without frontiers

The Power of One eBook: Top reasons to choose HP BladeSystem

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.


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.


SDO OSOA Resources page.

IBM SDO Introduction.

An introduction to SDO for PHP.

BEA Introduction to SDO.

HP ProLiant Gen8: Integrated lifecycle automation

More from The Register

next story
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Do YOU work at Microsoft? Um. Are you SURE about that?
Nokia and marketing types first to get the bullet, says report
Microsoft takes on Chromebook with low-cost Windows laptops
Redmond's chief salesman: We're taking 'hard' decisions
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
EU dons gloves, pokes Google's deals with Android mobe makers
El Reg cops a squint at investigatory letters
Chrome browser has been DRAINING PC batteries for YEARS
Google is only now fixing ancient, energy-sapping bug
Big Blue Apple: IBM to sell iPads, iPhones to enterprises
iOS/2 gear loaded with apps for big biz ... uh oh BlackBerry
prev story


Reducing security risks from open source software
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.