Feeds

What can service data objects do for your SOA system?

Data without frontiers

Securing Web Applications Made Simple and Scalable

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.

Bridging the IT gap between rising business demands and ageing tools

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
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
DARPA-derived secure microkernel goes open source tomorrow
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Top 8 considerations to enable and simplify mobility
In this whitepaper learn how to successfully add mobile capabilities simply and cost effectively.
Seven Steps to Software Security
Seven practical steps you can begin to take today to secure your applications and prevent the damages a successful cyber-attack can cause.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.