Ed,
After some thought...
This seems like a reasonable approach and one that some vendors are doing in
a proprietary way already.
I have also seen where folks want to be able to limit the scope of a bean in
the more general sense. For example, to enforce the case where clients go
through Session Beans to interact with their Entity Beans, some are using
security hoops. A name space scoping rule via deployment would be more
convenient.
<soap box on>
The only reservation I have on this is that I think of EB's at the moment as
coarse grained facades to the objects they encapsulate (e.g. the component
is the Order not all the stuff inside the Order). I don't care for EB's all
over the show in the domain model because of the mixing of life cycle and
container hooks with pure domain objects. It seems the RDBMS just won't stay
out of our domain model. Shame.
I also like the idea that my domain objects might stand independent of EB's,
and could be used in other contexts.
<soap box off>
For the EB centric, this seems reasonable. I guess I am stubborn.
-Chris.
> -----Original Message-----
> From: Ed Roman [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, March 31, 2000 12:11 AM
> To: [EMAIL PROTECTED]
> Subject: 'local' entity beans vs dependent objects
>
> Chris and other gurus- I've been thinking a lot about this since I wrote
> that chapter of my book, and I'd like your reactions to the following
> thought process.
>
> As I understand it, the primary argument against making entity beans
> fine-grained, and using dependent objects, is because inter-bean
> communications are generally expensive. Because of this, many people have
> been advocating the use of dependent objects, which are Java classes that
> hang off a parent bean.
>
> But there are some problems that bug me with dependent objects. They are:
>
> 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.
>
> 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
> object
> is very different than the API for an entity bean. For example, when I
> create a dependent object, I use new(). When I create an entity bean, I
> use
> home.create().
>
> If slow inter-bean communications is the primary motivator behind
> dependent
> objects, then what if inter-bean communications could be made fast without
> resorting to dependent objects?
>
> 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).
>
> A remote inter-bean call could be:
> * out-of-process
> * used pass-by-value
> * had a stub and skeleton
> * have a thick EJB object with a great deal of middleware, such as
> transactions, security, and other middleware checks.
>
> As I understand it, the Inprise Application Server as well as others allow
> you to optimize inter-bean communications in a similar way to the above
> proposal. Would this not allow the application developer to make a more
> fine-grained object model?
>
> There are problems I can see with this proposed approach. The ones most
> obvious to me are:
>
> * I do realize that Inprise has done this in a proprietary way, and there
> is
> no standard from Sun for a local verses a remote bean.
>
> * RMI marshalling semantics are not preserved when a developer writes an
> application that:
> * Leverages local inter-bean calls
> * Relies on RMI pass-by-reference semantics
> * And then, that bean is then redeployed into a container that
> does not
> support local inter-bean calls, violating the pass-by-reference semantics,
> and changing the application
>
> But if Sun standardized on a formal way of controlling local vs remote
> inter-bean calls, then both these issues would be solved. For example:
>
> <ejb-jar>
> <enterprise-beans>
> <entity>
> <ejb-name>Order</ejb-name>
> <ejb-ref type="dependent">OrderLineItem</ejb-ref>
> ...
> </entity>
>
> <entity>
> <ejb-name>OrderLineItem</ejb-name>
> ...
> </entity>
> </enterprise-beans>
> ...
> </ejb-jar>
>
> 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.
>
> 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".
