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:
- There are so many different options that it is difficult for Java developers to acquire expertise in more than a few of them
- The Java data APIs are difficult to use
- Many of the Java data APIs are not suited to service-oriented architectures
Service Data Object Technical Benefits
The technical benefits of the Service Data Object specification include:
- The Service Data Object specification is open (JSR 235) and implemented by multiple software product vendors
- Simplifies the J2EE data programming model by reducing the number of data APIs
- Provides a service-oriented architecture abstraction layer
- Service Data Object API available in both C++ and Java
- Supports a disconnected programming model
- Decouples application code from data access code
- Unifies support for both static and dynamic data APIs
- Reduces development, test, and maintenance costs by using less code
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.
CodeFutures has jointly developed FireStorm/SDO as part of an alliance with Rogue Wave Software.
You can download the product, branded as HydraSDO for Databases, from the Rogue Wave Download Center.