openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: Architectural overview (how to get started targeting a new persistence back-end) ?
Date Mon, 27 Jul 2009 18:25:46 GMT

  Architecture of OpenJPA supports extension at multiple levels. Going by
the list of "extension points" in your mail, I am guessing your use case
will require extension both at "object management kernel" as well as in
"store manager". Let me elaborate what I mean.

1. OpenJPA architecture is *strictly* layered into a object management
kernel (Broker) (that knows nothing about the exact nature of the
persistence data store) and a layer (StoreManager) that manages data store
operations. The object management kernel also does not commit to any
specific industry-standard object persistence API such as JPA or JDO.

2. This core architectural design supports JPA specification artifacts such
as EntityManager as a north-bound facade to Broker and relational database
as persistent datastore via JDBCStoreManager.

3. Given the above, the begin with an extension, the preliminary questions
   a) does this extension change object management behavior (e.g. state
interception, life-cycle management, user data representation)?
   b) does this extension change the data store interaction (e.g. XML
database, object database)?

For concrete example of (b), a separate OpenJPA called Slice is available
with the distribution that adapts OpenJPA for horizontally-partitioned
distributed databases, or xmlstore for a file-based storage. OpenJPA has
also been extended for object databases or LDAP, but these implementations
are  not part of public bundles. 
Such extensions often extends StoreManager only. For Slice, however,
EntityManager is also extended because persist() operation in a distributed
database environment requires user-defined data distribution policy be
called back. 

For concrete example of (a), look for Fluid [1] -- a project under the aegis
of Apache Lab -- that extends OpenJPA to support weakly-typed data (Service
Data Objects  or SDO) defined on XML schema.  

4. Your extension ideas also suggests that the use case requires more
mapping metadata beyond JPA annotations. You are right in your hypothesis
that these special annotations be parsed and registered to specialized data
model classes (ClassMetaData/ClassMapping etc.). At this point, there is no
provision to stick an "opaque user object" to ClassMetaData for such purpose
and inheritance seems to be the option. The instance management
(StateManager) layer does allow such "opaque user object" for extensions to
use and interpret.

Regards --

[1] Fluid:

View this message in context:
Sent from the OpenJPA Developers mailing list archive at

View raw message