Silvio D'Alessandro
03. April 2017
5 min

Point-To-Point messaging with JMS 2.0 API

The following blog post describes how to set up a minimal Java Messaging Service (JMS) example while using new features of the JMS API (Version 2.0) in a JavaEE 7 environment.

In order to successfully rebuild this example on your own I recommend you have the following software installed:

  • Eclipse
  • Java 7 or higher
  • Glassfish

Prerequisites

I won’t show up how to configure your project and set up your application server. This blog post just focuses on understanding some of the JMS API features and how to use them. So make sure that you have your project and application server already configured before you start.

Understanding the JMS 2.0 API Programming Model

As mentioned in the title of the blog post, I would like to show up how to send and receive messages using the JMS 2.0 API. This is what the JMS 2.0 API Programming Model looks like:

The big difference to the previous JMS API is located in the center of the picture. There now is an interface called ‘JMSContext’ which comes with a bunch of convenient features and bundles the ‘Connection’ and the ‘Session’ interfaces. One of these features is the AutoClosable functionality, which means that you do not have to close the connection by yourself (this often lead to errors). That said it is a more elegant and slenderized way of coding as the following piece of code demonstrates:

// JMS 2.0 and above

// before JMS 2.0

Another improvement of the new API is that the JMSContext handles exceptions of connections and sessions internally. So there has been removed a lot of boilerplate code. The JMSContext also can be used to create both, message consumer and message producer, which are responsible for sending and receiving messages.

Point-To-Point domain model and JMS Resources

As the goal is to build a Point-To-Point JMS application, let’s first take a look at the respectively domain model:

So it is necessary to have a queue where all messages are sent to and from where you can receive those messages. That’s where a JMS Resources comes into play. A JMS Resource can be one of the following:

  • Admin Object Resource
    • Queue
    • Topic
  • Connector Resource
    • QueueConnectionFactory
    • TopicConnectionFactory
    • ConnectionFactory

How all this fits together we will see later. First let’s do some coding!

Create the Message Producer

As a first step create a java class, which will send the messages to the queue. Let’s call it Message Producer. The MessageProducer class contains the following code:

The MessageProducer is a stateless EJB which has two necessary fields:

  • JMSContext
  • Queue

Using Context and Dependency Injection (CDI) on the JMSContext allows you to focus on your main purpose – creating and sending messages. So we use the JMSContext to create a producer and send the message to the queue.

The @Resource annotation gives you the possibility to map the field to the queue where all messages will be sent.

 
Create the Message Consumer

Now that the code is able to send messages to the queue you need another class that is able to receive those messages. Let’s call that class MessageConsumer. The MessageConsumer class contains the following code:

The MessageConsumer looks very similar to the MessageProducer. It is a stateless EJB and uses the JMSContext and the queue with the appropriated annotations as well. It has one method, which is used to receive the messages that were sent to the queue. In order to receive them, it creates a consumer by using the JMSContext and uses the queue as its destination.

 
Make things work

As both classes inject the JMSContext we must enable CDI. In order to do this, just create a file called ‘beans.xml’ (depends on your CDI version). This file has to be located in ‘Java Resources/src/main/webapp/META-INF/’ and can be empty. Furthermore you need some kind of code that links all that stuff you did before. It could be look as follows:

There are several things we are doing here:

  1. Define a JMS Destination
  2. Create a URI where the logic can be called (/TestServlet)
  3. Use the MessageProducer and MessageConsumer as EJBs
  4. Call the code

The interfaceName specified belongs to one of the possible Admin Object Resource mentioned earlier (here: queue). The name attribute contains besides the portable Java Naming and Directory Interface (JNDI) (java:app)  a simple name for the resource. The destinationName is self-explanatory.

Using the @WebServlet annotation allows you to map every incoming request on ‘/TestServlet’ to this servlet.

As you annotated the MessageProducer and the MessageConsumer with @Stateless it is possible to get an EJB instance of the classes with the @EJB annotation so you don’t have to create those instances on your own.

The ‘doGet’ method is called on every ‘GET’ request of a client. When called, the message producer sends a message to the queue which is than received by the message consumer. The received message is printed to the console afterwards.

Run the application

As a last step you just have to deploy your application to the application server, start it and call the ‘TestServlet’ URI. Then you should see the result in the console of your IDE:

 

Comment article