may i ask what CMP and BMP below stand for?
----- Original Message -----
From: Richard Monson-Haefel <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 03, 1999 2:24 PM
Subject: Re: IBM comes out in favor of fine-grained entity beans
> 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".
>
===========================================================================
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".
