Back to Article List

Originally published June 2006 [ Publisher Link ]

SDO - Service Data Objects

Accessing data is the lifeblood of any application, but the various manners in which its stored has given way to many techniques for tapping such information. Depending on the software platform and programming language you use, you will more than likely be immersed in a particular data access method, unfortunately this same method will also be more than likely applicable only to your platform-language. In the context of service-oriented architecture (SOA), where reusability is a cornerstone, many data access methods fall short on this last requirement. That's the reason why a mechanism named Service Data Objects (SDO) has been created.

The reality is that there is no shortage of data access methods, Java has JDBC, JDO and JAXB to name a few, while Microsoft has ADO.NET, ODBC and ActiveX to also name a few, but each one of these methods is designed with a particular purpose in mind. Some of them are designed exclusively for accessing relational databases while others are used for purposes like accessing XML structured data or flat files.

Even then, in SOA most data access can be done behind the scenes while using a service facade, making data access transparent from the underlying access technology and repository, so do we really need another data access mechanism especially designed for a SOA? The short answer is yes, since there is no established roadmap or name if you will, for the issue just described.

Think about this possibility: Wouldn't it be easier and more efficient to use a unified manner in which to access any type of data store -- relational, XML , in-memory or other -- and modify it independently of the programming language or platform being used? Well, this is exactly what SDO is all about.

At a technical level, SDO defines its building blocks as data graphs, containers which posses data tree structures, each one having its own data types, metadata, parent-child relationships, cardinality relationships, default values or any other property commonly related to data structures. The important thing to realize about these data graphs is that they can be constructed from any type of data store -- relational, XML or any other proprietary format -- the main benefit being data can be inspected and modified through a uniform approach irrespective of its origin.

Complementing the use data graphs in SDO are data mediator services, which are charged with constructing data graphs from the many data repository variations and access technologies supporting SDO. In this sense you can expect to find data mediator services for Java relational database access or PHP XML access, to cite a few examples. The point here is that once this level of indirection is addressed, data graphs can be manipulated not only independently of their data repository type, but also irrespective of the access technology being used.

Before you make any judgment on SDO's merits of making a big splash in SOA or as a data access mechanism, you should be aware that SDO's functionality is not something that emerged from any SOA needs, but rather from the Java camp. SDO's origins date back to late 2003 as JSR-235 of the Java community process. At that time, SDO was probably tagged by many as yet another API in the growing body of Java libraries no matter how interesting the term "heterogeneous data access" sounded, a fact that should be evident seeing how SDO faired against other Java technologies related to data that exploded around the same time, such as Hibernate.

So you might now ask: Why is SDO which has had relative success in Java be that relevant for SOA? In regards to SDO's success in Java, this is more than likely because it was trying to solve something that was already achievable through any number of APIs. The thought of a unified API for accessing any data repository is a nice one, but the adoption rate of SDO seems to point to vendors and users wary of yet another Java API. In the case of SDO's relevancy within SOA, this does not come as a standalone technology, but rather a complementary technology to Service Component Architecture (SCA).

In a previous column addressing SCA , we mentioned the fact this initiative has gained strength among a series of vendors and, as it turns out, the component model proposed by SCA is a natural fit for the same principle offered by SDO. With that said, lets take a look at how SCA and SDO work together using Apache Tuscany .

Apache Tuscany provides two language implementations for SCA and SDO, one built for Java and another for C++. The following example illustrates a Java based SCA runtime making use of a Java SDO. Being an Apache project, Tuscany is heavily based on other Apache projects such as Axis2, Tomcat and Geronimo, so knowledge in these platforms can be considered a prerequisite, especially in regards to deployment issues. Our first listing illustrates a SCA module descriptor.

<?xml version="1.0" encoding="UTF-8"?>
<module 
    xmlns="http://www.osoa.org/xmlns/sca/0.9" 
    xmlns:v="http://www.osoa.org/xmlns/sca/values/0.9"
        name="customerinfo">
        
    <import.sdo schemaLocation="wsdl/customer.xsd"/>
    <import.wsdl wsdlLocation="wsdl/customerinfo.wsdl"/>

        
    <component name="CustomerInfoServiceComponent">
     <implementation.java class="CustomerInfoServiceImpl"/>
    </component>

</module>

This descriptor is used in the deployment of an SCA module. Notice how at the top there is a line reading import.sdo, which is associated with an XML schema named customer.xsd, this defines the structure for the data object. Second, you can observe the tag <component>, which is used to refer to an SCA component, that in itself contains the nested element <implementation>. This last value is associated with an implementation class that makes use of the SDO API, which is illustrated in Listing 1.2.

import org.apache.tuscany.core.sdo.helper.SDOHelper;

import commonj.sdo.DataObject;
import commonj.sdo.helper.DataFactory;


public class CustomerInfoServiceImpl {

    @SDOHelper
    public DataFactory dataFactory;
    
    public DataObject getCustomerInfo(String customerID) {

    DataObject customer = 
         dataFactory.create("http://customer", "Customer");
    customer.setString("customerID", customerID);
    customer.setString("firstName", "John");
    customer.setString("lastName", "Smith");
    return customer;
    }

}

Notice how this class makes use of the DataObject, which is central to defining an SDO. This particular SDO class has its data values hard-coded for simplicity, but an elaborate example would establish a connection to a data repository at this point via a data mediator service. Finally, lets take a look at how an SCA client would tap this SDO, listing 1.3 illustrates such a client.

import java.lang.reflect.Method;
import java.util.Properties;
import java.util.logging.Level;
import java.util.logging.LogManager;

import org.apache.tuscany.common.monitor.MonitorFactory;
import org.apache.tuscany.common.monitor.impl.JavaLoggingMonitorFactory;
import org.apache.tuscany.core.client.TuscanyRuntime;
import org.osoa.sca.CurrentModuleContext;
import org.osoa.sca.ModuleContext;

import commonj.sdo.DataObject;

/**
 * This client program shows how to create an SCA runtime, 
 * start it,locate the CustomerInfo service and invoke it.
 */
public class CustomerInfoClient {

 public static final void main(String[] args) 
                                    throws Exception {
        
        // Setup Tuscany monitoring to use java.util.logging
        LogManager.getLogManager().readConfiguration(
CustomerInfoClient.class.getResourceAsStream("/logging.properties"));
        Properties levels = new Properties();
        MonitorFactory monitorFactory = 
new JavaLoggingMonitorFactory(levels, 
                              Level.FINEST, "MonitorMessages");

        // Create a Tuscany runtime for 
        // the sample module component
        TuscanyRuntime tuscany = 
new TuscanyRuntime("CustomerInfoModuleComponent",
                    "http://customerinfo", monitorFactory);

        // Start the Tuscany runtime and associate it 
        //with this thread
        tuscany.start();

        // Get the SCA module context.
        ModuleContext moduleContext = 
                 CurrentModuleContext.getContext();

        // Locate the CustomerInfo service
        Object customerInfoService = 
moduleContext.locateService("CustomerInfoServiceComponent");
        
        // Invoke the CustomerInfo service
        Method getCustomerInfo = 
customerInfoService.getClass().getMethod("getCustomerInfo", 
                     new Class[] {String.class});
        DataObject customer = 
(DataObject)getCustomerInfo.invoke(
                         customerInfoService, "37645");
        
System.out.println("customerID = " + 
                    customer.getString("customerID"));
System.out.println("firstName = " + 
                    customer.getString("firstName"));
System.out.println("lastName = " + 
                    customer.getString("lastName"));
System.out.flush();

    // Disassociate the runtime from this thread
    tuscany.stop();

    // Shut down the runtime
    tuscany.shutdown();
    }

}

Among the most relevant calls in this class we find moduleContext.locateService("CustomerInfoServiceComponent");, this line is used for locating an SCA module by the name CustomerInfoServiceComponent, which if you recall is the same name declared in the deployment descriptor for the module associated with the SDO implementation class. Further along, we once again find the DataObject from SDO, but on this occasion, it's issued to invoke calls on the actual SDO object instance customerInfoService with customerID number 37645.

Now, if you analyze this last example purely from the Java standpoint you won't find it that exciting. As a matter of fact, the deployment and localization process is pretty reminiscent of the standard Java/J2EE model. But on the other hand, if you start to swap both SCA runtimes & SDO components written in languages like C++ or PHP and they can still localize and execute business logic amongst each other, you will see the benefit the SCA/SDO approach has.

With this we conclude our look at SDO, an approach which was once relegated to the Java world, but has been given a new usage perspective with the appearance of SCA. If you plan on accessing data within the context of an SOA, then looking deeper into SDO as a universal data access mechanism may well be worth your time, especially considering the vendor weight the SDO/SCA combo has when it comes to SOA.

Originally published June 2006 [ Publisher Link ]

Back to Article List