Data access with Service DataObjects
The Service DataObjects (SDO) framework is a data-centric, disconnected, XML-integrated, data access mechanism that provides a source-independent result set.
- SDO is data-centric because it eliminates the need for client applications to work with special formats of data, such as the object representations of the EJB API. Instead, clients work with traversable graphs of DataObjects.
- SDO is disconnected because the retrieved result is independent of any back end data store connections or transactions.
- SDO is XML-integrated in that it provides services to convert retrieved data to and from XML format.
The SDO API lets you work with data from multiple data sources, including...
- relational databases
- entity EJB components
- XML pages
- Web services
- Java Connector Architecture
- JavaServer Pages
SDO components
- SDO clients
- 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 (DMS)
- 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 that contains 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 that defines the structure of the DataGraph that is produced by the DMS as well as the query to be used against the back end.
The DMS queries the targeted back end and transforms the native result set into the DataGraph format. 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.
WAS provides functionality for two separate Data Mediator Services.
- Java Java Database Data Mediator Service
Retrieve data from a relational data source and return a DataGraph.
- EJB Data Mediator Service
OO rendering of the data into entity beans that can store business logic.
- Data sources
- Data sources are not restricted to backend databases. A data source contains data in its own format. In the case of 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
- 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 V1.0 DataObjects are always linked together and contained in DataGraphs. The V1.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 you create from external code generators.
- 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 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 keeps track of the 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 run time 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 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 you 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.
Sub-topics
Java DataBase Connectivity Mediator Service
Enterprise JavaBeans Data Mediator Service
Service Data Objects: Resources for learning
Related tasks
Task overview: Using enterprise beans in applications
Related Reference
Dynamic and static object types for the JDBC DMS
Related information
IBM developerWorks Web site
Apache Tuscany free open source project Web site
Java SDO subproject of the Apache Tuscany incubator project Web site