hey Ed, thanks for throwin' down with us. i pick some nits below but the
details are important to me so i don't want any incorrect assumptions to
pass unnoticed.
> -----Original Message-----
> From: Ed Roman [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, May 15, 1999 1:45 AM
> To: [EMAIL PROTECTED]
> Subject:
>
> Wrap entity beans with session beans for performance. If your EJB system
> is
> distributed across multiple tiers,
[Frentress, James] here i assume you're referring to OUT (of
process) calls and probably even calls across physical systems. no argument
for "session wrapper" is given here.
> you don't want a network roundtrip on
> every get/set method that you call on entity beans.
[Frentress, James] i've argued before and i still believe that with
the plethora of design patterns available for increasing IN (in-process)
computing in a distributed system (and proper distributed computing in
general), why do people cling to the notion that every call in a distributed
system results in an OUT call? this sentence lends no direct support for the
"session wrapper" argument but rather argues for good distributed
architecture.
> Session beans can act
> as bulk access providers to session beans, allowing you to call one
> session
> bean method that performs many entity bean operations. This enhances
> network performance. You cannot put the bulk access methods in the entity
> bean itself, because the bulk access could involve several DIFFERENT
> top-level entity beans.
[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.
> Note: You can sidestep network performance problems by deploying your
> enterprise beans and their clients in a single tier.
[Frentress, James] to clarify my understanding, i assume you mean
moving OUT calls to be IN calls. the further OUT your call was, the larger
the presumed gain will be as you move it IN. no argument to support "session
wrapper" here.
> However, as soon as
> you shift to a multi-tier deployment, your performance will be hosed.
[Frentress, James] session bean is merely an implementation option
and has no direct bearing on this issue. an architecture that addresses
distributed (eg OUT) computing is the important thing. therefore, this
doesn't support the "session wrapper" argument.
> If
> you wrap entities with sessions, you have a high-performance solution that
> works in any tier combination.
[Frentress, James] i'd reword this to note it as a possible
implementation, one of many - and not the best in all or even many cases, of
a distributed (specifically OUT) architecture. a deployment descriptor is
designed for use by someone who does not really understand the
inner-workings of the beans it exists to support. setting timeout properties
"incorrectly" for a session bean causes systems to break spectacularly. i'd
further argue that nobody, including the bean author, can tell you which
values will be appropriate unless they say "huge number" in which case
you're arguing against "session wrapper".
> Combinining enterprise beans with their
> clients in a single tier is not an option sometimes either. For security,
> companies occasionally need to segregate their deployment with firewalls
> due
> to security reasons. Other companies need deployments involving multiple
> heterogeneous enterprise domains, such as departmental or corporate
> domains.
[Frentress, James] i'm sure i'm being dense but i see no argument
for "session wrapper" here.
> PS: I don't buy the distributed GC argument. Clients keep references to
> EJB
> objects, not entity bean class instances. The container can release the
> entity bean class instance regardless of what the client is doing, and
> instantiate it again later if necessary. Anyway, this is a systems-level
> issue, not an application-level issue.
[Frentress, James] i think imre will address this.
> (On a related note, can anyone come up other reasons besides these
[Frentress, James] sorry, but on the topic of "session wrapper",
i've heard net zero argument as to why this is the superior or even a good
OUT architecture. i know everyone parrot's the scheme (i'm sure i did before
i "knew" better) and i've even heard what i thought were good arguments.
your arguments above are for a proper distributed (specifically OUT)
architecture but i don't see direct support as to why "session wrapper" is a
good way to go.
> on why
> you'd need to seperate a servlet/JSP/ASP layer and an enterprise bean
> layer
> into two different tiers?
[Frentress, James] a good analogy is "why do we have database
servers" or specialization in general. presentation may have special
features that a specialized service handles best - and then again maybe not.
i assume by "tiers" you mean that "presentation" and ejb are OUT of process.
> After all, these days the major app server
> support both GUI logic and enterprise beans deployed in a single tier.
> Maintenance is better with a single tier (half the machines to
> administer),
[Frentress, James] possibly but not necessarily and probably
"fewer" is a better word than "half".
> performance is better (no network between GUI logic and business logic),
[Frentress, James] this is not necessarily true but instead depends
on a number of variables.
> DB
> connections can still be pooled, thread priorities can be tuned to give
> priority to tasks within the app server, and new machines can be added for
> scalability. Load-balance HTML requests between the machines with a
> packaged box and you've got a deployment.)
>
[Frentress, James] it's quite possible i rambled and missed the
point of some of your arguments. if you or anyone else will help me get my
mind right, i'll appreciate it.
seeya,
jim
> >From: Jim Frentress <[EMAIL PROTECTED]>
> >Subject: Re: Entity no more expensive than Session: WAS:
> findLargeAccounts
> >- why bother?
> >Date: Fri, 14 May 1999 17:06:35 -0700
> >
> >I'd be extremely interested in more feedback on this, especially the
> >perspectives of CORBA based vendors (IBM (im), Inprise (jw), Oracle >
> >(hh)).
> >I'd also love to hear what WebLogic (ss) thinks about this.
> >
> >-----Original Message-----
> >From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
> >Sent: Friday, May 14, 1999 4:09 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Entity no more expensive than Session: WAS:
> >findLargeAccounts - w hy bother?
> >
> >Jim,
> >
> >The reason for this tendency to wrap entity beans with session beans is
> >that, on certain platforms, entity objects cannot be released after use.
> >
> >This issue causes great difficulty for servers written in languages other
> >than Java (i.e. based on CORBA). Java servers, however, can take
> advantage
> >of distributed GC. Well, sort of. DGC is not exactly useful for JDK1.1
> >based
> >servers. The servers themselves need to hold on to the entity objects so
> >that they can pass them out to the next client. Of course, then GC cannot
> >reclaim the objects, hence even with JDK1.1 based servers, temporary
> >entities are a no-no.
> >
> >With Java 2 the situation changes drastically. A Java 2 based server can
> >hold on to entity objects with "weak" references, thus allowing unused
> >entities to be collected automatically. As you already know, being able
> to
> >create entities on the fly dramatically increases server resident data
> >reuse
> >and decreases unnecessary session object creations and maintenance. The
> >downside? One would say DGC. However, DGC is used regardless whether you
> >access session or entity objects. Actually, chances are that with entity
> >references you will need less DGC since you are passing around fewer
> >remote
> >references.
> >
> >Do I need to say that Ejipt is based on Java 2 and is taking full
> >advantage
> >of the scalable server features of the platform ? :-)
> >
> >Imre Kifor
> >Valto Systems
>
>
>
> _______________________________________________________________
> 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".
