your control. Hence, JMS would be better for the integration of internal solutions of a
The latest improvements in action
Released in March 2002, the JMS 1.1 Specification was getting old and heavy com-
pared to other APIs of the Java EE platform that have been simplified through the
evolution of the platform. Based on this observation, you will understand why one of
the main goals of JMS 2.0 API was to update the API so that it can be as simple as
the other APIs of the platform and can integrate easily with them. To make this pos-
sible, several areas have been reviewed; these include the reduction of boilerplate
code, removing redundant items, adding new features, and integration of the novel-
ties of the Java language.
In the JMS 2.0 Specification, three new features are highlighted: sending of mes-
sages asynchronously, delivery delay, and modification of the JMSXDeliv-
eryCount message property.
Sending messages asynchronously
In synchronous processing, if a method A invokes a method B, method A will remain
blocked until the method B has completed. This can induce a waste of time. To over-
come this problem, JMS 2.0 provides a set of methods to send messages asyn-
chronously without losing sight of the progress of the operation. The following code
demonstrates how to send messages asynchronously. The method setAsync()
takes a listener as a parameter, which allows you to be informed at the end of the
process or when an exception is thrown. If the listener is not null, the message will
be sent asynchronously (the process will be performed by another thread different
from the caller's thread). Otherwise, the message will be sent synchronously.
try(JMSContext context =