hey Ed,
> -----Original Message-----
> From: Ed Roman [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, May 16, 1999 2:33 AM
> To: [EMAIL PROTECTED]
> 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.
[Frentress, James] in a very general sense, i'm arguing for good
distributed and decoupled architecture.
> You're questioning, "why use session beans?"
[Frentress, James] most precisely, should "session wrapper"
continue to be generally prescribed? i'll address this fairly completely
below.
> 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?
[Frentress, James] ya lost me here. maybe we'll come back to this
below.
> - 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.
[Frentress, James] no argument here except for "other device" since
it's there that the real possibilities lie.
> So what else is there?
[Frentress, James] how much time do you have ... ;)
> 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.
[Frentress, James] and it's why session is one of many
implementation candidates for a distributed architecture. the question
remains, is it a good or even necessary option and in what instances should
it be employed? most specifically, should "session-wrapper" advice continue
to be given.
> 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)
[Frentress, James] disagree. our entire system executes this way.
system-wide, it's a screenful of code. our design adds extreme functionality
because it can conditionally execute absolutely *any and all* requests
supported by the underlying system (even if there's a failure in the midst)
within a transaction, and allow the caller to peruse error objects by call.
excellent for debugging. excellent for portability. excellent for
maintenance and deployment. safer than a brittle session-wrapper that allows
unqualified people to break the system in a very opaque way. did i say fast
and featherweight?
> 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.
[Frentress, James] trivial examples are so limited in their ability
to address a total solution, but lets follow and expand on this for a
moment.
imagine you've got the account entity bean as you say, with many
attributes. there are many use-cases associated with this account entity. in
fact, there very likely are more use-cases than you can imagine when you
first implement the thing. following the advice most commonly prescribed,
you create a session-wrapper that allows access to a number of underlying
persisting entity beans. so how many methods must you create on this session
bean to address all your use-cases? the answer is that you don't know, you
can only address the cases you've identified (good thing because it's going
to be bloated enuf with the things you thought of right away). so you start
adding methods to the session bean. now it doesn't take very much
imagination to see problems here. you immediately run into massive
overloading requirements. soon thereafter you need more (overloaded) methods
that you hadn't planned on. on-and-on like this all the way to the problem
Imre discusses elsewhere regarding timeout. and all that for an artificial
thing that isn't giving you anything you can't get with better design.
the better design will allow you to transparently treat all ejb's as
if you're actually making method calls directly on them. it is completely
possible to implement what i'm talking about with session bean. however,
that would *not* be a "session wrapper". that would be a combination of
Broker, Queue, and Command. whether or not to implement these things with
session is another topic entirely. with this thread, some of us are
challenging the widely held and increasingly spread belief that session
wrappers are a good thing. my experience designing/deploying/running real
ejb systems is that they are not something to prescribe generally.
> -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".
