There is a way to create a service (Flow or Java) which binds to socket?
Our SW engineering team asked me if it is possible to create a such kind of integration between an legacy app and IS. This service (or whatever it can be) should run like a daemon, listening and send data through it. It should support receive AND sending data many times while the socket is open.
Does any one has an idea in order to do that? If anyone could give some hints on this subject, I would appreciate a lot.
You can try to create a java service which listens on a port, then install it as a start up service for the package. I don’t see any reason why this shouldn’t work.
ok, but how I tell IS to create a new thread and assign the incoming connection to it?
My Java service now looks like:
int listenPort = 6000;
try {
ServerSocket server = new ServerSocket(listenPort);
server.setSoTimeout(180000);
Socket incomingConnection = null;
while (true) {
incomingConnection = server.accept();
/***********/
idcPipeline.insertAfter(“incomingConnection”, icomingConnection);
/* how do I create a new thread to hadle this? */
handleConnection(incomingConnection);
}
}catch(BindException e){
idcPipeline.insertAfter(“error”, e.toString());
idcPipeline.insertAfter(“errorMessage”, "Unable to bind to socket: " + e.getMessage());
throw new ServiceException(e);
} catch (Exception e) {
idcPipeline.insertAfter(“error”, e.toString());
idcPipeline.insertAfter(“errorMessage”, e.getMessage());
throw new ServiceException(e);
}finally{
// Always destroy your cursors!!!
idcPipeline.destroy();
}
The attached ZIP file contains an IS package called SocketExample that contains a single java service that will listen on a user-supplied port number for input. It makes use of a protocol called KnockKnockProtocol found on the service’s “Shared” tab.
Test this service by compiling and running the KnockKnockClient.java program found in the package’s \pub folder.
In real life you would want something more sophisticated. In a recent post, Fred Hartman suggested that creating a java class that implements the com.wm.app.b2b.server.ServerListenerIf interface.
Thanks for the provided directions. I am new to wM and IS, so I am not very aware of IS’s do’s and dont’s.
CODING THE PROTOCOL INTERCHANGE INSIDE THE JAVA SERVICE?
Peeking your code, it seems that is advisable to handle all the communication processing inside the Java program, and after the talk has finished, return the processed data back to the pipeline. Do you recommend this way to tackle the socket communication task? Or should code actions (like openConnection, closeConnection, etc.) in Java and let the control flow being coded using Flow language? The Java program should return an Object to the calling service with the Socket objet?
I simply converted Sun’s “KnockKnockServer” example from their “All About Sockets” tutorial to an IS java service. I am in no way suggesting that this represents a webMethods best practice.
Actually, if it were me, I would work first to design the socket-level communication out of my integration application due to the complexities of implementing the stateful communications protocol in either java or a Flow service. If the resource has any other means of communicating with the outside world (HTTP, Java API, web services, database, FTP, etc.) I would explore that before tackling the socket-level i/o.
Given that your requirements might not allow you that flexibility, I would look next at developing a custom adapter using the Integration Server ADK 6.1. Note: This is not a task that I would recommend for inexperienced Java developers or for those brand new to webMethods Integration Server.
Perhaps others here could offer suggestions on doing socket-level i/o within Integration Server.