Forums Register Login

shopping cart for FBN

+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
I have same question too. Maybe it will be te itinerary for FBN, but I maybe wrong.please comment
+Pie Number of slices to send: Send
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...
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
 

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 ]
+Pie Number of slices to send: Send
I'm with Parag

CardPaymentService
LoyaltyPaymentService
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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 ]
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
 

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 ]
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
 

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 ]
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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"?
+Pie Number of slices to send: Send
 

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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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)?
+Pie Number of slices to send: Send
Correction to the above,
I mean compare order to itinerary
"I know this defies the law of gravity... but I never studied law." -B. Bunny Defiant tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 2418 times.
Similar Threads
Presentation of J2EE best practices ...
No statefull EJB required for FBN ?
Shopping Cart
Expandable Form Elements -- Please Help
Stateful session bean applications.
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 06:07:16.