----- Original Message -----
From: David Rauschenbach <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 31, 1999 10:28 AM
Subject: Re: EB granularity was RE: design question with entity beans
> >> 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.
>
> I can't speak for what Imre's going to do in his clustering, but I can
> point out an assumption you made in your conclusion. You assumed that nodes
> in the cluster don't have any interest in communicating with each other for
> the purposes of cache consistency.
>
> Speaking for myself, I prefer a multicast between nodes on a fast subnet
> over an RDBMS query.
Technology that is hardly present on any commercial level.
>
> Ian McCallion <[EMAIL PROTECTED]> on 08/31/99 09:22:53 AM
>
> Please respond to A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
>
>
> To: [EMAIL PROTECTED]
>
> cc: (bcc: David Rauschenbach/ZLAND)
>
>
>
> Subject EB granularity was RE: design question with
> : entity beans
>
>
>
>
>
>
>
>
> Note: Some recipients have been dropped due to syntax errors.
> Please refer to the "$AdditionalHeaders" item for the complete headers.
>
>
>
> ** 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".
>
> ===========================================================================
> 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".
