Container Managed Persistance
Bean Managed Persistance
--- Evan Chua-Yap <[EMAIL PROTECTED]> wrote:
> 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".
>
>
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.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".
