• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Different ways of implementing shopping cart

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    Soggadu Sokudi
    Greenhorn
    Posts: 4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Ranch Hand
    Posts: 187
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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?
     
    Valentin Tanase
    Ranch Hand
    Posts: 704
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Greenhorn
    Posts: 18
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 ]
     
    Ranch Hand
    Posts: 1683
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Ranch Hand
    Posts: 392
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 704
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    reply
      Bookmark Topic Watch Topic
    • New Topic