Service Data Objects (SDO) offer a consistent model for managing data, regardless of its source system and source format (Beatty et al. 2003). SDO makes use of a Disconnected Data Architecture. SDO supports the management of data that has been decoupled from its source and transported across different systems and tiers, by subsequently synchronizing it with its source again. SCA and SDO can be used independently of one another, and their specifications have nothing in common. However, a combination of the two specifications represents a powerful and flexible tool for developing distributed applications.
The SDO specification was published jointly by BEA and IBM, standardized as JSR 235, and transferred to the Open Service-Oriented Architecture (OSOA). The current version of the specification is version 2.1 for Java, COBOL, C++, and C (Barber, Edwards 2007).
SDO consists of data objects, data graphs, and data access services, as shown in the following diagram:
Now let's take a look at these three components:
- Data object: This is the object-oriented representation of the fundamental data. It encapsulates the data attributes in the form of simple values, as a reference to other objects and the descriptive metadata.
- Data graph: This represents a Data Transfer Object (DTO), which is transferred between the different tiers of an architecture. It can be made up of several individual data objects by using object graphs. These can include, for example, a master data set consisting of several detail data sets and their relationships to one another. In addition to the user data, changes to the object are included, or in other words, all the data objects that have been added, modified, and deleted are included.
- Data access service: This is the interface between the client and the data sources. The data access service is responsible for decoupling the applications from the physical accesses to the source systems, which hold the data. This service uses the data access object pattern.
SDO also provides metadata for describing data objects, including data types, relationships between data objects, and constraints. The metadata API is used by tools and other frameworks to simplify the development of applications that make use of SDO.
SDO implements a series of patterns, including:
- Data Access Object (DAO): The DAO encapsulates the calls to the data access layer.
- Data Transfer Object (DTO): The DTO is a transport container for data objects moving between different layers, tiers, or systems, and it reduces the number of method calls from remote interfaces.
- Entity object (EO): The EO is an object from the application domain. It represents entities from the business domain.
- Disconnected data usage: Data objects can be generated by data system accesses. The connection to the data system can be broken and recreated later, and changes to the data object can be propagated to the data system.
- Optimistic concurrency semantics data access: As a result of disconnected data usage, after the connection to the data system has been broken, the resources must be released for further accesses as part of the resource management process. An optimistic access strategy is put in place in order to maintain data consistency, despite competing accesses. When changes to data are propagated back to the data system once the connection has been re-established, the data in question is checked to determine whether it has been modified by another process in the meantime (after the initial query). This involves, for example, comparing the time stamps or counters. The original data set (the data that was read initially) may also be included with the modified data, and compared with the current data in the data system.