Greetings,
Just one or two points.
There is no inherent reason why you cannot talk directly to an Entity Bean.
The architectural reason for not doing so is really two fold: A)Entities are
mostly used as a means for providing persistence. Since enterprise data
tends to get mapped into all kinds of applications, it makes sense that
these are developed at an aggregation level that can be reused amongst these
applications. The result is less business logic or at least 'process'
knowledge in entities. B)minimizing network bandwidth. If each entity
doesn't know much about the process as a whole, then we will need to
communicate with lots of them to accomplish the task. That results in a
sharp increase in network calls (assuming the client is remote). If however
we could make one call to an object residing on the same server (as all
those entity beans) and have it make all the other calls, our network would
thank us.
Session beans fulfill this role. Furthermore, they are written with a
particular application (or at least fewer application types) in mind and
contain the business logic for that application. You can picture an
enterprise with lots of different applications using different session beans
each using many of the same entity beans.
However, to religiously wrap each entity bean with one session bean just so
you can talk to the outside world would (I believe) be missing the point.
Stateful session beans are good for doing just that - retaining state during
the clients session. Assuming there is a need to cache data for the
individual client, they are a great way to go. But remember, there may be
lots of other apps. all trying to cache their sessions data on the same
machine.
That's why Stateless session beans are more scalable: in effect they force
the client to cache any session state or cache nothing at all. For a GUI
client no problem. For a Web client more of a problem, however using
servlets some of that might be cached using servlet sessions (forcing the
load to your web server!).
Bottom line is: there's no basic best way to do things. You have to
consider the proposed deployment senario along with the application type.
My 2 pence!
Cheers,
Jon
Jon Ferguson PhD.
Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
"The art of living is to experience more and to want less."
-----Original Message-----
From: Shun, Vadim [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 21, 1999 12:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Help : EJB invoked in an applet.Some Doubts....
Per my understanding of EJB, it is highly undesirable for client to
communicate directly to the entity bean. It is preferrable whenever possible
to use session beans (stateless if possible) that will hold the connection
with entity beans. You can say you are using Mediator pattern to achieve
ultimate decoupling and utilize the best performance in component driven
environment.
Re. EJB server. I liked Voyager and WebLogic. WebLogic is easier to use and
it supports EJB 1.1 and JSP and can serve also as Web server or as a
secondary Web server chained to the primary Web server for performing
specific servlet based tasks.
Voyager has an advantage that it allows for transparent CORBA and DCOM
client access to your EJB. I liked their architecture and services better
but they are alittle behind in standards support (they are current as of
this writing on EJB 1.0 and Corba 2.2). I found Voyager a little more
difficult to use a well.
You can download both for 30 days of your purpose is to learn.
Re. free one. There is free source project www.ejboss.org but I do not think
they have a product anybody can use (maybe I am wrong).
Vadim.
-----Original Message-----
From: Kenneth D. Litwak [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 21, 1999 1:11 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Help : EJB invoked in an applet.Some Doubts....
I didn't follow the start of this thread, but I'd like to make a
suggestin if
it's relevant. I caught the end of a very good EJB presentation at JavaOne
last
June and the speaker said thatfor performance reasons, you wouldnot want an
applet to directly interact with an EJB. Using a pieceof middleware would
be
much more effecient thanpassing entity bean info backa nd forth from EJB
server
to client and back again. Plus, of course, the less coupled the client
(whatever it is) is to a specific middle tierimplementation, the better.
That's
not because I dislike EJBs. I think they're a great idea. It's simply an
issue
of code maintenance. I'd always vote for a client sending a command object
to a
tier twoprogram to ask it to do work on the client's behalf. Just my $.02.
Ken
>
>Hi All,
>
> you can use Visual Cafe to create the jar packager. you add the
class,
and it creates the jar with all the classes it uses. but i think you wont
like
to buy it only for this... :((
>
> i'm starting to study EJB. what EJB host are you using?
>
> you says that the files needed in a applet are very large. about
what
size are them?
>
> thanks,
>
> guich.
>
>
>
>---
>To unsubscribe, mail [EMAIL PROTECTED]
>To get help, mail [EMAIL PROTECTED]
---
To unsubscribe, mail [EMAIL PROTECTED]
To get help, mail [EMAIL PROTECTED]
===========================================================================
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".
