Hello Pinaki,
Thank you for starting an interesting discussion here.
AFAIK, I think the SDO group is not trying to redefine a new persistence
standard... as SDO is not really related to persistence by itself.
IMHO, you should rather look at SDO as a standard for DTO.
The DAS itself is in charge of accessing and manipulating the data sources.
The DAS expert group is certainly not willing to specify a new way to
manipulate data sources.
The DAS specification is rather focusing on defining the protocol between the
various DAS components and their interaction with SDO.
So existing standards like JPA and JDO are obviously best candidates for
Java-ORM-oriented DAS implementations.
But keep in mind the DAS specification is neither limited to Java nor to RDBMS.
And even in the case of a single RDBMS, mapping (ORM) is not mandatory.
I think that is more or less what Tuscany is illustrating today (JDBC-based
DAS).
BTW: Tuscany is just an example of what a DAS could be.
I'm aware of at least 2 other DAS implementations built upon JPA and another
one relying on top of JDO.
I think there is nothing in JPA today preventing implementation of a DAS on top of it.
The same way, I cannot see missing features in JPA today for a DAS implementation.
It seems you confirm this statement with Fluid.
Anyway, it's nice to see the JPA group is willing to consider potential
requirements from the SDO / DAS community, if any, in the future.
NB: you're right about the lack of identity in SDO. The community is currently
working on it.
I'll definitely have a look at Fluid.
BTW: did you try to synchronize your effort with the Tuscany team?
Best Regards,
....: Eric Samson, Founder & CTO, xcalia
Service your Data!
De : Pinaki Poddar [mailto:[EMAIL PROTECTED]
Envoyé : mardi 8 janvier 2008 20:08
À : Doug Clarke
Cc : SMITH SHAUN M.; Doughan Blaise P; Sachin Thatte; Cheryl Burnell; Robyn
Chan; [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED]; Pinaki
Poddar; [EMAIL PROTECTED]
Objet : RE: EclipseLink DAS and JPA
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_serv.html <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/persisting_serv.html>
[3] http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/persisting_serv_1.html <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/07/persisting_serv_1.html>
[4] http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/08/openjpa_impleme.html <http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/08/openjpa_impleme.html>
Regards --
Pinaki
________________________________
From: Doug Clarke [mailto:[EMAIL PROTECTED]
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_serv_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.
