Wrap entity beans with session beans for performance. If your EJB system is
distributed across multiple tiers, you don't want a network roundtrip on
every get/set method that you call on entity beans. 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.
Note: You can sidestep network performance problems by deploying your
enterprise beans and their clients in a single tier. However, as soon as
you shift to a multi-tier deployment, your performance will be hosed. If
you wrap entities with sessions, you have a high-performance solution that
works in any tier combination. 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.
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.
(On a related note, can anyone come up other reasons besides these on why
you'd need to seperate a servlet/JSP/ASP layer and an enterprise bean layer
into two different tiers? 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),
performance is better (no network between GUI logic and business logic), 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.)
>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".
