** Warning - long post **
I can certainly agree with Imre Kifor when he says:
> ...balance is the key...
when deciding the granularity of EJBs. Neither Chris Raber nor I, as
advocates of the bigger-is-probably-better approach to granularity, would
as Imre hinted
> ...squeeze unrelated functionality together in the name of "performance"
Where Imre and I appear to diverge though is in our assumptions about the
design points of EJB servers.
I assume a horizontal scaleability design point involving multiple copies
of the EJB server, on multiple JVMs, on multiple machines each accessing
the same database that is also shared with other (EJB or non-EJB)
applications. With a horizontal scaleability design point, the usefulness
of caching bean instances is limited and EJB servers supporting this design
point must aim to give acceptable performance without caching.
Conversely, when Imre says:
> ...I take a few hashtable lookups [to locate a
> cached EB instance] anytime over database access...
then it seems he is assuming a vertical scaleability design point using a
single copy of the EJB server running in a single JVM on a single machine
to get as much work through it as possible. As horizontal scaleability is
the way the industry is going I am somewhat surprise by his advocacy of
this approach.
But how does this relate to EB granularity, I hear 1400 people asking? Well
horizontal scaleability says that the database, not an object cache in a
JVM, is the point of data (re)use and sharing. Hence efficient access to
the database (rather than use of a hashtable) is key to performance. This
appears to me (sorry if I'm wrong) to take away Imre's main argument for
fine-grained EBs, because having multiple EBs access the database
separately could not be more efficient than a coarse-grained EB making a
single request. Thus there are no gains which can compensate for the
overhead of extra EB->EB calls inherent in fine-grained EBs, i.e.
coarse-grained EBs will generally perform better than fine-grained EBs.
This is in addition to the other benefits of the coarse-grained approach,
such as I don't have to make up a security policy on which security
contexts can invoke the setOrderItemQuantity method of the OrderItem Entity
Bean. (Try asking your security administrator that question!)
Imre also says:
> ...[the coarse-grained approach] is
> too easy to remember (while forgetting
> good design practices) and can lead to
> hard to manage code...
It is too early to reject my approach as bad design practice. Transactions,
security, distribution, operational management and application developement
lifecycle are important attributes in an application design that are not
related to the Domain Object Model at all. Advocates of coarse-grained EBs
are saying that EBs seem like a good place to hang all these attributes but
this conflicts with also trying to use EBs to reflect the DOM. Good design
practice will be what the tools, middleware, etc support consistently.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
