Not sure if we want to replace, but maybe have a JPA DAS based on fluid and let the community decide witch one they want to use. BTW, I have already suggested Pinaki to continue Fluid development in Tuscany [1], maybe I could approach him again.
Thoughts ? [1] http://www.mail-archive.com/[email protected]/msg21176.html On Jan 9, 2008 4:45 AM, Simon Nash <[EMAIL PROTECTED]> wrote: > This isn't the first time I've heard it said that JPA is the best > way for SDO to access relational data. Should we pull the Fluid > work that integrates JPA and SDO into Tuscany? Could this replace > our current use of DAS for this purpose, so that we focus DAS on > providing service-oriented access to various kinds of data? > If not, why not? > > Simon > > > Eric Samson wrote: > > > 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. > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
