>> I would NOT use a servlet or other device, because the EJB container
that the deployer chooses to use might not support them.
Why not? We have JRun running on our WebLogic 4.02 box, and will continue
to do so until WebLogic supports Java 2. It seems fine... even though the
servlet is out of proc with the EJS, we don't notice.
I don't see why you shouldn't count on being able to run servlets
everywhere, whether it and the EJS comes from a single vendor or not.
David
Ed Roman <[EMAIL PROTECTED]> on 05/16/99 02:33:17 AM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: David Rauschenbach/ZLAND)
Subject: sessions wrapping entities
Jim,
If I understand your message correctly, you're agreeing that you need to
wrap entity beans with SOMETHING (a "bulk access provider") to enhance
network performance and perform many operations on behalf of a single call
from a client. You're questioning, "why use session beans?" Well, here's
what I would NOT use:
- I would NOT use an entity bean, because we are not modeling persistent
objects, we are modeling bulk access providers to persistent objects.
Entity beans = session beans + ejbStore/ejbLoad. Why force the container
to
perform these no-op persistent operations?
- I would NOT use a servlet or other device, because the EJB container that
the deployer chooses to use might not support them. I need my beans for
sale to run in any container, and I need my bulk access provider to run in
my entity bean's address space.
So what else is there? Session beans. Session beans are supported in every
EJB container, and they are non persistent. Perfect for wrapping entity
beans and providing that extra value add. And since session beans are
transactional, you can perform bulk *transactional* operations on multiple
entity beans as well.
Example: I have a bank account entity bean. I want to withdraw from one
account and deposit into another account in the same transaction. How do I
do it? Two ways: write some non-EJB client code to deal with transactions
using a transaction API (bad and error prone) or write a session bean
deployed with TX_REQUIRED who calls withdraw() on entity bean 1, and then
deposit() on entity bean two. Simple, safe, and fast.
-Ed
>[Frentress, James] of course you know there is nothing special
>about session bean when it comes to accessing ejb's of any type.
>so, while using session beans to allow "bulk" operations can do
>what you say, the same can be accomplished using entity, or any
>other java class for that matter. as a general statement, a great
>mechanism for this is the Broker, Queue, and Command design
>patterns (messrs. Gamma et. al. and Buschmann et. al.) this
>paragraph provides argument for "session wrapper" at the "one of
>many possible implementation options" level.
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
===========================================================================
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".
