Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


< EclipseLink‎ | Development
Revision as of 14:36, 30 January 2009 by (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

EclipseLink Incubator: SDO Data Access Service with JPA

The work is being developed within the EclipseLink/Development/Incubator and is being tracked by bug 258057.

This incubator is intended to illustrate how SDO can be used with JPA to provide relational database access to data exposed as SDO DataObjects. This functionality bridges SDO, JPA, and MOXy components and may also result in the generation of some additional utilities to simplify development tasks and tooling support.

Incubator Exit Criteria

This incubator feature is intended to facilitate rapid development and interaction with consumers. Once each usage scenario is validated with the consumers and the necessary testing is in place the functionality will be migrated back into the main components (SDO, MOXy, JPA, & Core) as well as the necessary test cases being migrated into the corresponding projects.

This incubator feature will continue to evolve functionality until all of the consumer required use cases surrounding SDO usage with JPA have been addressed.

Use Cases

There are several options for using SDO with JPA:

  1. SDO DataObjects wrapping JPA entities. The XSD and DataObject model defined by JAXB mappings on the JPA entities
  2. JPA Mapping of SDO DataObjects

1. SDO DataObjects wrapping JPA entities

In this use case a developer wishes to expose their JPA model as an SDO DataObject model (static or dynamic). The JPA entities are mapped to a XSD through JAXB mappings.

  1. In this use case the developer defines the mapping from the JPA domain model (POJOs) to an XML schema (XSD) using JAXB mappings (annotations or EclipseLink native OXM).
  2. The XSD is then generated using the JAXB Java-XML Compiler (JXC), or in the meet-in-the-middle case the schema from the previous step.
  3. The SDO Data Object model is now implicitly define through the use of the generated XSD. If the service developer wishes to use a static DataObject model they can optionally use the SDO compiler to generate this model based on the XSD.

Support for this use case has been added to EclipseLink 1.1. See the following links for more information:

Feature Development

In order to implement the above defined functionality the following development tasks and associated design work is required.

  1. Merge using ChangeSummary
  2. Examples
Merge using ChangeSummary

When a developer wishes to persist a DataObject graph and a ChangeSummary is available this solution should leverage the ChangeSummary to avoid calculating the necessary changes based on reading in the objects and doing comparisons.

2. JPA Mapping of SDO DataObjects

In this use case the static SDO impl classes are the JPA entities.

Back to the top