Dave,
You're not missing anything. You're asking the right questions. Entity beans
are not nearly as helpful as they first appear.
Entity beans provide two things:
1) Persistence; they're the persistent enterprise bean.
2) The standard enterprise bean stuff: Distributed interface, transaction
management, security, etc.
Entity beans are typically used through session beans. The session beans
provide the enterprise bean stuff, so having entity beans provide it as well
is unnecessary overhead, overhead which tends to make entity beans much less
scalable than they ought to be.
So the main advantage entity beans provide is persistence. But they don't
even do that very well. In EJB 1.1 (the latest approved spec), an entity
bean's persistent fields must be primitives (not very OO), serializable
(stored in the RDBMS as blobs; not very relational), or other entity beans.
Thus your whole domain becomes lots of little entity beans, which multiplies
the inefficiencies. EJB 2.0 (currently in the approval process) introduces
dependent objects and declared relationships, which should help some.
The CMP/BMP debate is mostly bogus. Contrary to popular belief, CMP does not
make persistence automatic, as nice as that would be. In both cases, the
container decides when to load and store an object. In both cases, you must
define the O/R mappings yourself. If you use a tool like TopLink or Cocobase
to define the O/R mappings, you can generate the mappings as BMP (Java code
in the beans) or CMP (XML in the deployment descriptor), so it doesn't make
a very big difference which approach you use. CMP does handle some other
persistence nastiness for you, so when it works and does what you need, it's
still better than BMP, but not nearly as much as you'd think.
So entity beans are much less useful than they're cracked up to be.
Another standard under development, Java Data Objects (JDO)
(http://access1.sun.com/jdo/), is attempting to develop a type of object
that supports persistence without the other enterprise bean overhead. The
ServerSide site has a good discussion that compares JDO with entity beans
(http://theserverside.com/discussion/thread.jsp?thread_id=771).
<vendor>
Here at GemStone, we have an example application, FoodSmart, to demonstrate
best practices for J2EE development. (It's on the Developer's Guide CD:
http://www.gemstone.com/products/j/dev_guide.html.) It implements its domain
in two alternative ways: with entity beans and with standard Java objects.
This side-by-side comparison shows that the persistence entity beans provide
can be done just as easily without entity beans. We discuss issues like this
on our Java Success site (http://www.javasuccess.com). We've found that the
implementation using standard Java object provides better performance and
scalability because it lacks the entity bean overhead.
</vendor>
Good luck on finding an approach that works best for your needs.
Bobby
-----
Bobby Woolf
Senior Architect
GemStone Systems, a Brokat company
[EMAIL PROTECTED]
-----Original Message-----
From: Dave Glasser [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 18, 2001 00:22
To: [EMAIL PROTECTED]
Subject: [EJB-INT] Why use entity beans?
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".
===========================================================================
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".
