Originally posted by antonio gallo:
How do you manage the seat's selection from the time the user is given a list of available ones to the time he selects some for each flight and comes back to the business tier? Someone could, in the mean while, have chosen, booked or buyed some of these seats and so they could be stale.?
Originally posted by antonio gallo:
And even further how do you manage expired reservations that may occurr if a customer no longer buys the reserved itineraries? Which is your opinion as far as the matter?
Originally posted by antonio gallo:
I agree with your solutions and I also thought in the same way.
I think that a reservation table or something like it is necessary in order to link customers'selected segments to seats. Reservation could have timeouts or expiration dates for each entry and a spawinng thread uses this information to clear stale entries and unreserve seats. .
Originally posted by antonio gallo:
Do you agrre with me or do you think that this structure is not necessary? It's an extension of the Business Domain Model.
Originally posted by antonio gallo:
I don't agree with you as far as your sentence :
But further, i still think, only way you can pay for saved itineraries (in d/b) is to execute Chang Itinerary use case whose purpose isn't exactly the same.(It does not talk of directly selecting an itinerary and forwarding to pay itinerary use case
Prepare itinerary use case allows a customer to select seats and then price and pay the itinerary so the prepare itinerary use case sends the current itinerary to the pay for itinerary use case and is its entry point.
Originally posted by antonio gallo:
I have some doubts as far as the use case when it says that system returns alternative flights if less then selected and within one hour..... . How would you address this point? IMO, the system should return the list of all the possible itineraries/flights in the selected time frame and moreover the price is calculated later through a dedicated use case so only a flat price indepent of the seat's selected class may be available at that time. I'm thinking of skipping this point. Which is your opinion?
Originally posted by antonio gallo:
Moreover, are you thinking of using a stateful facade session bean for managing segments/seats selection after the flight search has been performed (through a stateless one) or you think that a stateless facade is enough? Looking at the use case there's a continuous interaction between the customer and the system (selects flights, select seats) but these information are IMO strictly related and could also be passed each time.
Originally posted by antonio gallo:
To better clarify my opinion, when the user selects seats for each segment he could also send the related flights in a unique DTO (formatted with the necessary info) and so no state maintanance might be necessary. What do you think about this matter?
Originally posted by antonio gallo:
In my opinion there's no performance problem since 1) I have to use this table to link segments to seats and 2) clearing is an asynchronous process that can be scheduled at a given time cutting of expired entries.
For your comment:
"What would happen if you save your itinerary without paying and come up after 2 days to pay for the itinerary that you have saved.. After 2 days, you just want to pay for already prepared itinerary and not want to create another itinerary."
The answer is in the alternative flow of the pay for itinerary use case. Look well at requirements before going on. You could miss something.
This alternative flow should also suggest you to save itineraries on the db. Do you agree now? Let me know your opinion.
Originally posted by antonio gallo:
Moreover, are you thinking of using a stateful facade session bean for managing segments/seats selection after the flight search has been performed (through a stateless one) or you think that a stateless facade is enough? Looking at the use case there's a continuous interaction between the customer and the system (selects flights, select seats) but these information are IMO strictly related and could also be passed each time. To better clarify my opinion, when the user selects seats for each segment he could also send the related flights in a unique DTO (formatted with the necessary info) and so no state maintanance might be necessary. What do you think about this matter?
Originally posted by antonio gallo:
I think that you should not worry about segment's consistency when you change the itinerary since there's no explicit requirement about it and moreover, someone could also change an itinerary and choose an alternative mean (bus or train) to go from B to C.
I think that we should clarify when itineraries can be saved and how to manage them (using stateful or stateless session bean). As far as your suggestions, in the prepare itinerary use case, user selects flights and then seats. I think that it means all seats for each flight and so I think that these info are sent in one go.
The story is complex.
Look at your profile and let me know what do you think of my message.
Originally posted by antonio gallo:
Hi Jatin, what about creating a restricted discussion group on scea part 2 in orther do further discuss project's requirements and architecture?
I sent you yesterday a private message. Can you please reply? Look at your profile and check the messages.
Bye.
Antonio
Originally posted by antonio gallo:
Hi Jatin, what about creating a restricted discussion group on scea part 2 in orther do further discuss project's requirements and architecture?
I sent you yesterday a private message. Can you please reply? Look at your profile and check the messages.
Bye.
Antonio
Santiago Urrizola : La Plata - Argentina<br />SCEA (89%-92%)<br /><a href="http://gpitech.wordpress.com/" target="_blank" rel="nofollow">http://gpitech.wordpress.com/</a>
Politics is a circus designed to distract you from what is really going on. So is this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|