As far as CMP is concerned, I think app servers could be somewhat
analogous to RDBMS - what sort of state were databases in when they
were a couple of years old?
Also, these systems are designed for scalability. How well do your
code-generated persistant objects scale? Can you handle 10,000 concurrent
clients? From what you said:
"The only problem we could think of that entity beans might provide an
elegant solution to was situations where many clients would be
concurrently accessing a single entity bean, and you want one user's
modifications to be visible immediately to clients"
I think this can cover quite a few cases in the target use cases for
which EJB was designed.
I think transactions have some of the most difficult functionality to
implement. If a client doesn't need transactions, then I will often
question whether they need EJB.
I agree on the network chattiness - I think something needs to
happen here. I advocate the addition of a "localLookup()" call
as well as JNDI.
>From: Dave Glasser <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Why use entity beans?
>Date: Thu, 18 Jan 2001 00:22:16 -0500
>
>Assuming that concurrent access is not a major factor, can someone
>explain to me what the benefits of using entity beans are, as opposed
>to a basic object->relational mapping?
>
>My company is currently embarking on its first major project involving
>EJB, and I and the others involved in designing the system have been
>working hard getting up to speed in the technology. (We already have a
>good background in OO Design, Java and RMI.) The more we learned about
>entity beans, the more we began to ask ourselves, "why are we using
>these?" Ultimately we decided to simply abandon them altogether, and
>use the EJB container primarily for transaction management, while
>passing serialized data objects back and forth between the server and
>clients.
>
>One of the most hyped features about entity beans has been CMP, but
>unless we're missing something, that seems to be a joke, not nearly
>sophisticated enough to meet our needs. And even if it did, all it
>would save us is time and effort, and that's not one of our overriding
>goals in building this system, it's performance, stability,
>scalability, etc. As it happens anyway, we already have a homegrown
>code generator that, given a DB table's metadata, will generate a
>matching data object class, a class to do all of the basic CRUD
>chores, and a session bean (with the attendant interfaces) for
>accessing it, so CMP would not even save us a great deal of work.
>
>Another thing that had us scratching our heads was, a great deal of
>the literature pertaining to entity beans is about ways you can work
>around their excessive overhead, like network chattiness, excessive
>hits on the database, scalability issues, etc., and some of these
>workarounds, e.g. Monson-Haefel's "bulk accessor" methods just seemed
>clumsy and awkward. If there are so many pitfalls and gotchas
>associated with entity beans, why on earth does anyone use them?
>
>The only problem we could think of that entity beans might provide an
>elegant solution to was situations where many clients would be
>concurrently accessing a single entity bean, and you want one user's
>modifications to be visible immediately to clients (as soon as they
>call the changed property's getter method, that is.)
>
>I hope no one misinterprets this post as an anti-Java or anti-EJB
>troll. Believe me, I love just about everything else about Java and
>J2EE. In fact, I would be happy if someone who has some actual
>experience with entity beans could enlighten me if there is some great
>payoff in using them that I've missed.
>
>===========================================================================
>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".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
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".
