You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Pinaki Poddar <pp...@bea.com> on 2008/01/08 20:07:45 UTC
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_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.
Fwd: EclipseLink DAS and JPA
Posted by David Jencks <da...@yahoo.com>.
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" <pp...@bea.com>
> Date: January 8, 2008 11:07:45 AM PST
> To: "Doug Clarke" <do...@oracle.com>
> Cc: "SMITH SHAUN M." <sh...@oracle.com>, "Doughan Blaise P"
> <BL...@oracle.com>, "Sachin Thatte" <sa...@bea.com>,
> "Cheryl Burnell" <cb...@bea.com>, "Robyn Chan" <rc...@bea.com>,
> <de...@openjpa.apache.org>, <tu...@ws.apache.org>, <jpa-
> experts@sun.com>, "Pinaki Poddar" <pp...@bea.com>,
> <pi...@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.
Re: EclipseLink DAS and JPA
Posted by Luciano Resende <lu...@gmail.com>.
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/tuscany-dev@ws.apache.org/msg21176.html
On Jan 9, 2008 4:45 AM, Simon Nash <na...@hursley.ibm.com> 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:ppoddar@bea.com]
> > Envoyé : mardi 8 janvier 2008 20:08
> > À : Doug Clarke
> > Cc : SMITH SHAUN M.; Doughan Blaise P; Sachin Thatte; Cheryl Burnell; Robyn Chan; dev@openjpa.apache.org; tuscany-dev@ws.apache.org; jpa-experts@sun.com; Pinaki Poddar; pinaki.poddar@gmail.com
> > 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: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_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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: EclipseLink DAS and JPA
Posted by Simon Nash <na...@hursley.ibm.com>.
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:ppoddar@bea.com]
> Envoyé : mardi 8 janvier 2008 20:08
> À : Doug Clarke
> Cc : SMITH SHAUN M.; Doughan Blaise P; Sachin Thatte; Cheryl Burnell; Robyn Chan; dev@openjpa.apache.org; tuscany-dev@ws.apache.org; jpa-experts@sun.com; Pinaki Poddar; pinaki.poddar@gmail.com
> 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: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_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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: EclipseLink DAS and JPA
Posted by Eric Samson <er...@xcalia.com>.
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:ppoddar@bea.com]
Envoyé : mardi 8 janvier 2008 20:08
À : Doug Clarke
Cc : SMITH SHAUN M.; Doughan Blaise P; Sachin Thatte; Cheryl Burnell; Robyn Chan; dev@openjpa.apache.org; tuscany-dev@ws.apache.org; jpa-experts@sun.com; Pinaki Poddar; pinaki.poddar@gmail.com
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: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_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.
RE: EclipseLink DAS and JPA
Posted by Eric Samson <er...@xcalia.com>.
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:ppoddar@bea.com]
Envoyé : mardi 8 janvier 2008 20:08
À : Doug Clarke
Cc : SMITH SHAUN M.; Doughan Blaise P; Sachin Thatte; Cheryl Burnell; Robyn Chan; dev@openjpa.apache.org; tuscany-dev@ws.apache.org; jpa-experts@sun.com; Pinaki Poddar; pinaki.poddar@gmail.com
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: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_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.