In 2002 came out the first stable version of JMS version 1.1. More than a decade later, the specification has become widely used and today there are multiple implementations of open-source and commercial time.
Yet in eleven years, many vendors have developed new capabilities over those provided by JMS.
Now the JMS 2.0 was finally released on 21 May 2013, Let's look at all the new features :
- DeliveryDelay
A property named DeliverDelay will be added in the JMS message header. This will enable a producer to specify a time interval before a message is delivered to a customer.
This property can be useful in delayed treatment, at the end of the day, for example.
- Sending a message asynchronously
The client calls the method send() and the API makes her hand once the message has been sent successfully. With version 2.0, it will be possible to call this method asynchronously and have the hand immediately. The API then invoke a callback onAcknowledge () to indicate that the message has been sent.
The decision to use this feature will be on a case by case basis. My service of sending he needs to be more scalable as possible? Am I able to replay a flow error if it is detected asynchronously?
- JMSXDeliverCount becomes mandatory
The JMSXDeliverCount property to specify the number of times that a message must be delivered was optional in version 1.1. It becomes mandatory with version 2.0.
This non backward compatibility only affects the JMS provider, customers themselves are not affected by this change.
- Hierarchy of topics
A very interesting feature is the possibility to prioritize topics.
Suppose we have the following four topics:
CLIENTS.FRANCE.ACHAT
CLIENTS.FRANCE.VENTE
CLIENTS.USA.ACHAT
CLIENTS.USA.VENTE
It will be possible to use patterns for subscription JMS clients.
If you want to subscribe to all topics relating to French customers:
CLIENTS.FRANCE. *
Or all purchases:
CUSTOMERS. *. PURCHASE
This feature uses very well require the use of good governance to manage the naming of topics and types of data conveyed.
- Multiple customers on the same durable subscriber
Currently on a JMS queue, it is possible to have multiple consumers. The JMS provider use an algorithm to round-robin for load-balancing between the different customers.
But for JMS topics, it is not currently possible to have only one consumer in sustainable subscriber.
With version 2.0 it is possible to connect multiple clients on the same durable subscriber. The mechanism of round-robin will be also applicable to the topics to allow for better scalability.
- Batch mode
Although already implemented by some providers as webMethods JMS Broker, this feature will receive messages in batch mode. Namely the receipt by a JMS client several messages at once.
In 1.1, we had the following method:
void onMessage (Message message);
In 2.0 we have:
void onMessages (Message [] message);
Conclusion
JMS 2.0 proposes some very useful new features. The API will be greatly simplified and it will also allow the use of CDI for dependency injection.
Yet in eleven years, many vendors have developed new capabilities over those provided by JMS.
Now the JMS 2.0 was finally released on 21 May 2013, Let's look at all the new features :
- DeliveryDelay
A property named DeliverDelay will be added in the JMS message header. This will enable a producer to specify a time interval before a message is delivered to a customer.
This property can be useful in delayed treatment, at the end of the day, for example.
- Sending a message asynchronously
The client calls the method send() and the API makes her hand once the message has been sent successfully. With version 2.0, it will be possible to call this method asynchronously and have the hand immediately. The API then invoke a callback onAcknowledge () to indicate that the message has been sent.
The decision to use this feature will be on a case by case basis. My service of sending he needs to be more scalable as possible? Am I able to replay a flow error if it is detected asynchronously?
- JMSXDeliverCount becomes mandatory
The JMSXDeliverCount property to specify the number of times that a message must be delivered was optional in version 1.1. It becomes mandatory with version 2.0.
This non backward compatibility only affects the JMS provider, customers themselves are not affected by this change.
- Hierarchy of topics
A very interesting feature is the possibility to prioritize topics.
Suppose we have the following four topics:
CLIENTS.FRANCE.ACHAT
CLIENTS.FRANCE.VENTE
CLIENTS.USA.ACHAT
CLIENTS.USA.VENTE
It will be possible to use patterns for subscription JMS clients.
If you want to subscribe to all topics relating to French customers:
CLIENTS.FRANCE. *
Or all purchases:
CUSTOMERS. *. PURCHASE
This feature uses very well require the use of good governance to manage the naming of topics and types of data conveyed.
- Multiple customers on the same durable subscriber
Currently on a JMS queue, it is possible to have multiple consumers. The JMS provider use an algorithm to round-robin for load-balancing between the different customers.
But for JMS topics, it is not currently possible to have only one consumer in sustainable subscriber.
With version 2.0 it is possible to connect multiple clients on the same durable subscriber. The mechanism of round-robin will be also applicable to the topics to allow for better scalability.
- Batch mode
Although already implemented by some providers as webMethods JMS Broker, this feature will receive messages in batch mode. Namely the receipt by a JMS client several messages at once.
In 1.1, we had the following method:
void onMessage (Message message);
In 2.0 we have:
void onMessages (Message [] message);
Conclusion
JMS 2.0 proposes some very useful new features. The API will be greatly simplified and it will also allow the use of CDI for dependency injection.
