Socket Listener

[jeanguyer]

Hi,

I am new to Jboss Esb, and i've a newbie question :
according to this image (found on http://labs.jboss.com/jbossesb/):
[img]http://labs.jboss.com/portal/jbossesb/screenshots/ESB.gif[/img]

Jboss Esb have a socket listener . After looking in the samples, i can't find a sample using it. I've saw JMS, mail , file , sql gateways but no basic socket listener.

I'm trying to build a Proof Of Concept for using JbossEsb in Healthcare Information System using MLLP protocol and HL7 messages.
Can you guys show me some samples of how to do it ?

Sorry for the bad english.
Best Regards,
Jean Guyer.

[beve]

Hi Jean,

if you take a look at the webservice_producer quickstart you'll find an example of this:

<jbr-provider name="JBR-Socket" protocol="socket" host="localhost">
 <jbr-bus busid="Socket-1" port="8888" />
</jbr-provider>

Regards,

Daniel

[jeanguyer]

thank you , i've successfully set up a socket listener on a new esb.
Unfortunately it doesn' t work out of the box.

When i use a HL7 client(opensource project) which send a message , i raise this exception :

15:37:43,826 ERROR [ServerThread] Worker thread initialization failure
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:720)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:368)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
Caused by: java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:763)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:278)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:95)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:72)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:55)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:185)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:164)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
... 7 more

Log of client :

Connecting system localhost:2100... System localhost:2100 connected. Send message... <0x0b>MSH|^~\&|ADT-HIS||HL7INSPECTOR||20060101100000||ADT^A01|1|P|2.3<0x0d> EVN|A01|20060101|<0x0d> PID||||4711|Doe^John||19701024|M|||Sesamstreet 11^76137^Karlsruhe^D|||||GS|EV|||<0x0d> PV1||I|S2^13^3^CHI^^21||||||||||||||||1234|||||||||||||||||||||||||200601010930|||||||<0x0d> <0x1c><0x0d> Message send. Waiting for acknowledge message... ¬ÃÂÂ<0x00><0x05> End of stream reached Disconnecting from system localhost:2100... System localhost:2100 disconnected. Send messages server stopped.

jbossesb.xml

<jbossesb
 xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd"
 parameterReloadSecs="5">
 <providers>
 <!-- Socket BUS -->
 <jbr-provider name="JBR-Socket" protocol="socket"
 host="localhost">
 <jbr-bus busid="MLLPEntrantBus" port="2100" />
 </jbr-provider>
 <jms-provider name="JBoss Messaging Entrant"
 connection-factory="ConnectionFactory"
 jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
 jndi-URL="localhost">
 <jms-bus busid="MLLPCanal">
 <jms-message-filter dest-type="QUEUE"
 dest-name="queue/MLLPTEST" />
 </jms-bus>
 </jms-provider>
 </providers>
 <services>
 <!-- SERVICE MLLP HL7 -->
 <service category="HL7Category" name="SocketMLLPService"
 description="Listener des fichiers entrants HL7 MLLP">
 <listeners>
 <jbr-listener name="MllpHL7BusListenner" busidref="MLLPEntrantBus"
 is-gateway="true" maxThreads="1" />
 <jms-listener name="MLLPCanalListener"
 busidref="MLLPCanal" maxThreads="1" />
 </listeners>
 <actions>
 <action name="print"
 class="org.jboss.soa.esb.actions.SystemPrintln">
 <property name="message" value="Message HL7 recu" />
 </action>
 </actions>
 </service>
 </services>
</jbossesb>

I think EsbSocketListener doesn't like basic inputStream.
So what is the next move now ?

Regards,
Jean Guyer

[beve]

The jbr-listener listener is actually a JBoss Remoting listener which. If you take a look at org.jboss.soa.esb.samples.quickstart.webserviceproducer.test.SendMessage
and its sendMessageToJBRListener method you can see how it connects to the socket.

I'm not sure that this will work for a "normal" client socket or with the HL7 project (I'm not familiar with it).

I using jboss remoting an option?

/Daniel

[jeanguyer]

The clients sending HL7 messages use the following classes : java.net.socket, java.io.OutputStreamWriter.

We can't force clients to update their code to use Jboss Remoting.
JbossEsb should have a basicSocketListener which don't need Jboss Remoting.

The best solution, i can see for my study case is to implement an mbean with a socket listener which trigger with ServiceInvoker esbService.

I'll be much happier with a nearly "out of the box" solution , so if you have others clues, i'll be glad to see it.

Regards,
Jean Guyer

[beve]

Hi again,

I've been playing around with the JBossRemotingGatewayListener and saw the same exception you posted.
My problem was that I had a version missmatch between the server and client. I was using differerent versions of jboss-remoting.jar.

Could you verify that your client and server are using the same version?

/Daniel

[bcarothers]

Would there be value in adding a socket-listener that listened for connections on a port and then treated any input up to an EOF character of some sort as a single message which could then be sent through the bus?

It seems like it might solve this problem.