I'm using a SFSB in business tier to hold shopping cart content and would like to keep it.
In web/presentation tier, I have a product.jsp (with a managed productBean to add product to cart) and a cart.jsp (with a managed cartBean to update cart).
After SFSB adds product to cart, is it good idea to send the whole shopping cart content back to web/presentation tier for display to user?
Or is it better to minimize the communication payload between tiers and keep a copy of shoppinp cart content in cartBean in web tier. But that will leave two copies of shopping cart content: one in web tier and another one in business tier.
If I understand the query properly, showing the contents of the cart retrieved from the bean and then using a copy of it in web tier for display purpose is enough. While adding/modifying/deleting the product to the cart, only the product id has to be passed from web and added to SFSB.
If copy is not maintained for display then SFSB has to be available even in web tier. If business logic has to be seperated from presentation tier I think copy is required.
I plan to make Cart a POJO and hang it on the SFSB. After computation/calculation, the Cart POJO can be off the SFSB and given to presentation tier for display.
Everytime user adds/removes an item in cart, the item ID and quantity are sent to SFSB to refresh the Cart. Then the Cart POJO is sent back to presentation tier for display.
If user does multiple item updates (i.e. changing no. of units to purchase for multiple items) at the same time, then a hashmap containing a list of item IDs and quantities are sent to SFSB to refresh the Cart.
Does it look like a reasonable approach or is it too much inter-tier communication?
Btw, there is only web client (no rich UI client). I chose SFSB (over HttpSession) with following justifications:
1. Better resource management (SFSB can be passivated/activated when limit is reached)
2. Better transaction control
3. Easier to turn cart into persistent entity if needed (remember the cart content after browser crashes & restarts)
4. Clear separate of concern. Business logic (i.e. apply discount) can be easily applied to data that is close to the logic.
5. Thread safe
6. Aligned with approach in JEE Blueprint
Of course there are downsides:
1. More overhead and impact to performance
2. Less scalable than managing the Cart in HttpSession and having a SLSB to consume the Cart (i.e. calculating shipping cost or turn it into an order)
3. Not able to turn SFSB into Web Service (if future needs arise)
Do these statements hold water?
Joined: Mar 12, 2011
To justify for SFSB, Is your functional requirement talks anything about transaction? If yes, then definately SFSB will have more weightage and yes there will be a POJO which is used to pass data between business and web tiers. But sufficient memory is required for the bean to passivate and activate.
SFSB when it is compared with SLSB using HTTPSession for maintaining the state of the client, may be scalable but how it is handled in Cluster environment. But the intension of the examiner would be to use SFSB whenever there is a scenario of shopping cart.
How about maintaining cart in the http session as a POJO for display purpose along with the SFSB. Whenever cart is modified (updated for quantity, or deleted or inserted) then make update to SFSB and sync up the Http session also.
Joined: Mar 12, 2011
There is no need to maintain POJO of cart in Http session in case of SFSB. Purpose of SFSB is to make sure to maintain the variable's state in session.
Joined: Jan 01, 2011
What my point was, rather than storing all the product information , like id, title, description, images , reviews, comments, quantity, price at EJB level, we just store product id and quantity in the Session bean. Rest of the information we can store in Httpsession at the presentaion layer. Just my two cents. Wouldn't it be costly transaction to fetch all the data from SFSB every time , user clicks on the cart to view it.
What are the other options of caching the data at presentation layer?
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com