geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raghuram Rajah <raghuram.ra...@s1.com>
Subject RE: [persistence] Some thoughts regarding CMP and JDO
Date Fri, 08 Aug 2003 17:07:38 GMT
+1 to all the Matt mentions. I personally don't see the point in
re-inventing the wheel. Besides, using an existing (and sound) persistence
manager like OJB would give Geronimo good traction both in feature-set and
time-to-market. Not to mention the opportunities that belonging to Apache
family would bring (things that immedietely come to my mind are potential
for more stronger interaction between the Geronimo JTS and OJB OTM).

If the Geronimo team still strongly believes in getting into the business of
writing O/R mapping frameworks, atleast an abstraction is due there. Just
so, the native persistence manager could be swapped for either OJB (or even
Hibernate, Toplink, Cocobase or whatever). Also, an early exposure to this
abstraction could let OJB team to fill the gap. 

Further, bringing in another persistence service within the apache family
(Torque vs. OJB vs. Geronimo-persistence), makes me wonder where we are
going.

Thanks,
Raghu.

-----Original Message-----
From: Matthew Baird [mailto:Matthew.Baird@motiva.com]
Sent: Friday, August 08, 2003 12:16 PM
To: OJB Developers List
Cc: geronimo-dev@incubator.apache.org
Subject: RE: [persistence] Some thoughts regarding CMP and JDO


If I'm reading this correctly:
 
1. Version 1.0 is going to try and support several back ends other than just
RDBMS's (ie LDAP, XML, CICS)
2. You've already started to re-implement the persistence mechanisms.
3. Using the "front ends" of other Persistence frameworks equates to roughly
supporting their general API's and probably more specifically their Query
API's, however all real work will be done by the new persistence code on the
back end.
4. You are open to integrating code/thoughts from several different
persistence mechanisms into the Geronimo-specific implementation.
 
Feel free to correct me if I'm wrong on this one.
 
Based on those assumptions:
 
1. This is a pretty huge project with a rather large featureset. Supporting
non-relational backend stores is a major PITA without bringing a lot of
value.
2. Do we need yet another persistence framework? Most people reading this
have been involved in building persistence frameworks in the past and
understand the scope. Is there a solid reason for not choosing something
that is out there and just using that? At the very least, it's a huge head
start on the project which allows more time to be spent building aspects of
the container that don't already exist.
3. Isn't one of the Jakarta criteria "Alignment with existing Apache
subprojects."?
4. Perhaps there is some show-stopper in the OJB design that will not lend
itself to being used as the persistence layer. Although it sounds like the
designs are aligned.
 
It really comes down to a build vs. buy, and in this case the price is $0.00
so it seems to be a no-brainer. Why not turn the proposal upside down: Use
OJB as the default back-end persistence mechanism and lend your CMP 2.0
experience towards making OJB a better project as well?
 
cheers,
Matthew

	-----Original Message----- 
	From: Dain Sundstrom [mailto:dain@coredevelopers.net] 
	Sent: Thu 8/7/2003 9:34 AM 
	To: Mahler Thomas 
	Cc: geronimo-dev@incubator.apache.org; OJB Developers List (E-Mail) 
	Subject: Re: [persistence] Some thoughts regarding CMP and JDO
	
	

	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
	
	


Mime
View raw message