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.

thanks
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
> clear:
>        "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:
> http://people.apache.org/~ppoddar/fluid/site/welcome.html
> <http://people.apache.org/~ppoddar/fluid/site/welcome.html>
>  A series of blogs where I ramble about it
> [2]
> http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/ 
> persisting_ser
> v.html
> <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/ 
> persisting_se
> rv.html>
> [3]
> http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/ 
> persisting_ser
> v_1.html
> <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/ 
> persisting_se
> rv_1.html>
> [4]
> http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/08/ 
> openjpa_implem
> e.html
> <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/08/ 
> openjpa_imple
> me.html>
>
> Regards --
>
> Pinaki
>
>
> ________________________________
>
> 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
>
>
> Pinaki,
>
> I came across a blog entry
> <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/ 
> persisting_se
> 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.
>
> Cheers,
>
> Doug Clarke
> Eclipse Persistence Services Project (EclipseLink)
> www.eclipse.org/eclipselink
> Project co-lead
>
>
>  Oracle Email Signature
> Logo<http://www.oracle.com/dm/design/images/oracle_sig_logo.gif>
> 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.