Re: [persistence] Some thoughts regarding CMP and JDO

[jcd]

Aren't we, in some respects, getting a bit overzealous about the 
Persistence Tier?  Let's focus on getting the EJB life-cycle management 
and transaction hierarchies dialed and designed.  Why not gear efforts 
to the production of a solid BMP implementation with Connection, 
Datasource, and Transaction management - get that dialed and define a 
pluggable OPTIONALthird-party persistence interface.

What is the consensus out there regarding the use of BMP?  Is there any 
desire to have the ability to 'unplug' any/all container persistence 
services in exchange for a smaller footprint, lighter weight 
implementation?  Concentrating efforts on the basic EJB container 
services might well prove to be a quicker track to a stable, performing 
implementation that can be extended to accommodate the various 
persistence approaches at a later time.  It is my feeling that this 
approach could postpone much of the inevitable analysis paralysis that 
often accompanies 'The Persistence Debate."  Meanwhile, back at the 
ranch, Geronimo is beating his drums to early release victory.

Best,
John C. Dale
Professional Services
Compuware
Chris Rauschuber wrote:
Hello Dain and Geronimo,
If there is a need for persistence to LDAP, please take a look at
http://jellyfish.sourceforge.net, a JDO-like persistence mechanism for
LDAP.  We'd be happy to coordinate with you if you're interested.
Regards,
Chris Rauschuber
 

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
       


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com