aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes mileage account and crediting, debiting miles again!!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "mileage account and crediting, debiting miles again!!!!" Watch "mileage account and crediting, debiting miles again!!!!" New topic
Author

mileage account and crediting, debiting miles again!!!!

antonio gallo
Greenhorn

Joined: Jan 20, 2006
Posts: 13
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.
Santiago Urrizola
Ranch Hand

Joined: Apr 27, 2006
Posts: 172
Think on a class model as "technology independet" ... and you realize wy appears in Domain model and may be in your class model...


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>
antonio gallo
Greenhorn

Joined: Jan 20, 2006
Posts: 13
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.
Santiago Urrizola
Ranch Hand

Joined: Apr 27, 2006
Posts: 172
i think you are confuse with "logical model" or "object model" of your application with, where the data came from ... just think this: you need the user acount with his owned millage ... why dont model this ?.
Another question is how and which technique you use to access this data, this is not from you "object model" you show this in shor component diagram ...
Jonathan Gerrish
Greenhorn

Joined: Mar 25, 2003
Posts: 24
My thoughts and questions, would appreciate your comments, Cheers, Jon:-

1) In the airline industry Milage credit _always_ takes place when the flight departs. Probably FBN has some back end process that credits milage on flown segments to the customers milage account. Therefore we don't need to consider milage credit.

2) The requirements do not detail the FFMS functionality at all. Its HTML/CGI but is it publically visible? ie: do users have to log in. OR, is it internal only and travel agents just input the Frequent Flyer number to access the account. It seems to me there would have to be at least two bits of functionality. i) get/show account, ii) Redeem milage from account plus user login, if its a public site.

3) The booking with milage redemption alternative use case _must_ be an atomic action, so milage should not be redeemed when the flight fails to book, also the flight can't book but milage is not redeemed. This implies the use of transactions. However I am guessing that its not possible to roll back milage redeption (should the actual booking fail), so perhaps it would need to log this error for the attention of a supervisor to manually correct.

4) It is possible to interface with the milage system at either the database layer, or the presentation layer using HTML screen scraping. Since the system cost $500,000, it must be a sizable project and therefore I would make the assumption that there is substatial business logic embedded in the Perl code. Re-writing is specifically forbidden, so screen scraping is the way forward.

5) The transport protocol HTTP/HTTPS I assume is not specified. Would it make any sense pooling connections? Not in the case of HTTP since its stateless, but HTTPS? It prob. wouldn't use HTTPS if it was an internal only web site. If it was external it would need a users login for each connection, so this is not feasible to pool really. Is it acceptable to just have a DAO/LegacySystem Facade class that abstracts both the data transformation / scraping as well as the connections and include straight HTTP URL calls?
Jatin Sutaria
Greenhorn

Joined: Dec 09, 2004
Posts: 27
Originally posted by Jonathan Gerrish:
My thoughts and questions, would appreciate your comments, Cheers, Jon:-

1) In the airline industry Milage credit _always_ takes place when the flight departs. Probably FBN has some back end process that credits milage on flown segments to the customers milage account. Therefore we don't need to consider milage credit.

Event then, this back-end process should have been run on legacy FBN's ImS database and subsequently updated FMS's Oracle database. On still need to assume such a similar back-end process that reads the new FBN's system d/b and updates FMS's d/b(?).

Originally posted by Jonathan Gerrish:

2) The requirements do not detail the FFMS functionality at all. Its HTML/CGI but is it publically visible? ie: do users have to log in. OR, is it internal only and travel agents just input the Frequent Flyer number to access the account. It seems to me there would have to be at least two bits of functionality. i) get/show account, ii) Redeem milage from account plus user login, if its a public site.

3) The booking with milage redemption alternative use case _must_ be an atomic action, so milage should not be redeemed when the flight fails to book, also the flight can't book but milage is not redeemed. This implies the use of transactions. However I am guessing that its not possible to roll back milage redeption (should the actual booking fail), so perhaps it would need to log this error for the attention of a supervisor to manually correct.

If it is an atomic action, it should have been an atomic action for the legacy FBN system with IMS d/b as well. I am still struggling to find out how it could have been atomic for legacy FBN system? As per requirement ,travel agent has to keep custoemr on hold ang go to a shared computer to retrieve customer mileage status. If FBN travel agents with their 3270 terminal do not have access to this system, how would it be possible for above to be an atomic action in legacy FBN system?
Jonathan Gerrish
Greenhorn

Joined: Mar 25, 2003
Posts: 24
Jatin, Hi...

Originally posted by Jatin Sutaria:

Event then, this back-end process should have been run on legacy FBN's ImS database and subsequently updated FMS's Oracle database. On still need to assume such a similar back-end process that reads the new FBN's system d/b and updates FMS's d/b(?).


Absolutely! But since the requirements do not make explicit reference to this, its just somthing we've inferred. Is it really necessary to include it as part of the design diagrams, or perhaps just a note in the assumptions?


Originally posted by Jatin Sutaria:

If it is an atomic action, it should have been an atomic action for the legacy FBN system with IMS d/b as well. I am still struggling to find out how it could have been atomic for legacy FBN system? As per requirement ,travel agent has to keep custoemr on hold ang go to a shared computer to retrieve customer mileage status. If FBN travel agents with their 3270 terminal do not have access to this system, how would it be possible for above to be an atomic action in legacy FBN system?


Its atomic in the sense that the travel agent ensures that either both actions succeed, or both actions fail. Error conditions are not explicitly defined in the usecases. ie: what happens to the booking if the loyalty system is down. But you could expect that a travel agent would handle the error condition better than leaving either one of the systems in an inconsitent state?

Has anyone had good scores without the use of transactions, and what level of error handling have you guys assumed? What functionality have you assumed that the milage system provides?

Cheers, Jon
Jatin Sutaria
Greenhorn

Joined: Dec 09, 2004
Posts: 27
Originally posted by Jonathan Gerrish:
Jatin, Hi...



Its atomic in the sense that the travel agent ensures that either both actions succeed, or both actions fail. Error conditions are not explicitly defined in the usecases. ie: what happens to the booking if the loyalty system is down. But you could expect that a travel agent would handle the error condition better than leaving either one of the systems in an inconsitent state?

Has anyone had good scores without the use of transactions, and what level of error handling have you guys assumed? What functionality have you assumed that the milage system provides?

Cheers, Jon


To keep it atomic, one may need to have a component that can update both the databases at the same time. Since, such a component would not have been possible in legacy FBN system, one can presume that legacy FBN may have used some other way out. More or less this should be the way the new FBN system should adopt, since re-usability of FMS looks to be an important requirement.

Since We say accruing mileages is the responsiibility of a backend process, one option can be to have a 'Mileage' kinda table in FBN and assume another such backend process that can map FMS system with this table(read from FMS...write into this table). So, you can have an atomic transaction woring now on the same database. Problem could be data in 'Mileage' table would not have most updated data and extent of stale data may depend upon the frequency of this backend process. What do you think of this?

Jatin
Jonathan Gerrish
Greenhorn

Joined: Mar 25, 2003
Posts: 24
Originally posted by Jatin Sutaria:


To keep it atomic, one may need to have a component that can update both the databases at the same time. Since, such a component would not have been possible in legacy FBN system, one can presume that legacy FBN may have used some other way out. More or less this should be the way the new FBN system should adopt, since re-usability of FMS looks to be an important requirement.

Since We say accruing mileages is the responsiibility of a backend process, one option can be to have a 'Mileage' kinda table in FBN and assume another such backend process that can map FMS system with this table(read from FMS...write into this table). So, you can have an atomic transaction woring now on the same database. Problem could be data in 'Mileage' table would not have most updated data and extent of stale data may depend upon the frequency of this backend process. What do you think of this?

Jatin


Hi,

Yes, I agree, I think we can assume the legacy system would not have been able to access the FMS database. The requirements don't state whether there is some backend process to credit milage, or if its a manual task for travel agents, as you say there must have been some other way out, not detailed in the requirements. As such I think this is beyond the scope of the project.

My main issue is surrounding the redeption of milage.

We would only want to show the Milage Redeption option on the payment screen if the user has a loyalty account, and has sufficient milage allowance to make a redemption. Then if they chose that option we'd attempt to redeem the milage. This to me implies an interface to the milage system like this:-

Interface LoyaltySystem {
boolean isRedemptionPossibleForItinerary(Itinerary it);
void redeemMilageForItinerary(Itinerary it)
}

My worries were around what happens if either of the systems fail at the redemption.... any thoughts?

Thanks, Jon
Jatin Sutaria
Greenhorn

Joined: Dec 09, 2004
Posts: 27
Originally posted by Jonathan Gerrish:


Hi,

Yes, I agree, I think we can assume the legacy system would not have been able to access the FMS database. The requirements don't state whether there is some backend process to credit milage, or if its a manual task for travel agents, as you say there must have been some other way out, not detailed in the requirements. As such I think this is beyond the scope of the project.

hello Jonathan,
Since we are reusing the existing FMS system, we should be using it the same way as existing FBN system with IMS database have been using it, otherwise there can be a risk of changing the FMS system (implicitly). In my opinion, only the implementation of the interface between legacy FBN with IMS database to FMS system needs to be changed (and not the interface), keeping the FMS system as it is.

Therefore, it is important, for me, to arrive at a logcal guess of what would have been the original interface. It could well be a set of background processes which had read the original IMS database and updated the FMS tables in case of legacy FBN system. So, if one have substantiate this guess, one can assume that the interface between the new FBN system and FMS system could also have background processes that now would read from FBN's Oracle database and update the FMS database.

Do the above guess answer your question. I guess, it needs some more discussion done below
Originally posted by Jonathan Gerrish:

My main issue is surrounding the redeption of milage.


i am assumping that redemption of mileage implies awarding mileage travel to a customer, and may logically lead to reduction/debiting the miles that has been accrued by a customer. Kindly confirm.

Originally posted by Jonathan Gerrish:

We would only want to show the Milage Redeption option on the payment screen if the user has a loyalty account, and has sufficient milage allowance to make a redemption. Then if they chose that option we'd attempt to redeem the milage. This to me implies an interface to the milage system like this:-

Interface LoyaltySystem {
boolean isRedemptionPossibleForItinerary(Itinerary it);
void redeemMilageForItinerary(Itinerary it)
}

My worries were around what happens if either of the systems fail at the redemption.... any thoughts?

Thanks, Jon


Thats why i had thought of a Mileage table in FBN's database (also in legacy FBN IMS d/b(please see my previous post). Now if you extend the assumption further what if you also assume some more background processes that reads FMS database and populates the Miliage table of FBN's database and does vice-versa as well. (This assumption can also hold for legacy FBN system with IMS database. Also, demerits were discussed in the previous post, regading having not most upadted Miliage data in Miliage table in FBN's database.

Now, new FBN system is as separate from FMS as was legacy FBN system. and You just worry about Mileage table in FBN's Oracle databse, as you are not going to update the FMS system at the same time and question of FMS system failing does not come in to equation.
I assume i am hitting the same ball as you and if it is, how do you find this approach?.

Thanks,

Jatin
Jonathan Gerrish
Greenhorn

Joined: Mar 25, 2003
Posts: 24
Hi Jatin,

Agreed. FMS implementation must not be changed. We must assume some kind of interface for loading credited milage into the loyalty system, I think your ideas for reengineering are definately sound ones.

What I am not certain of, is whether defining the mechanism for crediting loyalty points is within the scope of this assignment. We know that somewhere in the system as a whole, this process must happen, but within the context of the assignment, there are no use cases, neither textual references to any process for crediting milage.

One thing that is important to me is to control scope creep. As I said before, I am interested in satisfying the requirements, no more, no less.

I think it seems to be somthing we acknowledge would happen, but we do not include it in the design.

Do you think this is a component that the examiners would be looking for in our solutions?

My other open questions are:-

1) How would you consider the interface for the FMS? ie: what CGI scripts could be available (ShowMilage / RedeemMilage - ie: use milage to pay for flight).

2) Should we consider error conditions, eg: what happens if either milageRedemption or Booking fail?

Thanks for your prompt replies, much appreciated.

Cheers, Jon
Jatin Sutaria
Greenhorn

Joined: Dec 09, 2004
Posts: 27
Originally posted by Jonathan Gerrish:
Hi Jatin,

Agreed. FMS implementation must not be changed. We must assume some kind of interface for loading credited milage into the loyalty system, I think your ideas for reengineering are definately sound ones.

What I am not certain of, is whether defining the mechanism for crediting loyalty points is within the scope of this assignment. We know that somewhere in the system as a whole, this process must happen, but within the context of the assignment, there are no use cases, neither textual references to any process for crediting milage.

One thing that is important to me is to control scope creep. As I said before, I am interested in satisfying the requirements, no more, no less.

Yes, agreed. Identifying an exisitng interface between legacy FBN with IMS d/b and FMS is not in scope. But the point i was trying to make is i want to maintain the interface spscifics same for the new FBN system with FMS system as well ,as said before. Further i am trying to justify that what is going to change is the implementation to this interface and not the interface.
So this interface can be defined as following:
It is a set of offline backend processes that reads data from FBN's d/b and updates the FMS's Oracle database. So thus, the interface is not a java interface.

So lets see how this assumption of the interface holds for legacy and new FBN system.
For legacy system
Backend process programs read from IMS database and deposits the read files in some location in some format. Another set of back end process programs reads these files, analyses them and upadtes the FMS's Oracle database.

For new system
Backend process programs read from FBN Oracles's database and deposits the read files in some location in same format as before. Another set of back end process programs reads these files, analyses them and upadtes the FMS's Oracle database.

So in the new system, what is expected to change is just the backend process programs that read, now, from FBN's Oracle database instead of IMS database.

Originally posted by Jonathan Gerrish:
[QB}
I think it seems to be somthing we acknowledge would happen, but we do not include it in the design.
[/QB]

I think, if you justify why the interface would remain the same, i see no harm in including this as a note.
Originally posted by Jonathan Gerrish:
[QB}
Do you think this is a component that the examiners would be looking for in our solutions?
[/QB]

No, i think just mentioning this as as assumption may be enough
My other open questions are:-
Originally posted by Jonathan Gerrish:
[QB}
1) How would you consider the interface for the FMS? ie: what CGI scripts could be available (ShowMilage / RedeemMilage - ie: use milage to pay for flight).

2) Should we consider error conditions, eg: what happens if either milageRedemption or Booking fail?
[/QB]


For the first question, for me, no screen scraping is needed, one can directly call the CGI/Perl web page dierctly from a web or swing application. And interface may be offline as defined above.

For the second question: yes; i think one should consider the error condition; since mileage redemption and booking operations work on the same databse(please refer my previous post), there can be quite a few scenarios in which error conditions can be addressed. One, not exactly sure though, is to fail the booking if redemption fails.


Your comments!

Regards,
Jatin
Jonathan Gerrish
Greenhorn

Joined: Mar 25, 2003
Posts: 24
Hey,

So looking at the requirements carefully I see two key phrases:-

1) Second paragraph in Background text: -

"The agent must place the customer on hold and go to a shared computer to _retrieve the customers mileage account_"

2) Use Case Specification: Pay for Itinerary, alternative flow:-

"System verifies mileage availability and returns confirmation screen"

These two statements infer to me that its just a read operation of the FFMS, to retrieve and validate whether awards travel can be applied. If it can, the booking can be made, otherwise not. There is no alternative conditions for if the user has selected awards travel and its not available, but we can assume it sends a failure email, or returns to the credit card payment screen.

I think we can consider this a read operation only, and make the assumption that "some back end process" is required to debit and credit mileage in the background.

There is also the issue that the user could book two itineraries in quick succession using the same set of mileage, if the back end processes are not quick enough. I'll make a note of this in my document.

I think making this assumption is the easiest thing to do. It takes away complicated failure scenarios, transactions over multiple sources etc.

I really don't think the assignment is supposed to be _that_ complicated, so as you can see I am looking for the easy and simple approach. :-)

Cheers, Jon.
Nelson Karan
Greenhorn

Joined: Jul 13, 2006
Posts: 11
Originally posted by Jonathan Gerrish:

There is also the issue that the user could book two itineraries in quick succession using the same set of mileage, if the back end processes are not quick enough. I'll make a note of this in my document.
Cheers, Jon.


IMO, that sounds really bad. That poses a data integrity issue, which a good architect should address.

It sounds like what you could do, based on your approach, is just keep track (in the FBN db) the mileage points that the customer has used today. Assume the batch job would update both databases nightly. Each time the customer attempts Award Travel, you could just do a quick check to see if the customer still has sufficient mileage points remaining. This solves problems: (1) tx atomicity, and (2) data integrity. Let me know if you think otherwise.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: mileage account and crediting, debiting miles again!!!!