• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Saving Itinerary, yet again

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As i go through use cases, i feel there is no entry point given to view unpaid itineraries that were saved in database from previous sessions.

More and more, i am inclined to assume that itinerary should last till a user session lasts and should not be saved in database.

This raises a problem for seat reservation; How can you reserve or lock a seat unless you save an itinerary.

There are people in this forum, who were not saving itineraries in d/b, say that a seat will remain reserved for you until it is reserved by other customer. So if some other customer pays for the itinerary and reserves the same seat its gone for you. And if you try to save your itinerary, System will force you to look for some other seats. This doesn't sound practical to me.

Awating comments ..
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think that itineraries should be saved. I think that the prepare itinerary use case misses a point where the system saves itinerary before pricing them. Saving itineraries, allows their later retriavals after logging it (some companies maintains reservations for some days) in a way that is no longer dependent on the session's life time or stateful session bean timeout.

If you look at the use cases, pricing an itinerary requires a user to be logged in and so I think that a user should log in before selecting seats and then the system saves itinerary for him if the selected seats are available.

In this way you can lock seat saving them on the db but there ae still two problems. 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. Which is your opinion? 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?
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with your assumption of saving unpaid itineries (as long as you document it) and think points you raised are valid but do have solutions

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.?


In that case, system would have to guide the customer to reserve other seats, if they exist.

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?



There can be a backend process designed that can periodically scan through all such unpaid but reserved itineraries and disqualify them on a time basis and subsequently free those seats.

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

Pay For Itinerary use case starts the basic flow with this:
"Other use cases send priced itinerary ", so customer can't directly go to this UC.

Jatin
 
antonio gallo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Do you agrre with me or do you think that this structure is not necessary? It's an extension of the Business Domain Model.

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.

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?

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?
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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. .




Having a table that specifies timeouts and epiration dates can have a negative impact on performance. Also you may not be capturing the timeout's for each entry and so in my opinion there is no ned to have these attributes for all the entries..I think, it is safe to assume a generic time out value application to all reserved seats, say 2 hours. Better still, you can have a structure that can hold the generic time out value.

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.



I agree, such a structure is neccessary.

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.


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.

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?


System should return the flights that are less costly than the one selected and are within one hour(+/-) of entered flight time.
I think, you have to make some assumption about how you can search such flights. Like you can say that says return me segments numbering less than 5 giving some criteria for search function.

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.


I am not saving my unpaid itienraries in d/b and so i have stateful session to manage my itinerary cart. For managing seat/segment entities, i haven't thought much at the moment but think, will go for stateless facade.

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?


Interaction with seat\segment entities(data interaction) can be carried out by a stateless facade. Still i would invite comments from others
Jatin
 
antonio gallo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Yo have a valid point. I now would have to take this into the equation.
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Change itinerary UC, one aso need to baseline how to carry out this change.

I, for one, am thinking on these lines:

a.If the itinerary has only one segment A-B, Customer can delete and add any number of segments, only condition being the last segment should terminate in to B
b.If the itinerary has two or more segments: A-B-C or A-B-C-D, for the first segment, Customer can delete and add any number of segments, only condition being the last segment should terminate in to B. For the rest of the segments, two end points can not be changed

This is to ensure that the changed itinerary is consistent and so valid.

What do you think of this?
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?



i think, it depends upon when you are saving the itinerary in d/b.
There looks to be 2 ways for handling this:
1. It could be when a user confirms an itinerary(let me know your opinion/). That would imply whatever you save in the shopping cart, it is going to go in database as unsaved itinerary. So why would one need a stateful session bean to manage segment/seat selection for an itinerary. (coming to it later)

2. One can also assume that he is going to have a shopping cart where he will save his itineraries in application memory and also have an option(Save Unpaid Itineraries button) to explicitly save unpaid itineraries into d/b. In this case, you can have stateful session bean for shopping cart and stateless session bean to manage save data operations



If you choose the former option, there is a question of managing continuous interaction between the customer and the system (selects flights, select seats), as you say can also be managed with a stateless session bean. There could be several segments selected for an itinerary by a customer. All these have to be sent, one by one, or sent at one go. Whatever, for this you need to manage state at wither ejb tier or web tier.
when you say "when the user selects seats for each segment he could also send the related flights in a unique DTO (formatted with the necessary info)", there could be several flight for an itinerary and seat selection for flights has to stay somewhere for a user(either web session or ejb session). And if session have to be managed, i would prefer a stateful session bean

To sum this up, i would prefer a stateful session bean to manage segment/seat selection whenever you decide to save your itinerary in d/b.
Let me know if i have missed anything over here.

Jatin
 
antonio gallo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



If the itinerary is A-B-C-D and back D-C-B-A, it would mean selecting 3 flights for onward journey and 3 flights for return journey at one go, as per requirements. This can be achieved by a stateless bean operation.

Once the 6 flights are selected, system can return the seats for all the 6 flights at one go. Again this can be achieved by a stateless bean operation.

Once the seats are selected, they all can be saved at one go as a stateless bean operation.
So if it has to happen this way, it can be a stateless session bean. (?)

As regards to when to save, what are your suggestions?

Jatin
 
antonio gallo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



I have replied. Please check your messages.

Jatin
 
Jatin Sutaria
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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



I have replied. Please check your messages.

Jatin
 
antonio gallo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I replied too, two hours ago. Please check again.
 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i support the sugestion about creating a part II discusion forum.
 
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
reply
    Bookmark Topic Watch Topic
  • New Topic