Java/Jakarta Message Service (JMS)

Let’s learn JMS first to set the groundwork for learning ActiveMQ later on.

Introduction

JMS is a standard specification that defines a set of interfaces and protocols for reliable and asynchronous messaging.

It provides a way for applications to communicate with each other without knowing the details of the underlying communication protocols, such as TCP/IP or HTTP.

JMS provides a standard way for clients to create, send, receive, and read messages, regardless of the messaging style used.

The latest JMS version is called Jakarta Message Service and is part of jakarta.jms package, and it contains tons of interfaces.

Understanding JMS

Imagine you have two applications:

• Application A produces some information
• Application B needs to use that information

The simplest way is: A directly calls B (like an API call).

This works, but it creates tight dependency:

• B must be running
• B must respond immediately
• If B is slow or down, A is affected
• A and B must agree on timing

As systems grow, this becomes fragile.

What JMS is

JMS is a way for applications to communicate without talking to each other directly.So instead of:

“Hey B, do this now”

Application A says:

“Here is a message for whoever needs it”

and leaves.

That message is stored in the middle, and:

• The receiver can process it later
• The sender doesn’t need to wait
• Both sides can run independently

Why this is important

This approach gives you freedom:

• Sender and receiver don’t need to run at the same time
• A slow receiver doesn’t slow down the sender
• Temporary failures don’t break the system
• You can scale sender and receiver separately

This is especially useful in real systems where:

• Traffic spikes
• Parts of the system go down
• Work needs to be done in the background

What JMS actually provides

JMS is not a product and not a server.

JMS is a common language for messaging, a set of rules everyone agrees on

It says:

• How messages are sent
• How messages are stored
• How messages are delivered
• What guarantees exist

Because everyone follows the same rules you can change the messaging vendor and your application code stays the same.

What sits in the middle

Between sender and receiver is a message system (often called a broker).

Its job is simple:

• Accept messages
• Hold them safely
• Deliver them when possible

JMS defines how applications talk to this system, not how the system is built.

Real-world examples

JMS is useful when:

• An order is placed and many things must happen later
• A payment is processed and notifications follow
• Logs, emails, or reports are handled in background
• Systems talk across teams or companies

JMS lets systems communicate by leaving messages instead of making calls.

Why JMS is standardized

Different companies build different messaging systems.

Without JMS:

• Each one has its own way
• Code becomes locked to one vendor

With JMS:

• Everyone follows the same communication rules
• Applications stay portable
• Long-term maintenance becomes easier

JMS is a Java standard that defines how applications exchange messages in a loosely coupled, message-based way.

It specifies the rules vendors must follow, while leaving the implementation details to them.

Developers program against the JMS APIs, so switching the messaging provider does not require changing application code.

Core Concepts

Key Concepts:

• ConnectionFactory: Creates connections to the JMS provider
• Connection: Represents an active connection to the messaging server
• Session: A single-threaded context for producing and consuming messages
• Destination: Where messages are sent (Queue or Topic)
• MessageProducer: Sends messages to a destination
• MessageConsumer: Receives messages from a destination

Messaging Models

Note that in a real-world scenario, you would typically create the producer and consumer in separate applications or threads, and use different destinations for different types of messages.

Point-to-Point (Queue): One sender, one receiver. Each message is consumed by exactly one consumer. Think of it like a task queue where workers pick up jobs.

Get Mayank Pant’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Publish-Subscribe (Topic): One sender, multiple receivers. Each message is delivered to all subscribed consumers. Like a newsletter where everyone gets a copy.

Message Types

JMS supports several message types:

• Message: The base interface, used for simple notifications without a body, often with only headers and properties
• TextMessage: Carries a java.lang.String as its payload, ideal for XML, JSON, or plain text.
• MapMessage: Stores name-value pairs, where names are Strings and values are Java primitives, accessed by name or sequentially.
• BytesMessage: Transports a stream of uninterpreted bytes, useful for binary data or interfacing with external systems.
• StreamMessage: A stream of primitive values (like int, double, boolean) in order, read sequentially.
• ObjectMessage: Contains a single, serializable Java object, making it easy to pass complex application data.

Acknowledgment Modes

When creating a session, you specify how messages are acknowledged:

• AUTO_ACKNOWLEDGE: The session automatically acknowledges a message once the listener successfully finishes processing it or after receive() returns.
• CLIENT_ACKNOWLEDGE: The consumer manually calls message.acknowledge() to confirm receipt; useful for batch processing or complex validation before marking as done.
• DUPS_OK_ACKNOWLEDGE: A "lazy" mode where the session acknowledges delivery later, potentially leading to duplicate messages but reducing overhead.
• SESSION_TRANSACTED: Message delivery and acknowledgment are tied to local JMS transactions, committing or rolling back together with other operations

Common JMS Providers

You’ll need a JMS provider implementation like Apache ActiveMQ, RabbitMQ, IBM MQ, or AWS SQS. The code remains largely the same regardless of provider.

Use Cases

JMS is great for asynchronous processing, decoupling microservices, handling background jobs, event-driven architectures, and ensuring reliable message delivery between systems.

Features of JMS

1. Messaging Models: JMS supports two messaging models, Publish-Subscribe and Point-to-Point.
   In Publish-Subscribe, messages are broadcasted to multiple subscribers, while in Point-to-Point, messages are delivered to only one receiver.
2. Reliable Delivery: JMS ensures reliable message delivery by supporting transactional messaging and message persistence.
   Message persistence ensures that messages are not lost in case of system failures. Transactional messaging ensures that either all or none of the messages in a transaction are delivered.
3. Asynchronous Communication: JMS allows applications to communicate asynchronously, which means that they do not have to wait for a response from the receiver. This is useful in situations where a sender does not need an immediate response, or when the receiver may be temporarily unavailable.
4. Message Filtering: JMS allows messages to be filtered based on criteria such as message properties, message content, and message headers. This is useful in situations where a receiver is interested in only certain types of messages.
5. Message Transformation: JMS allows messages to be transformed between different message formats, such as XML, JSON, or plain text. This is useful when different systems use different message formats.
6. Scalability: JMS supports distributed systems and can handle high message volumes, making it suitable for large-scale applications.
7. Security: JMS provides several security features, such as authentication, encryption, and authorization, to protect messages from unauthorized access.

Dissecting the documentation and understanding the latest JMS version

For historical reasons JMS offers alternative sets of interfaces for sending and receiving messages:

• Java Message Service 1.0 defined two domain-specific APIs, one for point-to-point messaging (queues) and one for pub/sub (topics). Although these remain part of Jakarta Messaging for reasons of backwards compatibility they should be considered to be completely superseded by the later APIs.
• Java Message Service 1.1 introduced a new unified API which offered a single set of interfaces that could be used for both point-to-point and pub/sub messaging. This is referred to here as the classic API.
• Jakarta Messaging 2.0 introduces a simplified API which offers all the features of the classic API but which requires fewer interfaces and is simpler to use.

Each API offers a different set of interfaces for connecting to a Jakarta Messaging vendor and for sending and receiving messages. However they all share a common set of interfaces for representing messages and message destinations and to provide various utility features.

Interfaces common to multiple APIs

The main interfaces common to multiple APIs are as follows:

• Message, BytesMessage, MapMessage, ObjectMessage, StreamMessage and TextMessage - a message sent to or received from a Jakarta Messaging provider.
• Queue - an administered object that encapsulates the identity of a message destination for point-to-point messaging
• Topic - an administered object that encapsulates the identity of a message destination for pub/sub messaging.
• Destination - the common supertype of Queue and Topic

Classic API interfaces

The main interfaces provided by the classic API are as follows:

• ConnectionFactory - an administered object used by a client to create a Connection. This interface is also used by the simplified API.
• Connection - an active connection to a Jakarta Messaging provider
• Session - a single-threaded context for sending and receiving messages
• MessageProducer - an object created by a Session that is used for sending messages to a queue or topic
• MessageConsumer - an object created by a Session that is used for receiving messages sent to a queue or topic

Simplified API interfaces

The simplified API provides the same messaging functionality as the classic API but requires fewer interfaces and is simpler to use. The main interfaces provided by the simplified API are as follows:

• ConnectionFactory - an administered object used by a client to create a JMSContext. This interface is also used by the classic API.
• JMSContext - an active connection to a Jakarta Messaging provider and a single-threaded context for sending and receiving messages
• JMSProducer - an object created by a JMSContext that is used for sending messages to a queue or topic
• JMSConsumer - an object created by a JMSContext that is used for receiving messages sent to a queue or topic

Legacy domain-specific API interfaces

Although the domain-specific API remains part of Jakarta Messaging for reasons of backwards compatibility it should be considered to be completely superseded by the classic and simplified APIs.

The main interfaces provided by the domain-specific API for point-to-point messaging are as follows:

• QueueConnectionFactory - an administered object used by a client to create a QueueConnection.
• QueueConnection - an active connection to a Jakarta Messaging provider
• QueueSession - a single-threaded context for sending and receiving messages
• QueueSender - an object created by a QueueSession that is used for sending messages to a queue
• QueueReceiver - an object created by a QueueSession that is used for receiving messages sent to a queue

The main interfaces provided by the domain-specific API for pub/sub messaging are as follows:

• TopicConnectionFactory - an administered object used by a client to create a TopicConnection.
• TopicConnection - an active connection to a Jakarta Messaging provider
• TopicSession - a single-threaded context for sending and receiving messages
• TopicPublisher - an object created by a TopicSession that is used for sending messages to a topic
• TopicSubscriber - an object created by a TopicSession that is used for receiving messages sent to a topic

Administered Objects

Administered objects are pre-configured resources that applications use to interact with the messaging provider.

These objects are created and configured by an administrator, not by application code. They contain provider-specific details such as connection information and destination configuration, but they are exposed to applications in a standard, portable way.

This design ensures that application code does not depend on vendor-specific settings.

Administration and Portability

Messaging providers differ widely in how they are installed, configured, and managed. If applications had to deal with these differences directly, portability would be difficult.

To solve this, Jakarta Messaging separates administration from application logic. Administrators handle setup and configuration, while developers write code that works the same across environments and vendors.

This separation is achieved through administered objects.

Types of Administered Objects

There are two main administered objects used by Jakarta Messaging clients:

• ConnectionFactory
  Used by an application to establish a connection to the messaging provider. The application does not need to know how the connection is created or configured.
• Destination
  Represents the location where messages are sent or received. Applications refer to destinations by name rather than by physical or vendor-specific details.

Role of JNDI

Administered objects are stored in JNDI (Java Naming and Directory Interface).

JNDI acts as a naming directory where applications can look up the resources they need by name. Instead of embedding configuration details in code, applications simply request the required resources from JNDI at runtime.

This approach enables:

• cleaner application code
• environment-specific configuration without code changes
• easier maintenance and vendor flexibility

More Reading?

Jakarta Messaging Concepts