Feeds

What can service data objects do for your SOA system?

Data without frontiers

Choosing a cloud hosting partner with confidence

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.

Intelligent flash storage arrays

More from The Register

next story
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Netscape Navigator - the browser that started it all - turns 20
It was 20 years ago today, Marc Andreeesen taught the band to play
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
Return of the Jedi – Apache reclaims web server crown
.london, .hamburg and .公司 - that's .com in Chinese - storm the web server charts
Chrome 38's new HTML tag support makes fatties FIT and SKINNIER
First browser to protect networks' bandwith using official spec
Admins! Never mind POODLE, there're NEW OpenSSL bugs to splat
Four new patches for open-source crypto libraries
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Cloud and hybrid-cloud data protection for VMware
Learn how quick and easy it is to configure backups and perform restores for VMware environments.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.