+

Search Tips   |   Advanced Search

Data access with Service DataObjects, API versions 1.0 and 2.01

The Service Data Objects (SDO) framework is a data-centric, disconnected, XML-integrated, data access mechanism that provides a source-independent result set.

Put simply, SDO is a framework for datan application development, which includes an architecture and API. SDO does the following:

The Service Data Objects framework provides a unified framework for datan application development. With SDO, we do not need to be familiar with a technology-specific API in order to access and use data. We need to know only one API, the SDO API, which lets you work with data from multiple data sources, including relational databases, entity EJB components, XML pages, web services, the Java Connector Architecture, JavaServer Pages, and more.

Unlike some of the other data integration models, SDO does not stop at data abstraction. The SDO framework also incorporates a good number of Java EE patterns and best practices, making it easy to incorporate proven architecture and designs into the applications. For example, most web applications today are not (and cannot) be connected to backend systems 100 percent of the time; so SDO supports a disconnected programming model. Likewise, many applications tend to be remarkably complex, comprising many layers of concern. How will data be stored? Sent? Presented to users in a GUI framework? The SDO programming model prescribes patterns of usage that allow clean separation of each of these concerns.


SDO components

An architectural overview of SDO describes each of the components that make up the framework and explains how they work together. The first three components listed are "conceptual" features of SDO: They do not have a corresponding interface in the API.

SDO clients

SDO clients use the SDO framework to work with data. Instead of using technology-specific APIs and frameworks, they use the SDO programming model and API. SDO clients work on SDO DataObjects and do not need to know how the data they are working with is persisted or serialized.

Data mediator services

Data mediators services (DMS) are responsible for creating a DataGraph from data sources, and updating data sources based on changes made to a DataGraph. (A DataGraph is an envelope object containing service data objects.)

The DMS provides the mechanism to move data between a client and a data source. It is created with back end specific metadata. The metadata defines the structure of the DataGraph that is produced by the DMS as well as the query to be used against the back end. When the DMS is requested to produce a DataGraph, it queries its targeted back end and transforms the native result set into the DataGraph format. Once the DataGraph is returned, the DMS no longer has any reference to it, making it stateless with respect to the DataGraph. When the DMS is requested to flush modifications of an existing DataGraph to the back end, it extracts the changes made from the original state of the DataGraph and flushes those changes to the back end. A DMS typically employs some form of optimistic concurrency control strategy to detect update collisions.

WebSphere Application Server provides functionality for two separate Data Mediator Services. If we simply need to retrieve data from a relational data source and return a DataGraph, using the Java Database Data Mediator Service is a good choice. However, if we have business logic, then you probably want an object-oriented (OO) rendering of the data into entity beans. One could consider SDO as an object rendering of data like entity beans. But entity beans have better Object-Relational (OR) mapping tools, and the EJB container and persistence manager for entity beans offer more sophisticated caching policies. Your best choice then is the EJB Data Mediator Service. The EJB mediator can work with these caches. Also, the entity bean programming model is a single level store model. We can navigate from entity to entity and the container and persistence manager either prefetches or lazily fetches in data as needed. On update, the programmer commits the transaction and the container and persistence manager do the work of tracking updated beans and writing them back to the data store and in memory cache.

Data sources

Data sources are not restricted to backend data sources (for example, persistence databases). A data source contains data in its own format. As to the SDO 1.0 API, only the DMS accesses data sources; SDO applications do not. The applications only work with SDO 1.0 DataGraphs.
Each of the following components corresponds to a Java interface in the SDO programming model.

DataObjects

As the fundamental components of SDO, DataObjects provide a common view of structured data for SDO clients. DataObjects can hold multiple different attributes of any serializable type (such as string or integer); more complex DataObjects can also contain simpler DataObjects. DataObjects hold all of their data in properties.

SDO version 1.0 DataObjects are always linked together and contained in DataGraphs. The version 1.0 DataObject interface provides simple creation and deletion methods (createDataObject() with various signatures and delete()), and reflective methods to get their types (instance class, name, properties, and namespaces). The interface also supports static object types that we create from external code generators. See the article "Dynamic and static object types for the JDBC DMS" for more information.

DataGraphs

A DataGraph is a structured result returned in response to a service request. The DMS transforms the native backend query results into the DataGraph, which is independent of the originating backend data store. This makes the DataGraph easily transferable between different data sources. The DataGraph is composed of interconnected nodes, each of which is an SDO DataObject. It is independent of connections and transactions of the originating data source. The DataGraph tracks changes made to it from its original source. This change history can be used by the DMS to reflect changes back to the original data source. DataGraphs can be converted to and from XML documents enabling them to be transferred between layers within a multi-tiered system architecture. A DataGraph can be accessed in either breadth-first or depth-first manner, and it provides a disconnected data cache that can be serialized for web services

The DataGraph returned by the mediator can contain either dynamic or generated static DataObjects. Use of generated classes gives type safe interfaces for easier programming and better runtime performance. The EMF generated classes must be consistent in name and type with the schema that would be created for dynamic DataObjects except that additional attributes and references can be defined. Only those attributes and references specified in the query are filled in with data. Remaining attributes and references are not set.

Change summary

SDO 1.0 change summaries are contained by DataGraphs and are used to represent the changes that have been made to a DataGraph returned by the DMS. They are initially empty (when the DataGraph is returned to a client) and populated as the DataGraph is modified. Change summaries are used by the DMS at backend update time to apply the changes back to the data source. They enable the DMS to efficiently and incrementally update data sources by providing lists of the changed properties (along with their old values) and the created and deleted DataObjects in the DataGraph. Information is added to the change summary of a DataGraph only when the change summary's logging is activated. Change summaries provide methods for DMS to turn logging on and off.

The SDO 1.0 change summary is not a client API; it is used only by the DMS.

Properties, types, and sequences

DataObjects hold their contents in a series of properties. Each property has a type, which is either an attribute type such as a primitive (for example, int) or a commonly used data type (for example, Date) or, if a reference, the type of another DataObject. Each DataObject provides read and write access methods (getters and setters) for its properties. Several overloaded versions of these accessors are provided, allowing the properties to be accessed by passing the property name (String), number (int), or property metaobject itself. The String accessor also supports an XPath-like syntax for accessing properties. For example, we can call get("department[number=123]") on a company DataObject to get its first department whose number is 123. Sequences are more advanced. They allow order to be preserved across heterogeneous lists of property-value pairs.


For more introductory information

For a good introduction to SDO 1.0 that also includes a small sample application, refer to the IBM developerWorks paper "Introduction to Service DataObjects."

To fully understand the EJB data mediator service we need a good understanding of the EJB programming model. For more information refer to the articles "Task overview: Using enterprise beans in applications" and "Service Data Objects: Resources for learning."


Subtopics

  • Task overview: Using enterprise beans in applications
  • Dynamic and static object types for the JDBC DMS
  • Service Data Objects: Resources for learning
  • IBM developerWorks website
  • Apache Tuscany free open source project website
  • Java SDO subproject of the Apache Tuscany incubator project website