Thor Heinrichs-Wolpert wrote:
> Very interesting.
>
> For real world modeling, I don't see how EJB's abstract you away from
> locking in to a persistence layer (dependenat objects and sets), at least
> until the EJB2.0 spec is there.
In our experiences with EJB applications we have encountered similar issues.
Using EntityBeans to represent persistent entities is very heavyweight and also
restricts the object model. For example I cannot have component inheritance
today.
JDO provides a portable way to develop SessionBeans which can efficiently access
fine grained persistent objects. We recently did a 001 benchmark and compared
the performance of SessionBean+Entity Beans versus SessionBean+JDO. We got 6
times better performance with the JDO model !!!
However its a pity that the J2EE specifications cannot conform to a common query
language. This really impacts the development of J2EE applications.
btw check out http://www.versant.com/developer/judo/index.html for tons of
information on JDO as well as preview release.
-Raju
>
> I've implemented my BMP EJB's using a JDO type persistence layer we wrote,
> which combines the JDO spec from the ODMG (same as Castor) but have
> implemented a few other bits like JDBC interceptors for injecting caching
> pools (or not) as well as using the ideas in Connectors for security
> interceptor injections (for using Oracle's FGAC, or using the security from
> things like Peoplesoft).
>
> I was quite juiced on this until ... I saw the the JDO, EJB2.0 and JMS query
> styles ... all of which are different. Why is that?
> I also very much dislike the post processing being touted for JDO as you
> need to do a bunch of Magic to get around classloader security, etc. I much
> prefer the straightforward style of JDO as available by most OODB vendors.
>
> I still like Entity beans, but I use them as agregators, not a 1-1 table
> mapping thing. This gives me a transactional component, like an Order,
> which takes care of it's own order-items, etc. Rather than implementing it
> as several Entity Beans that work together. I see this being a easier thing
> to do with the EJB2.0 spec, or within the EJB1.x spec with a lockin to a
> particular JDO or PersistenceLayer vendor.
>
> Thor HW
> ----- Original Message -----
> From: "Floyd Marinescu" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, August 25, 2000 12:51 PM
> Subject: Java Data Objects vs. Entity Beans
>
> > It seems to me that Java Data Objects are what Entity Beans should have
> > been. I would like to open discussion on this topic.
> >
> > Check out my post:
> > http://theserverside.com/discussion/thread.jsp?thread_id=771
> >
> > thanks, take care EJB Guru's!
> >
> > Floyd
> >
> > ---------------------------------
> > Senior Architect / Director of Marketing
> > The Middleware Company
> > http://www.middleware-company.com
> > http://www.TheServerSide.com
> > [EMAIL PROTECTED]
> > 416-889-6115
> >
> > Check out TheServerSide.com, the internets first J2EE community!!!
> >
> >
> ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
