antonio gallo

Greenhorn
+ Follow
since Jan 20, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by antonio gallo

Hello, I have seen at the CertManager DB that I passed part 2 with 94%.
I'm very happy, of course. :-)
Can I assume that I'm certified?
I found no info as far as the scea part 3 essay exam even if they get valuated together and so I think that part 3 should not be a problem if I passed part 2 and have been graded.
When will I get me results as far as part 3 in order to become definitely certified?
Can some already certified member please answer my question?
Thanks in advance and thanks to JavaRanch for the precious contribution.
Bye.
Antonio
I agree with You. Also designing enterprise applications from Sun is a good book to read. I saw that the number of discussions has highly decreased in thi forum. I'm writing sequence diagrams and Have some doubts as far as some use cases. Is there anyone who likes to discuss/chat with me as far as requirements and use cases that are ambiguous? What about creating a discussion group? Let me know.
Antonio
Hi Santiago, what do You mean with your sentence? Can You please provide more details? If I consider mileage account as an external entity, being related to an external system which FBN interfaces to, I think that a part from the technology you choose, the problem persists.
Can You give me some hints?
Bye.
Antonio.
Hi all certified and not.
Can I ask you how did you (or are going to) manage the concept of mileage account?
It shows up in the BDM even if the miles are retrieved interfacing to the FFMS system that can not be rewritten. In this light, I can not understand the utility of this class in the business model. Can you please give me some details? I saw some posts in the forum but they did not convince me.
I also saw that the requirements do not specify anything as far as mileage crediting (when a customer pays with credit card) and debiting (when a customer selects an award travel). Did you consider these possibilities in the pay for itinerary use case?

I originally thought of a html scaping technique in order to retrieve mileages from FFMS but in this way I'm unable to address neither the Mileage Account problem ( what should it be?, mileage account let one think of an entity on the db) nor the transactional aspects related to a failure in updating miles through an html connection. I'm wondering wether using a direct access(both in read and write mode) to a mileage account table on the FFMs db would be better for these cases.
Which is your opinion as far as these mattaers? Requirements are very confusing.
Thanks.
Antonio.
Hello Ram, congratulations for your great score!
Can I ask you how did you manage the concept of mileage account?
It shows up in the BDM even if the miles are retrieved interfacing to the FFMS system that can not be rewritten. In this light, I can not understand the utility of this class in the business model. Can you please give me some details?
I also saw that the requirements do not specify anything as far as mileage crediting(when a customer pays with credit card) and debiting (when a customer selects an award travel). did you consider this possibilities in the pay for itinerary use case? I originally thought of a html scaping technique in order to retrieve mileages from FFMS but in this way I'm unable to address neither the Mileage Account problem ( what should it be?) nor the transactional aspects related to a failure in updating miles through an html connection. I'm wondering wether using a direct access(both in read and write mode) to a mileage account table on the FFMs db would be better for these cases. Can you give me a suggestion? Requirements are very confusing.
I replied too, two hours ago. Please check again.
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 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.
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.
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?
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?
Congratulation! Perfect score!

I'd be greatful if You could clarify some doubts.
1) Did You save itineraries/segments to the DB even before paying them?
2) The use case addresses the possibility to select seats but does not explain if it means selecting phisical seats on an airplane or only their class (business economic...) ? How did you address this matter? Did You consider the possibility of a Customer to select several seats for each flight?
3) How did you address the problem of selecting seats avoiding race conditions? If I look at the prepare itinerary use case, I see that there are several intercations between the system and the customer (user selects flights, then select seats for each segment and so on..) . Being interaction performed with a human being, there could take some time between one action and the other and so I think that it's not possible to use a single transaction. In this light, how do you manage the problem? To better explain, when the user selects a list of flights (representing the itinerary), the system looks the available seats for each flight and return this info to the user. Then the user select seats for each route (or flight). In this time frame, it's certainly possible someone else to have booked some of the seats and so there's the possibility that the seats are no more available when coming back to the business layer to save them. How did you manage this problem? I know that there are two strategyes (optimistic and pessimistic locking) and that you can rely on entity ejb's isolation levels but being not standard specifications , I have some doubt about them. Which is your opinion? And if you you check seat availbility again, what do you do if some of the selected seats of the itinerary is no longer available? Would the customer select all the seats again?
4) The prepare itinerary use case is very ambiguous and at the eginning it refers to the possibility of the system to return alternative flights if less then selcted and within one hour. I think that this is very confusing since an airline system should return the list of all the available flights within a time frame and moreover, pricing has not yet been valuated at this point. Only a flat (class independent price) may be available at this time. My idea is to skip this point and only address the flight search and retrieval part. Which is your opinion as far as the matter? How did you interpret this point?

Thanks in advance.
Antonio.
Hello, I'm starting working for the SCEA project and I have some doubts that I'd like to discuss with you.
If you look at the Prepare Itinerary Use Case Specification, there's a line:

"System responds with the selected flight priced and alternative flights if less than selected and within one hour of departure and return times."

This text is misleading for the following reasons:

1) If you look at the interview, FBN uses a flat price scheme per destination, so the price should not depend on the time you take the plane and so there should not be cheaper alternative flight as far as the source and destination airport are the same.
2)How can the system calculate the price of the flight (the word less than selected means that a price is calculated) if the price itinerary use case is executed only at the end, after the user has selected the seats (and so the class) ?

Moreover, the use case refers to a one way or round trip flight and not to an itinerary (I suppose that also the terms are misused in the use case).

If we want to find an explanation for point 1, given it for granted that two flights going from point A to point B will ALWAYS have the same fare, we have to suppose that the system displays alternative flights if a different route exists for an itinerary in a given time frame. We can go from A to B also passing from C or D and in this case the price wil be different being different the mileage's count.

However, point 2 is more complicated to address.

If you lock at the modern airline companies, for each source and destination airport, they usually show a list of itineraries including number of stops and the list of flights (which can be more than one when a lay over is to be performed). Each segment is priced and you have to choose the solution as whole. You can not choose a flight of a solution (considered as an itinerary) and a flight of an other one.
The price itinerary can than calculate the whole price, by summing the price of each flight, according to imposed taxes and selected fly classes.
In the light of these considerations, I down't know how to manage the alternative flights "less than the selected ones" (if the itinerary is to be priced at a later point) and I'm thinking of skipping this point because I don't know how to collocate it.
Moreover, returning alternative flights would require some cache mechanism on the client or on the business layer (in order to compare user choices with the total set of the possibilities that a Customer may have discarded.
Now, since all these doubts and misunderstandings can impact the design of the system in any way... are there any thoughts?