Author Avatar

Pradeep Mishra


Share post:

Why We Need JMS?

Remote procedure call (RPC) systems, including Java RMI, are synchronous — the caller must block and wait until the called method completes execution, and thus offer no potential for developing loosely coupled enterprise applications without the use of multiple threads. In other words, RPC systems require the client and the server to be available at the same time. However, such tight coupling may not be possible or desired in some applications. Message-Oriented Middleware (MOM) systems provide solutions to such problems. They are based on the asynchronous interaction model and provide the abstraction of a message queue that can be accessed across a network. Note, however, that messaging here refers to asynchronous requests or events that are consumed by enterprise applications and not humans as in electronic mail (email). These messages contain formatted data that describe specific business actions.

Java Message Service is an API that supports the formal communication called messaging between computers on a network. JMS provides a common interface for standard message protocols and message services in support of the Java programs.

The Java Message Service (JMS) was designed to make it easy to develop business applications that asynchronously send and receive business data and events. It defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products.

JMS provides the facility to create, send and read messages. The JMS API reduces the concepts that a programmer must learn to use the messaging services/products and also provides the features that support the messaging applications.
JMS helps in building the communication between two or more applications in a loosely coupled manner. It means that the applications which have to communicate are not connected directly they are connected through a common destination.

JMS Components

A typical JMS system contains the following components:

  1. JMS Client: Java program used to send (or produce or publish) or receive (or consume or subscribe) messages.
    • JMS Sender: JMS Client which is used to send messages to the destination system. JMS sender is also known as JMS Producer or JMS Publisher.
    • JMS Receiver: JMS Client which is used to receive messages from the Source system. JMS Receiver is also known as JMS Consumer or JMS Subscriber.
  2. JMS Provider: JMS API is a set of common interfaces, which does not contain any implementation. JMS Provider is a third-party system that is responsible to implement the JMS API to provide messaging features to the clients. JMS Provider is also known as MOM (Message Oriented Middleware) software or Message Broker or JMS Server or Messaging Server. JMS Provider also provides some UI components to administrate and control this MOM software.
  3. JMS Administered Objects: JMS Objects that are preconfigured by an administrator for the use of JMS clients. They are ConnectionFactory and Destination Objects.
    • ConnectionFactory: ConnectionFactory object is used to create a connection between Java Application and JMS Provider. It is used by the application to communicate with the JMS provider.
    • Destination: Destinations are also JMS Objects used by a JMS Client to specify the destination of messages it is sending and the source of messages it receives. There are two types of Destinations: Queue and Topic.
  4. JMS Message: an object that contains the data being transferred between JMS clients.

In the above diagram, the JMS provider implements the JMS API. It is the entity with which the JMS client interacts. The JMS client establishes a connection and a session through which the interaction takes place. The JMS client establishes the connection based on configuration information in the connection factory and identifies where a message is to be sent to or retrieved from based on the destination. Both the connection factory and destination objects are listed in the Java Naming and Directory Interface (JNDI) namespace. JNDI is the Java industry-standard API for accessing naming and directory services. Since the connection factory and destination are administered objects by JNDI, it means the JMS client can connect to different JMS providers without changing the JMS client code; that is, it creates portability. It also means that attributes that often can and do change dynamically such as the destination can be changed independently of the JMS client code.

Message Delivery Models

JMS supports two different message delivery models:

  1. Point-to-Point (Queue destination): In this model, a message is delivered from a producer to one consumer. The messages are delivered to the destination, which is a queue, and then delivered to one of the consumers registered for the queue. While any number of producers can send messages to the queue, each message is guaranteed to be delivered and consumed by one consumer. If no consumers are registered to consume the messages, the queue holds them until a consumer registers to consume them.
  2. Publish/Subscribe (Topic destination): In this model, a message is delivered from a producer to any number of consumers. Messages are delivered to the topic destination, and then to all active consumers who have subscribed to the topic. In addition, any number of producers can send messages to a topic destination, and each message can be delivered to any number of subscribers. If there are no consumers registered, the topic destination doesn’t hold messages unless it has a durable subscription for inactive consumers. A durable subscription represents a consumer registered with the topic destination that can be inactive at the time the messages are sent to the topic.

JMS Advantages

  • Loosely Coupled: We can develop loosely coupled applications very easily. That means JMS API is a standard or specification that should be implemented by all JMS Providers so that we can change the existing JMS Provider to a new JMS Provider with few changes (that means only configurations) or without changing our JMS Application code.
  • Asynchronous: We can develop asynchronous messaging applications very easily. That means JMS Sender can send messages and continue on its own work. It does not wait for the completion of message consumption by the JMS Receiver.
  • Robust and Reliable: JMS ensures that a message is delivered one and only once to the destination system. So we can develop reliable applications very easily.
  • Interoperability: JMS API allows Interoperability between other Java Platform languages like Scala and Groovy.

Most popular JMS Providers

S.No.JMS Provider SoftwareOrganization
1.WebSphere MQIBM
2.Weblogic MessagingOracle Corporation
3.Active MQApache Foundation
4.Rabbit MQRabbit Technologies(acquired by Spring Source)
6.Sonic MQProgress Software
8.Open MQOracle Corporation
9.SonicMQAurea Software


JMS API is a robust way to implement a messaging system in our applications. There are various popular JMS providers including AMQP from Spring framework.

I hope you have enjoyed this post and it helped you to understand JMS on high level. Please like and share and feel free to comment if you have any suggestions or feedback.

Different ways of implementing Singleton Design Pattern in Java
Java Message Service (JMS) programming model


Leave a Reply