Deep dive into Java Message Service

Java Message Service (JMS) is an API which facilitates loosely coupled and asynchronous message transferring between platform independent applications. Similar to Java DataBase Connectivity (JDBC) which lies between a Java application and database to enable data transactions, JMS resides between Applications, run in different JVMs to enable data transactions.

A design that comprised of JMS can be decomposed into four main components such as,

• Client ➡️ JMS Client could be a Java application which consumes or generates messages (Either a JMS Sender or JMS Receiver)
• Provider ➡️ JMS Provider is a messaging entity to handle messages from JMS client. It functions as a broker between JMS Sender and JMS Receiver.
• Message ➡️ JMS Message is an entity that gets transferred with applications
• Administered Objects ➡ There are some JMS objects involved in JMS communication such as connection factory and destinations which are generated by administrative tool.

Message transferring can be enabled in two models using JMS. They are,
1. Point-to-point model
2. Publish-Subscribe model

Point-to-point model (P2P) : This model facilitates one-to-one message delivery by having a queue as a virtual channel in the middle (Figure 1).

Figure 1. Point-to-point message transmission in JMS ( Fire and Forget model)

Queue is the destination for message producers. Consumer consumes particular message from queue. P2P model provides an asynchronous as well as ordered message delivery. Two types of communication models can be implemented with P2P JMS model such as,

• Fire and Forget model ( One way communication model)

It’s the simplest model of communication with complete isolation between producer and consumer. Producer sends message to queue and not expecting any response or acknowledgement back. Producer does not give attention to whether or not the customer received the message.

• Dual channel model ( Request-Reply model)

Figure 2. Dual channel communication model in JMS

A simple dual channel model (Figure 2) consists of two queues; one for storing requests and the other for storing responses. Producer sends request message to request-queue and waits for response from response-queue. Consumer waits until receiving a request from request-queue then sends back a response to response-queue.

Publish-Subscribe model : This model enables one-to-many and many-to-one messaging pattern in addition to P2P model. Topic is configured as JMS destination where producers generate messages with topics. Consumers get subscribed to topics. All consumers subscribed to a certain topic receives the associated message from producer.

Where can it be used

We will look into a simple real-world scenario where JMS can be utilized. Let’s assume, we are providing online shopping app. When customers place their order, some information should get saved to database at the same time, some should be sent back as mail to confirm the customer’s order. If we used JMS here, even if the servers (ex: mailing server) are being down while placing order, message will be stored in queue and get delivered when servers are up. If it is a conventional message transmission without queues customer info tend to get lost and cannot request them to place the order again. 😃