Feeds

What can service data objects do for your SOA system?

Data without frontiers

Internet Security Threat Report 2014

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.

Choosing a cloud hosting partner with confidence

More from The Register

next story
Euro Parliament VOTES to BREAK UP GOOGLE. Er, OK then
It CANNA do it, captain.They DON'T have the POWER!
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Post-Microsoft, post-PC programming: The portable REVOLUTION
Code jockeys: count up and grab your fabulous tablets
Twitter App Graph exposes smartphone spyware feature
You don't want everyone to compile app lists from your fondleware? BAD LUCK
Microsoft adds video offering to Office 365. Oh NOES, you'll need Adobe Flash
Lovely presentations... but not on your Flash-hating mobe
prev story

Whitepapers

10 ways wire data helps conquer IT complexity
IT teams can automatically detect problems across the IT environment, spot data theft, select unique pieces of transaction payloads to send to a data source, and more.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
How to determine if cloud backup is right for your servers
Two key factors, technical feasibility and TCO economics, that backup and IT operations managers should consider when assessing cloud backup.
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 and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.