Java Data Objects (JDO) is a standard way to access persistent data in databases, using plain old Java objects (POJO) to represent persistent data. The approach separates data manipulation (done by accessing Java data members in the Java domain objects) from database manipulation (done by calling the JDO interface methods). This separation of concerns leads to a high degree of independence of the Java view of data from the database view of the data.
Interfaces are defined for the user’s view of persistence:
- PersistenceManager: the component responsible for the life cycle of persistent instances, Query factory, and Transaction access
- Query: the component responsible for querying the datastore and returning persistent instances or values
- Transaction: the component responsible for initiating and completing transactions
Java Persistent Objects (JPOX) is designed as a heterogenous tool for storage of data, using accepted standard APIs. JPOX 1.0 supports persistence using the JDO 1 standard (JSR 0012). JPOX 1.1 additionally supports persistence using the JDO 2 standard (JSR 0243). JPOX 1.2 will additionally support persistence using the JPA 1 standard (JSR 0220).
SOA creates an environment where different types of data must work together. This makes application development complex. Service Data Object(SDO), provides a very simple programming model that addresses this issue. The key high level advantages of SDO are:
- Uniform access to data from heterogeneous sources which could be XML, RDB, POJO, SOAP, etc.
- SDO provides both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model. This provides a simple programming model without sacrificing the dynamic model needed by tools and frameworks.
- Provides Meta-data for easy introspection of data types
- Supports a disconnected model, whereby data can be retrieved from a data source via Data Access Service. The data can be modified by a client with change tracking, and applied back to the data source.
- SDO programming model is language neutral
Data Access Service (DAS) simplifies handling of data when interacting with the back-end data source and frees application developers from dealing with tedious and error-prone transformation between end source types and SDO Data Object Types/properties.
SCA is a programming model for abstracting business functions as components and using them as building blocks to assemble business solutions. An SCA component offers services and depends on functions that are called references. It also has an implementation associated it with it which is the business logic that can be implemented in any technology.
SCA provides a declarative way to describe how the services in an assembly interact with one another and what quality of services (security, transaction, etc) is applied to the interaction. Since service interaction and quality of service is declarative, solution developers remain focus on business logic and therefore development cycle is simplified and shortened. This also promotes the development of reusable services that can be used in different contexts. For example, a shopping cart service can be used in a retail application or a travel application without changing. Services can interact with one another synchronously or asynchronously and can be implemented in any technology.