JMS 2.0 Support in WSO2 ESB

JMS is a messaging API implemented to communicate between two or more java clients using an enterprise messaging system. Java client components can use JMS API to communicate with other distributed Java clients while maintaining a loosely coupled, asynchronous connection. Therefor JMS API is well known and most often used as a message communication methodology.

JMS 1.1 was introduced in 2002 and it remained unchanged until 2013, wherein the JMS 2.0 was introduced. In order to cater for todays message communication requirements, JMS 2.0 address many issues and shortcomings that was there with 1.1. Mainly JMS 2.0 introduces a simplified API in order to reduce the amount of code that needs to be written by the programmer. Even though the code lines are reduced, all the classic API functionalities are still available with JMS 2.0 simplified API. ( with JMS 2.0 programmer can decide which API to use classic or simplified, because both are available with JMS 2.0) But more than that, JMS 2.0 supports for many extra functionalities that were not available with 1.1. More details on these extra features are given below.

What’s new in JMS 2.0
  • Shared Subscription
This can be considered as one of the main features introduced with JMS 2.0. For a moment let's assume that you have subscribed to a JMS topic with multiple JMS consumers. If a message comes to that topic, multiple copies of that message will be forwarded to each of the consumer of the topic. In earlier there was not a way to share the messages between consumers that comes to the topic.

If clients use shared subscription feature in JMS 2.0 the message will be forwarded to only one of the consumers. (consumers will share the messages that comes to the topic ) Main advantage of this is to share workload between consumers.

Fig.1: Traditional Message Subscribing

Fig. 2: JMS 2.0 Shared Subscribers

  • Delivery Delay
Delivery delay can be added to the JMS Producer so that the publisher will not deliver the message until that time interval is elapsed.
  • JMSX Delivery Count

This property allows the message consuming application to know how many times a particular messages has been redelivered. Identifying such scenarios can be very important to administrative purposes.


Configuring ESB with HornetQ to support JMS 2.0

Configuring the WSO2 ESB

  • Download the ESB 5.0.0 pack from here [1]

Configuring and starting the HornetQ message broker

  • HornetQ can be downloaded from here [2]
  • Extract the .tar.gz and move into <HornetQ_HOME>/config/stand-alone/non-clustered/
Add the following to the hornetq-jms.xml

  • Now, start the HornetQ broker.
Linux: Run the file <HornetQ_HOME>/bin/ with root privileges. [ sudo ./ ]  
Client Application
You may also need to download the sample client application from the location [3].

JMS 2.0 Feature : Message Delivery Delay
This document explains how to configure WSO2 ESB Transport sender with the JMS 2.0 feature, Delayed Delivery.

Configure the WSO2 ESB for HornetQ MB
  • Update the following in the ESB_HOME/repository/conf/axis2/axis2.xml
  • Then start the ESB server and copy the following proxy configuration into the source view.

Then Run the [2] which will consume messages from the queue which the two proxy servers are producing.

Execute the following curl command with the payload given in [4] in order to send a request to the proxy service. This proxy service will place a placeOrder message in the JMS queue named ‘mySampleQueue’.

curl -v -d @placeOrder.xml -H "Content-Type: text/xml; charset=utf-8" -H "SOAPAction:urn:placeOrder" http://localhost:8280/services/JMSDeliveryDelayed

Then the client application will retrieve that message and consumes it.

You may notice that the client application consumes the message after around 10 seconds. This is because the publisher will not deliver the message until that time interval is elapsed.

JMS 2.0 Feature : Shared Topic Subscription
WSO2 ESB inbound listener can be configured as a shared topic listener with JMS 2.0. This example explains how to do it with hornetq message broker.

Copy the following synapse configuration into the source view of your ESB.

Run the [3] which will act as shared topic subscriber with the WSO2 ESB inbound listener.

Now run the [2] which will publish 5 messages to the HornetQ topic.

Observation :
Since there are two shared subscribers are configured, those 5 messages will be shared between inbound listener and . ( the total number of consumed messages between inbound listener and will be equal to the number of published messages by )

JMS 2.0 Feature : JMSXDeliveryCount
In JMS, there is a special property in to indicate the number of times the message got (re)delivered. Even though this feature existed before JMS 2.0, setting it was not mandatory in earlier version. But in JMS 2.0, JMS provider must set JMSXDeliveryCount value in messages.

This value can be retrieved from WSO2 Synapse configuration (using property mediator), and it will be helpful in administration purposes.

Start the WSO2 ESB using following configuration which will create an Inbound Endpoint to the JMS broker and simple sequences to log the message status with JMSXDeliveryCount value.   

Copy the following synapse configuration into the source view of the ESB.

You may see the following log message in the ESB console.
INFO - LogMediator To: , MessageID: ID:60868ca5-d174-11e5-b7de-f9743c9bcc9e, Direction: request, DeliveryCounter = 1

If the delivery count is more than one, then you can send this to a Dead Letter Channel (DLC) queue.

That concludes another session in which we covered a lot of ground about JMS 2.0 features in WSO2 ESB 5.0.0. We started explaining new JMS 2.0 features which were introduced in ESB 5.0, their usecases and a workshop session covering those concepts in a practical manner. I'll see you in the next blog post.



Popular posts from this blog

WSO2 ESB Worker Manager Cluster without a Load Balancer

XML to XML transformation via Smooks Mediator in WSO2 ESB

SSL Debugging in WSO2 ESB