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 Best way to implement 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 "Best way to implement shopping cart" Watch "Best way to implement shopping cart" New topic
Author

Best way to implement shopping cart

Unni Pillai
Ranch Hand

Joined: Aug 22, 2010
Posts: 35
Hi All,

I am little confused with the implementation of a shopping cart.While user is adding/removing and changing the count of items etc do we need to use session concept? . we can do these operations in client side or if wanted to go the server also it is not mandatory to keep a session with the server right? I know the side effects like what if the user open multiple browsers etc.

If we need to use session, Http Session is better than Stateful ejbs right?

In SCEA, any body passed with out keeping the session in e commerce application?

uma

SCJP,SCWCD,SCEA
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30309
    
150

Why wouldn't you want to use an HttpSession?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Unni Pillai
Ranch Hand

Joined: Aug 22, 2010
Posts: 35
Hi Jeannae,

I was trying design a stateless e commerce application. ie, I will be passing the customerId for all the server communication.(update the cart,calculate total etc etc) thinking that it will be good for performance. but now I am confused with am I doing completely foolish?

If I am using http session , I dont have to change the class diagram otherwise I have to some changes in the class diagram .

Any insight would be helpful.

Uma
Rishi Shehrawat
Ranch Hand

Joined: Aug 11, 2010
Posts: 218

In this case i feel that HttpSession will be better than Stateful Session Bean.

I agree that in terms of performance it is always better to have a completely stateess application, however you also need to consider overhead of persisting the cart (i am presuming that you will be using a database for it) vis-a-vis the memory saved.
Yegor Bugayenko
Ranch Hand

Joined: Feb 11, 2011
Posts: 65
Call it "RESTful" instead of "stateless". Nicer wording, more modern.


follow me at yegor256.com
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30309
    
150

Rishi Shehrawat wrote:I agree that in terms of performance it is always better to have a completely stateess application, however you also need to consider overhead of persisting the cart (i am presuming that you will be using a database for it) vis-a-vis the memory saved.

Not necessarily. You are saving the memory of the session with the network overhead of passing the cart around. For a large cart, this could be significant.
Rishi Shehrawat
Ranch Hand

Joined: Aug 11, 2010
Posts: 218

In case the cart size is turning out to be large then i guess that it makes sense to persist in database. However it might need additional effort for cleaning of tables as all users who actually create cart might not actually do a checkout. So you might need to have a mechanisim in place to remove these from table.. Although this aspect probably is not in scope for the assignment.

Also if you are able to make you application completely stateless/RESTful it can improve sclability significantly as you can completely do away with session replicaiton/sticky sessions in a clustered environment.
Sharma Ashutosh
Bartender

Joined: Apr 06, 2001
Posts: 346
I used Statefull session bean(Vs HttpSession) for the Shopping cart implementation for the following reasons:

1)If it is just a web application where clients for the application is always within web tier -one can use the HttpSession to store the state. But in the case of SuD, we are creating various Services(Service Facade and Service) which can be called not just from web tier based clients but also from other services,Java applications, mobile platforms etc..(keeping in mind future state extensibility).
2)This way the HTTP Session won't be bloated when the number of concurrent user count reaches to N.
3)Don't want to implement business logic in the web tier and it should be in the business tier. Moving business logic away from SFSB to the Web tier breaks encapsulation and distribution of responsibility in the application. System will be much harder to maintain and extend in future.
4)Poor reusability and integration: Implementing Shopping Cart in HTTPSession will consequence lower reusability as it will not be able to be reused directly from non-Web Application clients. Later this can't be exposed as a Service. Somewhat similar to points #1 and #4.
5)HttpSession instances do not have a mechanism that allows them to receive transaction notifications.An SFSB that implements the SessionSynchronization interface has a way to return the data of the SFSB to its original state whenever there is a transaction rollback.This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. SFSB is the only bean which can implement this interface(SLSB and MDBs can't). Data can be loaded into the bean when the transaction starts and unloaded right before the transaction finishes, while the afterCompletion callback can be used to reset default values.

Though i admit , when we use SFSB - one has to take extra steps in terms of clustered environment as they are affects various NFRs like scalability, failover and fault tolerance.

I will say whatever you are using SFSB or HttpSession-justify it in the assignment as well as in the part 3.

Ashutosh Sharma
SCJP 1.2, SCEA 5, Brainbench certified J2EE Developer, Documentum Certified Professional
Blog : http://scea5-passingpart2and3.blogspot.com/
Rishi Shehrawat
Ranch Hand

Joined: Aug 11, 2010
Posts: 218

If we are trying to make complete application reusable by clients other than web clients, then HttpSession should not be used is the complete application, making the application completely RESTful. The other way of looking at it is to assume that service layer will be reusable by other clients, this means making a assumption that some logic will sit with the client invoking the service layer. To me doing away completely with sessions to support other types of clients is a bit of an overkill. I would do away with sessions completely if it was stated as an explicit requirement.

Every one has a different way of approaching a problem, I agree that it is very important to document assumtions/reasons for selecting a certain option.
Fernando Franzini
Ranch Hand

Joined: Jan 09, 2009
Posts: 486
    
    2

Sharma Ashutosh wrote:I used Statefull session bean(Vs HttpSession) for the Shopping cart implementation for the following reasons:

1)If it is just a web application where clients for the application is always within web tier -one can use the HttpSession to store the state. But in the case of SuD, we are creating various Services(Service Facade and Service) which can be called not just from web tier based clients but also from other services,Java applications, mobile platforms etc..(keeping in mind future state extensibility).
2)This way the HTTP Session won't be bloated when the number of concurrent user count reaches to N.
3)Don't want to implement business logic in the web tier and it should be in the business tier. Moving business logic away from SFSB to the Web tier breaks encapsulation and distribution of responsibility in the application. System will be much harder to maintain and extend in future.
4)Poor reusability and integration: Implementing Shopping Cart in HTTPSession will consequence lower reusability as it will not be able to be reused directly from non-Web Application clients. Later this can't be exposed as a Service. Somewhat similar to points #1 and #4.
5)HttpSession instances do not have a mechanism that allows them to receive transaction notifications.An SFSB that implements the SessionSynchronization interface has a way to return the data of the SFSB to its original state whenever there is a transaction rollback.This means that any data that is modified in an HttpSession during a transaction will not be reverted if the current transaction is rolled back. SFSB is the only bean which can implement this interface(SLSB and MDBs can't). Data can be loaded into the bean when the transaction starts and unloaded right before the transaction finishes, while the afterCompletion callback can be used to reset default values.

Though i admit , when we use SFSB - one has to take extra steps in terms of clustered environment as they are affects various NFRs like scalability, failover and fault tolerance.

I will say whatever you are using SFSB or HttpSession-justify it in the assignment as well as in the part 3.


Another item to be added to the list:
- Statefull is more scalable because it can use the resource passivation feature and is suitable for storing high volumes of data. HttpSession can not.


Fernando Franzini - Java Blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Best way to implement shopping cart