> I also like the idea that my domain objects might stand independent of EB's,
> and could be used in other contexts.
So do I, but I still can't see how it can be done. You can have the same
set of root object and dependent objects work as beans or direct data
objects, but your application has to make a decision whether to access
them as remote objects or local object, and that choice pretty much
determines how your application will look.
Sign. Wish it would be easier.
> > 1) Dependent objects cannot be accessed independently of their parents. I
> > need to go through the parent entity bean, which can be both unintuitive
> > as
> > well as performance constraining.
Yes. But if you look at the larger picture the cost of making an object
remotable is significant, you want to cut it down by having some objects
non-remote, that is, not beans, which means all the remote access has to
funnel through the bean.
It's a tradeoff between more work to go through bean to access dependent
object, or less performance by making all related objects as beans.
> > 2) If I want to promote a dependent object into a full-fledged entity
> > bean,
> > or demote an entity bean to a dependent object, then all the clients of
> > that
> > business entity must be modified. After all, the API for a dependent
Painful, I agree.
> > For example, a local inter-bean call could be a lightweight call that was:
> > * in-process
> > * used pass-by-reference
> > * had no stub, nor skeleton
> > * had a very thin EJB object that did not add a great deal of middleware
> > to
> > the call, such as security checks (After all, why would you ever need to
> > do
> > a security check when an Order calls a LineItem? You'd want that security
> > check to happen when the client calls the Order, but not when the Order
> > calls the LineItem).
There are three performance issues with remote vs. non-remote object
access.
* RMI -- local access can bypass RMI, do in-process and not use a
socket. Most EJB servers already do that today.
* Pass-by-reference -- this immediately breaks your application. If the
caller is in-process you get pass-by-reference, if the caller is
out-of-process you get pass by reference. How does the bean know who's
calling it?
* Security/transaction/whatever -- these add little overhead if you have
pass-by-value to begin with
> > This technique would solve both the problems I eluded to earlier with
> > dependent objects:
> >
> > 1) You can access a 'local' bean without going through its parent, since a
> > 'local' bean is still an entity bean. Not true for dependent objects.
> >
> > 2) You can promote a 'local' bean to a 'remote' bean without changing its
> > clients, since both are entity beans. Not true for dependent objects.
How about the following:
* You define a set of objects that can be persisted including dependent
objects -- not EJB
* You use them directly (non-remote) from session beans -- fast,
efficient
* You write a wrapper EJB bean in order to expose them to the outside
world
Tools for O/R persistence existed long before EJB. EJB is a well defined
API to make them remotely accessible, but if you only intend them to be
used inside a session bean, I would advocate using O/R persistence
directly and not CMP.
arkin
> >
> > What do you think?
> > -Ed
> >
> > --
> > Ed Roman
> > CEO, The Middleware Company
> > Author, "Mastering Enterprise JavaBeans and the Java 2 Platform,
> > Enterprise
> > Edition"
> > http://www.middleware-company.com
> > [EMAIL PROTECTED]
> > 512-784-7840
> >
> > Need help with EJB / J2EE? Ask about our on-site training and consulting
> > services.
> >
> > >
> > > From: Chris Raber <[EMAIL PROTECTED]>
> > > Subject: Re: PhoneNumber and Address as EJBs?
> > > Date: Wed, 29 Mar 2000 07:19:54 -0800
> > >
> > > Don't believe everthing you read in books! Opinions abound on this
> > topic.
> > > There is a ton of stuff in the archives on the granularity concept.
> > >
> > > Also check out Craig Larman's article titled Enterprise JavaBeans 201:
> > The
> > > Aggregate Entity Pattern. There is a link to this at
> > > http://www.gemstone.com/javasuccess/
> > >
> > > -Chris.
> > >
> > > > -----Original Message-----
> > > > From: DaveFord [SMTP:[EMAIL PROTECTED]]
> > > > Sent: Monday, March 27, 2000 10:34 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: PhoneNumber and Address as EJBs?
> > > >
> > > > Would you guys recommend making PhoneNumber and Address classes EJBs?
> > How
> > > > about LineItem of an invoice? I was reading Ed Roman's "Mastering
> > > > EnterpriseBeans", and he made order line items and EJB. But I recall
> > the
> > > > EJB
> > > > spec said not to model fine grained, dependent objects as EJBs. What
> > your
> > > > opinion?
> > > >
> > > > Dave Ford
> >
> > ==========================================================================
> > =
> > 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
