• 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

shopping cart for FBN

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Folks
Do u think something similar to shopping cart in the petstore is required for FBN ???
In my perspective we need unless one wants use webtier to keep the session info which is not scalable, any thoughts ???
Eric
 
Ranch Hand
Posts: 139
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have same question too. Maybe it will be te itinerary for FBN, but I maybe wrong.please comment
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I found this old post, I have the same question.
Do we need something like ShoppingCart in the class diagram for FBN?
and if we do, will it be OK if it's named ShoppingCart?
(I think it is not the appropriate name.)

Any comments appreciated...
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Justin Chang:
I found this old post, I have the same question.
Do we need something like ShoppingCart in the class diagram for FBN?
and if we do, will it be OK if it's named ShoppingCart?
(I think it is not the appropriate name.)

Any comments appreciated...



I agree with Robin..I am leaning towards 'ItineraryManager' as my 'shoppingcart'.

Parag
 
Justin Chang
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply.
But in my opinion, 'ItineraryManager' sounds that it acts as a processor which is a stateless session bean, similar to 'OrderProcessor', rather than 'shoppingcart'.

Any thoughts?
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Justin Chang:
Thanks for the reply.
But in my opinion, 'ItineraryManager' sounds that it acts as a processor which is a stateless session bean, similar to 'OrderProcessor', rather than 'shoppingcart'.

Any thoughts?



Yeah..you are right. I had meant to say the ItineraryManager would manage the Itinerary..so the Itinerary would be the shopping cart, so to speak.

Parag
 
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I interpret is ShoppingCart is just a holder for Product's and its not any processor to make it as a SLSB. Itinerary would be best fit to replace ShoppingCart or any other extended object which sits in between User and Itinerary.
Or how about having a SearchProcessor SLSB to create Itinerary and search Segment's
[ September 08, 2004: Message edited by: Anil Vupputuri ]
 
Justin Chang
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag

I'm a bit confused now. If the Itinerary acts as a ShoppingCart(SFSB), then which class is used to be persisted?

I think the Itinerary is EB, rather than SFSB. But I'm not sure which class will be used as a ShoppingCart. Any suggestions?


Anil

SearchProcessor and ItineraryManager are both required, I think. But I wonder whether or not something like CreditCardProcessor or MileageProcessor is also required?
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Justin Chang:

Anil

SearchProcessor and ItineraryManager are both required, I think. But I wonder whether or not something like CreditCardProcessor or MileageProcessor is also required?



I think CreditCardService and MileageService sounds more reasonable as they would be more like SLSB "services", rather than "processors".

Parag
[ September 08, 2004: Message edited by: Parag Doshi ]
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm with Parag

CardPaymentService
LoyaltyPaymentService
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Justin Chang:
Parag

I'm a bit confused now. If the Itinerary acts as a ShoppingCart(SFSB), then which class is used to be persisted?

I think the Itinerary is EB, rather than SFSB. But I'm not sure which class will be used as a ShoppingCart. Any suggestions?



Justin,
First,thanks for pointing this out. I had to revisit my seq diagram and I realised that I had implicitly maintained my "shopping cart" in my ItineraryManager (SFSFacade). But, now I realise, I need to find another object to store it in. I had a look at the PetStore and saw that they have a concept of ShoppingCartModel which is a VO and used to communicate with the web tier and a ShoppingCartLocal which is a SFSB to maintain it on the ejb tier.
I am almost tempted to use a VO as the holding object of the contents and the VO could be managed by the ItineraryManager. I am not sure whether I need a VO or a SFSB to maintain my "shopping cart" state on the ejb tier.
I think a SFSB seems like a right choice, but I already have a SFSFacade, so dont know if it makes sense to have another SFSB for holding "shopping cart" state.

Is it a normal usage to have a stateful session facade managing a stateful session bean "shopping cart" rather than having a instance variable as a "shopping cart" which could be a VO ?

Parag
 
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone,
I've been looking through the blueprints and other resources to try to give some input to this thread. From what I've seen I would use a 'cart' as a VO (or DTO - data transfer object) and have it set up as a variable within a SFSB ShoppingCart in the EJB tier.

When I'm ready to buy the cart contents, the 'cart' DTO would pass to the EJB where it would be added to the an orders database via approriate EJB's.

Hope this helps with the 2 options you came up with, Parag.

Ray
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ramon Gill:
Hi everyone,
I've been looking through the blueprints and other resources to try to give some input to this thread. From what I've seen I would use a 'cart' as a VO (or DTO - data transfer object) and have it set up as a variable within a SFSB ShoppingCart in the EJB tier.

When I'm ready to buy the cart contents, the 'cart' DTO would pass to the EJB where it would be added to the an orders database via approriate EJB's.

Hope this helps with the 2 options you came up with, Parag.

Ray



Thanks Ray. It definitely helped in clearing my doubt. I am leaning towards a stateless session facade and using a SFSB for my shopping cart. That way, I can have a light weight facade and only the state relevant to the client would be stored in the SFSB. I think that I dont need two stateful session beans to manage this scenario.

Please correct me if this sounds totally out of whack !

Parag
 
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag,

though I took a quite different shot at the shopping cart, the steps regarding state maintenance are just the same as in your proposal.

HTH,
Harbo
[ September 13, 2004: Message edited by: H. Hafer ]
 
Anil Vupputuri
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe you can have one intermediatery object as VO (carrier of all the vital information like Itinerary and Payment details) which is passed between User and Itinerary Manager (which is Stateless Session Facade).
I feel Servlet is best place to maintain user session without having any Stateful Session Bean.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anil Vupputuri:
Maybe you can have one intermediatery object as VO (carrier of all the vital information like Itinerary and Payment details) which is passed between User and Itinerary Manager (which is Stateless Session Facade).
I feel Servlet is best place to maintain user session without having any Stateful Session Bean.



Anil,
There is a big war on whether session needs to be maintained in HTTP or Stateful beans. I am going with stateful bean approach because the blue prints recommend them. In real life, I might take a different approach. I have 2 web servers which I can load balance, so HTTP sounds like a logical place too.

Parag
[ September 13, 2004: Message edited by: Parag Doshi ]
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by H. Hafer:
Parag,

though I took a quite different shot at the shopping cart, the steps regarding state maintenance are just the same as in your proposal.

HTH,
Harbo

[ September 13, 2004: Message edited by: H. Hafer ]



Harbo,
Not to again start a forbidden thread, what did you conclude on ur un-paid itinerary persistence? Are you persisting them or not?
A simple yes/no would be alrite as I dont want to start a new thread of discussion again
I was just curious on what you concluded.

Parag
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:
Are you persisting them or not?
A simple yes/no would be alrite [...]


Parag,
your type of question made a simple yes/no impossible.
However, since the requirements doesn't state what to do with unpaid itineraries, I did it the lazy way.

Oh, and it doesn't state what to do with paid itineraries, either ...

HTH,
Harbo
[ September 13, 2004: Message edited by: H. Hafer ]
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by H. Hafer:

Parag,
your type of question made a simple yes/no impossible.
However, since the requirements doesn't state what to do with unpaid itineraries, I did it the lazy way.

Oh, and it doesn't state what to do with paid itineraries, either ...

HTH,
Harbo


[ September 13, 2004: Message edited by: H. Hafer ]



Not persisting paid itineraries either you sure are one lazy architect

Parag
 
Anil Vupputuri
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:


Thanks Ray. It definitely helped in clearing my doubt. I am leaning towards a stateless session facade and using a SFSB for my shopping cart. That way, I can have a light weight facade and only the state relevant to the client would be stored in the SFSB.



In summary,

User --(VO)--> SFSB (Shopping Cart) --> SLSB (Itinerary Manager- Sessoin Facade)

isn't that you're trying to say.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anil Vupputuri:


In summary,

User --(VO)--> SFSB (Shopping Cart) --> SLSB (Itinerary Manager- Sessoin Facade)

isn't that you're trying to say.



Actually its :

BD ---> SLSB(SessionFacade) ---> SFSB(Shopping cart) [holds onto a VO]

Parag
 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Actually its :

BD ---> SLSB(SessionFacade) ---> SFSB(Shopping cart) [holds onto a VO]

Parag



Is SLSB on the front of the SFSB? if so, do you transfer the remote or local interface of the SFSB from web client or swing client to SLSB? I am trying to use SFSB to hold the cart, but my invoke sequence as following:

BD->SFSB->SLSB. Am I wrong?
[ September 14, 2004: Message edited by: James Wang ]
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Wang:


Is SLSB on the front of the SFSB? if so, do you transfer the remote or local interface of the SFSB from web client or swing client to SLSB? I am trying to use SFSB to hold the cart, but my invoke sequence as following:

BD->SFSB->SLSB. Am I wrong?

[ September 14, 2004: Message edited by: James Wang ]



James,
You are not wrong. What you have designed would also work. I had to choose between a stateful session facade and a stateful session bean for my shoppingcart. I opted for a SFSB shopping cart and a stateless session facade. Also, it seems to be a normal practice to store the remote handle in the HTTPSession and pass it from the web tier to the ejb tier.

Parag
 
Anil Vupputuri
Ranch Hand
Posts: 527
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:

BD ---> SLSB(SessionFacade) ---> SFSB(Shopping cart) [holds onto a VO]



But SLSB is a non-conversational business process, so how do u maintain client state during multiple method calls...should your SessionFacade be SFSB?

What are the pros on choosing SLSB --> SFSB.

Curious to know, how does the Petstore deal with Shopping cart.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anil Vupputuri:


But SLSB is a non-conversational business process, so how do u maintain client state during multiple method calls...should your SessionFacade be SFSB?

What are the pros on choosing SLSB --> SFSB.

Curious to know, how does the Petstore deal with Shopping cart.



Anil,
I will try to keep it as general as possible and not discuss the assignment requirements. As you are aware, there are 2 types of session facades(SF). One is the stateless variety and other is the stateful one. The stateless is primarily used for business process workflow. If you need to perform a function and that requires 2-3 different remote calls, then make the call on the SLSF (stateless session facade) and it will manage the workflow. The other side is that if you want to perform a business function which needs to hold a user specific state (as user's data state might influence the function process), you can go for a SFSF (stateful session facade).
There are 2 choices as to where you can maintain the user's state. one is in the facade itself (hence its stateful) or you can store it in a session bean which is behind the stateless session facade (my choice). If we go with option #2, then the facade can be a lightweight stateless bean. The only requirement (as far as I can see) is that the stateful bean handle has to be stored (possibly in HTTPSession) and sent back and forth for each call which might need the services of the stateful session bean. This keeps the httpsession lightweight as it only stores the handle and my session facade is only concerned abt the business process without worrying abt storing user specific state.

Now, which is a better alternative, SFSF or SLSF? I dont know the answer to that question, as many articles suggest using SLSF and many say SFSF. I think the shoppingcartsessionfacade in petstore is stateful as it holds the customer reference in it. I am not sure whether the shopping cart is stateful or stateless (could be stateful, i couldnt figure it out).

any other thoughts on the pros and cons of stateful vs stateless session facade are welcome

Parag
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag, why do you still need to consider a shopping cart should be stateful or stateless if you already have a stateful session object for user? Can't you just have an object array as shopping cart and let this SFSB hold the reference?

I must admit I haven't think about this shopping cart yet, and didn't study the pet store sample. So please point out this model's shortcoming.
[ September 16, 2004: Message edited by: calvin zhu ]
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by calvin zhu:
Parag, why do you still need to consider a shopping cart should be stateful or stateless if you already have a stateful session object for user? Can't you just have an object array as shopping cart and let this SFSB hold the reference?

I must admit I haven't think about this shopping cart yet, and didn't study the pet store sample. So please point out this model's shortcoming.

[ September 16, 2004: Message edited by: calvin zhu ]




Calvin,
I had a look at the petstore code and its deployment descriptor. They have a ShoppingClientFacadeLocal which is a stateful session facade as it holds the Customer reference. It also holds a reference to the ShoppingCartLocal which is a stateful session bean which has a Map of CartItems to store the user's selection. So petstore has 2 stateful session beans ( why??). One is a facade and other is the shopping cart. I dont know the reasoning behind it.
The reason I differentiated btw the stateless and stateful session bean was that I wanted a lightweight stateless facade which should only be responsible in managing the workflow. To manage the customer's shopping items, I would rather have a stateful session bean for it.
Your approach would also work as your facade would be stateful and also hold onto the object array of items. I chose to differentiate btw the 2 responsibilities.

Please correct me if you find any flaws in my choice.

Parag
 
calvin zhu
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag,
I looked at the pet store 1.3.1 design documents. Actually it has 3 SFSB:

ShoppingCartEJB�(Stateful) maintains the contents of an individual user�s virtual shopping cart
ShoppingControllerEJB�(Stateful) provides access to the Shopping Client Facade; extends the WAF EJB controller (EJBControllerLocalEJB)
ShoppingClientFacadeEJB�(Stateful) caches references and provides unified access to customer, shopping cart, and user ID

I would like to know the reason why pet store need 3 SFSB too. Too bad there is no clear explaination about this, and I searched old topics, somebody asked the same question about "why EJB controller is a SFSB in pet store", no answer.

I guess the reason is to clear divide the responsibity by put the function into 3 module. Otherwise using one stateful session controller hold the reference to customer and shopping cart is good enough.

About your design, I don't see any flaws myself. I think as long as you pass the SFSB's reference around should be fine. The only thing I will think about SLSB facade is that SLSB's method is atomic, so will this method become too complicate in the end?
 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The discussion about SFSB is helpful, but it said we have two web servers and an application server, that means the web server is clustered, how can we make it work if we use SFSB for "shopping cart"?
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Joseph Zhou:
The discussion about SFSB is helpful, but it said we have two web servers and an application server, that means the web server is clustered, how can we make it work if we use SFSB for "shopping cart"?



Why would that be a problem? The session state is maintained on the ejb tier and the web tier can hold onto the session reference.

Parag
 
Joseph Zhou
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Parag,
The original question started from Steve Phelan's note: "...if you keep state in stateful EJBs, would this state automatically propagete across clustered servers in a highly scalable solution? If not, what alternative would you suggested in this scenario?", hte back ground knowlwdge can get from: http://www.onjava.com/lpt/a/1228

IMO, in a clustered solution, you can keep state either in web tier or EIS tier, but not SFSB. any comments?
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everybody,
This is a great forum. I Have just started the Part II exam.
(have been reading lots of documentation last week on the assignment)
I feel I ready to go now!

On this subject: In the example of Mark Cade (SCea guide, page 169), he put the shopping card between the customer and the product. Isn't this the same problem (compare Product to Itenary)?
 
Josep Andreas
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Correction to the above,
I mean compare order to itinerary
reply
    Bookmark Topic Watch Topic
  • New Topic