Connectivity to External System

[Goutam Bhattacharjee]

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...

[Rashmi Razdan]

In case it helps , chk section ,Asynchronous Messaging Module Implementation in the url :
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1a3.html.
Please let me know your issues wrt this implementation, than it being asyn.. may be u cud extract soemthing from jms for it to work as sync...

rashmi

[Ravi Dhanum]

Rashmi,

I also have a question regarding this. I clicked the link and the web page was not found. Where can I find the information?

-Ravi

[Dan Drillich]

Ravi,

Please discard the period at the end of the url

-- Dan

[Ravi Dhanum]

Thanks, Dan. I will read it.

-Ravi

[Ravi Dhanum]

Hello,

I have read the blueprints url from above. That design uses JMS for sending the order. In our case, we need synchronous, HTTPS, and a Post. From EJB (or some other class), can we use JSSE and URL classes to send the XML? Is this the implementation others are using?

Thanks in advance.

-Ravi

[Manju Karthik]

Hi,

I have the same doubt too. Transmaster is coming up with new interface and it is xml-rpc based. And also protocol is internet (HTTPS). So why can't it be a webservice. FBN airline can consume this webservice, the calls to webservice can be synchronous too. It actually makes sense to have synchronous call as this is a credit card authorization.... So making such an assumption and documenting it should be ok right. Any thoughts??

-Manju.

[Rashmi Razdan]

Hi ,
sorry for late reply, i was away and didnt chk mesages this long weekend.
though mesaging is asynchronous , we can use PtoP type..

i think in many Qs in 200dump.. there were mesaging used for synchronus mesgaing as well
any comments or doubts.. let me know what u think of it.

anyway I am not against webservice option.

[Deepak Pant]

Originally posted by Goutam Bhattacharjee:
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...

Goutam,

I think the point to stress here is:

What design pattern you chose to connect to an external system?
How extensible and maintainable is the interface?
Will the design allow connecting to other credit card providers in future? How difficult will it be to use a technique other then XML-RPC?

How XML-RPC is coded is also important but above questions are more important for an Architect to answer.

So think about the answers and then focus on how XML-RPC can be invoked? Can be done using simple HTTP Connection Open/Close or Thru use of JAX-RPC etc etc.

Hope I did not confuse you.

Deepak

[Ravi Dhanum]

Hello all,

This discussion is very helpful.

I like the idea of a web service, but the protocol of a web service is SOAP, not HTTPS with POST.

How can a web service fit with this requirements?

Thanks in advance.

-Ravi

[Goutam Bhattacharjee]

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.

[Deepak Pant]

Yes thats what I meant and you do not need an EJB to do that job.

As I stressed earlier, the key point is to identify how well you design the interface so that future solutions can be plugged into the system without causing lot of changes.

[Ravi Dhanum]

Goutam,

When using HttpConnection open/close, are you using JSSE to encrypt the data? If not, then how will the data be encrypted?

Thank you.

-Ravi

[Goutam Bhattacharjee]

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.

[Manju Karthik]

Hi Goutham,

SSL over HHTP (HTTPS) provides only transport layer security.
The message is still plain text, if the data is more confidential message level security is required. In which case, data/message need to be encrypted.

But i do agree with your point, that since the only confidential information credit card number is already encrypted as per the spec. There is no need for encryption of the whole message.

I still dont see the benefit of using the HTTP connection over web service.

Deepak,

Did you consider webservice for transmaster and did u do any comparison with HTTP connection?? I am still not able to come to conclusion of this. Web services being the latest tech and also java community is supporting it to great extent. I think i am mentally prepared for webservices as i am working on a web services project currently, so the traditional way of using HTTPconnection is not so appealing to me... any suggestions. Am i missing something here.

-Manju.

[Rashmi Razdan]

Gautam,
I was almost set to use the P2P messaging for the transmaster and all of a sudden im now confused.

How much does ur URLConnection thing differ from the prevalent socket connection.In that case how much is the new Inernet API helping us.

deepak,

I understand JMS may not be the best soln, but is it not an option.As it will be too late to change anything for me now.

Manju, have u finally settled for webservice.

Is my understanding totaly wrong.

rashmi

[Rashmi Razdan]

Hi,

Rather than using urlConnection.. we have this pakage below which provides the methods to connect to SML-RPc server.. So can we simply put a java class which uses this package to handle RPC communicaiton???
http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/XmlRpcClient.html

[Deepak Pant]

Manju/Rashmi,

My solution was based on synchronous communication as application requirement demands it.

I did not use it as webservice because I am at the calling end. The APIs have been published by TransMaster for me to use. The APIs follow XML RPC style and all I needed was a simple mechanism to call it.

So for me both JMS & webservice were out.

As I had mentioned previously in the post, you guys should focus on
What design pattern to use to connect to an external system?
How extensible and maintainable is the interface?
Will the design allow connecting to other credit card providers in future? How difficult will it be to use a technique other then XML-RPC?

Deepak

[Rashmi Razdan]

thanks deepak..u have valid point..rather points.. and i understood now.

[Ravi Dhanum]

Manju,

Sorry to respond late to the emails. I hope you can answer my question:

I thought ssl worked by using a symetric key to encrypt message body. You stated that the message body would not be encrypted. Could you explain this?

Thanks in advance. -Ravi

[Manju Karthik]

Hi Ravi,

In broad sense, yes the message will be protected during SSL session.
But in real world, that is not the case. Specially when internet is used for communication. SSL session is established between two systems, lets say a client connects to server via SSL over internet to access the service. The call is not directly transfered to destination, in real world it will go via multiple routers..... before reaching the destination. Any hacker expert can hack and get the data if the message is not explicitly encrypted (message level security).

Hope this helps. For more reading,

http://dev2dev.bea.com/products/wlworkshop81/articles/remy.jsp#_ftn3

This article is more towards webservices security, but it applies to any SSL communication.

-Manju.

[Goutam Bhattacharjee]

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.

[Chandramouli Ram]

Hi,

Just wanted add a little info.
While making HTTPS connection, you need to use HttpsURLConnection (since jdk 1.4), which is part of the "javax.net.ssl" package.

[Joseph Zhou]

Something in this long thread confused me.
1.xml-rpc is about RPC, so it is a synchronous call, nothing with MQ etc. 2.based on SUN JWSDP or something similar, a xml-rpc has a web services endpoint to be connected by clients and has a WSDL pulished, client side supporting stuff can be created by some tools and the caller can uses whatever language he want(if there is a tool to help him), so we don't need too much consideration about http connection, xml and SOAP etc.
3.https is secure, it is http over SSL, not the "S" within http. For SSL, please take a look of the doc from Netscape, the link is at linked page of the forum.
Please let me know if I missed anything.

[Ravi Dhanum]

Manju,

Thanks for the response. This is very helpful.

-Ravi

[Chandramouli Ram]

Hi Goutam,

In this trail, I feel that the main finding/conclusion is to open an URLConnection to the Transmaster's URL. As one cannot do it from with in the EJB Container, is it going to be done from the web layer/Swing presentation layer? May be we can have an Authorizer Interface and multiple AuthorizerImpl to take care of the variations, while a BusinessDelegate and Service Locator patterns can be employed as well.

As for caching, my only concern is that, once the URLConnection object is created using say the following code:
HttpsURLConnection urlcon = (new URL(TM URL)).openConnection();,
the next step would be to call the "connect()" method. And, URLConnection objects will have a small and finite timeouts, unlike the database connections. So how do we maintain a pool of active connection objects? Not sure if I am grossly missing something!

[Chandramouli Ram]

Hi Goutam,

I just figured out that it's indeed possible to connect to URL from EJB. My sincere apologies for publishing a wrong info. Here is the relevant URL from Sun's site:

http://java.sun.com/j2ee/sdk_1.2.1/techdocs/guides/ejb/html/Advanced4.html

[Goutam Bhattacharjee]

Hi Ram,
That was really good in clearing all doubts. Excellent !

[Lucy Hummel]

... <snip >
..
.


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?
....
<snip >

gb.

Hi GB,

In my opinion if and how the connection are handled is implementation detail and part of the implementation of the Design Pattern Service Locator .



What is your opinion about that?

[Lucy Hummel]

Originally posted by Goutam Bhattacharjee:
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.

Sorry, for using the quoting wrong.
...

But I still have the opinion above that the connection caching is implementation detail and is not part of SCEA.


Lucy

[Tony Thian]

Originally posted by Ram Chandramouli:
Hi Goutam,

I just figured out that it's indeed possible to connect to URL from EJB. My sincere apologies for publishing a wrong info. Here is the relevant URL from Sun's site:

http://java.sun.com/j2ee/sdk_1.2.1/techdocs/guides/ejb/html/Advanced4.html

Hi,
I found another way to do it using a third party JCA adapter:
http://www.librados.com/pdfs/04/socket.pdf

[ravindra janapreddy]

Hi

I agree with Lucy that we must not get into the implementation details of the exact approach to be followed for interfacing with Transmaster. As an Architect, we must just focus on creating an interface and leave out the exact implementation details to the developer.

Thanks and Regards

-- Ravi

[Ali Reza Hosseini]

I think it is enough to have a connector (or resource adapter) using JCA which encapsulates TransMaster's XML-RPC based inetrface and on the other side provides a standard interface to other java compotents based on JCA contracts.

This solution gives a suitable answer to the architectural issues
mentioned above and let the developer decide how to implement the
connector's conversation with the payment system.

any comments?

regards

alireza