Hi Sripada
Its true that u can maintain the session in the servlet side.
Lets take the most popular example -- a shopping cart. Here the end user
will go on adding/removing the items in his cart and the web page goes on
updating/showing the items that he has chosen so far and the total price etc
etc.
Now lets take the servlet session paradigm. Here u can represent the cart by
the httpsession object and go on doing session.putValue.. and for each the
servlet can ask the stateless session bean to calculate the price of the
selected items. And when the nd user finally submits -- then the servlet
finds out all the items he has selected and gives it to the stateless
session bean for calculation etc etc.
Now the other way of doing this is --- instead of stateless session bean --
have a stateful session bean and make the servlet act just as a gateway to
the stateful bean. The stateful session bean mailtains all the cart details
--- so effectively the stateful session bean becomes a shopping cart instead
of the servlet/httpsession becoming the cart.
Now with the 1st one -- take the case of a non http client -- who will not
want to access the application logic using servlets --- then that client
have to maintain the cart on his own. But the 2nd case is more effective in
the case of a non http client. Or even if u take a non servlet client like
say cgi script which does not have those sophisticated session apis ---
their the 2nd soln will be better.
This is entirely my feelings --- I may be wrong and any comments is
appreciated.
TIA
Anamitra
-----Original Message-----
From: Sripada Srinivas
To: [EMAIL PROTECTED]
Sent: 4/15/00 6:16 AM
Subject: Re: Largest EJB Implementation ?
Hi Ana,
> Does
> it point to the fact that their requirements were pretty simple or
they did
> some designs like maintaining sessions in the web server and not in
the ejb
> server??
**********
I am wondering how do you manage this. If the bean is contacted through
the
servlet, the session maintainance needs to be carried out by Servlet
only.
Correct me If I am wrong.
***********
>
> I really dont get what value add I am getting from using EJBs if I
dont go
> for entit beans or stateful session beans. AFAIK it is not a good
design to
> make the clients session aware --- and thats precisely why stateful
session
> beans came into being.
******************
Is it the reason??
******************
> But then people say it is too slow and go back to
> 1> Either storing the session info in HttpSession in the servlets
engine OR
> 2> Storing session info in a hastable like data structure in the ejb
server
> side -- something like a dependent object to the ejbeans.
> ie back to square one!
*************
It really baffles me how does the stateful session bean can make a
client code,
not take care the responsiblity of the session tracking??. I am talking
about
the scenario using the servlets, which is quite popular.
*********
--Sripada
========================================================================
===
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".
