Goutam Bhattacharjee

Ranch Hand
+ Follow
since Aug 05, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Goutam Bhattacharjee

Congrats Sanly !

Can un provide some help on this:

How did you reuse the frequent flyer system? This is because the business req's says that this cannot be re-written/changed.

So, we may need to:

1. Contact the web front end of frequent flyer system and read HTML outputs

or,

2. Introduce JNI wrappers over cgi/perl programs

or,

3. Just use the frequent flyer database, with the award points calculation logic in j2ee components. (Possibly in the ejb layer)

I am confused. Which one is best. The last option seems the most conventioanl one, but it means that the front end of the frequent flyer system will not be used.

Regards
Goutam...
I have a confusion about the re-usability of the 'Frequent Flyer' system.
I wud like to know, what assumptions did u make about the system? According to the requirements, it cannot be re-written.

In fact, there are 2 prominent points:

1. While it is understandable that the Oracle database in the 'Frequent Flyer' system can be accessed by the Business Entities and DAO(s) of the new application, but how do u propose to reuse CGI & perl scripts?

2. Let's assume that we create links from the new j2ee application, to the pages of the 'Frequent Flyer' system. That would mean that the HttpSession established in the j2ee web-app, be carried over to the 'Frequent Flyer' web-app. This can be achieved by session replication techniques. However, the big qs is: if a Customer, after visiting the pages of the 'Frequent Flyer' web-app, wishes to return to the j2e web-app?
To do this, we need to introduce links/buttons in the 'Frequent Flyer' web-app, which point to the j2ee web-app. But, as per requirements, the 'Frequent Flyer' system cannot be re-written!


Considering these issues, I am proposing that ONLY THE DATABASE from the 'Frequent Flyer' system will be reused, and NOT THE WEB COMPONENTS

Folks, please opine.

Thanks in advance.
Hi Dhiren,
1st of all, heartiest Congratulations!


I wud like to know, what assumptions did u make about the 'Frequent Flyer' system? According to the requirements, it cannot be re-written.

In fact, there are 2 prominent points:

1. While it is understandable that the Oracle database in the 'Frequent Flyer' system can be accessed by the Business Entities and DAO(s) of the new application, but how do u propose to reuse CGI & perl scripts?

2. Let's assume that we create links from the new j2ee application, to the pages of the 'Frequent Flyer' system. That would mean that the HttpSession established in the j2ee web-app, be carried over to the 'Frequent Flyer' web-app. This can be achieved by session replication techniques. However, the big qs is: if a Customer, after visiting the pages of the 'Frequent Flyer' web-app, wishes to return to the j2e web-app?
To do this, we need to introduce links/buttons in the 'Frequent Flyer' web-app, which point to the j2ee web-app. But, as per requirements, the 'Frequent Flyer' system cannot be re-written!


Considering these issues, I am proposing that ONLY THE DATABASE from the 'Frequent Flyer' system will be reused, and NOT THE WEB COMPONENTS

Please opine.
Will be obliged if others also join in....

Thanks in advance.
Is there any Yahoo group for IBM 288 ?

Developing Web Services with WebSphere Studio Application Developer V5.1/

Or any site/link where sample qs can be found?
Don't like to spend $10.00 for a 'Test' exam!
Hi Chaitanya,
Did u find any link to a sample database/doc for IBM 288?

Have read your story. I understand that some lunatic was at the helpdesk. Eager to know what happened next. Did u file any complaint at higher authorities?

Goutam...
Friends,
Anybody working on part 2, please share some of your thoughts.

Is it safe to assume that only unpaid itineraries can be changed?

If we do not assume this, then the complexity grows manyfold.

waiting to hear from u people.
Friends,
Any of you know any link that contains sample questions on SCEA part 3? I am desparately looking for some sample qs.
Those who have completed,
Is doing part 2 enough for part 3, or there more to it?

If anybody have some sample qs on part 3, can u share those?

Thanks.
Folks,
I find this to be a disputed issue. Can a customer change an itinerary after it has been paid? The facts to keep in mind are,

1. after payment, tickets will be generated, and probably the customer can take print-outs.

2. there is no mention of returning the price differential to the customer if the changed itinerary is of lower cost than the original one.

3. If after changing the paid itinerary, the customer just saves it in the database, and does not pay for the changed itinerary (suppose till the actual journey date), do we need to return the money for the entire itinerary?

I guess the easy way out is to allow modification to unpaid itineraries only. But will that not put a limitation on the capabilities of the solution?
Anybody has got a different idea in this?

Thanks..

Hi Ram,
That was really good in clearing all doubts. Excellent !
Hi Deepak,
Congratulations for getting a high score!

Can u shed some light on the reuse of the 'Frequent Flyer System'? As per requirements, it cannot be re-written.

But how can we reuse the CGI & perl codes in the new application?

The oracle database for frequent flyer can be reused, though.
In this context, did u define any entity bean for representing the mileage account? Or access to the frequent flyer database has been only done through a DAO ?
Let me respond to Rashmi's strategy as per the specifications.

The 1st point is: TransMaster API is an RPC API, which is, by nature, synchronous.
2ndly, according to the interview session with FBN CEO/CIO, TransMaster have committed a response time of no more than 3 seconds.
Lastly, according to the 'Pay For Itinerary' use case, the system 'waits for authorization' - this means, if the connectivity to TransMaster is done from, a session bean method, that method will NOT return until the XML-response comes back from TransMaster.

(Correct me if these assumptions ar wrong)

These are strong forces against using any asynchronous model. I had thought
about JMS and MDB(s) while communicating to TransMaster, but after considering these, I had to reject them.

Now, Rashmi has suggested an alternative in using a JAVA implementation of XML-RPC.
The problem is, while the XML-request in TransMaster uses the RPC format, the response does NOT !
This means that, we need to do a customized XML parsing of the response from TransMaster. Thus, using any XML-RPC API, according to me, will not help. Therefore, treating TransMaster as a typical web-service is out of the way.

Rejection of those options leaves me with the alternative of using core java.net classes like URLConnection or HttpURLConnection, to establish 'https' connection to the TransMaster interface.

While explaining my views here, it may be appropriate to raise a pertinent point: Can we cache the URLConnection instances? Suppose we create a pool for URLConnection instances? This may be good idea to speed up performance, rather than creating a new URLConnection instance every time
Deepak, what's ur view on this?

By the way, thanks to Manju for clarifying the issue of XML-encryption. Manju do u think my suggestion of using sun.misc.BASE64Encoder for encrypting the credit-card number is sufficiently secured?

Waiting to hear from all of you intelligent minds..

gb.
Deepak,
Thanks for letting your opinion know. So, members of this topic, I think we can agree upon choice of java.net.URLConnection to open a connection to TransMaster, write the xml request and read the xml response. Any other ideas. please let everybody know. (It may be a better one!)

Coming to the question raised by Ravi, when we create a URLConnection object, we need to pass the url where the TransMaster service is available. As per the specifications, this should be available on a 'https' site.

Thus, the creation of the java.net.URLConnection object may be in this fashion:

java.net.URLConnection conn = new java.net.URLConnection(new java.net.URL("https://www.transmaster.com/cc_verify"))

Since this connection is happening over SSL transport, the contents of the XML request will be encrypted. Therefore, I do not see why we need JSSE to manually encrypt the XML contents.
However, if u have a look at the sample XML-request, u will see that the credit card number has been encrypted, within a non-encrypted request. Considering the credit card number as a string, this encryption can be carried out with: sun.misc.BASE64Encoder

That's what I think.
If anybody finds any holes in that, please respond.

Thanks
gb.
Deepak, when u say about simple HTTP Connection Open/Close, do u mean we can use the java.net.URLConnection class?
Open a connection with this class, then get the OutputStream and write onto it. Then capture the InputStream to read the response.

I think this will be better idea than tyo use any XML-RPC java API. This is becoz, the response does NOT folow XML-RPC format, rather, it's a proprietoty format! Therefore, we have to do a customized XML-parse to get the result from the XML-response.

Please let me know if that's what u r also thinking.


Ravi,
SOAP is NOT the ONLY option when using web-services. XML-RPC is one of the other options available. However, XML-RPC is not an international standard.
Whether SOAP or XML-RPC, they need a transport layer protocol. This can http, https, SMTP, ftp etc. In this case we are using https.
Hi Yong,
hat methodology did u use to for connectivity between the ejb toer and the credit card verfier system? (TransMaster). EJB specification says we should avoid socket connection from an ejb. It looks to me that we can treat TransMaster as a web-service (since it has an API in xml-rpc) and then let the ejb layer access this web service. Please opine whether this assumption is correct.

Thanks
gb
Folks, can somebody shed any light on what connectivity options do we have to access TransMaster from the ejb layer? TransMaster uses a XML-RPC api, does that mean it should be available and can be accessed as a Web-Service? I do not think we can use generic java sockets, as socket connections are not allowed from within an ejb. Also, this as per specifications, this is a synchronous call, therefore we cannot use message queueing techniques.
So, what's the solution?

Regards
Goutam...