File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Use of Stateful Session Bean for Shopping Cart Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Use of Stateful Session Bean for Shopping Cart" Watch "Use of Stateful Session Bean for Shopping Cart" New topic
Author

Use of Stateful Session Bean for Shopping Cart

Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Hi,

I'm going to use a SFSB for Shopping Cart. I've read a lot o posts regarding this approach e the most part of them indicates this order:

client -> SLSB -> SFSB

The client (client application or Web application) calls a SLSB in order to perform operations in the Shopping Cart.


My doubt is if it would be a good approach to mix these two things:

client -> SLSB -> SFSB (for confirming, pricing, etc...)
client -> SFSB (just to set the selected Flights and Segments into the Shopping Cart)


Any comments?


Thanks in advance.
Samuel
Jatin Sutaria
Greenhorn

Joined: Dec 09, 2004
Posts: 27
Hello,

Here's what i think:

Originally posted by Samuel Pessorrusso:

My doubt is if it would be a good approach to mix these two things:

client -> SLSB -> SFSB (for confirming, pricing, etc...)

It should be good as long as you have a mechanism in place that allows to access the same SFSB instance through the stateless bean. But isn't confirming and pricing stateless operations. Why you would want to involve a stateful session bean for that. Is there a need to go to the cart to perform stateless operations on it. why can't your form bean objects (POJO objects that correspond to entities) go directly to stateles session beans for stateless operartions.

Originally posted by Samuel Pessorrusso:


client -> SFSB (just to set the selected Flights and Segments into the Shopping Cart)

Think it looks OK, but would still prefer a session facade in front of SFSB.

Thanks,
Jatin
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
You just need to pass the Handle for the approach:
Client -> SLSB -> SFSB

In this way the SLSB becomes a Facade for the ShoppingCart and the services related to Itinerary management.
[ July 27, 2006: Message edited by: Samuel Pessorrusso ]
Santiago Urrizola
Ranch Hand

Joined: Apr 27, 2006
Posts: 172
my two cents ..

Client -> BusinessDelegate -> SFSB -> AppService (SLSB) -> Entity ->DAO
or
Client -> BusinessDelegate -> SFSB -> AppService (SLSB) -> DAO


Santiago Urrizola : La Plata - Argentina<br />SCEA (89%-92%)<br /><a href="http://gpitech.wordpress.com/" target="_blank" rel="nofollow">http://gpitech.wordpress.com/</a>
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
Samuel
Why can't you just have
Client -->SLSB (for searching flights, getting price etc) and
Client ---> SFSB(for creating itinerary)
A session bean method acts as a business method of a workflow and I don't see any additional benefit in wrapping it up with SLSB.


Technical quiz and interview questions   SCJP 6 mock practice test
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Why can't you just have
Client -->SLSB (for searching flights, getting price etc) and
Client ---> SFSB(for creating itinerary)
A session bean method acts as a business method of a workflow and I don't see any additional benefit in wrapping it up with SLSB.


We can reduce the number of remote calls.
Example:

Client select Flights calling the SLSB; the SLSB sets the Flights in the SFSB; SLSB executes price use case which returns the priced itinerary; SLSB updates the SFSB; SLSB starts the search for the alternative flights and returns the alternative Flights to the client;

If you notice, the client has made just ONE remote call and the SLSB update the SFSB, execute the price use case and execute the search for alternative flights. The SLSB is really working as a Facade.

Am I doing something wrong?
Any comment?
Sarbur sar
Greenhorn

Joined: Oct 10, 2005
Posts: 13
------------------------------
Client select Flights calling the SLSB; the SLSB sets the Flights in the SFSB; SLSB executes price use case which returns the priced itinerary; SLSB updates the SFSB; SLSB starts the search for the alternative flights and returns the alternative Flights to the client;

If you notice, the client has made just ONE remote call and the SLSB update the SFSB, execute the price use case and execute the search for alternative flights. The SLSB is really working as a Facade.
------------------------------

If we use the SLSB to manage the shopping cart session bean, then how shoppingcart session bean reference will be maintained in SLSB across multiple method calls such as search flight, price, alternative flight. So I would feel that following approach will be best option,
client --> Facade SFSB --> Shoppingcard SFSB.

Any comments.
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Originally posted by Sarbur sar:
------------------------------
If we use the SLSB to manage the shopping cart session bean, then how shoppingcart session bean reference will be maintained in SLSB across multiple method calls such as search flight, price, alternative flight.


As I said before, the caller (web or client application), gives to the SLSB the SFSB Handle (the Handle is stored at the user session which is located at the caller application).

Any comments?
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
Samuel you are right.I would have a SLSB as facade not SFSB and the approach what you have mentioned looks fine.
But I think session storage would start when the customer would finally select the flights, just before seat look up.
But with what we have discussed hierarchy would be
client -> SLSB -> SFSB
And you should not use this
client -> SFSB.
Every call would go to SLSB , when ever there is need to store session, call SFSB.
[ July 28, 2006: Message edited by: Vinays Singh ]
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Thanks for your answer. I agree with you; that is what I was thinking.


Best regards
Samuel
Sarbur sar
Greenhorn

Joined: Oct 10, 2005
Posts: 13
-------------------------------
As I said before, the caller (web or client application), gives to the SLSB the SFSB Handle (the Handle is stored at the user session which is located at the caller application).
--------------------------------
I understand your approach. SFSB bean first will be created in SLSB, but still this handle of SFSB will stored in client side(web-tire/application client tier). Is it really required to pass handle to SLSB each request or we can maintain the SFSB from client side itself by using remote call.

Instead of sending the handle each request, why dont we use the Stateful session bean to hold the reference of ShoppingCartSessionBean. I believe that Petstore uses the SFSB Facade to keep reference shoppingcart session bean.

Any comments..
Samuel Pessorrusso
Ranch Hand

Joined: Jul 21, 2005
Posts: 164
Originally posted by Sarbur sar:
-------------------------------
Instead of sending the handle each request, why dont we use the Stateful session bean to hold the reference of ShoppingCartSessionBean. I believe that Petstore uses the SFSB Facade to keep reference shoppingcart session bean.


I have already thought about that, but I don�t like the idea of using a SFSB for services instead of using it just to maintain the Shopping Cart; but that�s is MY opinion, you can do whatever you want, there are a lot of ways of doing the same thing (you just need to justify).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use of Stateful Session Bean for Shopping Cart