Service Data Objects (SDO) is a specification approved by the Java™ community through the Java Specification Request (JSR) 235 (see Resources). It is also part of the joint effort from IBM and BEA Systems called CommonJ (see Resources). SDO is an API (application programming interface) that helps simplify and unify data access across different data source types, which is becoming more and more crucial in the IT industry. Monolithic applications are not built as often anymore and information is often stored in various types of sources (database, Web service, Lightweight Directory Access Protocol (LDAP), legacy, and so forth). This complexity requires developers to become skilled in many APIs (Java database connectivity (JDBC), Java APIs for XML-Based Remote Procedure Call (JAX-RPC), or J2EE Connector Architecture (JCA) to name a few). SDO simplifies and complements the Java 2 Platform, Enterprise Edition (J2EE) development mode, providing one unique API to access heterogeneous data sources. The specification also addresses other aspects of data handling that I will explain throughout this article.
The goals of SDO are numerous. In a sense, SDO can appear as the "Swiss Army Knife" of J2EE, because it contains many features for a variety of purposes. Basically, there are five main topics SDO and related technologies plan to address:
- Data access simplification: The first goal is to provide uniform data access to a wide variety of Enterprise Information Systems (EIS). This comprises databases, legacy (using JCA), XML, or Web services sources. By using a unique and simple model, applications get rid of the complexity of several data access APIs and frameworks with SDO.
- Data abstraction: Data representation is independent from its source using SDO. This is an implementation of a J2EE pattern called Domain Store (see Resources). This level of abstraction has several advantages, such as making data manipulation easier and promoting loose coupling between different layers.
- Data manipulation: Once the information is retrieved, SDO also wants to offer a uniformed programming language for data manipulation. In short, using the API and its interfaces, an SDO client must be able to read data and perform changes. SDO features both a connected and disconnected model, which I will explain in greater detail later in this article.
- Data transport: One part of the SDO concept is based on the Transfer Object and the Transfer Object Assembler patterns (see Resources). Once encapsulated into SDO objects, data can be transferred efficiently over J2EE layers.
- Design patterns adoption: A key objective of SDO is to also encourage the adoption of common J2EE patterns. That's why SDO architecture is based on well-known patterns like Transfer Object, Data Access Object, Transfer Object Assembler, and Domain Store (see Resources). Using SDO, an application takes advantage of these proven design strategies. It fosters layering and loose coupling.
Figure 1 shows where SDO fits in a J2EE layered architecture:
Figure 1. SDO in a J2EE layered architecture
SDO architecture: The big picture
The SDO architecture provides a set of core components, which are supposed to be augmented by SDO-capable implementations and frameworks.
The SDO specification defines the data holders (Data Objects and Data Graphs) and refers to a special component called the Data Mediator Service (DMS). The DMS is responsible for data source access and for data graph handling, as shown in Figure 2:
Figure 2. Role of the DMS
Figure 3 describes the SDO architecture and its key components, as shown below:
Figure 3. SDO architecture
The Data Object is the component that holds the data. To simplify, it consists of a key/value pair of properties. Each value can be a primitive data type or another Data Object. A Data Object is serializable.
Imagine you need to represent information related to a dessert in a restaurant. A particular instance of a Data Object could hold the following values:
Listing 1. Data Object values example
<ID, 123> <Description, "Chocolate Cake"> <Price, 7> |
For those familiar with JDBC concepts and the java.sql.ResultSet interface, the SDO dynamic API mode will be easy to understand. Just like with JDBC, you can access a property value by its name or index.
The dynamic API is particularly relevant when the exact structure of the data is not known before runtime.
To obtain values contained in a Data Object, the SDO API provides easy-to-use methods:
Listing 2. Obtaining values in a Data Object
// returns the first element of the graph
DataObject dessert = (DataObject) graph.get(0);
// get the dessert name and its price
String dessertName = dessert.getString("Description");
int dessertPrice = dessert.getInt("Price");
|
The SDO architecture also provides static API capabilities when the data structure is defined at development time. For instance, if the data source is an XML file with a well-defined schema (xsd file), SDO will support Java code generation and Java binding. It is out of the scope of the SDO specification, but binding technologies like Java Architecture for XML Binding (JAXB) will probably integrate SDO support.
The Data Object Graph is the hierarchical structure of data. It contains a tree of Data Objects and another structure called the Change Summary (see Figure 4). The Change Summary describes the change history information for all the Data Objects in the Data Graph. Moreover, as it is composed of Data Objects, a Data Graph is serializable.
Figure 4. Data Object Graph
The metadata is a meta model that describes the content of objects. It allows introspection of a Data Graph instance.
As shown in Figure 5, each object is associated to some basic metadata information, represented by a type and an ordered list of properties.
Figure 5. Object metadata
The SDO architecture will also involve additional components, which are not defined by the specification.
The previous paragraph described the logical metadata of the information (for example, the metadata -- once the information has been loaded into SDO objects). The physical metadata (for example, metadata of the original source format) is out of the scope of the SDO specification. The physical metadata typically does not affect SDO clients; however, it does affect DMS, which are responsible for data source accesses.
The DMS is a component that provides methods to populate a Data Graph. It saves the changes back to the data source. Typically, there will be different DMS types, each one related to a specific data source and technology (XML, JMS, JCA, JDBC, and so forth). As a DMS always returns the information in the same format (a Data Graph), it hides the actual data storage and provides a level of abstraction between the SDO application and the EIS.
DMS is out of the SDO specification scope, but the implementation will probably also offer the possibility to aggregate data from several data sources and types, in a transparent way, so that one unique SDO Data Graph contains information from heterogeneous sources. You will see this in Figure 6:
Figure 6. DMS
Disconnected data architecture
One interesting feature of the SDO model is that it allows a disconnected programming model. As a matter of fact, when an SDO client claims a Data Graph and receives it, it is then disconnected from the DMS. This prevents the DMS from holding locks on the data source. The client can work with the Data Objects without any time constraints, and the changes are applied back to the data source using an optimistic concurrency scenario.
This disconnected model is particularly adapted to n-tier Web-based architectures, because it respects layering techniques, provides ease of use, and a high level of concurrency access.
Figure 7 is the sequence diagram of a simple request. Basically, when an SDO client needs to retrieve data, it uses the DMS to require a Data Graph. The DMS manages the data source access and creates a graph with the information received. Usually, the graph contains several Data Objects in a hierarchical tree structure. The client works with the graph using a disconnected programming model. Once some data is modified and the client wants to save its changes, it sends the altered Data Graph to the DMS. Then the DMS updates the data source.
Figure 7. SDO graph
All the objects contained in a Data Graph extend the serializable Java interface. Thus, the tree serialization is straightforward, but it must respect the following schema, as shown in Figure 8.
Figure 8. Serializing a Data Graph
Right now, the specification is not clear about how a Data Graph must be described. The element called "models" supports the Essential Meta Object Facility (EMOF), while the one called "xsd" is supposed to contain an XML schema. Both are supported by SDO and address the same purpose: metadata description.
Once serialized, the Data Graph is composed of three parts: the schema, the serialized Data Objects, and the Change Summary, as shown in Figure 9. The Data Object part contains the tree structure and values of the objects, while the Change Summary lists all the modifications made to the graph just before the serialization happened. Unchanged values of the original tree are omitted. The Data Graph schema will only be included if it is necessary for deserialization. As mentioned before, it could be an XSD or an EMOF model.
Figure 9. The three parts of the serialized Data Graph
An important part of SDO is to make data manipulation easier. So once a Data Graph is constructed, it is important to be able to traverse the tree and to access its elements with the SDO API. The authors of the specification have chosen to support the XPath language. There's only one particularity with SDO; it accesses data using 0 as the base index, while the first element in the XPath specification can only be identified by an index of 1. The reason for this is to make the SDO API closer to the Java API, because programmers are accustomed to referring to the first element of an array using the syntax, array[0].
Let's look at a simple example to figure out how you can deal with Data Objects of a graph: a restaurant's menu. It can be depicted with the following Unified Modeling Language (UML) diagram, as shown in Figure 10.
Figure 10. Data Objects of a graph (in UML diagram)
A specific instance of the SDO graph is shown here:
Figure 11. SDO graph
First of all, you need to obtain the root element of the graph. That's the starting point of everything:
DataObject root = dataGraph.getRootObject(); |
To access the Menu Object, simply use:
DataObject menu = root.getDataObject("Menu"); |
What kind of menu are you inspecting? Well, the following expression will tell you:
String menuType = menu.getString("Name"); // |
By the way, it is a dinner.
Now imagine you want to choose a main dish. You first need to know what's on the menu today:
DataObject mainDish = menu.getDataObject("coursetype[Type='Main']"); |
If you have decided to have the T-Bone, you can then access it directly in the graph from its index:
DataObject tBone = (DataObject) mainDish.get(0); |
To check whether you have enough money to pay the bill, get the price:
int tBonePrice= tBone.getInt("Price"); |
Are you still hungry? What about dessert? First, you can retrieve the list from the tree in order to make up your mind:
DataObject dessert = menu.getDataObject("coursetype[Type='Dessert']");
List dessertList = dessert.getList(); |
You can then access elements from the ordered collection you've just obtained. Or maybe you had already decided to choose the wonderful chocolate cake. You can access it directly using the following expression:
DataObject cake = menu.getDataObject(coursetype.2/dishes.2); |
Due to the use of XPath, accessing elements of a Data Object Graph is quite simple and intuitive. There are also a lot of additional features in the SDO API to create or delete objects, or to change their values.
So far, an SDO appears to be much more than an API. It is also a design and programming model. That's why SDO can (and probably will) be involved in multiple enterprise application concepts. Let's take a look at some of them now.
SDO is not meant to replace existing persistence mechanisms, but instead to leverage their use providing a uniform programming interface. Instead of learning multiple APIs and frameworks, a programmer will typically concentrate on one unique programming model (SDO). Behind the scenes, SDO-capable tools and DMS will deal with all the specific and cumbersome data source semantics. So without even knowing it, an SDO client, through DMS, could interact with JDBC, Java Data Objects (JDO), Hibernate, Entity Enterprise JavaBeans (EJBs), Web Services, or any other data source.
Interactions between application layers
SDO objects are independent from the underlying data sources. They encapsulate information in a plain old Java object (POJO) and they are not related to specific technologies like EJB or Servlet.
Consequently, SDO objects are perfect candidates to cross tiers in a J2EE architecture. They can be the by-value Java objects that are created by the integration layer before being sent to the business layer. Additionally, an SDO object can be used to carry information between the presentation layer and the business layer. (See the Resources section for more information about the Transfer Object pattern.)
User interface data binding (JSR 227)
There has been an increasing effort lately to enable automatic binding between user interface (UI) components and business services, regardless of the technologies used. For instance, how can a JavaServer Faces (JSF) component interact in a standard way with an EJB or a Web service? And how can a Struts component use the same standard? SDO provides objects and APIs that could be used to facilitate the binding needs identified by JSR 227 working group (see Resources).
Using a normalized and auto-descriptive model, SDO opens the door to tools and frameworks that automate data access and generate Java objects in a standard way. Due to its introspection capabilities and its dynamic data APIs, SDO eases the integration with existing or upcoming tools. If it is embraced by the community, it could be the common API to federate thousands of existing frameworks.
SOA tends to promote an industry-standard framework that is interchangeable, adaptive, and flexible. It is all about on demand business; however, SOA is just a concept or blueprint for IT infrastructure. The industry has already adopted Web services standards to realize SOA applications. A Web service represents a self-contained and self-describing piece of functionality that can be found and accessed by other applications using open standards. The Java community can rely on a set of APIs and technologies to publish, discover, or consume services. It means you can interact with external applications using well-defined protocols like Simple Object Access Protocol (SOAP).
So far, however, there's no standard way to carry information within your application. Of course, this can be achieved by developing your homemade Java objects or taking advantage of XML binding like JAXB, Castor, XMLBeans, or any other solution from a plethora of technologies available today. But do you really want to be tied to multiple technologies and frameworks?
This is where SDO can help. It provides a unique model containing structured and interrelated composite objects to hold information in your own application. Moreover, SDO promotes a uniform data access for a wide variety of data sources and services. It also decouples the business process from the the source of the information. In a sense, SDO can be the framework that simplifies and unifies data application development in a SOA. It answers the need for a standardized and vendor-agnostic way to cope with heterogeneity.
SDO is not just a specification. You can already find tools that leverage SDO technology to access a heterogeneous EIS.
WebSphere® Application Server Version 6.0 (Application Server), which is J2EE 1.4 compliant, provides a set of programming model extensions to fulfill specific enterprise needs not yet covered by the specification. In order to foster SOAs, Application Server Version 6.0 supports SDO and provides some DMS implementations.
WebSphere Studio Application Developer Version 5.1.2 and the IBM next-generation software development platform (Rational® Application Developer Version 6) fully support SDO. The reference implementation of the SDO specification from IBM is included in the Eclipse Modeling Framework (see Resources) so that you can already develop SDO-enabled applications importing the appropriate package (import org.eclipse.emf.*;). In addition, as stated before, WebSphere (and thus IBM development platforms) comes with a couple of DMS implementations you can integrate in your applications (com.ibm.websphere.sdo.mediator.*).
SDO specification version 1.0 has been submitted and approved by the Java Community Process in late 2003 and it is still a work in progress. Just like any submission, it is hard to forecast whether it will be widely adopted or not in the long run. Nevertheless, the specification is backed by major Java industry stakeholders and it really addresses an important aspect of common enterprise applications: heterogeneous data access. SDO provides a neutral representation of business data, fosters a datasource-agnostic model, and promotes loose coupling. For these reasons, it will probably be a key component of future SOA applications.
Learn
-
Read Eclipse In Action: A Guide for Java Developers.
- Look at these:
- Learn more about the SDO specification and you'll certainly have a better understanding of how to implement what's discussed in this article.
- Read theJSR 235 specification.
- Service Data Objects, WorkManager, and Timers is a good overview of the SDO specification.
- Core J2EE Patterns: Best Practices and Design Strategies is one of the best books on the topic of Java patterns.
- Learn more about the Essential Meta Object Facility.
- Get the XML Schema specification.
- Learn more about the Xpath specification.
- Read the JSR 227: A Standard Data Binding and Data Access Facility for J2EE.
- IBM provides background on the WebSphere Application Server V6.0.
- Get more information on Rational Application Developer.
- Find out more about the Eclipse Modeling Framework.
- Check out some other good sources on the Eclipse Modeling Framework:
- The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
- Standards roadmap -- understand the impact and importance of standards and specifications for the development of SOA and Web services.
- SOA and Web services -- hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Get products and technologies
-
Get your hands on application development tools and middleware products from DB2®, Lotus®, Rational, Tivoli®, and WebSphere. You can download evaluation versions of the products at no charge, or select the Linux™ or Windows® version of developerWorks' Software Evaluation Kit.
Discuss
-
developerWorks blogs: Get involved in
the developerWorks community.
Jean-Louis Marechaux works as an IT Architect for the IBM Business Consulting Services group in Canada. His interests and expertise include J2EE architecture, Web Services technologies, SOA, and engineering process and methodologies (IBM Rational Unified Process®). You can contact him at jlmarech@ca.ibm.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).
- Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
- Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
- Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
- Buy: Rational Application Developer
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
