Chip Wilson wrote:
> IBM posted a technical artical on the VisualAge Developer's Domain that
> recommends using entity beans for fine-grained, dependant objects.
> Examples from the article include the address and job history for a
> resume.
>
> http://www.software.ibm.com/ad/r/99enews12/vajejb/
>
Clearly the Address and Job objects illustrated in the article are dependent
objects, which means that they are aggregated by the Resume object. The author
recommends making all these objects entity beans which makes sense considering
the restrictions he has placed on design. The first thing that struck me is
the limitation of the Websphere in O/R mapping. Like many EJB servers it can
only handle very simple object-to-table mappings in CMP. Obviously, the
relationships between the dependent objects and their aggregator require a more
sophisticated mapping, so I would recommend one of two alternatives: Use BMP;
use a different EJB server.
With BMP, you can map the Resume entity bean to its dependent objects so that
they can be cached in a collections during ejbLoad( ) or, if the number of
dependent object is potentially large, they could be loaded as needed from the
business methods that access them. I would make the dependent objects
available to the client as immutable serializable objects which are passed by
value to the client. (More about this on my web site
www.ejbnow.com\ejbtips.html ). Although BMP is more complex to develop, the
performance is not necessarily inferior to CMP, so its an excellent option when
the state of an EB is complex and the server is limited in its CMP.
The other option is to simply use a different EJB server. There are some EJB
servers which are coming out with very sophisticated O/R mapping that would
make it fairly simple to map these dependent objects directly the the database
structure shown in the article (TOPLink for Weblogic is one that comes to
mind.). Obviously, WebSphere is not far behind on this goal.
The real question is, however, why not use fine-grained entity beans for
dependent objects. The first reason is performance. Enterprise beans require
a great deal of interposition to manage security, transaction, and
persistence. In addition, every invocation on an enterprise bean requires that
the RMI protocol be followed (RMI/IIOP for EJB 1.1) -- obviously sockets and
streams may not be employed for beans communicating in the same address space,
but the RMI requirements for copied values and references diminished
performance even in the same VM. Second, defining dependent objects as
entities beans implies that they have meaning outside the context of their
aggregator. This raises questions about cascading deletes, directly access,
etc.. In other words, if the dependent object have meaning outside the
aggregator then they are not technically dependent objects. Address and Job are
clearly dependent objects. (Sorry if this is a bit circular). Keeping the
dependent objects as regular Java objects (not entity beans), simplifies
security, transactions and persistence.
The important thing to keep in mind is that the dependent data does not have to
be stored as Java serialized objects in the database or even in the entity bean
cache. Dependent data can remain simple data until its needed by the client.
When the client needs to view, remove, or add dependent data it can be wrapped
in a dependent object and serialized to the client. In addition, dependent
data does not need to be cashed at all times by the aggregator. In the case of
sophisticated CMP and intelligently coded BMP, dependent data can accessed only
as needed.
--
Richard Monson-Haefel
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
( http://www.monson-haefel.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".
