There is an exisiing Perl cgi scritp application which we are not allowed to change and have to reuse to the maximum through a J2EE application. What could be the best way to connect to it? e.g. use a session bean to coonect to a home grown RMI server running on the same node as cgi application and thus using RMI from session bean to connect to RMI server and requesting to execute certain perl scritps. The RMI server may use JNI to execute perl scritps. However, this solution does not seem to very elegent.
- Posted by: Tauqeer Bhatti
- Posted on: July 24 2003 10:50 EDT
Well ... the other option is to invoke the CGI program the way a client would, via HTTP. The simplest way to do so would be a java.net.URL object:
URL url = new URL("http://>");
URLConnection con = url.openConnection();
InputStream is = (InputStream) con.getContent();
// Read results from inputstream
This is a lot simpler than RMI, but I doubt performance will be very good. On the other hand, if you do a simple solution with lousy performance, maybe they will realize this is a stupid achitecture, and allow you to replace the CGI.
I claim that the most elegant solution would be to write a JCA connector which will use sockets to communicate with your Perl application. At least, it will be a reusable solution and you'll not have to re-write half of your application when you finally decide to get rid of Perl.
Thanks ! for your response. Please let me share the following two design choices with you.
One solution as I suggested earlier is using a Session Bean which will use a URLConnection Object to execute certain scritps and receive response form WebServer (this WebServer will be executing those scripts). Session bean may parse the response from the server to draw some meaningfull information.
The other options may be that my session bean just post a Synchornous message (this message may have an XML body containg info. about the percl scritp to be executed)using JMS. Then we can have multiple instances of JMS client appliations which will consume that message and execute requested script. After executing that script they may create an xml message containg the results of the execution. This message reply will be retrurned to my session bean. Session bean now can use results of perl script execution in my J2EE application.
However, I am a little hesitant to use second approach since once perl application is migrated to a java application spending on JM provider will be wasted. However, I'd like to have a session bean facade, since the implementation behind this facade may change with out affecting client programming model.
Looking forward to your input.
Of the two, my guess is:
Option 1 will perform better (at least for throughput of individual requests)
Option 2 will scale better.
Note that the above are just wild guesses, based on a vague intuition on my part.
Given that you will probably eventually need to replace this component anyway, I would go with the simpler option (Option 1).