You need to read the assignment a bit more. You have to decide how to interface with the Frequent flyer miles system. If you are going to use technology that is not mentioned in the assignment, you have to justify why you used it and document your assumptions as well.

1) Yes, The Freq Flyer was developed using Perl, HTML, CGI, HTML, and Oracle DB. 2) To connect the J2EE (our solution) with Freq Flyer? Hmm, I am still thinking ... 3) I think we still (must) need Freq Flyer in our solution.

And my turn, by the way:

1) How about the Cobol System for payment transactions. What do we do with it in our solution? Keep in, change it or remove it? If we keep it, how to connect (integrate) our Java solution with this old Cobol

2) I think in the current system, agents use screen to connect to the Cobol. The connect will accesses an IMS Database, and/or Transmater. What is the position of Transmatter in our solution?

Thanks [ June 17, 2007: Message edited by: Pham Huy Anh ]

Frank Kuepper

Ranch Hand

Posts: 45

posted 10 years ago

Hi Pham,

for your questions, there's also not much more to say than to cite Johns answer above: "You need to read the assignment a bit more." It is specified very clearly how to deal with TransMaster!

Greetings, Frank

SCEA (93%/93%)

Ralf Pant

Greenhorn

Posts: 1

posted 10 years ago

Originally posted by Sam Gehouse:

1) Is Frequent Flyer written using a technology other than Java/J2EE? This is what I assumed after wreading the assignment.

2) If Frequent Flyer is written using other than J2EE, is it sufficinet to just make a note as: Use CORBA, or Messaging or Web Services for interoperability.

3) Or, do I need more elaboration on how to connect to Frequent Flyer from J2EE.

Personally, I infer from the requirements document (in particular the CEO�s interview statement �You will have to interface with what is there�) that the frequent flyer mileage system can be accessed solely through its web interface. This means that without rewriting the entirety of that system or parts of it, there is no way of interfacing with it other than simulating an HTTP client and parsing the HTML responses. I think about suggesting the use of Apache Commons HttpClient in my solution to simplify that job, although this may be regarded as an implementation detail not subject to the architecture and design.