Luca Ventura

Greenhorn
+ Follow
since Sep 01, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Luca Ventura

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.



Hello!

I think that screen scraper is the only solution given that both CORBA and XML/RPC solutions imply to modify FFM system, because FFM has only a web interface (written in perl, etc) that doesn't support XML/RPC and CORBA.
In fact in a XML/RPC solution FFM system should generate XML code and support RPC calls, while in a CORBA solution I should install some code in the server side (in this case the FFM system) like the skeletons (stubs are for the client side). Are you agree?

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.



Hi Ganesh,
but to have a parsers that opens up a URLConnection to FFM and read the data is a solution very similar to "screen scraping" (with the only difference that I would build a new user interface with the data retrieved)...are you agree? Anyway the more difficult point of this approach is HOW to retrive the data from html pages returned from FFM and HOW to send requests to FFM. I should know the exact format of every request (parameters to send and so on) and how the result-page are formatted. I think this could be an assumption: that is to say "I KNOW THE FORMAT OF ALL TYPES OF REQUESTS AND OF EVERY RESULT PAGE". The second assumption I should have is: "THE FFM SYSTEM WILL NOT CHANGE" because if the system change I will have also to modify the new java application (the parser, for example).

Is it possibile that there isn't a more flexible solution?

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 )




Hello! But how could I parse the HTML text from the FFM and consume the needed data? In fact FFM hasn't this feature and I can't modify the system! Reading the requirements it seems that the data must be consumed from the new java application I must give to the travel agents: the FFM must only provide this data. Are you agree? I thought to build a new business layer for the java application that connects to the same Oracle db used by FFM...but in this way the new java application will not use the old system any more: it will use only the same db! Is this correct? Can I do this???


I have another doubt: in the interview FBN CIO says that a E5500 machine running the Frequent Flyer system...but Frequent Flyer system stands for "frequent flyer mileage system"?

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?



Hello! First of all I would like to clarify the use of term "FFM", "FFN" I used in this topic: I typed FFN instead of FFM by mistake...so they means the same thing, that is to say "Frequent flyer mileage system" This information can be useful to all new users will read this topic :-)

By the way...in the Sun's project specifiction it seems that "Frequent Flyer system" and "frequent flyer mileage system" are the same thing: can you confirm this?

Rose...what you mean with "FFM was only java system in old scenario"? FFM is written in Perl, HTML, CGI and have an Oracle database, and there is no track of java! :-( The same thing applies to the legacy system that use travel agents to access to the IMS db: it is written in Cobol! I think you wanted the scope of the project is to find a j2ee compiant solution to integrate these two systems: am I right? In this case, as you can read the "interview":

1) I can't rewrite it and my new new java application must be able to access the system
2) Customers must be able to have access to it through the Internet.

So if I don't use a screen scraping solution I wouldn't use the web interface written in Perl, HTML, CGI any more. Who would go on using it? I think that it makes no sense to write a new interface and mantain the old one. In fact who will go on using the old interface?

Which level of integration did you use (UI level (screen scraping) / business level/data level)? Sorry...but I am a little confused!


Thanks a lot in advance!

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



I think to understand what you say...for example I could add a new interface to the existing one, am I right? But in this case...who will go on using the old interface? :-( By the way...what do you mean with "IMO"??? Thanks a lot for your help and patience! :-)
Thank you a lot Axel for you explanations...but I have three questions on POJO again:

1)Who is that execeute a POJO? The Application Server?
2)How is it possible to call a POJO?
2)Can both POJO and EJB handle the same type of protocols (http, rmi-iiop, etc)?

Thanks a lot in advance,

Luca