Feeds

What can service data objects do for your SOA system?

Data without frontiers

High performance access to file storage

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:

  • Dynamic and static (strongly typed) data APIs
    SDO provides both a dynamic and a static API for accessing information within the data model. The static API allows for strongly typed access to data held within a data object. The dynamic API allows for very flexible processing of the data graph and retrieval of results.
  • Disconnected programming model
    Within SDO the connection between the originating data source and the SDO model is broken once the data has been retrieved. However, if necessary, the changes made to the data can be reflected back into the originate data source at a later date.
  • Introspection of data
    As an SDO data graph maintains a meta model of the data held within it, it is possible to determine what data is in the model purely from the SDO itself. The data model can indicate the type of a data item, the number of data items allowed, any sequencing information, etc.
  • Relationship integrity
    The meta model associated with an SDO data graph maintains information relating to relationships within the graph that will be checked and enforced by the SDO data structures.

High performance access to file storage

More from The Register

next story
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
US taxman blows Win XP deadline, must now spend millions on custom support
Gov't IT likened to 'a Model T with a lot of things on top of it'
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
HP ArcSight ESM solution helps Finansbank
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.