You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Mahler Thomas <th...@itellium.com> on 2003/08/07 14:02:09 UTC
[persistence] Some thoughts regarding CMP and JDO
Hello all,
I'm contacting you on behalf of the Apache OJB development team
(http://db.apache.org/ojb).
OJB is part of the Apache DB subproject and aims at providing first class
standards based object relational mapping technology. We are currently
finalizing our 1.0 release.
Our team is excited to have a complete J2EE implementation at Apache and we
are willing to contribute to your project.
OJB is heavily used in Tomcat, JBOSS and other application server
environments and supports JTA and JCA.
OJB provides special support for implementing BMP solutions easily.
It provides ODMG and JDO compliant APIs.
That's why we feel that OJB is a natural choice if you are thinking about a
persistence engine to implement CMP (and maybe JDO). We are willing to
integrate all necessary changes into our codebase.
Who is working on persistence concepts? Whom could we contact to get
involved into the respective discussions?
If you have any questions don't hesitate to contact me or the ojb developer
mailing list.
cheers and all the best for this new project,
Thomas Mahler
OJB developer
mailto:thma@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
Very nice. It would be really cool if we could participate on this new
project !
On Thu, 2003-08-07 at 09:02, Mahler Thomas wrote:
> Hello all,
>
> I'm contacting you on behalf of the Apache OJB development team
> (http://db.apache.org/ojb).
> OJB is part of the Apache DB subproject and aims at providing first class
> standards based object relational mapping technology. We are currently
> finalizing our 1.0 release.
>
> Our team is excited to have a complete J2EE implementation at Apache and we
> are willing to contribute to your project.
>
> OJB is heavily used in Tomcat, JBOSS and other application server
> environments and supports JTA and JCA.
> OJB provides special support for implementing BMP solutions easily.
> It provides ODMG and JDO compliant APIs.
>
> That's why we feel that OJB is a natural choice if you are thinking about a
> persistence engine to implement CMP (and maybe JDO). We are willing to
> integrate all necessary changes into our codebase.
> Who is working on persistence concepts? Whom could we contact to get
> involved into the respective discussions?
> If you have any questions don't hesitate to contact me or the ojb developer
> mailing list.
>
> cheers and all the best for this new project,
> Thomas Mahler
>
> OJB developer
> mailto:thma@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
If you guys don't mind me jumping in here, this is exactly why I added
the to the wiki wishlist that the CMP be pluggable. Every one of our
customers could not use CMP right now, or even Hibernate, Castor, JDO
and the others, because of their limitations when it comes or O.R.
mapping and the query limitations of OCL. Having a really pluggable CMP
could allow someone like us, who has a layered, pluggable persistence
engine, to plug into a container and provide the end user with the
ability to have really complex persistence requirements yet gain the
capabilities of an EJB container (transactions, security, clustering, etc.).
RObert
Thomas Mahler wrote:
> Hi Dain,
>
> thanks for the quick reply and for explaining your plans.
> I'd like to explain some central concepts of OJB to increase the mutual
> understanding and to start a discussion how to get together.
>
> Dain Sundstrom wrote:
>
>> Hello Thomas (and the rest of the OJB team),
>>
>> Jeremy Boynes and I (and a few others) wrote the CMP 2.0
>> implementation in JBoss, and we have been working on the persistence
>> code in the initial Geronimo code base.
>>
>> There is some code right now (a compiler and sql generator) and a
>> fairly extensive design, but it looks like we have similar designs.
>> The design is fairly simple from the high level. We will support
>> several front end layers simultaneously at runtime (CMP, JDO, maybe
>> Hibernate, heck maybe SQL).
>
>
> Front end layers means APIs that user code uses for persistence
> operations, right?
> OJB currently provides support for ODMG, JDO and SODA as standardized
> user APIs.
>
> I have some doubts about Hibernate in this context.
> 1. Hibernate does not expose a standard API, but its own proprietary
> API. Why supporting proprietary APIs?
> 2. AFAIK Hibernate does not provide any SPI to plug in a user defined
> persistence service. So how do you plan to plug in your central
> persistence service into Hibernate?
>
>> The job of the front end layer is to handle the life-cycle and
>> callbacks required by the related specification, but all real work
>> will be delegated to a centralized persistence service. This
>> persistence service handles caching, locking, versioning, clustering
>> and so on. When persistence service actually needs to manipulate
>> data it delegates to a store manager service.
>
>
> We have a similar design in OJB. The JDO front end layer is currently
> being implemented on top of a transaction manager called OTM (Object
> Transaction Manager). The OTM layer is reponsible for
> management of distributed object level transactions (incl. JTA and
> JCA), lockmanagement (our lockmanagement is working accross clusters
> already!) and cache management (We provide wrappers to JCS, Tangosol
> Coherence, etc.).
>
> The OTM layer itself is written on top our persistence microkernel
> called PersistenceBroker. It seems to correspond to your StoreManager.
> The PersistenceBroker is a pluggable component. That is the existing
> implementation for RDBMS persistence can be replaced at runtime by
> other implementations targeting LDAP, Filebased, XML or whatsoever.
>
> Our ODMG implementation is currently built directly on top of the
> PersistenceBroker, but we plan to refactor it to be also based on OTM.
>
> The resulting layering is shown in the attached images.
>
>> The target initial store managers include SQL 92, SQL 99, Oracle
>> (which is not really SQL), file based (XML maybe), and we have plans
>> to add LDAP, clustered database layer and some legacy systems.
>
>
> OJB PersistenceBroker already provides support for more than 10 of the
> most popular RDBMS platforms. I'm working on a file based solution
> (based on Prevayler), others have been playing around with LDAP.
>
> The following ASCI picture sums this up (if it comes
>
>> through):
>>
>> ---------------
>> CMP ----------> | | ------> SQL
>> JDP ----------> | persistence | ------> Oracle
>> Hibernate ----> | manager | ------> LDAP
>> | | ------> CICS (whatever)
>> ---------------
>>
>> Now the persistence manager has a huge job, so it is broken down into
>> plugins for caching, locking and so on, which effectively makes the
>> persistence manager just a coordinator of the plugins.
>
>
> I mentioned it before: this is exactly how we do it in OJB already. We
> are using a pluggable component concept. We are thinking of enabling
> our components for Avalon and/or JMX.
>
>>
>> Anyway, this is getting a little too technical for right now,
>> considering the initial code doesn't even have Entity beans. From
>> what I have seen, we have a similar vision, and I think we should
>> talk about merging our efforts into a common persistence engine
>> (maybe we can even get Gavin and the Hibernate team to sync up with us).
>
>
> I don't know how much of your plans are production level code already?
> For OJB the answer is quite clear. It's a working and mature codebase.
>
> It provides a robust and scalable architecture that matches the
> requirements you mention to a high degree.
>
> So in my eyes it would save geronimo *a lot of work* to base the
> persistence engine on OJB.
> Writing generic persistence engines is a tricky business. We are doing
> it with OJB for about 3 years now...
>
>> I think it would be really positive for Java to at least have all of
>> us at least talking so our systems can play well together, but if we
>> joined forces.... :D
>
>
> I agree. I'd like to see this happen.
> I believe that OJB already implements 80 - 90 % of the scope you
> describe. It would make a lot of sense to use OJB as the base
> persistence framework and to simply add the yet missing pieces like
> StoreManagers for LDAP or CICS and a CMP code generator.
>
> So before embarking on the adventure of writing yet another generic
> persistence engine, I think we should look at the things that
> db.apache.org already offers today.
> We should define the gaps and should come to a solid make or buy
> decision.
>
> Dain, please get me right. I'm not trying to sell something. I simply
> want to avoid double work and to push integration of Apache projects.
>
> We won't think about implementing our own servlet engine when we
> simply can use Tomcat, would we?
>
> cheers,
> Thomas
>
> PS: I'm offline for the next 2 weeks, so I won't be able to reply to
> you in this time. But other OJB developers are available.
>
>>
>> -dain
>>
>>
>> On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
>>
>>> Hello all,
>>>
>>> I'm contacting you on behalf of the Apache OJB development team
>>> (http://db.apache.org/ojb).
>>> OJB is part of the Apache DB subproject and aims at providing first
>>> class
>>> standards based object relational mapping technology. We are currently
>>> finalizing our 1.0 release.
>>>
>>> Our team is excited to have a complete J2EE implementation at Apache
>>> and we
>>> are willing to contribute to your project.
>>>
>>> OJB is heavily used in Tomcat, JBOSS and other application server
>>> environments and supports JTA and JCA.
>>> OJB provides special support for implementing BMP solutions easily.
>>> It provides ODMG and JDO compliant APIs.
>>>
>>> That's why we feel that OJB is a natural choice if you are thinking
>>> about a
>>> persistence engine to implement CMP (and maybe JDO). We are willing to
>>> integrate all necessary changes into our codebase.
>>> Who is working on persistence concepts? Whom could we contact to get
>>> involved into the respective discussions?
>>> If you have any questions don't hesitate to contact me or the ojb
>>> developer
>>> mailing list.
>>>
>>> cheers and all the best for this new project,
>>> Thomas Mahler
>>>
>>> OJB developer
>>> mailto:thma@apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Thomas Mahler <th...@web.de>.
Hi Dain,
thanks for the quick reply and for explaining your plans.
I'd like to explain some central concepts of OJB to increase the mutual
understanding and to start a discussion how to get together.
Dain Sundstrom wrote:
> Hello Thomas (and the rest of the OJB team),
>
> Jeremy Boynes and I (and a few others) wrote the CMP 2.0 implementation
> in JBoss, and we have been working on the persistence code in the
> initial Geronimo code base.
>
> There is some code right now (a compiler and sql generator) and a fairly
> extensive design, but it looks like we have similar designs. The design
> is fairly simple from the high level. We will support several front end
> layers simultaneously at runtime (CMP, JDO, maybe Hibernate, heck maybe
> SQL).
Front end layers means APIs that user code uses for persistence
operations, right?
OJB currently provides support for ODMG, JDO and SODA as standardized
user APIs.
I have some doubts about Hibernate in this context.
1. Hibernate does not expose a standard API, but its own proprietary
API. Why supporting proprietary APIs?
2. AFAIK Hibernate does not provide any SPI to plug in a user defined
persistence service. So how do you plan to plug in your central
persistence service into Hibernate?
> The job of the front end layer is to handle the life-cycle and
> callbacks required by the related specification, but all real work will
> be delegated to a centralized persistence service. This persistence
> service handles caching, locking, versioning, clustering and so on.
> When persistence service actually needs to manipulate data it delegates
> to a store manager service.
We have a similar design in OJB. The JDO front end layer is currently
being implemented on top of a transaction manager called OTM (Object
Transaction Manager). The OTM layer is reponsible for
management of distributed object level transactions (incl. JTA and JCA),
lockmanagement (our lockmanagement is working accross clusters already!)
and cache management (We provide wrappers to JCS, Tangosol Coherence, etc.).
The OTM layer itself is written on top our persistence microkernel
called PersistenceBroker. It seems to correspond to your StoreManager.
The PersistenceBroker is a pluggable component. That is the existing
implementation for RDBMS persistence can be replaced at runtime by other
implementations targeting LDAP, Filebased, XML or whatsoever.
Our ODMG implementation is currently built directly on top of the
PersistenceBroker, but we plan to refactor it to be also based on OTM.
The resulting layering is shown in the attached images.
> The target initial store managers include
> SQL 92, SQL 99, Oracle (which is not really SQL), file based (XML
> maybe), and we have plans to add LDAP, clustered database layer and some
> legacy systems.
OJB PersistenceBroker already provides support for more than 10 of the
most popular RDBMS platforms. I'm working on a file based solution
(based on Prevayler), others have been playing around with LDAP.
The following ASCI picture sums this up (if it comes
> through):
>
> ---------------
> CMP ----------> | | ------> SQL
> JDP ----------> | persistence | ------> Oracle
> Hibernate ----> | manager | ------> LDAP
> | | ------> CICS (whatever)
> ---------------
>
> Now the persistence manager has a huge job, so it is broken down into
> plugins for caching, locking and so on, which effectively makes the
> persistence manager just a coordinator of the plugins.
I mentioned it before: this is exactly how we do it in OJB already. We
are using a pluggable component concept. We are thinking of enabling our
components for Avalon and/or JMX.
>
> Anyway, this is getting a little too technical for right now,
> considering the initial code doesn't even have Entity beans. From what
> I have seen, we have a similar vision, and I think we should talk about
> merging our efforts into a common persistence engine (maybe we can even
> get Gavin and the Hibernate team to sync up with us).
I don't know how much of your plans are production level code already?
For OJB the answer is quite clear. It's a working and mature codebase.
It provides a robust and scalable architecture that matches the
requirements you mention to a high degree.
So in my eyes it would save geronimo *a lot of work* to base the
persistence engine on OJB.
Writing generic persistence engines is a tricky business. We are doing
it with OJB for about 3 years now...
> I think it would
> be really positive for Java to at least have all of us at least talking
> so our systems can play well together, but if we joined forces.... :D
I agree. I'd like to see this happen.
I believe that OJB already implements 80 - 90 % of the scope you
describe. It would make a lot of sense to use OJB as the base
persistence framework and to simply add the yet missing pieces like
StoreManagers for LDAP or CICS and a CMP code generator.
So before embarking on the adventure of writing yet another generic
persistence engine, I think we should look at the things that
db.apache.org already offers today.
We should define the gaps and should come to a solid make or buy decision.
Dain, please get me right. I'm not trying to sell something. I simply
want to avoid double work and to push integration of Apache projects.
We won't think about implementing our own servlet engine when we simply
can use Tomcat, would we?
cheers,
Thomas
PS: I'm offline for the next 2 weeks, so I won't be able to reply to you
in this time. But other OJB developers are available.
>
> -dain
>
>
> On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
>
>> Hello all,
>>
>> I'm contacting you on behalf of the Apache OJB development team
>> (http://db.apache.org/ojb).
>> OJB is part of the Apache DB subproject and aims at providing first class
>> standards based object relational mapping technology. We are currently
>> finalizing our 1.0 release.
>>
>> Our team is excited to have a complete J2EE implementation at Apache
>> and we
>> are willing to contribute to your project.
>>
>> OJB is heavily used in Tomcat, JBOSS and other application server
>> environments and supports JTA and JCA.
>> OJB provides special support for implementing BMP solutions easily.
>> It provides ODMG and JDO compliant APIs.
>>
>> That's why we feel that OJB is a natural choice if you are thinking
>> about a
>> persistence engine to implement CMP (and maybe JDO). We are willing to
>> integrate all necessary changes into our codebase.
>> Who is working on persistence concepts? Whom could we contact to get
>> involved into the respective discussions?
>> If you have any questions don't hesitate to contact me or the ojb
>> developer
>> mailing list.
>>
>> cheers and all the best for this new project,
>> Thomas Mahler
>>
>> OJB developer
>> mailto:thma@apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Thomas Mahler <th...@web.de>.
Hi Dain,
thanks for the quick reply and for explaining your plans.
I'd like to explain some central concepts of OJB to increase the mutual
understanding and to start a discussion how to get together.
Dain Sundstrom wrote:
> Hello Thomas (and the rest of the OJB team),
>
> Jeremy Boynes and I (and a few others) wrote the CMP 2.0 implementation
> in JBoss, and we have been working on the persistence code in the
> initial Geronimo code base.
>
> There is some code right now (a compiler and sql generator) and a fairly
> extensive design, but it looks like we have similar designs. The design
> is fairly simple from the high level. We will support several front end
> layers simultaneously at runtime (CMP, JDO, maybe Hibernate, heck maybe
> SQL).
Front end layers means APIs that user code uses for persistence
operations, right?
OJB currently provides support for ODMG, JDO and SODA as standardized
user APIs.
I have some doubts about Hibernate in this context.
1. Hibernate does not expose a standard API, but its own proprietary
API. Why supporting proprietary APIs?
2. AFAIK Hibernate does not provide any SPI to plug in a user defined
persistence service. So how do you plan to plug in your central
persistence service into Hibernate?
> The job of the front end layer is to handle the life-cycle and
> callbacks required by the related specification, but all real work will
> be delegated to a centralized persistence service. This persistence
> service handles caching, locking, versioning, clustering and so on.
> When persistence service actually needs to manipulate data it delegates
> to a store manager service.
We have a similar design in OJB. The JDO front end layer is currently
being implemented on top of a transaction manager called OTM (Object
Transaction Manager). The OTM layer is reponsible for
management of distributed object level transactions (incl. JTA and JCA),
lockmanagement (our lockmanagement is working accross clusters already!)
and cache management (We provide wrappers to JCS, Tangosol Coherence, etc.).
The OTM layer itself is written on top our persistence microkernel
called PersistenceBroker. It seems to correspond to your StoreManager.
The PersistenceBroker is a pluggable component. That is the existing
implementation for RDBMS persistence can be replaced at runtime by other
implementations targeting LDAP, Filebased, XML or whatsoever.
Our ODMG implementation is currently built directly on top of the
PersistenceBroker, but we plan to refactor it to be also based on OTM.
The resulting layering is shown in the attached images.
> The target initial store managers include
> SQL 92, SQL 99, Oracle (which is not really SQL), file based (XML
> maybe), and we have plans to add LDAP, clustered database layer and some
> legacy systems.
OJB PersistenceBroker already provides support for more than 10 of the
most popular RDBMS platforms. I'm working on a file based solution
(based on Prevayler), others have been playing around with LDAP.
The following ASCI picture sums this up (if it comes
> through):
>
> ---------------
> CMP ----------> | | ------> SQL
> JDP ----------> | persistence | ------> Oracle
> Hibernate ----> | manager | ------> LDAP
> | | ------> CICS (whatever)
> ---------------
>
> Now the persistence manager has a huge job, so it is broken down into
> plugins for caching, locking and so on, which effectively makes the
> persistence manager just a coordinator of the plugins.
I mentioned it before: this is exactly how we do it in OJB already. We
are using a pluggable component concept. We are thinking of enabling our
components for Avalon and/or JMX.
>
> Anyway, this is getting a little too technical for right now,
> considering the initial code doesn't even have Entity beans. From what
> I have seen, we have a similar vision, and I think we should talk about
> merging our efforts into a common persistence engine (maybe we can even
> get Gavin and the Hibernate team to sync up with us).
I don't know how much of your plans are production level code already?
For OJB the answer is quite clear. It's a working and mature codebase.
It provides a robust and scalable architecture that matches the
requirements you mention to a high degree.
So in my eyes it would save geronimo *a lot of work* to base the
persistence engine on OJB.
Writing generic persistence engines is a tricky business. We are doing
it with OJB for about 3 years now...
> I think it would
> be really positive for Java to at least have all of us at least talking
> so our systems can play well together, but if we joined forces.... :D
I agree. I'd like to see this happen.
I believe that OJB already implements 80 - 90 % of the scope you
describe. It would make a lot of sense to use OJB as the base
persistence framework and to simply add the yet missing pieces like
StoreManagers for LDAP or CICS and a CMP code generator.
So before embarking on the adventure of writing yet another generic
persistence engine, I think we should look at the things that
db.apache.org already offers today.
We should define the gaps and should come to a solid make or buy decision.
Dain, please get me right. I'm not trying to sell something. I simply
want to avoid double work and to push integration of Apache projects.
We won't think about implementing our own servlet engine when we simply
can use Tomcat, would we?
cheers,
Thomas
PS: I'm offline for the next 2 weeks, so I won't be able to reply to you
in this time. But other OJB developers are available.
>
> -dain
>
>
> On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
>
>> Hello all,
>>
>> I'm contacting you on behalf of the Apache OJB development team
>> (http://db.apache.org/ojb).
>> OJB is part of the Apache DB subproject and aims at providing first class
>> standards based object relational mapping technology. We are currently
>> finalizing our 1.0 release.
>>
>> Our team is excited to have a complete J2EE implementation at Apache
>> and we
>> are willing to contribute to your project.
>>
>> OJB is heavily used in Tomcat, JBOSS and other application server
>> environments and supports JTA and JCA.
>> OJB provides special support for implementing BMP solutions easily.
>> It provides ODMG and JDO compliant APIs.
>>
>> That's why we feel that OJB is a natural choice if you are thinking
>> about a
>> persistence engine to implement CMP (and maybe JDO). We are willing to
>> integrate all necessary changes into our codebase.
>> Who is working on persistence concepts? Whom could we contact to get
>> involved into the respective discussions?
>> If you have any questions don't hesitate to contact me or the ojb
>> developer
>> mailing list.
>>
>> cheers and all the best for this new project,
>> Thomas Mahler
>>
>> OJB developer
>> mailto:thma@apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Dain Sundstrom <da...@coredevelopers.net>.
Most persistence engines are designed as a single unit. I personally
would like to open up the internals so other programmers with new ideas
can come along and rewrite a single plugin without having to take on
the entire system. Also the plugins are useful as standalone services.
For example a the design includes a cluster aware distributed cache,
which will be useful to may other parts of the system. The real trick
it to keep the system decoupled so components can be easily swapped,
while keeping it easy to configure and use.
For other persistence frameworks, I think we will be able to share and
swap implementations of plugins or at least design ideas.
-dain
On Thursday, August 7, 2003, at 03:59 PM, Emmanuel Bernard wrote:
> Hum, some Reply-To issue
>
> Emmanuel Bernard wrote:
>
>> Hello Dain,
>> I'm not a persistence expert but I missed some stuffs. Its looks like
>> the front end layer will delegate to the persistence manager and the
>> persistence manager will use several plugins (one implementation out
>> of n for each kind of plugin). What I missed is that Hibernate, for
>> example, seems to be the persistence manager AND the plugins. I do
>> not know how to keep the plug-in architecture and still use such
>> persistence layers exept if Hibernate is hacked to conform to this
>> architecture.
>> If I understand well, the architecture you propose is uniformisation
>> of peristence layer (the same stuff Avalon try to do with component
>> life-cycle). Am i right ?
>>
>> Emmanuel
>>
>> Dain Sundstrom wrote:
>>
>>> Hello Thomas (and the rest of the OJB team),
>>>
>>> Jeremy Boynes and I (and a few others) wrote the CMP 2.0
>>> implementation in JBoss, and we have been working on the persistence
>>> code in the initial Geronimo code base.
>>>
>>> There is some code right now (a compiler and sql generator) and a
>>> fairly extensive design, but it looks like we have similar designs.
>>> The design is fairly simple from the high level. We will support
>>> several front end layers simultaneously at runtime (CMP, JDO, maybe
>>> Hibernate, heck maybe SQL). The job of the front end layer is to
>>> handle the life-cycle and callbacks required by the related
>>> specification, but all real work will be delegated to a centralized
>>> persistence service. This persistence service handles caching,
>>> locking, versioning, clustering and so on. When persistence service
>>> actually needs to manipulate data it delegates to a store manager
>>> service. The target initial store managers include SQL 92, SQL 99,
>>> Oracle (which is not really SQL), file based (XML maybe), and we
>>> have plans to add LDAP, clustered database layer and some legacy
>>> systems. The following ASCI picture sums this up (if it comes
>>> through):
>>>
>>> ---------------
>>> CMP ----------> | | ------> SQL
>>> JDP ----------> | persistence | ------> Oracle
>>> Hibernate ----> | manager | ------> LDAP
>>> | | ------> CICS (whatever)
>>> ---------------
>>>
>>> Now the persistence manager has a huge job, so it is broken down
>>> into plugins for caching, locking and so on, which effectively
>>> makes the persistence manager just a coordinator of the plugins.
>>>
>>> Anyway, this is getting a little too technical for right now,
>>> considering the initial code doesn't even have Entity beans. From
>>> what I have seen, we have a similar vision, and I think we should
>>> talk about merging our efforts into a common persistence engine
>>> (maybe we can even get Gavin and the Hibernate team to sync up with
>>> us). I think it would be really positive for Java to at least have
>>> all of us at least talking so our systems can play well together,
>>> but if we joined forces.... :D
>>>
>>> -dain
>>>
>>>
>>> On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'm contacting you on behalf of the Apache OJB development team
>>>> (http://db.apache.org/ojb).
>>>> OJB is part of the Apache DB subproject and aims at providing first
>>>> class
>>>> standards based object relational mapping technology. We are
>>>> currently
>>>> finalizing our 1.0 release.
>>>>
>>>> Our team is excited to have a complete J2EE implementation at
>>>> Apache and we
>>>> are willing to contribute to your project.
>>>>
>>>> OJB is heavily used in Tomcat, JBOSS and other application server
>>>> environments and supports JTA and JCA.
>>>> OJB provides special support for implementing BMP solutions easily.
>>>> It provides ODMG and JDO compliant APIs.
>>>>
>>>> That's why we feel that OJB is a natural choice if you are thinking
>>>> about a
>>>> persistence engine to implement CMP (and maybe JDO). We are willing
>>>> to
>>>> integrate all necessary changes into our codebase.
>>>> Who is working on persistence concepts? Whom could we contact to get
>>>> involved into the respective discussions?
>>>> If you have any questions don't hesitate to contact me or the ojb
>>>> developer
>>>> mailing list.
>>>>
>>>> cheers and all the best for this new project,
>>>> Thomas Mahler
>>>>
>>>> OJB developer
>>>> mailto:thma@apache.org
>>>
>>>
>>>
>>
>>
>
>
>
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Emmanuel Bernard <ep...@yahoo.fr>.
Hum, some Reply-To issue
Emmanuel Bernard wrote:
> Hello Dain,
> I'm not a persistence expert but I missed some stuffs. Its looks like
> the front end layer will delegate to the persistence manager and the
> persistence manager will use several plugins (one implementation out
> of n for each kind of plugin). What I missed is that Hibernate, for
> example, seems to be the persistence manager AND the plugins. I do
> not know how to keep the plug-in architecture and still use such
> persistence layers exept if Hibernate is hacked to conform to this
> architecture.
> If I understand well, the architecture you propose is uniformisation
> of peristence layer (the same stuff Avalon try to do with component
> life-cycle). Am i right ?
>
> Emmanuel
>
> Dain Sundstrom wrote:
>
>> Hello Thomas (and the rest of the OJB team),
>>
>> Jeremy Boynes and I (and a few others) wrote the CMP 2.0
>> implementation in JBoss, and we have been working on the persistence
>> code in the initial Geronimo code base.
>>
>> There is some code right now (a compiler and sql generator) and a
>> fairly extensive design, but it looks like we have similar designs.
>> The design is fairly simple from the high level. We will support
>> several front end layers simultaneously at runtime (CMP, JDO, maybe
>> Hibernate, heck maybe SQL). The job of the front end layer is to
>> handle the life-cycle and callbacks required by the related
>> specification, but all real work will be delegated to a centralized
>> persistence service. This persistence service handles caching,
>> locking, versioning, clustering and so on. When persistence service
>> actually needs to manipulate data it delegates to a store manager
>> service. The target initial store managers include SQL 92, SQL 99,
>> Oracle (which is not really SQL), file based (XML maybe), and we have
>> plans to add LDAP, clustered database layer and some legacy systems.
>> The following ASCI picture sums this up (if it comes through):
>>
>> ---------------
>> CMP ----------> | | ------> SQL
>> JDP ----------> | persistence | ------> Oracle
>> Hibernate ----> | manager | ------> LDAP
>> | | ------> CICS (whatever)
>> ---------------
>>
>> Now the persistence manager has a huge job, so it is broken down into
>> plugins for caching, locking and so on, which effectively makes the
>> persistence manager just a coordinator of the plugins.
>>
>> Anyway, this is getting a little too technical for right now,
>> considering the initial code doesn't even have Entity beans. From
>> what I have seen, we have a similar vision, and I think we should
>> talk about merging our efforts into a common persistence engine
>> (maybe we can even get Gavin and the Hibernate team to sync up with
>> us). I think it would be really positive for Java to at least have
>> all of us at least talking so our systems can play well together, but
>> if we joined forces.... :D
>>
>> -dain
>>
>>
>> On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
>>
>>> Hello all,
>>>
>>> I'm contacting you on behalf of the Apache OJB development team
>>> (http://db.apache.org/ojb).
>>> OJB is part of the Apache DB subproject and aims at providing first
>>> class
>>> standards based object relational mapping technology. We are currently
>>> finalizing our 1.0 release.
>>>
>>> Our team is excited to have a complete J2EE implementation at Apache
>>> and we
>>> are willing to contribute to your project.
>>>
>>> OJB is heavily used in Tomcat, JBOSS and other application server
>>> environments and supports JTA and JCA.
>>> OJB provides special support for implementing BMP solutions easily.
>>> It provides ODMG and JDO compliant APIs.
>>>
>>> That's why we feel that OJB is a natural choice if you are thinking
>>> about a
>>> persistence engine to implement CMP (and maybe JDO). We are willing to
>>> integrate all necessary changes into our codebase.
>>> Who is working on persistence concepts? Whom could we contact to get
>>> involved into the respective discussions?
>>> If you have any questions don't hesitate to contact me or the ojb
>>> developer
>>> mailing list.
>>>
>>> cheers and all the best for this new project,
>>> Thomas Mahler
>>>
>>> OJB developer
>>> mailto:thma@apache.org
>>
>>
>>
>
>
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Dain Sundstrom <da...@coredevelopers.net>.
Hello Thomas (and the rest of the OJB team),
Jeremy Boynes and I (and a few others) wrote the CMP 2.0 implementation
in JBoss, and we have been working on the persistence code in the
initial Geronimo code base.
There is some code right now (a compiler and sql generator) and a
fairly extensive design, but it looks like we have similar designs.
The design is fairly simple from the high level. We will support
several front end layers simultaneously at runtime (CMP, JDO, maybe
Hibernate, heck maybe SQL). The job of the front end layer is to
handle the life-cycle and callbacks required by the related
specification, but all real work will be delegated to a centralized
persistence service. This persistence service handles caching,
locking, versioning, clustering and so on. When persistence service
actually needs to manipulate data it delegates to a store manager
service. The target initial store managers include SQL 92, SQL 99,
Oracle (which is not really SQL), file based (XML maybe), and we have
plans to add LDAP, clustered database layer and some legacy systems.
The following ASCI picture sums this up (if it comes through):
---------------
CMP ----------> | | ------> SQL
JDP ----------> | persistence | ------> Oracle
Hibernate ----> | manager | ------> LDAP
| | ------> CICS (whatever)
---------------
Now the persistence manager has a huge job, so it is broken down into
plugins for caching, locking and so on, which effectively makes the
persistence manager just a coordinator of the plugins.
Anyway, this is getting a little too technical for right now,
considering the initial code doesn't even have Entity beans. From what
I have seen, we have a similar vision, and I think we should talk about
merging our efforts into a common persistence engine (maybe we can even
get Gavin and the Hibernate team to sync up with us). I think it would
be really positive for Java to at least have all of us at least talking
so our systems can play well together, but if we joined forces.... :D
-dain
On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
> Hello all,
>
> I'm contacting you on behalf of the Apache OJB development team
> (http://db.apache.org/ojb).
> OJB is part of the Apache DB subproject and aims at providing first
> class
> standards based object relational mapping technology. We are currently
> finalizing our 1.0 release.
>
> Our team is excited to have a complete J2EE implementation at Apache
> and we
> are willing to contribute to your project.
>
> OJB is heavily used in Tomcat, JBOSS and other application server
> environments and supports JTA and JCA.
> OJB provides special support for implementing BMP solutions easily.
> It provides ODMG and JDO compliant APIs.
>
> That's why we feel that OJB is a natural choice if you are thinking
> about a
> persistence engine to implement CMP (and maybe JDO). We are willing to
> integrate all necessary changes into our codebase.
> Who is working on persistence concepts? Whom could we contact to get
> involved into the respective discussions?
> If you have any questions don't hesitate to contact me or the ojb
> developer
> mailing list.
>
> cheers and all the best for this new project,
> Thomas Mahler
>
> OJB developer
> mailto:thma@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [persistence] Some thoughts regarding CMP and JDO
Posted by Dain Sundstrom <da...@coredevelopers.net>.
Hello Thomas (and the rest of the OJB team),
Jeremy Boynes and I (and a few others) wrote the CMP 2.0 implementation
in JBoss, and we have been working on the persistence code in the
initial Geronimo code base.
There is some code right now (a compiler and sql generator) and a
fairly extensive design, but it looks like we have similar designs.
The design is fairly simple from the high level. We will support
several front end layers simultaneously at runtime (CMP, JDO, maybe
Hibernate, heck maybe SQL). The job of the front end layer is to
handle the life-cycle and callbacks required by the related
specification, but all real work will be delegated to a centralized
persistence service. This persistence service handles caching,
locking, versioning, clustering and so on. When persistence service
actually needs to manipulate data it delegates to a store manager
service. The target initial store managers include SQL 92, SQL 99,
Oracle (which is not really SQL), file based (XML maybe), and we have
plans to add LDAP, clustered database layer and some legacy systems.
The following ASCI picture sums this up (if it comes through):
---------------
CMP ----------> | | ------> SQL
JDP ----------> | persistence | ------> Oracle
Hibernate ----> | manager | ------> LDAP
| | ------> CICS (whatever)
---------------
Now the persistence manager has a huge job, so it is broken down into
plugins for caching, locking and so on, which effectively makes the
persistence manager just a coordinator of the plugins.
Anyway, this is getting a little too technical for right now,
considering the initial code doesn't even have Entity beans. From what
I have seen, we have a similar vision, and I think we should talk about
merging our efforts into a common persistence engine (maybe we can even
get Gavin and the Hibernate team to sync up with us). I think it would
be really positive for Java to at least have all of us at least talking
so our systems can play well together, but if we joined forces.... :D
-dain
On Thursday, August 7, 2003, at 07:02 AM, Mahler Thomas wrote:
> Hello all,
>
> I'm contacting you on behalf of the Apache OJB development team
> (http://db.apache.org/ojb).
> OJB is part of the Apache DB subproject and aims at providing first
> class
> standards based object relational mapping technology. We are currently
> finalizing our 1.0 release.
>
> Our team is excited to have a complete J2EE implementation at Apache
> and we
> are willing to contribute to your project.
>
> OJB is heavily used in Tomcat, JBOSS and other application server
> environments and supports JTA and JCA.
> OJB provides special support for implementing BMP solutions easily.
> It provides ODMG and JDO compliant APIs.
>
> That's why we feel that OJB is a natural choice if you are thinking
> about a
> persistence engine to implement CMP (and maybe JDO). We are willing to
> integrate all necessary changes into our codebase.
> Who is working on persistence concepts? Whom could we contact to get
> involved into the respective discussions?
> If you have any questions don't hesitate to contact me or the ojb
> developer
> mailing list.
>
> cheers and all the best for this new project,
> Thomas Mahler
>
> OJB developer
> mailto:thma@apache.org