Dave Glasser wrote:
>
> On Wed, 24 Jan 2001 14:18:03 +0000, Ian McCallion wrote:
> >I'm assuming you mean you decided not to use ENTITY beans to model business
> >concepts;-)
>
> Actually I meant session beans. I was responding to Richard
> Monson-Haefel's post where he discussed using session beans to model
> business concepts in much the same way that entity beans do.
Sorry!
> <big snip>
>
> Most of the actual business logic functionality will in fact occur
> inside session beans, except that it will act on simple data objects
> instead of entity beans. The "business rules", so to speak, will be
> coded inside session beans. When one of these rules are executed,
> however, it will be a quick transaction, using passed-in parameters.
> There will be no conversational state built up in the EJB container
> prior to a transaction being executed. (There will in some cases be
> conversational state built up in the servlet container.)
It's becoming clear to me now what you are doing and it sounds fine. My only
slight reservation is with avoiding conversational state in the EJB container.
This may be exactly right for your application but it should not be normal
practice; conversation state SHOULD be managed by the EJB container rather than
the servlet container for the following reasons:
1. It's easier to program to instance variables than to a session state
object.
2. Typically much of an application's business logic cannot execute
against data that has either just been read from a shared database
or is just about to be placed onto a shared database so avoiding
use of stateful session beans often results in servlets and
clients becoming rather heavy.
3. Any EJB server should be able to handle many thousands of stateful
session beans so there should not be an issue of scaleability.
> We'll still have the benefit of declarative transaction management,
> and in some cases distributed transactions, that EJB provides, and in
> my estimation that benefit is nothing to sneeze at. One thing I like a
> lot about EJB is how much you're able to configure your application at
> deploy time -- things like transaction boundaries, or binding a
> particular service to a JNDI name referenced in code, or selecting
> which type of bean class you want to deploy with a particular
> home/remote interface pair, etc.
Agreed.
> Believe me, I'm not one to use a technology just because it seems to
> be the hottest buzzword of the moment. I'll always ask myself, "what
> does this get me?" first, and if I can't come up with a reasonable
> answer, I won't use it. (Assuming the decision of whether to use it is
> mine, of course. :) This whole thread started because I was asking
> that very question about entity beans.
And an excellent thread it has bean;-)
Ian McCallion
===========================================================================
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".
