Service Data Object Overview

The Service Data Object specification (JSR 235) is designed to provide a uniform data access layer for heterogeneous data sources in a service-oriented architecture.

Java and J2EE already provides a very wide range of data programming models and APIs, which creates problems for Java developers:

Service Data Object Technical Benefits

The technical benefits of the Service Data Object specification include:

Open Industry Service Data Object Specification

The Service Data Object specification was originally submitted in 2003 to the Java Community Process . The specification was approved and later versions of the specification also gained support for other major technology companies. The strategic importance of the Service Data Object specification emerged when the Service Component Architect initiative was announced by several industry leaders.

Simplified Service Data Object Programming Model

Java has a very wide range of data APIs, making it difficult for Java developers to become experts in more than a few at any one time. However, enterprise applications often require data from heterogeneous sources. The Service Data Object specification provides a single API that can be used to access multiple types of data.

Multi-language Service Data Object API

The Service Data Object API is available in both Java and C++, which means it is available in what were successively the dominant programming languages for enterprise development over the past 20 years. The availability of a C++ API is particularly important for applications that need to share data between C++ and Java.

Disconnected Service Data Object

The Service Data Object specification goes beyond data abstraction and supports the concept of disconnected programming model, making it ideal for service-oriented architectures

Decoupled Application Code from Data Access Code

The core technical concept of the Service Data Object architecture is the disconnected data graph. A data graph is a collect of tree-structured or graph-structured data objects. The client retrieves a data graph from a data source, mutates the data graph, and applies any changes back to the original data source.

A Data Access Service (DAS) is used to connect applications to the data source via the data graph. The output of the DAS is a data graph. The data graph can be modified as required and updated when required (and is therefore disconnected).

The application architecture focuses on the data object and data graphs, not the DAS. This means that there is no need to understand the underlying technology used by the DAS (for example, JDBC for database access).

The Service Data Object architecture also means that a developer can use a single API to access multiple types of data via the DAS without any expertise in the back-end data access mechanism.

Static and Dynamic Service Data Object APIs

The Service Data Object specification enables both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model. This provides additional flexibility

Service Data Object Metadata API

The Service Data Object specification also provides a metadata API that enables applications and tools to introspect the data model for a data graph. The Service Data Object metadata API unifies data-source-specific metadata APIs to enable applications to uniformly handle data from multiple, different data sources.

Less Code Reduces Development, Test, and Maintenance Costs

By providing a single API to access multiple heterogeneous data sources, the Service Data Object specification can reduce the amount of code written.

Reduce the Amount of Code Maintained

Data Access Services (DAS) provide a standard way to persist information encapsulated in an SDO regardless of the backend system, whether it is a relational database accessed with JDBC, an LDAP server accessed by entity beans, or some other backend system that has a DAS implementation. In effect, custom code written to utilize heterogeneous backend systems is consolidated in a standard way with data access services. Less code to maintain often reduces time to market and risk by minimizing potential defects.