Why appeal to a session bean to calculate the price of a shopping cart? Why
not reify ShoppingCart and give it a method getTotalPrice(), which it would
implement by summing over its contents, which would be objects that respond
to getPrice(), perhaps by returning an instance variable value that was set
on the server side before the object was sent from the server? Not only
would this look the same to the user and save network roundtrips, but it
would also be in line with the "behaviorist" camp of methodologists (e.g.,
Rebecca Wirfs-Brock) who champion meaningful behaviors on business objects
and who rail against "dumb data holder" objects.
Randy Stafford
Senior Architect
GemStone Professional Services
> -----Original Message-----
> From: Bhattacharyya, Ana [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 17, 2000 9:32 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> 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".
===========================================================================
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".
