I've been thinking for a bit that it would be worth investigating if the proposed java-ldap object mapping service could be implemented as a new backend to openjpa.  This DAS-JPA link suggests to me that there would be additional advantages to doing so.

david jencks

Begin forwarded message:

From: "Pinaki Poddar" <ppoddar@bea.com>
Date: January 8, 2008 11:07:45 AM PST
To: "Doug Clarke" <douglas.clarke@oracle.com>
Cc: "SMITH SHAUN M." <shaun.smith@oracle.com>, "Doughan Blaise P" <BLAISE.DOUGHAN@oracle.com>, "Sachin Thatte" <sachin@bea.com>, "Cheryl Burnell" <cburnell@bea.com>, "Robyn Chan" <rchan@bea.com>, <dev@openjpa.apache.org>, <tuscany-dev@ws.apache.org>, <jpa-experts@sun.com>, "Pinaki Poddar" <ppoddar@bea.com>, <pinaki.poddar@gmail.com>
Subject: RE: EclipseLink DAS and JPA
Reply-To: tuscany-dev@ws.apache.org

Hello Doug,
  Thank you for your interest. I strongly concur with your view on
aligning a SDO DAS solution with JPA. In fact, to make my position
       "SDO should use JPA for persistence service and should *not*
define another persistence API. If current JPA does not provide adequate
support for SDO persistence then SDO community should approach JPA
community to include new API (or semantics on existing API) rather than
building a separate persistence API on its own. If SDO API does require
additions to work with JPA then these requirements are to be factored in
SDO specification."

   I explored this view via Fluid [1] which is an Apache Lab project
signifying its exploratory approach. Fluid through a prototype
implementation establishes the feasibility of such an approach without
any modification to JPA. The only accommodation I had to make is in
interpreting the oid argument of EntityManager.find() method 
                 public <T> T find(Class<T> cls, Object oid)
because of the templated signature, cls is always DataObject.class and
the exact DataObject type has to be coded via oid argument.

In course of this work, I had also underlined the current limitations of
SDO from a persistence perspective (e.g. lack of clear definition of
persistent identity or version fields) which I believe should be taken
up by SDO community. 

Tuscany had implemented a candidate API for SDO DAS. It is not what I
liked, but Fluid demonstrated how even Tuscany DAS can be emulated
rather easily [4].

While I have seen individuals using Fluid found it intuitive and easy,
so far institutional/community support has not been forthcoming. But I
sincerely believe that approach proposed/demonstrated in Fluid will gain
traction over time. In that regard your interest on behalf of
EclipseLink is reassuring. I also believe that given the cross-community
nature of this approach wider participation will be helpful to arrive at
a solution that is simple, elegant and promotes non-proliferation of API
(hence ccing to some other people/dev/expert groups).    

More information on Fluid can be found at 
[1] Fluid Website:
 A series of blogs where I ramble about it

Regards --



From: Doug Clarke [mailto:douglas.clarke@oracle.com] 
Sent: Tuesday, January 08, 2008 10:12 AM
To: Pinaki Poddar
Cc: SMITH SHAUN M.; Doughan Blaise P
Subject: EclipseLink DAS and JPA


I came across a blog entry
rv_1.html> you posted last year concerning OpenJPA and DAS where you
invited anyone involved in the EclipseLink DAS effort to connect with
you. I am not sure if this has already happened but I wanted to ensure
you had some contacts on our side.

Blaise Doughan is our development lead on SDO and DAS. 

I am personally very interested in a DAS solution that aligns closely
with JPA. If DAS does not go this route it would be great to still
discuss how a common non-standard JPA-SDO solution could be provided.


Doug Clarke
Eclipse Persistence Services Project (EclipseLink)
Project co-lead

 Oracle Email Signature
Doug Clarke 
Director of Product Management, Oracle TopLink 
Oracle Server Technologies
45 O'Connor, Suite 4000 | Ottawa, ON  K1P 1A4 Canada 
+1 613 288 4617

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.