JMS 2.0 Support in WSO2 ESB

Introduction
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.






Workshop

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/run.sh with root privileges. [ sudo ./run.sh ]  
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 QueueConsumer.java [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 TopicConsumer.java [3] which will act as shared topic subscriber with the WSO2 ESB inbound listener.
Now run the TopicPublisher.java [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 TopicConsumer.java . ( the total number of consumed messages between inbound listener and TopicConsumer.java will be equal to the number of published messages by TopicPublisher.java )






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.
Conclusion
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.



References
[1] https://svn.wso2.org/repos/wso2/scratch/ESB/packs/5.0.0-Releases/5.0.0-M1/

Comments

Post a Comment

Popular posts from this blog

Introducing Java Reactive Extentions in to a SpringBoot Micro Service

Image
Introduction Today we are going to take a look at Reactive Programming using Java8 and RxJava, which is a library for composing asynchronous and event-based programs by using observable sequences. RxJava stands for Reactive Extensions for the JVM. It extends the observer pattern [Gamma95] to support sequences of data/events and adds operators that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety and concurrent data structures [1]. Pre-Requisites : Having a good knowledge about Java8, Functional Programming and spring boot microservices. What is Reactive programming? In essence, Reactive programming is an asynchronous programming paradigm concerned with data streams. The system time, a list of entries from the DB/API, user clicks, everything can be a stream of data. Data from different streams can easily be combined and transformed, and in the end processed/observed by the
Read more

Optimal binary search trees

Image
Suppose that we are designing a program to translate text from English to French. For each occurrence of each English word in the text, we need to look up its French equivalent. We could perform these lookup operations by building a binary search tree with $n$ English words as keys and their French equivalents as satellite data. Because we will search the tree for each individual word in the text, we want the total time spent searching to be as low as possible. We could ensure an $Θ(log_2 \;n)$ search time per occurrence by using a red-black tree or any other balanced binary search tree. Words appear with different frequencies, however, and a frequently used word such as the may appear far from the root while a rarely used word appears near the root. Such an organization would slow down the translation, since the number of nodes visited when searching for a key in a binary search tree equals one plus the depth of the node containing the key. We want words that occur frequently in the t
Read more

Combining the emissions of multiple Observables together using RxJava Zip operator in a Spring Boot Micro service

Image
Introduction Well, today we are going to discuss an advanced RxJava operator called Zip. Let’s first take a look at the zip operator at a glance and then move on to a real world example that leverages the capabilities of the operator. In fact, zip is a very powerful and useful operator provided in the RxJava library. Prerequisites : Good knowledge of Java8, Functional Programming, RxJava, Spring Boot, Microservices. User Level : Advanced Since this is an advanced article, I am not going to walk you through the basics of RxJava or Spring Boot microservices. If you need to get some basic understanding of RxJava, I thoroughly recommend you to go through one of my previous blog posts [1] [2] or any other good introductory article about RxJava. If you need to learn more about Spring Boot microservices please go through some of the spring tutorials which are really comprehensive and impressive. RxJava Zip Operator Combines the emissions of multiple Observables together via a speci
Read more