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".
