Bobby Woolf wrote:
>
> 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).
I agree with all of this. However entity beans were also intended to allow the
partitioning of interesting application function (as distinct from rote
persistence code) into reusable persistent objects, pure "data" objects being
bad OO as the function then lies in other (non-persistent) objects.
Unfortunately, most interesting application function operates on session state
data so it cannot be encapsulated in objects whose state is stored to a shared
database at the end of every transaction. Since there is no architected way in
EJB of partitioning session state data (see for example this thread
http://archives.java.sun.com/cgi-bin/wa?A2=ind9812&L=ejb-interest&D=0&P=20208 on
the inadvisability of having one stateful session bean calling another)
interesting application function has a procedural structure that inhibits reuse.
Douglas Adams wrote in "The Hitchiker's Guide to the Galaxy":
"their fundamental design flaws are completely obscured
by their superficial design flaws", or in other words you
are "blinded to the essential uselessness of them by the
sheer satisfaction of getting them to work at all".
Though Adams, being a Mac user, was probably thinking of M$ products, IMHO this
also applies to Entity Beans and other tools for creating Data Objects.
Ian McCallion
Alexis Systems Limited
Romsey, UK
===========================================================================
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".
