aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Different ways of implementing shopping cart Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Different ways of implementing shopping cart" Watch "Different ways of implementing shopping cart" New topic
Author

Different ways of implementing shopping cart

Soggadu Sokudi
Greenhorn

Joined: Dec 14, 2005
Posts: 4
Hello friends,

What are the different ways of implementing shopping cart functionality and what are the pros and cons of each implementation.

I understand it is difficult to answer at one shot. Please help me out.

Thanks,
Soggadu
[ December 14, 2005: Message edited by: Soggadu Sokudi ]
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Soggadu,

I didn�t implement any shopping char application in my life but I�ll try my best to help. Defining the problem it occurs to me that the real challenge for the shopping chart module (remark that I�m not saying for the entire application, whose complexity can grow exponentially) is to find an efficient way of storing and maintaining the user state. Having said that it also occurs to me (due to the fact that the application should be web enabled) there are two distinct approaches:

  • Maintain the client state using SFSBs.
  • Maintain the client state using HttpSession.



  • I�m stopping here for now and wait for other people to share there thoughts. I�d like to make sure that I�m on the right track. I�d also appreciate if there are other different approaches or the problem should be redefined. If nobody will answer till tomorrow morning then I�ll assume that my approach is right and we shall see from there.
    Regards.


    I think, therefore I exist -- Rene Descartes
    Soggadu Sokudi
    Greenhorn

    Joined: Dec 14, 2005
    Posts: 4
    Hi Valentin,

    Thank you for your reply.

    I think you are in the right direction. One more approach I could think of - using temporary database tables for maintaining the state. The significant disadvantage of this approach is performance hit.

    Regards,
    Soggadu
    Devender Thareja
    Ranch Hand

    Joined: Jul 14, 2005
    Posts: 187
    Originally posted by Soggadu Sokudi:
    Hi Valentin,

    Thank you for your reply.

    I think you are in the right direction. One more approach I could think of - using temporary database tables for maintaining the state. The significant disadvantage of this approach is performance hit.

    Regards,
    Soggadu


    You mean use SLSB and database temporary tables? For database interaction would you use entity beans on POJO?


    Devender Thareja
    SCEA, SCBCD, SCJP
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    Hi Soggadu,


    I think you are in the right direction. One more approach I could think of - using temporary database tables for maintaining the state


    Makes sense to me. It should at least be consider as the third possibility. So far we have:

  • Maintain the client state using SFSBs.
  • Maintain the client state using HttpSession.
  • Use DAO/Entity EJBs/ORM tool to persist the state in the database.



  • Are there any other options?
    Regards.
    paramesh ande
    Greenhorn

    Joined: Dec 15, 2005
    Posts: 18
    Hi,
    For Shopping Cart type of applications , state persistance can be done by using the Cookie objects also, besides the HttpSessions ,SFSB, and the EntityBeans.
    By using cookies we can store the state of the client at the client machine only.

    [ December 15, 2005: Message edited by: paramesh ande ]
    [ December 15, 2005: Message edited by: paramesh ande ]
    Roger Chung-Wee
    Ranch Hand

    Joined: Sep 29, 2002
    Posts: 1683
    You can also maintain state in hidden form fields. But storing session state in the client using HTTP cookies or hidden form fields has significant security risks as it exposes a part of your application internals to the untrusted client layer. Also, a cookie-based approach won't work at all if the user has disabled the use of cookies in the browser.

    An alternative to cookies is URL rewriting, which means appending the session ID to all the URLs (including all the hyperlinks and action attributes of the forms) in the HTML page which is being sent as a response to the client. However, although this a robust way to support sessions, it comes at a cost: its costs developer effort and it costs time and machine resources. (Bear in mind that even static HTML pages must be run through a servlet in order to rewrite the URLs.)

    As mentioned, you can store session state in stateful session beans or in the database. However, SFSBs do not scale as well as stateless session beans, and use of the DB can slow performance significantly. For a web client, it is probably best to store the session state in an HttpSession in the Web tier. If the business objects are stateless, then the application can often be scaled by simply adding more Web servers, rather than more Web servers and more EJB servers. Another advantage of using the HttpSession to store conversational state is that the Servlet API offers an easy way to be notified when a session expires.

    And although the Servlet spec does not require it, most servlet containers also provide some form of proprietary HttpSession replication which gives you load balancing, scalability, fault tolerance, and high availability.


    SCJP 1.4, SCWCD 1.3, SCBCD 1.3
    Sri Anand
    Ranch Hand

    Joined: Mar 06, 2005
    Posts: 392
    How abt Java Server faces framwork to maintain the state of Client..I am not expert in JSF's but .. just a throught
    Valentin Tanase
    Ranch Hand

    Joined: Feb 17, 2005
    Posts: 704
    Hi,

    Great job guys, nice team work :-) As Paramesh, Roger and Raghunandan pointed out, we can consider one more option: maintaining the state on the client side. Here there are our options so far:

  • Maintain the client state using SFSBs.
  • Maintain the client state using HttpSession.
  • Use DAO/Entity EJBs/ORM tool to persist the state in the database.
  • Use Http cookies/hidden fields/Java Server faces (needs further research) for maintaining the state on the client.


  • I guess this should be enough for now and we might proceed and chose the right solution for the shopping chart module. In my opinion the best solution should be (as always is in computer science) a trade off between performances on the one hand and low maintenance and development cost on the other. I also guess that we should point out some functional requirements like the number of clients/transactions per second the system should support as well as a rough estimation about the amount of data the chart should maintain. Soggadu does your system has any such requirements?
    Regards.
    Soggadu Sokudi
    Greenhorn

    Joined: Dec 14, 2005
    Posts: 4
    Awesome guys!!! More options than I expected. As Valentine mentioned, it is the time to start looking into the tradeoff. As of now, I don't have the requirements such as volume/frequency of requests.

    On the otherhand - to minimize the development time, I'm looking forward to get the shopping cart frame work and customizing it to my needs. Pointers to any open source available in the web are welcome.

    Thank you all for your replies.

    Regards,
    Soggadu
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Different ways of implementing shopping cart
     
    Similar Threads
    XML Parsing
    Different ways of implementing shopping cart
    Expandable Form Elements -- Please Help
    which session tracking method is good?
    Shopping Cart