This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Best way to implement shopping cart

 
Unni Pillai
Ranch Hand
Posts: 35
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33696
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why wouldn't you want to use an HttpSession?
 
Unni Pillai
Ranch Hand
Posts: 35
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 218
Hibernate Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 80
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Call it "RESTful" instead of "stateless". Nicer wording, more modern.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 33696
316
Eclipse IDE Java VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 218
Hibernate Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 346
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rishi Shehrawat
Ranch Hand
Posts: 218
Hibernate Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 489
2
Java Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic