Three specifications describing Service Data Objects (SDO) have been published jointly by BEA and IBM, and will be implemented in upcoming releases of the BEA WebLogic Platform and IBM WebSphere Application Server. The documents "provide programmers with simpler and more powerful ways of building portable server applications." Java Specification Requests (JSRs) are also being filed in the areas of these specifications for formal consideration under the Java Community Process (JCP).

Introduced by a whitepaper on Next-Generation Data Programming: Service Data Objects, the principal Service Data Objects document describes SDO as "data programming architecture and API for the Java platform that unifies data programming across data source types, provides robust support for common application patterns, and enable applications, tools, and frameworks to more easily query, view, bind, update, and introspect data. The core concepts in the SDO architecture are the Data Object and Data Graph. A Data Object holds a set of named properties, each of which contains either a primitive-type value or a reference to another Data Object. The Data Object API provides a dynamic data API for manipulating these properties. The Data Graph provides an envelope for Data Objects, and is the normal unit of transport between components. Data Graphs also have the responsibility to track changes made to the graph of Data Objects, including inserts, deletes, and modification to Data Object properties."

Related documents include: (1) Work Manager for Application Servers, which provides an API for application-server supported concurrent execution of work items, and (2) and Timer for Application Servers, which defines an API for using timers in an application-server supported fashion. The three specifications have been published under royalty-free terms.

Bibliographic Information

• Next-Generation Data Programming: Service Data Objects." A Joint Whitepaper with IBM and BEA. By John Beatty (BEA Systems), Stephen Brodsky (IBM Corp), Martin Nally (IBM Corp), and Rahul Patel (BEA Systems). November 2003. 15 pages. Copyright (c) BEA Systems, Inc. and International Business Machines Corp 2003.

• Service Data Objects. IBM Corp. and BEA Systems, Inc. By John Beatty (BEA Systems, Inc), Stephen Brodsky (IBM Corporation), Raymond Ellersick (IBM Corporation), Martin Nally (IBM Corporation), and Rahul Patel (BEA Systems, Inc). Version 1.0. November 2003. 39 pages.

• Work Manager for Application Servers. International Business Machines Corp. and BEA Systems, Inc. By John Beatty (BEA Systems, Inc), Chris D. Johnson (IBM Corporation), Revanuru Naresh (BEA Systems, Inc), Billy Newport (IBM Corporation), and Andy Piper (BEA Systems, Inc). Version 1.0. November 2003.

• Timer for Application Servers. International Business Machines Corp. and BEA Systems, Inc. By John Beatty (BEA Systems, Inc), Chris D. Johnson (IBM Corporation), Billy Newport (IBM Corporation), Stephan Zachwieja (BEA Systems, Inc). Version 1.0. November 2003. 6 pages.

Service Data Objects Overview

"While the Java platform and J2EE provide a variety of data programming models and APIs, these technologies are fragmented and are not always amenable to tooling and frameworks. Further, some of the technologies can be hard to use and may not be sufficiently rich in functionality to support common application needs. SDO is intended to create a uniform data access layer that provides a data access solution for heterogeneous data sources in an easy-to-use manner that is amenable to tooling and frameworks. SDO is not motivated by a need to replace lower-level data access technologies, but has the following goals:

• Unified data access to heterogeneous data sources
• Unified support for both static and dynamic data APIs
• Support for tools and frameworks
• Support for disconnected programming models
• Support for custom data access layers based on common design patterns
• Decouple application code from data access code

Service Data Objects (SDO) is designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems.

SDO is based on the concept of disconnected data graphs. A data graph is a collection of tree-structured or graph-structured data objects. Under the disconnected data graphs architecture, a client retrieves a data graph from a data source, mutates the data graph, and can then apply the data graph changes back to the data source.

The task of connecting applications to data sources is performed by data mediator services. Client applications query a data mediator service and get a data graph in response. Client applications send an updated data graph to a data mediator service to have the updates applied to the original data source. This architecture allows applications to deal principally with data graphs and data objects.

SDO enables both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model. This enables a simple programming model without sacrificing the dynamic model needed by tools and frameworks.

SDO also provides a metadata API, which allows applications, tools, and frameworks to introspect the data model for a data graph. The SDO metadata API unifies data-source-specific metadata APIs to enable applications to handle data from heterogeneous data sources in a uniform way...

SDO has a composable (as opposed to monolithic) architecture. The core SDO specification provides the base APIs that are applicable to all types of data sources. The core SDO specification, for example, does not presume a particular query language or a particular back-end store. Thus, SQL can be used just as well as XPath or XQuery, or any other query language for that matter. Relational databases can be used, as can object databases or XML data sources. The philosophy of the SDO architecture is to use common facilities where possible, and to allow for data-source-type-specific facilities where necessary. The core SDO specification creates the kernel that makes this flexibility and simplicity possible..." [excerpted from the IBM/BEA white paper]