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.

Business security measures using SSL

More from The Register

next story
'Windows 9' LEAK: Microsoft's playing catchup with Linux
Multiple desktops and live tiles in restored Start button star in new vids
Not appy with your Chromebook? Well now it can run Android apps
Google offers beta of tricky OS-inside-OS tech
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Greater dev access to iOS 8 will put us AT RISK from HACKERS
Knocking holes in Apple's walled garden could backfire, says securo-chap
NHS grows a NoSQL backbone and rips out its Oracle Spine
Open source? In the government? Ha ha! What, wait ...?
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
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.
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.