Ed,
<vendor>
It probably comes as no suprise, but I very much agree with you.
Entities are useful for both large- and medium-grained objects.
For very small objects, plain JavaBeans are a better solution.
But, as you note, these should be used only for cases where you
are confident that you will never want to expose these as bona
fide objects outside the server. I think something like a
LineItem is a very good candidate for entity beans. (And, yes,
I know the spec. states otherwise. People do make mistakes ;-)
As you point out, the main reason to avoid using entity beans
for smaller objects is the potential performance overhead. But,
again, as you point out this can be avoided in the intra-bean,
in-process call case. And it should be avoided by a competent
server implementation.
In general, I think the "pass-by-reference" issue is not as big
a deal as most people make it out to be. In the real world, these
LineItem type objects do not themselves hold complex data: typically,
a LineItem will comprise some numbers, strings and dates: things
that are readily mapped to Oracle, et al. Remember that the
different semantics for pass-by-reference (PbR) verses pass-by-value
(PbV) do not apply for these standard JDBC accessible data types.
In Java, all numbers, strings, dates, etc. are immutable objects.
Thus, whether you use pass-by-value or pass-by-reference for these
data types is irrelavent.
As do other vendors, we support the ability to turn on or off PbV
verses PbR. However, when asked to provide PbV semantics, we apply
this rule on an argument-by-argument basis. Thus, if your signature
contains only numbers, strings, dates, etc., then we don't do the
argument copying (since it is unnecessary). Which means that the
performance overhead of pass-by-value is only an issue for things
like LineItems if they contain complex data types (such as Vectors)
AND if they rely on PbV for their manipulation of such types (which
is unusual, in and of itself).
Remember that we are simply making LineItems into entity beans. If
the LineItem were a dependent object, then it would already be using
PbR semantics, and you would already have to be careful to not modify
parameters, etc. In the real world, most Java developers know how to
write code that uses PbR, since that is how they write all their
normal (non-distributed) code anyway!
Of course, to make colocated calls efficient, you need to avoid all
the other baggage: marshaling, stubs/skeletons, security checks, etc.
Avoiding this overhead is one of the marks of a good server. If a
server can't do this...
The other requirement for supporting large numbers of smaller-grained
entity beans is making the JDBC access efficient. Users of our products
know that we have implemented a large number of optimizations to avoid
all the typical problems associated with using entity beans: tuned write,
automatic read-only access detection, caching of state across finder
calls and bean access, etc. Our goal was to make using entity beans
as fast as writing the SQL yourself, or in many cases even faster.
(For example, when you write the SQL yourself, you have to recreate
your prepared-statements; our JDBC code knows to reuse prepared-statements
across transactions. You might be surprised how big an impact that one
small optimization has, and unfortunately it is an optimization that
cannot be made in a server-independent way for BMP beans, or for session
beans which do their own SQL.)
To summarize, you should be able to use entity beans for smaller-grained
objects (such as LineItems) and a well-implemented server should provide
you with excellent performance if you chose to do so.
</vendor>
-jkw
Ed Roman wrote:
>
> 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".
