This article is more than 1 year old
What can service data objects do for your SOA system?
Data without frontiers
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.
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).
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.
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
An introduction to SDO for PHP.
Biting the hand that feeds IT
