• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

HELP: travel agents and new java application

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frequent Flyer System.

Ray
 
Luca Vent
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
IMO you can change/create an interface without changing the system. With the right assumptions of course.

Ray
 
Luca Vent
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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! :-)
 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
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
reply
    Bookmark Topic Watch Topic
  • New Topic