aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Question About The Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Question About The "Seat"" Watch "Question About The "Seat"" New topic
Author

Question About The "Seat"

Cloutier Jean
Greenhorn

Joined: Feb 16, 2005
Posts: 5
Hi all, I have a little question in mind about the seat when reading the requirement. In the prepare Itinerary use case, after a customer prepared the Itinerary and before he go ahead to pay it, are those seats he just selected still availble to other customers who happens to be browsering around at the same time? If yes, what if when he is ready to pay, the seats were already taken by others. If no, what happens to those seats if the customer decides to pay for it three days later? no one can use those seats during? And also what we should pay attention in the design regarding this issue? thank you very much and looking forward to your reply.
Rama Kundurthi
Greenhorn

Joined: Feb 03, 2005
Posts: 13
I think for simplicity sake, you may assume that this seat is still available to other customers. Before confirming the itinerary, check for availability of that seat. If it is available, then continue otherwise throw seat selection page to the customer.

Any comments?...
Cloutier Jean
Greenhorn

Joined: Feb 16, 2005
Posts: 5
Thanks Rama. Are you indicating the "seats" will not be available anymore once they get confirmed? But the thing is you can always choose not to pay it even you have confirmed the itinerary. The extreme case is to confirm all the seats, but not to pay for it, so no one else is able to book any seats on the plane. Isn't that weird?
Rama Kundurthi
Greenhorn

Joined: Feb 03, 2005
Posts: 13
I think that unless itinerary is paid, seat can not be confirmed.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Hi Guys,
Do u think EJB is a better way of modeling the seat. If u model it as EJB then seat confirmation can be done with some lock and it is instant,whereas if u model it a POJO then only after all the changes have been done on the TO can u send it to the DB.

If u model it as EJB u have control on the updates instantly with seat locks.

But I am running into issues implementing it as an EJB becuase my search is done via DAO, so I will go with Rama's suggestions.

Incase search objects created r EJB's too then the seat EJB can be implemented.

Thanks
Dhiren
Rama Kundurthi
Greenhorn

Joined: Feb 03, 2005
Posts: 13
Seats are shared components until a seat is assigned to a customer. I think it is easy to manage this with EJB.
What kind of issues you are finding in modelling seat as EJB?

Are you doing seat search via dao and TOListHandler?.

May be all seats per flight can be returned with information whether each seat is occupied or not (which can be done via EJB). We can leave view part of the seats to the presentation layer.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Rama,

Seats are shared components until a seat is assigned to a customer. I think it is easy to manage this with EJB.
What kind of issues you are finding in modelling seat as EJB?

Are you doing seat search via dao and TOListHandler?.

May be all seats per flight can be returned with information whether each seat is occupied or not (which can be done via EJB). We can leave view part of the seats to the presentation layer.


Unless I create the intial search request using composite entity which I am not doing I am doing search using DAO, I dont have a composite EJB.

So when I want to display seats, I cant go to my TOListHandler which holds search info if I am wanting to create seat info as EJB. and the TOListHandler at first I dont create seats in it becuase that wd be too LARGE objects to hold just for a search object.

AS according to requirement we cant create the seats independent of the other object.

So Either I duplicating the entire flight object as EJB to create seats as EJB .

Or did I get the requirement WRONG and that seats can exist independently.

Thanks
Dhiren
Rama Kundurthi
Greenhorn

Joined: Feb 03, 2005
Posts: 13
I dont think seats can exist independently.

They are tied with Flight via flight carrier(equipment). As flights are read only objects, they may be TOs. For getting seats, you may pass flight carrier/flight information as argument to which ejb will return collection of seat EJBs.

Do you think it makes sense? or any comments?
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
I dont think seats can exist independently.

They are tied with Flight via flight carrier(equipment). As flights are read only objects, they may be TOs. For getting seats, you may pass flight carrier/flight information as argument to which ejb will return collection of seat EJBs.

Do you think it makes sense? or any comments?


Thats what I was thinking creating TO for search and get seat EJB creation info from the TO's but the catch is that this makes the design slightly insecure becuase anyone getting hold of primary key can go ahead and do reservations without having the need to create flight EJB's. Thats where I got stuck.
The seat EJB for secure design needs to go thru the flight but if flight is a TO then can it hold a ref to collection of EJB ? Or do I need to duplicate another compostie flight EJB object ?
Thanks
Dhiren
Rama Kundurthi
Greenhorn

Joined: Feb 03, 2005
Posts: 13
The seat EJB for secure design needs to go thru the flight but if flight is a TO then can it hold a ref to collection of EJB ? Or do I need to duplicate another compostie flight EJB object ?


That is a good point. I do not think FlightTO can have a reference to seat EJBs. I think using composite EJB makes sense. As FlightTO may have more/less information than FlightEJB, I dont think it is like totally duplicating the effort.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Rama,

That is a good point. I do not think FlightTO can have a reference to seat EJBs. I think using composite EJB makes sense. As FlightTO may have more/less information than FlightEJB, I dont think it is like totally duplicating the effort.


yes I agree with u on this. So how r both represented on the class diagram ,a flight EJB and flightTO. show one as helper objects and the other the true business objects. This was the other confusion so I wasnt going ahead with this becuase during the design check it would show up as a duplicate object..
Infact would it be a better idea to make a UserFlightEJB object instead of replicating the flightTO and making flightEJB ?

Thanks
Dhiren
Rama Kundurthi
Greenhorn

Joined: Feb 03, 2005
Posts: 13
Dhiren,

I am planning to show both of them in class diagram and some note related to these two classes.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Thanks Rama for this discussion.
It cleared a very big doubt I had been having for a while.

I guess then u will be showing both in the sequence diagrams.
Currently thats how I have them but I doubted the correctness of it.

Thanks again Rama
Dhiren
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
I do not think you have to show TOs in class diagram. Wouldn't it be typically something for a detailed design?
I think it would be OK to just show FlightTo them as attribute.
FlightTo could be a Composite TO with a reference to a SeatTo.

J
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
Josep,

I do not think you have to show TOs in class diagram. Wouldn't it be typically something for a detailed design?
I think it would be OK to just show FlightTo them as attribute.
FlightTo could be a Composite TO with a reference to a SeatTo.



Yes we can show seatTo but if this needs to be created at the time the search TO is created, we could have many useless objects in memory.
Incase this is not created at the time of search but when user selects and wants seats ,then seat retrival would need to go again to a DAO. Having seats as EJB is better for the transaction capability that it gives.

Currently I have a composite flightTO and when I needed to read the other info thats when I got stuck about how to handle the updating concurrently and thats when I thought of moving it to EJB.
I think Ajith (the SCEA moderator) suggested some place not to go down the slope of everything is an EJB and suggested "why seat needs to be an EJB".
If only a DAO can suffice in this scenario that would be great but I think the capability is limited and more objects sit in memory that way.
What r your thoughts .. ?
Thanks
Dhiren
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
I cannot help you I am afraid.
I am making both Flight,seats part of a coarse grained entity (CMP/CMR)
Reasoning:
1. A search will not return a lot of flights
2 In the future ou might want to use the entity to add flights/seats to db
regards,J
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question About The "Seat"
 
Similar Threads
Saving Itinerary, yet again
partII: stateful session bean is necessary to serve as a booking cart?
Must persist unpaid itineraries
Ambiguity - Use Cases
Unpaid Itinerary...again