Originally posted by Ramon Gill:
Hi Luca,
From looking at other threads it seems you are pretty keen to get some answers ... so heres my views ...
1. replace
2. replace. You're right about FFN.
3. The assigment says the FFS must remain. It doesn't mention how you interface with it. That's up to you.
Ray
Originally posted by Ramon Gill:
Frequent Flyer System.
Ray
Originally posted by Ramon Gill:
Hi,
IMO you can change/create an interface without changing the system. With the right assumptions of course.
Ray
Originally posted by Ramon Gill:
Luca,
Theres nothing wrong with the screen scraper solution you came up with. I just think there could be other solutions depending on an individuals interpretation of the requirements. The 'requirements' state that travel agents must be able to 'access the system'. You could IMO state an assumption that this allows you to build a new interface to the existing system, without changing the system.
There seems to be a number of conflicts within the requirements where you need to make assumptions in order to move forward.
Ray
Originally posted by D. Rose:
One more point to consider in design is integration of systems.
FFM was only java system in old scenario. Now with new java solution thought must be given to how best we can integrate two systems? UI level (screen scraping) / business level/data level?What will be advantages/disadvantages?
Originally posted by Ganesh Krishnan:
You can decide upon any solution as long as it doesn't affect the requirements of the customer. Here I mean the requirement as 'the old system' . As per the interview, we are not supposed to replace the FFM.
You can go for the screen scrapper solution as you suggested, but you need to document your stratergies as well as assumptions. Another easy and a possible solution could be to parse the HTML text from the FFM and consume the needed data. (Documentation HINT : Since the system is already there, assume that it will not change in future)
Originally posted by Ganesh Krishnan:
Hi Luca,
what i specified was just a hint on how you can get the datas from the FFM system and design is up to you. The parser would be part of the your Application design and can open up a URLConnection to FFM and read the data. In this way you are not affecting the existing system.
But connecting to the FFM db directly is not a correct approach since you are violating the requirement given by the assignment.
Yep, Frequent Flyer System and FFM are the same.
Alvin Tang
But connecting to the FFM db directly is not a correct approach since you are violating the requirement given by the assignment.
Originally posted by Ganesh Krishnan:
Joe,
In the interview with the CEO, he clearly specifies that we need to do anything to interface with the FFM system. This means we got to retrieve the data from the existing system via an interface which can be a screen scrapper or a CORBA interface or a XML/RPC Interface but not by directly connecting to the FFM db.
Alvin Tang
Alvin Tang
Originally posted by Joseph Zhou:
Sorry, something unclear my last post. the login still need to have some implementation becuase I assume the FFMS has single sign on. The followed question is for HTML solution: is the transaction broken/disconnected?
The moth suit and wings road is much more exciting than taxes. Or this tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|