JMS 2.0 with WSO2 ESB (Part I)

Introduction

In today’s connected environment, software applications should posses the ability to send and receive messages in order to maintain the communication. Having a separate entity to handle the intermediary role in message passing has become quite popular lately, because it gives the advantage of asynchronicity to the communication.

This pattern is often referred as Message Oriented Middleware. And this has become an essential in current online business environment. If we try to simplify this abstract concept, we can see this as a set of messaging clients (message senders and receivers) connected to one central message handling server (message broker) where all the message routing happens. In general, there are mainly two types of message routing that can take place,

  1. Point-to-Point (PTP) messaging
  2. Publish-Subscribe (Pub/Sub) messaging

Since this concept often used in software applications, we can understand the advantage that it can gain by having a common standard methodology (an API) to send and receive messages between message brokers and clients. Because there can be different types of message brokers and different types of underlying data communication layer implementations. Having a standard messaging API would give more flexibility and portability to the software client, where it can switch between different communication implementations without any extra effort.

Basically, this is what JMS is all about. JMS introduces a common API for Java software clients to follow in order to communicate with intermediate message handling servers. There are many message brokers that support JMS, including ActiveMQ, IBM MQ, HornetQ, WSO2 MB etc. Any Java application can connect to any of these message brokers using the standard JMS API without worrying about product-specific implementations. Switching between these message brokers is just a matter of changing few parameters.

From then to new, JMS has improved its API through three version updates.

JMS API Versions

  • JMS 1.0.2b (June 25, 2001) — Introduces two domain-specific APIs for PTP model and for pub/sub model while satisfying most basic communication requirements.
  • JMS 1.1 (April 12, 2002) — Introduces single message communication API (classic API) for both messaging models and including many extra features over initial JMS version. For more information: [1]
  • JMS 2.0 (May 21, 2013) — Introduces a simplified API to reduce the amount of code that should be written by a user when compares with the earlier APIs. Also it come with some new features as well. But creators has mentioned that JMS users are free to use both classic and simplified APIs (all the features will be the same) and the only difference will be the amount of code that should be written.

Using with ESB

Early versions of WSO2 Enterprise Service Bus (ESB) supports JMS 1.1 API and since WSO2 ESB 5.0.0[1] they have included the JMS 2.0 support. With this introduction, three new features were added to the existing JMS feature set.

  1. JMS Delivery Delay
  2. JMS Shared Topic Subscription
  3. JMS Message Delivery Count

JMS Delivery Delay

The idea behind the JMS delivery delay features is, messages that are sent to the JMS message broker won’t be forwarded to the message consumer until the given delay timeout is elapsed. This delivery delay is set at the Message Producer level, therefor every message that is being sent using this particular Message Producer will be delayed for the specified time interval.

Following sample explains how you can set and observe the delivery delay on WSO2 ESB JMS transport sender. I am using HornetQ for the testing purpose.

  1. Configuring WSO2 ESB for HornetQ with JMS 2.0

Please refer here [2]

2. Configuring WSO2 ESB for the Sample

  • Update the following in the ESB_HOME/repository/conf/axis2/axis2.xml
  • Start the WSO2 ESB
  • Create the following WSO2 ESB Sequence
  • Create the following WSO2 ESB Proxy

This configurations will create a sequence (delayed) and a proxy service (JMSDelivery). Proxy service will directly forward the message to the endpoint and another copy will be passed on to delayed sequence, which will send the message to the same endpoint but with the Delivery Delay is set to 10s.

  • Run the QueueConsumer.java which will consume messages from the queue.
  • Run the following command to invoke the proxy service.
ant stockquote -Daddurl=http://localhost:8280/services/JMSDelivery -Dmode=placeorder -Dsymbol=MSFT

Observation

QueueConsumer will receive two messages, (two copies of the same message) and the time difference in receiving those two messages will be 10s.

References

[1]. http://wso2.com/products/enterprise-service-bus/

[2]. https://docs.google.com/document/d/1UJ_cObagC8d3HFyH17hxf7R0SOI_7blBMyQMS9M83vg/edit?usp=sharing