WSO2TORIAL: WSO2ESB send message to a JMS endpoint (example for ActiveMQ)

Message queues are part and parcel of a modern ICT landscape, for instance it is hard to imagine a dead letter channel without the use of a message queue.

Of course WSO2ESB supports message queues and the JMS transport.  If you want to make use of the JMS transport (Java Message Service) within WSO2ESB you need to extend the configuration of the ESB. All transports in the WSO2ESB  are configured in the axis2 configuration file.

But few people know that you can directly use the JMS transport layer (and not go through a message store) in order to write a message to a queue.

In this blog we will show you how to do that and move the transport information to the configuration file, rather than keep it in the proxy. This will allow smoother deployment to different environments.

Senders and Receivers

Be reminded that Axis2 Transports come in pairs (Sender and Receiver) so when you want to send and receive JMS messages, please uncomment both. There is support for a number of JNDI supported brokers so uncomment the listener that corresponds with the broker you want to use. In some cases, e.g. ActiveMQ or Tibco EMS some JAR files need to be copied to the repository/components/lib directory. Which JARs exactly depend on the version of the message broker that you are using.

But for this article we are keeping it simple and will change the transport sender only and of course copy the required files to the lib directory (as indicated in the previous paragraph.you only need to enable the following line in the configuration:

(This configuration can be found in:  repository/conf/axis2/axis2.xml)

After doing this configuration you will be able to send message on the following way inside a proxy.(example to ActiveMQ)

As you can see, the uri is quite long and points to the messagebroker and the transport in use. 

Deploying to different environments

 As you can see all the configuration for the connection to the queue is inside this endpoint.

This means if you do releases to different stages (development, testing, acceptance, production) of the project the configuration needs to be modified. This way of working it makes it difficult to create one deployable artifact for the different environments.

 Solution for this is to modify the axis2.xml and extend the <transportSender> configuration. In the following example the configuration of the endpoint is moved to the ESB configuration. This makes it possible to move the deployable artifact to the different stages (development, testing, acceptance, production).

However, this also means that you can only use one messagebroker since this is shared between tenants.

After modify the axis2.xml configuration, the endpoints inside the proxy can be made as followed:

In here we can see that the “transport.jms.ConnectionFactory” is referring to the created configuration myQueueConnectionFactory no connection related information is in this endpoint anymore.

When deploying it to a different environment (e.g. TEST) the parameters are taking from the AXIS2.xml file which of course is pointing to a different environment than the DEV environment.

Thanks to Rob Blaauboer for his contribution to this blog.

If you would like to read more about WSO2esb (sometimes spelled as WS02) see our WSO2 tutorial page for tips and tricks for wso2 and to read another WSO2 esb tutorial. For WSO2 ESB training you can have a look at our WSO2 training page. If you are interested in WSO2 operational support or want to know more about a WSO2 ESB license feel free to contact us anytime. As open source integration specialist we are more then happy to help you.

WSO2TORIALS help you to change, update or improve WSO2 products and are based on our experiences with the products. WSO2TORIALS will guide you step by step with minimal knowledge required.