In the last chapter, we learned how to create web services in JEE. We learned to create both RESTful and SOAP-based web services. In this chapter, we will learn how to work with messaging systems in JEE. Thus far, we have seen examples of clients making requests to the JEE server and waiting till the server sends a response back. This is the synchronous model of programming. This model of programming may not be suitable when the server takes a long time to process requests. In such cases, a client might want to send a request to the server and return immediately without waiting for the response. The server would process the request and somehow make the result available to the client. Requests and responses in such scenarios are sent through messages. Furthermore, there is a message broker that makes sure that messages are sent to the appropriate recipients. This is also known as a message-oriented architecture. The following are some of the advantages of adopting a message-oriented architecture:

• It can greatly improve the scalability of the application. Requests are put in a queue at one end, and at the other end there could be many handlers listening to the queue and processing the requests. As the load increases, more handlers can be added, and when the load reduces, some of the handlers can be taken off.
• Messaging systems can act as glue between disparate software applications. An application developed using PHP can put a JSON or XML message in a messaging system, which can be processed by a JEE application.
• It can be used to implement an event-driven program. Events can be put as messages in a messaging system, and any number of listeners can process events at the other end.
• It can reduce the impact of system outages in your application because messages are persisted till they are processed.

There are many enterprise messaging systems, such as Apache ActiveMQ (http://activemq.apache.org/), RabbitMQ (https://www.rabbitmq.com/), and MSMQ (https://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx). The Java Messaging Service (JMS) specification provides a uniform interface for working with many different messaging systems. JMS is also a part of the overall Java EE specifications. Refer to https://javaee.github.io/tutorial/jms-concepts.html#BNCDQ for an overview of JMS APIs.

There are two types of message containers in any messaging system:

• Queue: This is used for point-to-point messaging. One message producer puts a message in a queue, and only one message consumer receives the message. There can be multiple listeners for a queue, but only one listener receives the message. However, the same listener doesn't necessarily get all the messages.
• Topic: This is used in the publish-subscribe type of scenario. One message producer puts a message in a topic, and many subscribers receive the message. Topics are useful for broadcasting messages.

We will cover the following topics:

• Sending and receiving messages to and from queues and topics using JMS APIs
• Creating JMS applications using JSP, JSF, and CDI beans
• Consuming messages using MDBs (message-driven beans)

We will see examples of how to use queues and topics in this chapter. We will use a GlassFish Server, which has a built-in JMS provider. We will use JMS APIs to implement a use case in the Course Management application, the same application that we have been building in the other chapters of this book.