unpaid itinerary once again

[Dhiren Joshi]

If the use points are looked at careful for both prepared and change , a particular use case is always executed.
Does that imply unpaid itinerary can not be presisted by requirements?
Thanks
Dhiren

[Deepak Pant]

Dhiren,

I think you are correct. We do not need to persist Unpaid Itinieraries.

But this also means that "Change Itinerary" will allow changes to Paid Itineraries. Isn't it ?

Deepak

[Dhiren Joshi]

I think you are correct. We do not need to persist Unpaid Itinieraries.

But this also means that "Change Itinerary" will allow changes to Paid Itineraries. Isn't it ?

Well the good thing is if u want to make an assumption ,(nothing is given specifically) .So u can turn it towards your advantage.

Generally paid itineraries are almost never eligible for changes.

HTH
Dhiren

[Deepak Pant]

Dhiren,

I see your point but I think I am not able to make my point clear.

The flow mentioned in "Change Itinerary", requires the system to provide some business workflow.

The customer looks at all the itineraries, drills down to segments, and then deletes a segment and system takes the customer to prepare itinerary.

To provide this workflow:

(a) Either system should allow changes to paid itineraries OR

(b) System should save upaid itineraries in the database and allow modifications to those.

If we are not doing one of the above then I think we are not even covering what has been mentioned in the use case.

Because allowing changes to unpaid itineraries, which is still in session does not meet the workflow mentioned in the usecase.


What do you think about this?

[Dhiren Joshi]

The customer looks at all the itineraries, drills down to segments, and then deletes a segment and system takes the customer to prepare itinerary.
To provide this workflow:

(a) Either system should allow changes to paid itineraries OR

(b) System should save upaid itineraries in the database and allow modifications to those.

The point I miss here is why cant a prepared itinerary in session and not persisted not be eligible for the required work flow.
My thoughts ..
1.. Because we dont persist it until its paid for.
2.. Becauase unless its presisted ,its assumed that segment is not even created so it cant be deleted.
Now the segment can be created even when it is in the cart and unpaid and not persisted or am I getting that wrong.. ?

If we are not doing one of the above then I think we are not even covering what has been mentioned in the use case.

Because allowing changes to unpaid itineraries, which is still in session does not meet the workflow mentioned in the usecase.

That would probably explain why the segment deletion is seeming important.
Cant we have a segment without really persisting it .. if not ... then I am .(though I will still look for an assumption alternative)
If yes ..then go for it and then only unpaid itinerary in session can be eligible for changes.
HTH
Dhiren

[Josep Andreas]

Yes,
I am assuming that only paid itineraries will be persisted as Itinerary.

At first I was not going to use a shoppingcart, but now I think of storing the Unpaid itineraries in a shoppingcart, and allow only changes to segments in the shopping cart.
(Only after the user has logged in, selected a payment type and clicked 'submit', will the Itinerary be saved)
This way, there is no conflict with any of the requirements.
What do you think?
regards,
J

[ January 21, 2005: Message edited by: Josep Andreas ]
[ January 21, 2005: Message edited by: Josep Andreas ]

[Deepak Pant]

Josep,

See I understand that stating whatever assumptions we want, we can make the design simple. But what I am not getting is that how do we represent the first four lines under the basic flow section of the Change Itinerary use case.

It clearly says that user does this, after that user does this, after that user does xxx. Now at given point you will not have more than 1 itinerary in the session. So how will you present the list of itineraries.

How does one justify the use case story board with the sequence diagram flow?

Thanks,
Deepak

[Josep Andreas]

Yes, thanks,
I was a bit too hasty with my assumptions...
cleaned up the class diagram pretty good though
Regards,
J

[Deepak Pant]

Originally posted by Josep Andreas:
Yes, thanks,
I was a bit too hasty with my assumptions...
cleaned up the class diagram pretty good though
Regards,
J

Are you also thinking of

(a) Either allowing user to modify the paid itineraries.
- this will require some logic around credit/debit of credit card/frequent flyer

(b) OR allowing user to save unpaid itineraries and then change them.
- this will require some cleanup of unpaid itineraries after certain elapsed days/hours

In my design I am opting for option (b).

[Dhiren Joshi]

Are you also thinking of

(a) Either allowing user to modify the paid itineraries.
- this will require some logic around credit/debit of credit card/frequent flyer

(b) OR allowing user to save unpaid itineraries and then change them.
- this will require some cleanup of unpaid itineraries after certain elapsed days/hours

In my design I am opting for option (b).

Deepak,
I was getting pretty confused with the change itinerary so I went back to all posts and what they cd bring up.

Ajith has clearly hinted in one post not to save unpaid itinerary (or create unnecessary "feel good" requirements.".
In many other POSTs unpaid itinerary is not presisted.

That being the case, Only paid itineraries r persisted generally .

now if paid is persisted then change itinerary ... requires a POST condition of unpaid itinerary ... so... change itineray is applied on unpaid.

If we change is on unpaid and unpaid doesnt persist the change use case acts only in a virtual persistent store.(Now this is my assumption about the virtual persistent)

All this info I pulled from different POSTs.

So again the question is hanging how lists of itineraries can be found unless assume user is reservation a couple of itineraries at one go.
I couldnt find an answer for this.
does the assumption sound reasonable enough ... to support this condition .

Thanks
Dhiren

[Josep Andreas]

Just finished reading the requirements 100 times,
so no more 'feel good assumptions' from me....

[Dhiren Joshi]

Josep,
So finally how are u going ahead with the change itinerary scenario. /

1. Unpaid itinerary (persisted in DB)
2. Unpaid itinerary (not persisted in DB)
3. Paid itinerary persisting in DB.

I have finally taken the least resistance path.
Assumptions of multiple itinerary in virtual cart .
Any suggestions.
Thanks
Dhiren

[Josep Andreas]

Yes, I am also going for this (option 2/3)...again.
But now I have the correct assumption.
Thanks,
J
[ January 23, 2005: Message edited by: Josep Andreas ]

[Dhiren Joshi]

Josep,
Are you going to handle change itinerary for paid itinerary as well . ?
Thanks
Dhiren

[Josep Andreas]

No, Change Itinerary only for option 2;
and store in DB only paid itineraries (3)
J

[Dhiren Joshi]

Yep Thats the same option I was looking at better .
Thanks for the input.
I will also go ahead with some assumptions.
Dhiren

[Ramesh Aiyappan]

I actually related the paid itinerary to a 'TICKET' in my hand, and no thoughts on Changing the paid itinerary.

Ramesh.
[ January 23, 2005: Message edited by: Ramesh Aiyappan ]

[Dhiren Joshi]

Josep,
I have a confusion.
If I do a seat confirmation and I reserve an itinerary, doesnt this already gone to the DB so how is it not a unpaid un persisted itinerary.

How do u manage the seat resources without persisting them ?
If I book a seat and its taken ,isnt it actually persisted to the DB?

Thanks
Dhiren

[Ramesh Aiyappan]

I dont think that we have to persist the booked seats, the seats are not mine until I pay for it. So I hope we have to provide some means of *LEASED LOCK* on the seats and not actual persistence until the payment is made.

Let me know if I am missing something.

Ramesh.

[Dhiren Joshi]

Ramesh,
R u setting some virtual persistent for the seat and implementing first come first basis of getting the seats.
Seems to be a solution for the problem now that u mention leased-lock.
The way I would percieve it, store in the virtual seats and continue if paid etc.
Problem if I have reserved seat but at the time of booking some one else has taken the seat.
I think thats "too bad " for the customer " He spent too much time deciding to buy it " any other solution ?


Thanks
Dhiren

[Josep Andreas]

Dhiren,
As only paid itineraries are persisted in my design (Unpaid seats are also stored in shopping cart),
I was thinking of:
1. you start a Transaction on the ejb context. (e.g. in facade)
2. Create itinerary/segments/reserve seats. (set ejb entity Beans (CMT) to transaction required; so they use this transaction)
3. Do payment (by CreditCard or to Mileage account)
4. If payment not successfull-> throw exception/rollback
5. else commit transaction

Options for reserved seat issue:
A If in step 2, the seat (that was previously free) is reserverd now by someone else, You throw an exception, handle it and let e.g. the user select another seat
B leased lock solution as described by Ramesh, but then indeed you need the
entity bean to store it.

mmm... (for now I go for A)

Some Info:
https://coderanch.com/t/151504/java-Architect-SCEA/certification/control-transaction-external-system
http://www.conceptgo.com/gsejb/eb04.html
http://theserverside.com/discussions/thread.tss?thread_id=16456

What do you think?
[ January 25, 2005: Message edited by: Josep Andreas ]

[Ramesh Aiyappan]

Dhiren,

Yes I am planning to have a ShoppingCart like thing for the booking. I would have this active till the Customer is active with his session.

By *LEASED LOCK* I meant a time based lock, wherein the booked seat will be locked for an agreed time. If we need to have the seat booked but not paid (for a longer time), we can provide some options for the Travel Agents or Privilege members to actually BLOCK the ticket for a longer time.

As we cant have the unpaid seats for ever, I thought the time based lock would be a solution.

I havent gone thru this in deep, these are just my initial thoughts.

Let me know your ideas.

Thanks,
Ramesh.

[Dhiren Joshi]

As only paid itineraries are persisted in my design (Unpaid seats are also stored in shopping cart),
I was thinking of:
1. you start a Transaction on the ejb context. (e.g. in facade)
2. Create itinerary/segments/reserve seats. (set ejb entity Beans (CMT) to transaction required; so they use this transaction)
3. Do payment (by CreditCard or to Mileage account)
4. If payment not successfull-> throw exception/rollback
5. else commit transaction

Options for reserved seat issue:
A If in step 2, the seat (that was previously free) is reserverd now by someone else, You throw an exception, handle it and let e.g. the user select another seat
B leased lock solution as described by Ramesh, but then indeed you need the
entity bean to store it.

Josep that looks acceptable. Intially I was going for that and not giving a lock on the seat. Seems less complicated. Simpler u keep the better it is. I think I will do that too.
Ramesh :If we store in shopping cart ,the seat still persists how do we not persist it ?
Thanks
Dhiren

[Alastair Calderwood]

Ramesh,

I am thinking of having collections called LockedSeats and BookedSeats for each flight. If someone puts a seat into their shopping basket, it is added to LockedSeats for a certain time, as you said. If they pay for it, it goes out of LockedSeats and into BookedSeats (a collection of EJBs).

There is another collection called AvailableSeats for each flight, which are the seats marked as available in the database, but this also has a listener on LockedSeats and BookedSeats so that any seat added to these collections is removed from AvailableSeats.

What do you think?

Alastair

[Josep Andreas]

Dhiren,
I assume that in your shopping cart you have a collection
that holds on to composite ItineraryTO's (which has segements and seats)?
This Composite ItineraryTO (POJO) would be the only input for making it a real itinerary,
since it contains ItineraryInfo,segments and seats.
Are you showing this ItineraryTO as a separate class in your diagram?

this design is also used in Petstore
thanks,
J
[ January 28, 2005: Message edited by: Josep Andreas ]

[Ramesh Aiyappan]

Dhiren,

I am considering a design wherein the SEAT is always persisted and its availability is based on the STATUS that is updated for the events.

Alastair,

As I have said above, I am not going for any in-memory objects, I depend on the database to store the SEAT and update its STATUS based on the event that manipulates the seat.

Ramesh.

[Dhiren Joshi]

Dhiren,
I assume that in your shopping cart you have a collection
that holds on to composite ItineraryTO's (which has segements and seats)?
This Composite ItineraryTO (POJO) would be the only input for making it a real itinerary,
since it contains ItineraryInfo,segments and seats.
Are you showing this ItineraryTO as a separate class in your diagram?

this design is also used in Petstore

Josep,
Yeah you are correct. When I do the search. I create the VLH .
Next when customer does the selection then I go ahead and do real itinerary.
Yes I have a whole separate POJO classes for the composite and for the real itinerary (EJB based) which caused me to stir my BDOM slightly.

HTH
Dhiren

[Josep Andreas]

Dhiren,
the Collection of ItineraryTO's (in the shopping cart) are used for storing the unpaid itineraries,
right?
Do you show them In class diagram. I am not sure if this is necessary?
You could just show attribute in the shopping cart.
In cade's guide they aren't, but there the TO is only used for communication between web tier and business tier.
J

[Dhiren Joshi]

the Collection of ItineraryTO's (in the shopping cart) are used for storing the unpaid itineraries,
right?
Do you show them In class diagram. I am not sure if this is necessary?
You could just show attribute in the shopping cart.
In cade's guide they aren't, but there the TO is only used for communication between web tier and business tier.

Josep,
May be I wasnt able to communicate it properly.
I create POJO objects for the search VLH. These POJO objects i represent in BDOM.
Next when a search is selected by customer I create a new set of Ejb composite objects to store the customer flight itinerary as EJB composite object.

The collection of ItineraryTO's u are referring to are the actual list of unpaid itineraries created by the customer. Yes that u can save as attribute of shopping cart u dont need to show the attributes u can just speficy in a note.
I have to figure now how to not create the unpaid itinerary as EJB becuase when I do so , I am repeating the error of persisting unpaid seats.
HTH
Dhiren

[Josep Andreas]

Dhiren,

In my case, The shopping cart holds on to a collection of regular Transfer Objects.
(Maybe itineraryTO is not a good name and it should be called
UnpaiditinararyTO or FlightSeatsTO.); This TO is really a Composite TO,
that holds on to the Segments(Flights) and the reserved seats.
I do not understand how your seats are persisted in DB this way.
Maybe you can explain.
(Petstore uses same design for shopping cart:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1a3.html
The cartItems are plain TO's and no CompositeTO.. ( but thats a detail..))
=======
Do you want to reserve seat as outcome of prepare itinerary? (It says so in some description) I am not sure that this is necessary. Earlier in this thread we assumed that seat is not really reserved until paid. I am ok with that. Parag did about the same:
https://coderanch.com/t/152786/java-Architect-SCEA/certification/Part-II-reserved-seat-taken

So I think (hope) I have no problems anymore on this issue?
(I am not using VLH)

regards,
J
[ January 30, 2005: Message edited by: Josep Andreas ]

[Dhiren Joshi]

I do not understand how your seats are persisted in DB this way.
Maybe you can explain.
(Petstore uses same design for shopping cart:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1a3.html
The cartItems are plain TO's and no CompositeTO.. ( but thats a detail..))

Well Josep,
When the seats were getting selected I was creating composite EJB b4 they were getting paid for , I will move that all in one transaction context with pay for itinerary as Parag did.
That way unpaid itinerary will not persist.
Thanks for the link

Dhiren

[jono]

Hi,

I have decided to persist unpaid itineraries and use a STATUS attribute on the Seat. Prepare Itinerary use case specifically mentions that a user can RESERVE a seat. "Reserve" is very unambiguous.

I have a related question which I cannot find an answer for. Change Itinerary use case states that the segment is deleted and the prepare itinerary use case is executed. This does not make sense to me - it means you start the prpeare itinerary use case with "a portion of" an itinerary. There is no provison for this in the prepare itinrary use case. I have therefore decide to have the user join the use case where it displays a set of priced search results and just have the flight(segment) not deleted selected. They are then free to update the itinerary an save again.

what do you think?