partII: stateful session bean is necessary to serve as a booking cart?

[Newman Huang]

as the itinerary preparing use case describing, customer just select the optional flight and its seat and then the itinerary would be ok. the booking behavior i think just a workflow-like procedure such as stepA->stepB->stepC. i find no reason to use stateful session bean to simluate it. whats comments?

i think one place the stateful session bean to be used is to support the fat-appclient. a c/s application does things in this way:
1)login
2)work

so, once user login, there should be a authencated-conversations between clinet and server. here supply a remote stateful session facade is very convenient.

i hope you dear rancher discussing with me.

[Cleuton Sampaio]

Every time I read the requirements I change my mind a little bit... in this case, if you look the BDM, you�ll see that the shopping cart is persisted (some entities are missing, of course).

If you use a SFSB to hold the itineraries cart you are impacting performance... that�s why I am reviewing my initial idea of using a SFSB as the shopping cart.

But, please note that I only have passed phase I...

When I expect too many simultaneos clients (considering requests per second) I usually avoid using SFSB. There are other solutions (POJOs inside HTTP Session).

And for the Application Client is easier.

Cleuton (Brazil)

[suekar meredilko]

by using SFSB, I feel that managing state is easier for the application clients.

Having done a draft design, I am now getting a feeling that for application client, the session management is more difficult unless I relay the requests via URLConnection to URL FrontController. I am getting tilted towards SFSB based design.

also SFSB is created for doing most of the state machine + workflow stuff.

I have to re-think this.

[Cleuton Sampaio]

Hmmm, have you read this message: https://coderanch.com/t/154944/java-Architect-SCEA/certification/which-exam-simulator-best-exam

The gui hasn�t used SFSBs and it worked !

See, application clients can maintain state. The application runs in an Application Container in the client machine.

Yup, time to change my design again ;-)

[suekar meredilko]

which message .. I think you point me to someother message I cant get what you mean.

[Dan Drillich]

Hi Cleuton,

You said:

in this case, if you look the BDM, you'll see that the shopping cart is persisted (some entities are missing, of course).

Sorry, but where do you see the shopping cart in the BDM?

As the good book (Core J2EE Patterns) says on page 47:

Scalability problems are typically due to the misapplication of stateful and stateless session beans. The choice of using stateful or stateless session beans must depend upon the business process being implemented. A business process that needs only one method call to complete the service is non-conversational business process. Such processes are suitably implemented using a stateless session bean. A business process that needs multiple method calls to complete the service is a conversational business process. It is suitably implemented using a stateful session bean.


However, some designers choose stateless session beans, hoping to increase scalability, and they may wrongly decide to model all business processes as stateless session beans. When using stateless session beans for conversational business processes, every method invocation requires the state to be passed by the client to the bean, reconstructed at the business tier, or retrieved from a persistent store. These techniques could result in reduced scalability due to the associated overheads in network traffic, reconstruction time, or access time respectively.

Look, in my opinion, a shopping cart is a perfect example of a good use of a stateful session bean.

Regards,
Dan
[ August 17, 2006: Message edited by: Dan Drillich ]

[suekar meredilko]

yes Dan agreed.

I am more inclined to use a SFSB 'cos.

-In this scenario the state is accessible by both swing app and the web-based app
-The complete procedure of creating/changing/pricing/paying iternary is conversational and workflow oriented
-Personally I agree that as for as the usecases are concerned and number of clients 600 and the amount of data (state) to be managed, SFSB will be a good choice.
-I was touting the SLSB model for sometime, but after reading the assignment many times and reading various posts, my rationale for choosing a stateless facade is fading away. I dont see anything (advantage) else besides scalability when choosing SLSB. If I assume that memeory is no more a constraint in today's world, then SFSB goes well as an architectural decision.

I am only contemplating because there will those non-unique or unregistered clients who come to the site and just check the flights and go away. This makes me feel SFSB may be an overkill.

Still undecided.

[Newman Huang]

Cleuton:

When I expect too many simultaneos clients (considering requests per second) I usually avoid using SFSB. There are other solutions (POJOs inside HTTP Session).

in the j2ee core patterns, it said
"
On the other hand, if your application supports various types of clients, including Web clients, Java applications, other applications, and even other enterprise beans, then conversational state can be maintained in the EJB layer using stateful session beans.
"
i think what choice you make depend on multiple dimension, the core pattern also refer to hardware, traffic,cluster,session copy... there is no a standard answer i think. important is what arguments for your choice.

suekar:

If I assume that memeory is no more a constraint in today's world, then SFSB goes well as an architectural decision.

i have searched the e10000 params, the assumption has no problems.
here is:

Sun Enterprise 10000 Server - For large-scale, mission-critical applications, such as high-volume OLTP, server consolidation, data warehousing, and decision support, the Sun Enterprise 10000 e10K server, also known as Starfire, helps lower Total Cost of Ownership (TCO) across your IT organization. Mainframe-like Dynamic System Domains enable the Sun Enterprise 10000 server to host multiple workloads, automatically adapting to your needs as your application environment changes. With support for up to 64 CPUs, 64 GB of shared memory, and more than 100 TB of storage, the Sun Enterprise 10000 server powers many of the world's most demanding, mission-critical application environments

[suekar meredilko]

Newman...thanks for that info. this makes my case even more solid to show SFSB.

but what about the un-registered clients who come to search flights, I think we should treat them seperately and not create SFSB for them.

thanks.

[Newman Huang]

hi,suekar

i tried some flight booking site. it splits into searching and booking page. maybe it is a good idea. just another view point.

[Dan Drillich]

Hi suekar and newman,

The separation between Search and Booking is very important.

As Parag said at https://coderanch.com/t/149754/java-Architect-SCEA/certification/DAO-SCJEA-Assignment

Luiz/Jesse,

Let me share my thought on DAO.

Around 70-80% of the customer/user will use the site for searching the flights. So I think Fast Lane reader will be ideal for searching the flights (read only data). As per blueprint, they are recommending accessing DAO directly from client/web tier. I am not too certain of directly accessing DAO from client tier. In the current scenario, even for search, I will use Stateless session bean � to DAO call. I do not see any reason for using entity bean for search. What do you suggest?

For creating/reserving seat, IMO it is good to use BMP (using DAO). By doing this we can utilize the infrastructure provided by Application server such as transaction management/data sharing. It is also advisable to use DAO since it is not a good idea to model entity bean for each of the domain classes (Segment/Flight/Equipment)



Any thought?

Regards,
Dan

[Bobby Sh]

Hi,

MY thoughts are as below:

- I have divided the design in two parts:
1. Search
2. Reservation.

1. Search : Once the user submit the search Criteria, a value list containing all the flights details will be returned using SLSB.

I assume that the UI will provide the feature like sorting(sort by price/time table/airline) and paging (show the result set in page fashion) the search result. Now the logic of sorting/ paging will be implemented in following way:
- The swing client will be able to sort/ 'Page the result set' at the client tier.
- The same logic for web user will be implemented in web tier in the session scope.

This way, the swing application will be faster than web client by avoiding network traffic.

Now when the user has selected the flight to book,
A VO will be sent to EJB layer, adding customer related detail.

---------------------------------------------------------------------

2. Reservation : Session Facade will be used to interact with all interfaces using
bean-managed transaction. This way the transaction can be rolled back if anything goes wrong (seat is no more available, TransMaster has returned failure during authentication)



I would like to know ranchers comment on this.

Bob

[suekar meredilko]

Originally posted by Bobby Sh:
Hi,

MY thoughts are as below:

- I have divided the design in two parts:
1. Search
2. Reservation.

1. Search : Once the user submit the search Criteria, a value list containing all the flights details will be returned using SLSB.

I assume that the UI will provide the feature like sorting(sort by price/time table/airline) and paging (show the result set in page fashion) the search result. Now the logic of sorting/ paging will be implemented in following way:
- The swing client will be able to sort/ 'Page the result set' at the client tier.
- The same logic for web user will be implemented in web tier in the session scope.

This way, the swing application will be faster than web client by avoiding network traffic.

Now when the user has selected the flight to book,
A VO will be sent to EJB layer, adding customer related detail.

---------------------------------------------------------------------

2. Reservation : Session Facade will be used to interact with all interfaces using
bean-managed transaction. This way the transaction can be rolled back if anything goes wrong (seat is no more available, TransMaster has returned failure during authentication)

<> your justification for using BMP is incorrect. You can do all that using CMT as well. i.e. Rolling back transactions etc.



Bob

I think what you mean is

BD -- > SLSB (Search)
BD -- > SLSB (Facade)

firstly what I understood is that this is the implementation of ValueListHandler design pattern. This is good to segregate the search from actual reservation because search does not require people to login explicitly.

I have a question for you though....why cant you put both into a single facade ? Whats your objective or having 2 seperate facade both SLSB(s). Since you are using SLSB how does it matter if you are using 1 SLSB or two.


hmm, my design atleast what I have re-designed over this week is changed.
I am inclined to use a combination of SLSB and SFSB (customer iternary)

i.e. BD->SLSB (Facade to Search and Reserve seperately)->SFSB(Created for preparing iternary after login)-> DAO. I am also caching the flight results for faster browsing. Some architects mention that it is not a good idea to store the valuelisthandler or the values cached into the web-tier but I am not v. convinced on that. Instead they mention that use SFSB to store the ValueListHandler. That will not work in this assignment according to me because we may have to assume that there will be a large chunc of users who are unregistered or have not logged in. We should not use SFSB for all of them.

That way, I can segregate searching seperately (to be used seperately for unregistered clients) by using SLSB and use SFSB for doing things with iternary and past iternary e.g. change, price and pay for registered, logged in clients. Basically at some point once the potential customer after checking the price makes a decision to buy, we have to treat him as a customer and create a SFSB for him. This is how thoughts are running in my head right now.

the server is E10000 and suppose to be robust with huge configuration .. as newman rightly put it... so I am convinced that SFSB is a safe bet too. The rationale is that I have to store client state and I am doing that using SFSB and would not have to handle that in my swing app or use the screen scrap thingy.

Atlast I am able to justify it to myself why I am going this direction. StarUML here I come back to you sweetheart!
[ August 20, 2006: Message edited by: suekar meredilko ]

[Bobby Sh]

Hi suekar ,

Your point regarding having a single SLSB is OK. The only reason I wanted to keep them separately was : one will have bean managed transaction management (booking) and other will not(search). and I agree, this can be done in the same session faced SLSB.


However, as far as using SFSB is concerned, I was thinking in this way.

Why to use SLSB:
Business logic wise, as far as search flight, prepare iternary, change iternary is concerned, we care about a user specific data (state), when we want to save it in database after confirming the iternary. However, till the user/ Customer selects seats, we do not need to
maintain the user state in EJB (you can maintain in web tire or client application). Only the time user want to save the iternary, we can send the user state in form of VO to EJB layer. By using SLSB, I would be reducing the call to EJB layers.

Why NOT to use SFSB
There would be users who would login and search for flight and will not confirm the iternary at that time, (for the reasons like they would like to check other website or deal). In such case if I am using SFSB, these EJB will eat App server memory till the session time out.

This is just my thought, would appreciate every one�s comment such that I can take a final decision on it.

Bob

[suekar meredilko]

Why NOT to use SFSB
There would be users who would login and search for flight and will not confirm the iternary at that time, (for the reasons like they would like to check other website or deal). In such case if I am using SFSB, these EJB will eat App server memory till the session time out.

This is just my thought, would appreciate every one�s comment such that I can take a final decision on it.

Bob[/QB]


This is exactly what I mentioned before why I am using both a SLSB as a facade containing business logic and an SFSB (only for confirmed iternaries) for logged-in users try to pay for prepared iternaries.For all other cases e.g. searching, pricing etc, we need not use SFSB. SFSB in my case will only be created once the user 'confirms' to the price and tries to checkout after seats are available. Hope I am clear

[Newman Huang]

suekar:

I have a question for you though....why cant you put both into a single facade ? Whats your objective or having 2 seperate facade both SLSB(s). Since you are using SLSB how does it matter if you are using 1 SLSB or two.

1 SLSB or 2 based on what a fine-grained you wanna in your design. here i think we misapprehend the meaning of facade and session bean. facade can be constructed by session bean. but facade not equals to session bean. facade is mainly oriented to client, no matter client is local or remote. and the client is especially not in the business tier. Using session bean in business tier, such as wrapping entity bean to do business operations, such a session bean can serves for one or more facades, even other session beans. that is fine-grained what i thought.

Bobby:

Why NOT to use SFSB
There would be users who would login and search for flight and will not confirm the iternary at that time, (for the reasons like they would like to check other website or deal). In such case if I am using SFSB, these EJB will eat App server memory till the session time out.

sure it is. Using SFSB facade for searching is not a good idea. but it is another case when customer begin to select a wanted flight. SFSB should step in now.

in cade's book, one point i does not agree with is the searchprocessor create a shoppingcart. if it means once searching happens, shoppingcart is created. shoppingcart implemented by a SFSB is sure not approprate here.

[Newman Huang]

suekar:

This is exactly what I mentioned before why I am using both a SLSB as a facade containing business logic and an SFSB (only for confirmed iternaries) for logged-in users try to pay for prepared iternaries.For all other cases e.g. searching, pricing etc, we need not use SFSB. SFSB in my case will only be created once the user 'confirms' to the price and tries to checkout after seats are available. Hope I am clear

i think whether to use SFSB(or httpsession) is judged by whether it is a conversation, like span multiple pages, through several interaction between browser and server, accrosing different business components for discontinuous processing. if a non-login customer searches flight and begin to prepare itinerary. when need force to login, how to keep what he has done? i think here it should be a conversation.

[suekar meredilko]

Newman,

Good point you brought up. I think we are clear what a facade is. But my original comment to Bobby was asking justification for 2 different session beans itself. Whether one is a facade the other is a different issue. If we are exposing a set of services to the client tier as a facade, why cant search go there as well.

Secondly, I am not clear from Cade's sequence diagram if he meant to create the shoppingcart from the searchprocessor for every request or only for logged-in/confirmed requests.

My take is that search does not require SFSB, BUT....... once the user confirms his iternary, we need to store his state. The EJB tier should be used for this. In my case besides the SLSB which is a facade , I have a ReservationSFSB which I create after the user 'confirms' to the Iternary.

i.e.

BD --> getFlightDetails()-->SLSB ---> DAO
BD --> getFlightPrice()--SLSB--->DAO
BD ---> confirmFlight() --> SLSB --> create SFSB -> ReservationSFSB

this SFSB is what I will hold for this user who confirmed the iternary then onwards.

This means that users who are simply searching or looking for deals will not be creating SFSB on the server thus saving server resources.

suekar
[ August 20, 2006: Message edited by: suekar meredilko ]

[Newman Huang]

suekar:

a suggestion is to take a look at what petstore has done.

i also reading now.

[suekar meredilko]

Newman.. Petstore uses 2 SFSB(s) by the way for the customer shopping package. Just see the ejbjar.xml

<display-name>ShoppingControllerEJB</display-name>
<ejb-name>ShoppingControllerEJB</ejb-name>
<session-type>Stateful</session-type>


<display-name>ShoppingClientFacadeEJB</display-name>
<ejb-name>ShoppingClientFacadeEJB</ejb-name>
<session-type>Stateful</session-type>


and uses a SLSB (CatalogEJB) for Catalog Search which is stateless.

[Bobby Sh]

Hi suekar ,

I understood the following, except one point:

BD --> getFlightDetails()-->SLSB ---> DAO
BD --> getFlightPrice()--SLSB--->DAO
BD ---> confirmFlight() --> SLSB --> create SFSB -> ReservationSFSB


Why are you calling 'SLSB --> create SFSB -> ReservationSFSB.' is that SLSB a facade?

But in this scenario, I would consider SFSB as facade 'cause this is hiding the complexity of ITransMaster, IternaryDAO, etc. I am just wondering why are you calling SFSB from SLSB. is there any advantage that I am missing?


---------------
Secondly, Are you guys using any Entity bean (with DAO) or directly DAO without using Entity Bean?

Looking at the cade book's case study, I do not see any Entity Bean.

Do you see any advantage of using one over another ?


Bobby

[suekar meredilko]

Originally posted by Bobby Sh:


Why are you calling 'SLSB --> create SFSB -> ReservationSFSB.' is that SLSB a facade?

But in this scenario, I would consider SFSB as facade 'cause this is hiding the complexity of ITransMaster, IternaryDAO, etc. I am just wondering why are you calling SFSB from SLSB. is there any advantage that I am missing?

---------------

Secondly, Are you guys using any Entity bean (with DAO) or directly DAO without using Entity Bean?

Looking at the cade book's case study, I do not see any Entity Bean.

Do you see any advantage of using one over another ?


Bobby

SFSB is just a structure used to store reservation information of the iternary it is not a facade. SLSB (Facade) will have those methods to invoke Transmaster and other DAOs. SLSB will create SFSB at an appropriate time and pass the handle of SFSB to the web-tier. Then onwards only this handle (which represents the state of reservation) is passed across tiers. thats it. This makes my facade v. light weight.It will only have workflow related calls.

I am not planning to use any Entity beans completely DAO based. But this can change.

Am I able to justify my design well enough ?

So search will not use SFSB but when when it comes to confirming the iternatry SFSB will be created.

another thing I want to mention is that use coarse methods. see my next post. you will understand what I mean. These coarse methods will go into SLSB making fewer roundtrips.

[Bobby Sh]

Hi,

So what you are saying that after creating ReservationSFSB, you would be dealing with this bean directly while you pay for it. (�.Right?)

One of my assumption is : after getting the actual price for the Iternary, user may not pay and may save the Iternary such that he will pay it by next day (another assumption). Keeping that in mind I was choosing only SLSB 'cause I do not want to keep the state
of user in bean.

Any comments?

Bob

[suekar meredilko]

If you do not store the state of the iternary anywhere, how will you address change Iternary ?

[Bobby Sh]

I would be saving it(state of the iternary) in database directly while I call the method confirmFlight(). I would be passing the customer state as a VO to SLSB.

In the change Iternary use case, user will first log in and search for the Iternary, and select the Iternary he want to modify.

[Bobby Sh]

I would be saving it(state of the iternary) in database directly while I call the method confirmFlight(). I would be passing the customer state as a VO to SLSB.

In the change Iternary use case, user will first log in and search for the Iternary, and select the Iternary he want to modify.

[veena madhukar]

Let us say the seat 1 to seat 5 were confirmed by a customer. You save that itinerary in the database.

What if the customer never pays for it, the airline had blocked the same for the customer without keeping it available for anybody else?

In another scenario if the airline does not the seats till it is been paid...then at the time of executing pay for itinerary use case execution what if the seats were not availble any more.

Any thoughts on how to address the same? I feel as part of pay for itinerary use case execution...there needs to be a check whether the seats of those flights are still available. if not avaialble then user is informed about the same without the completion of pay for itinerary use case.

[Muralidhar Mandapati]

As far as I can see the users can save the itenary that means he can only save the details of the travel which includes flight details, date of journey etc. Every time the user selects an saved itenary he got to check the availability of the tickets and then if the tickets available then the user can proceed further to purchase the tickets.

Any thoughts are highly appreciated.

Murali

[veena madhukar]

I have decided to assume as follows:

When i Prepare the itinerary the seats will also be selected. The itinerary is saved as a part of prepare itinerary use case.

Later the seats are blocked and assumed to be available as long as the itinerary is valid / available for the customer. Hence no need to check for the availability of seats at the time of pay for itinerary use case.

This is based on the assumption that seats blocked are available for a certain duration. Till that time even the itinerary is valid. After which point the itinrary is not valid and is not available for pay for itinerary use case. Customer then has to prepare itinerary afresh.

I am planning to go ahead with this assumption as it is closer to real case booking scenario when you do the booking through travel agents.

[Newman Huang]

hi, suekar

SFSB is just a structure used to store reservation information of the iternary it is not a facade. SLSB (Facade) will have those methods to invoke Transmaster and other DAOs. SLSB will create SFSB at an appropriate time and pass the handle of SFSB to the web-tier. Then onwards only this handle (which represents the state of reservation) is passed across tiers. thats it. This makes my facade v. light weight.It will only have workflow related calls.

when customer re-selects the alternative flights, here is how to operate the SFSB :

1)controller->httpsession->SFSB->remove and add
2)controller->httpsession->SFSB->pass SFSB to SLSB->remove and add

if 1), client does not access business tier through facade, and it makes controller becomes thicker
if 2), it seems silly to obey the facade rule

if uses SFSB Facade->SFSB Cart, it is:

controller->httpsession->SFSB Facade->SFSB Cart->remove and add

it seems reasonable.

[veena madhukar]

when customer re-selects the alternative flights, here is how to operate the SFSB :

1)controller->httpsession->SFSB->remove and add
2)controller->httpsession->SFSB->pass SFSB to SLSB->remove and add

if 1), client does not access business tier through facade, and it makes controller becomes thicker
if 2), it seems silly to obey the facade rule

if uses SFSB Facade->SFSB Cart, it is:

controller->httpsession->SFSB Facade->SFSB Cart->remove and add

it seems reasonable.
_________________________

Are you suggesting that

controller->httpsession->SFSB Facade->SFSB Cart->remove and add
this is reasonable.

If so, the following are not clear:
Is httpsession used to store client information?
If so...then why SFSB facade?
If not, Why 2 SFSB ? Also are you planning for having SFSB for the entire process whether search or booking?

Veena

[Newman Huang]

hi,madhukar

Is httpsession used to store client information?

httpsession need to store the SFSB facade's reference. but not to store client information. client conversation information is stored into SFSB.

If so...then why SFSB facade?

if you treet search->book flight->book seat->price->pay as a conversation, use SFSB facade for client accessing.

If not, Why 2 SFSB ?

one SFSB to act as stateful session facade, one SFSB to realize booking business logic such as add flights, reselect flights, set seats attribute...if you have researched petstore, you will find it uses three SFSB:
SFSB EJB Controller->SFSB Facade->SFSB-Cart

[veena madhukar]

if you treet search->book flight->book seat->price->pay as a conversation, use SFSB facade for client accessing.

____________________________________________________

I am not conviced about the need to use a stateful session bean for the above. Firstly pay itinerary might be executed by the customer or may never get executed. It is very typical to block tickets but necessarily book all of them. There could be atleast couple of days gap between Blocking and booking. In which case to have the information in session bean just to avoid a database call does not seem to be justified. Any thoughts?

[Newman Huang]

hi, madhukar

i agree it is not necessary to include the payment case in the conversation.for a customer paying itinerary right now, just send the priced itinerary to payment case is reasonable for need not to hit the db again.

[veena madhukar]

search->book flight->book seat->price

Price itinerary is never invoked independently. It is invoked either as a part of prepare itinerary or change itinerary.

We have the following in a stateful session bean:

Select Flight --> Select Seat;

Any comments?

Shall we start a new topic on this issue or any similar issues for discussion as this converstion is already lengthy.

[Murat Balkan]

I think no shopping cart is required to prepare an itinerary. Itinerary will have a flag indicating that it is payed or not.
What do you think?

[veena madhukar]

For payment you do not need a shopping cart -- i mean sstateful session bean. The information could be stored by means of a flag/ somehow in the database.

However, the stateful session bean is needed, if needed, decided to be based on the kind of activities that needs to be carried out as a part of use case.

i am still not sure whether or not a stateful session bean is needed.

[Newman Huang]

somebody passed with SFSB, somebody passed with no SFSB. so i think there is no "THEONE" solution for SCEA-PartII. make you assumptions and design to support your solution, let Sun's teacher persuaded by your submission.