wood burning stoves 2.0*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes HELP: travel agents and new java application 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 "HELP: travel agents and new java application " Watch "HELP: travel agents and new java application " New topic
Author

HELP: travel agents and new java application

Luca Vent
Greenhorn

Joined: Dec 25, 2003
Posts: 17
Hello!


I haven't understood some speficications of SCEA exam - part II:

1) Will the new java application for travel agents replace
the 3270 screens or not? I mean...when the java application is ready the travel agents will go on using the 3270 screens to access to the legacy system to book all airfares?

2)Must the old legacy system (to book airfares) written in Cobol remain or I can replace it with a new j2ee architecture? In fact reading the "background" section and the "interview" it seems to be required to mantain ONLY the "Frequent Flyer Mileage System" (FFN)...am I right?

3)About the java application required for travel agents: what is useful for if I can't replace the web interface written in perl/html/cgi of the FFN? I ask this because to write a new java application to access the content of the FFM makes sense only if I can access to the Oracle database of FFM without going on using the old web interface. In fact if I give to the travel agents this new java application to access the Oracle DB of FFM for what reason they should go on using the old web interface? This would make sense only if my java application connects to the FFM using the old web interface: this means to use a screen-scraping solution but in this way I can't distinguish the data type being retrieved and this is what I absolutely need (for example to get the points redeemed)!!

Thanks a lot in advance everybody!

Luca
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
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
Luca Vent
Greenhorn

Joined: Dec 25, 2003
Posts: 17
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


Thanks a lot for your help, but what dou you mean with "FFS"?

Luca
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Frequent Flyer System.

Ray
Luca Vent
Greenhorn

Joined: Dec 25, 2003
Posts: 17
Originally posted by Ramon Gill:
Frequent Flyer System.

Ray


So if I understand well I can't change anything of FFS, web interface included. Am I right? But if I can't change it how can my new java application connect to the web interface of FFS and be able to retrieve data it needs (for example to get the points redeemed)?? As I told you I thought to the "screen scraping" solution, but in this way it is difficult to get the data present in the web pages returned using the web interface of FFS. Are you agree?

Thanks a lot in advance!
Murat Balkan
Ranch Hand

Joined: Sep 10, 2002
Posts: 127
Hi,

You are right. You will have to parse the returning HTML source to get the data. If the remote web interface changes, your parser code will not work.Screen scrapping is not the best way to interact with legacy systems but in this situation we have to think remote interface will not change.

Murat
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Hi,
IMO you can change/create an interface without changing the system. With the right assumptions of course.

Ray
Luca Vent
Greenhorn

Joined: Dec 25, 2003
Posts: 17
Originally posted by Ramon Gill:
Hi,
IMO you can change/create an interface without changing the system. With the right assumptions of course.

Ray


Sorry...but the interface is part of the system: if I change the interface (or I create a new one) I change also the system. Are you agree? Which type of assumptions could avoid this??
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
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
Luca Ventura
Greenhorn

Joined: Sep 01, 2003
Posts: 6
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! :-)
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Hi Luca,
Yes, I think you can add a new interface. You could still leave the old one, so the entire old system still works the same way. I wouldn't care who uses it, as you are leaving it alone.

IMO means 'In My Opinion'.

Ray
D. Rose
Ranch Hand

Joined: Apr 25, 2003
Posts: 215
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?
Luca Ventura
Greenhorn

Joined: Sep 01, 2003
Posts: 6
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!
Ganesh Krishnan
Ranch Hand

Joined: Sep 28, 2004
Posts: 42
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 )
Luca Ventura
Greenhorn

Joined: Sep 01, 2003
Posts: 6
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"?
Ganesh Krishnan
Ranch Hand

Joined: Sep 28, 2004
Posts: 42
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.
Luca Ventura
Greenhorn

Joined: Sep 01, 2003
Posts: 6
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?
Ganesh Krishnan
Ranch Hand

Joined: Sep 28, 2004
Posts: 42
Luca,

The suggestion I gave was one of the approach which you can follow, but you are free to choose any design as long as it is documented properly. As far as I am know, there cannot be a perfect integeration between two independent system without affecting each other.

Our requirement is to go for an approach which doesn't affect the existing FFM system, hence it should be part of our J2EE application that we design.
Also, it is not that just we show the milege awarded to the customer/Travel Agent, but also to make decision based on it. This means we need to interpret the data from the existing system and make decision based on it.

I think you can assume that, the FFM system won't change as long as you document it properly.

Anybody else want to comment on this?
Alvin Tang
Greenhorn

Joined: Oct 16, 2004
Posts: 20
I wonder if it is feasible to use CORBA to interface with the existing Perl program? If no, then I think the only solution is Screen Scrapper!


Alvin Tang
Joe Law
Greenhorn

Joined: Oct 30, 2004
Posts: 9
Hi Ganesh,


But connecting to the FFM db directly is not a correct approach since you are violating the requirement given by the assignment.


Can you tell me why connecting to the FFM DB directly is violating the requirement? Thanks.

Joe
Ganesh Krishnan
Ranch Hand

Joined: Sep 28, 2004
Posts: 42
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.
Luca Ventura
Greenhorn

Joined: Sep 01, 2003
Posts: 6
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?
Alvin Tang
Greenhorn

Joined: Oct 16, 2004
Posts: 20
Anybody know whether screen scrapper is used to access Mainframe green screen terminal only? Can it be used to access a web-based system written in Perl?
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Hi,
I think Joe made a good point. As long as you state the right assumptions there are many ways of tackling this. IMO, Joe provided a good solution.

ray
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
The screen scrapper solution is safe and good for the assignment, but there are some cons:
1)Mileages contain money value, so customer probably need HTTPS to connect to FFM. The travel system sit with the FFM within the same company firewall, the SSL(no way to change) is not required and will add overhead.
2)FFM is in-house developed, so you knows everything, you can make it work anyway if you want a screen scrapper, but you cann't guarantee the transaction to across the FFM web tier(say when you paying by mileages, a friend is transfering some mileages for you).
Actually, DB is part of FFM system(EIS tier), so it can be interfaced too.(Core J2EE patterns version 2 has web services attached), it is fast and transactional. IMO, it's a better solution. what do you think?
Alvin Tang
Greenhorn

Joined: Oct 16, 2004
Posts: 20
I just know that screen scrapper can be used for web-based system in addition to mainframe system. I think it is an appropriate solution since there is no need to change the code in the Frequent Flyer mileage system (FFMS). Direct access to the database of FFMS is possible but this approach requires more effort in development and testing since the existing business logic written in Perl should not be reused, we need to write java code having similar business logic to access & update the Oracle DB.

Don't know if it is right and any comments are welcomed.
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
Hi Alvin,
You are right, the con of the DB solution is you have to implement some business logic, like login, getMileage, redeemMileage, or rewardMileage. but my concern is the transaction: is the breaked in the middle by the HTML?
Joseph Zhou
Ranch Hand

Joined: Aug 01, 2000
Posts: 129
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?
Luca Vent
Greenhorn

Joined: Dec 25, 2003
Posts: 17
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?


Hello! I think that FFM (Frequent Flyer Mileage System) doesn't require a secure connection (can someone else confirm this?). In fact in the "background" section there is written that TransMaster is used to process credit cards and it is used by the legacy system written in Cobol (to book airfares) and not by the FFM. Besides travel agents use a web interface to interface to the FFM system and there is no need to send secure data to get mileage information: in fact at this level TransMaster is not used. So I think we can build a new software layer (SL) that interface with the Cobol system and uses the new TransMaster API to process credit cards using a secure connection through Internet. You can assume that communication between the Cobol system and the SL is secure because they reside in the same Intranet. You can also use the standard https protocol
to send data from the user (client tier) and the web tier (where the web tier of the SL resides listening for incoming requests). You can easily interface the SL with the FFM system to get mileage information: also in this case FFM and SL reside in the same Internet and you can assume that communication is secure. I think this hint can be useful for you! :-)
Pinal N Patel
Ranch Hand

Joined: Sep 05, 2003
Posts: 57
Can't we just put a link to both web app and Travel Agent stand alone app (with URLconnection) to FFM system. The requirements does not talk about single-sign on or anything, so everyone, what is your take on this?....

Pinal
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: HELP: travel agents and new java application