SDO Standard
The SDO standard (originally JSR 235 and now managed as an OASIS standard) is designed to provide a uniform data access layer for heterogeneous data sources in a service-oriented architecture. The SDO standard was introduced to the JCP by IBM and BEA (now part of Oracle) several years ago as a solution to the lack of a data access API in Java. The specification was approved but gained very little third party vendor support, despite being the only Java data access API specifically designed for Web Services/Service-Oriented Architectures. This changed significantly when the SDO standard was chosen as the data access API for SCA. There is now widespread support for the SDO standard.
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
The Technical Benefits of the SDO Standard
The technical benefits of the SDO standard include:
- The SDO standard 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 SDO Standard
The SDO standard was originally submitted in 2003 to the Java Community Process . The standard was approved and later versions of the standard also gained support for other major technology companies. The strategic importance of the SDO standard 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 SDO standard provides a single API that can be used to access multiple types of data.
The SDO Standard includes the 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 Objects
The SDO standard 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 SDO standard 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 SDO standard 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 standard 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.
Download FireStorm/SDO
CodeFutures has jointly developed FireStorm/SDO as part of an alliance with Rogue Wave Software.
You can download it directly from the Rogue Wave site under the brand name HydraSDO for Databases.