Stomp is a text-orientated wire protocol that allows Stomp clients to communicate with Stomp Brokers.
Stomp clients are available for several languages and platforms making it a good choice for interoperability.
HornetQ provides native support for Stomp. To be able to send and receive Stomp messages, you must configure a NettyAcceptor with a protocol parameter set to stomp:
<acceptor name="stomp-acceptor"> <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class> <param key="protocol" value="stomp"/> <param key="port" value="61613"/> </acceptor>
With this configuration, HornetQ will accept Stomp connections on the port 61613 (which is the default port of the Stomp brokers).
See the stomp example which shows how to configure a HornetQ server with Stomp.
Stomp clients deals with destinations when sending messages and subscribing. Destination names are simply strings which are mapped to some form of destination on the server - how the server translates these is left to the server implementation.
In HornetQ, these destinations are mapped to addresses and queues. When a Stomp client sends a message (using a SEND frame), the specified destination is mapped to an address. When a Stomp client subscribes (or unsubscribes) for a destination (using a SUBSCRIBE or UNSUBSCRIBE frame), the destination is mapped to a HornetQ queue.
As explained in Chapter 9, Mapping JMS Concepts to the Core API, JMS destinations are also mapped to HornetQ addresses and queues. If you want to use Stomp to send messages to JMS destinations, the Stomp destinations must follow the same convention:
send or subscribe to a JMS Queue by prepending the queue name by jms.queue..
For example, to send a message to the orders JMS Queue, the Stomp client must send the frame:
SEND destination:jms.queue.orders hello queue orders ^@
send or subscribe to a JMS Topic by prepending the topic name by jms.topic..
For example to subscribe to the stocks JMS Topic, the Stomp client must send the frame:
SUBSCRIBE destination:jms.topic.stocks ^@
Stomp is mainly a text-orientated protocol. To make it simpler to interoperate with JMS and HornetQ Core API, our Stomp implementation checks for presence of the content-length header to decide how to map a Stomp message to a JMS Message or a Core message.
If the Stomp message has a content-length header, it will be mapped to a JMS TextMessage or a Core message with a single nullable SimpleString in the body buffer.
Alternatively, if the Stomp message does not have a content-length header, it will be mapped to a JMS BytesMessage or a Core message with a byte in the body buffer.
The same logic applies when mapping a JMS message or a Core message to Stomp. A Stomp client can check the presence of the content-length header to determine the type of the message body (UTF-8 String or bytes).
HornetQ also support Stomp over Web Sockets. Modern web browser which support Web Sockets can send and receive Stomp messages from HornetQ.
To enable Stomp over Web Sockets, you must configure a NettyAcceptor with a protocol parameter set to stomp_ws:
<acceptor name="stomp-ws-acceptor"> <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class> <param key="protocol" value="stomp_ws"/> <param key="port" value="61614"/> </acceptor>
With this configuration, HornetQ will accept Stomp connections over Web Sockets on the port 61614 with the URL path /stomp. Web browser can then connect to ws://<server>:61614/stomp using a Web Socket to send and receive Stomp messages.
The stomp-websockets example shows how to configure HornetQ server to have web browsers and Java applications exchanges messages on a JMS topic.
StompConnect is a server that can act as a Stomp broker and proxy the Stomp protocol to the standard JMS API. Consequently, using StompConnect it is possible to turn HornetQ into a Stomp Broker and use any of the available stomp clients. These include clients written in C, C++, c# and .net etc.
To run StompConnect first start the HornetQ server and make sure that it is using JNDI.
Stomp requires the file jndi.properties to be available on the classpath. This should look something like:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://localhost:1099 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
Make sure this file is in the classpath along with the StompConnect jar and the HornetQ jars and simply run java org.codehaus.stomp.jms.Main.