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 in that it does not support the retrieval of objects,
as is the case with Enterprise JavaBeans (EJB) persistence mechanisms. Results
are retrieved as a structured graph of data (the DataGraph).
- SDO is disconnected because the retrieved result is independent of any
backend data store connections or transactions.
- SDO is XML-integrated in that it provides services to easily convert
retrieved data to and from XML format.
Put simply, SDO is a framework for data application development, which
includes an architecture and API. SDO does the following:
- Simplifies the J2EE data programming model.
- Abstracts data in a service oriented architecture (SOA).
- Unifies data application development.
- Supports and integrates XML.
- Incorporates J2EE patterns and best practices.
The Service DataObjects framework provides a unified framework for data
application development. With SDO, you do not need to be familiar with a technology-specific
API in order to access and utilize data. You 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 pages, and more.
Unlike some of the other data integration models, SDO doesn't stop at data
abstraction. The SDO framework also incorporates a good number of J2EE patterns
and best practices, making it easy to incorporate proven architecture and
designs into your applications. For example, the majority of 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, today's
applications tend to be remarkably complex, comprising many layers of concern.
How will data be stored? Sent? Presented to end 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 DataGraphs 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.
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,
the Java DataBase Connectivity Mediator Service and the Enterprise JavaBeans Data Mediator Service.
- Data sources
- Data sources are not restricted to backend data sources (for example,
persistence databases). A data source contains data in its own format. Only
the DMS accesses data sources, SDO applications do not. SDO applications only
work with DataObjects in DataGraphs.
Each of the following components corresponds to a Java interface
in the SDO programming model.
- DataObjects
- DataObjects are the fundamental components of SDO. In fact, they are the service
DataObjects found in the name of the specification itself. DataObjects
are the SDO representation of structured data which can hold multiple different
attributes of any serializable type (such as string or integer), including
other DataObjects. Each DataObject also has a type (see SDO data object types for more information). DataObjects are generic
and provide a common view of structured data built by a DMS. While a JDBC
DMS, for instance, needs to know about the persistence technology (for example,
relational databases) and how to configure and access it, SDO clients need
not know anything about it. DataObjects hold their data in properties .
DataObjects provide convenience creation and deletion methods (createDataObject()
with various signatures and delete()), and reflective methods to get their
types (instance class, name, properties, and namespaces). DataObjects are
linked together and contained in DataGraphs. DataObjects have different ways
to access linked data, the two most common being through XPath expressions
and by a property index. DataObjects keep track of the original value of
any attribute that is modified.
- 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 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 easily 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
- 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.
Note: The 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.