Mastering JMS Integration in Mule 4: A Guide to the JMS Connector

Introduction

In the rapidly evolving landscape of integration, Mule 4 introduces the Java Message Service (JMS) connector, providing a simplified and efficient means of communication between applications. With its versatile features, the JMS connector in Mule 4 presents a robust solution for seamlessly integrating JMS-compliant messaging systems into your integration workflows.

JMS supports two models for messaging:

• Queue (Point to Point)
• Topic (Publish-Subscribe)

Queue (Point to Point)

• It enables one-to-one communication. It is also called point-to-point communication.
• The sender will deliver a message to the queue and single receivers will pick the message from the queue.
• The receiver doesn't need to listen to queue at the time when the message is sent to the queue.

Topic (Publish-Subscribe)

• It enables one-to-many communication. It is also called publish-subscribe communication.
• The publisher will deliver the message to a topic and it will be received by all subscribers who are actively listening to the topic.
• A subscriber will miss the published message if it is not actively listening to the topic unless messages are made durable.

Benefits of JMS

1. Decoupled Integration
2. Asynchronous Communication
3. Reliability in Messaging
4. Scalability Enhancement

Configure the ActiveMQ JMS Server: Download ActiveMQ from the provided link:https://activemq.apache.org/components/classic/download/

• Configure the JMS connector with Apache ActiveMQ by following the steps below:

ActiveMQ Setup

Extract the downloaded archive. You should be able to observe the following.

Initiate ActiveMQ by executing the command: D:\Application\apache-activemq-5.15.2\bin>activemq start.

Access http://localhost:8161/admin/ and you will encounter the displayed page. Utilize "admin" as both the username and password.

Select either "Queue" or "Topic" to create a new queue or topic, respectively.

Integrate with MuleSoft by completing the following steps for ActiveMQ connection configuration:

• Add the JMS configuration.

• Choose "ActiveMQ Connection" as the connection parameter.

• Next, add the client JARs to establish a connection with ActiveMQ. Click on "Configure" to incorporate the necessary client JARs.

The following dependency should be included in the POM.

<dependency>
<groupId>org.apache.activemq</groupId>
<artifact>ActiveMQ-client</artifact>
<version>5.14.5</version>
</dependency>

Additionally, include the dependency for the ActiveMQ broker (for non-persistent in-memory connection) or ActiveMQ Kaha

DB (for persistent connection). Click on "Configure Broker Dependency" to proceed.

Provide the broker URL as tcp://localhost:61616 and perform a connection test. The test connection should succeed as illustrated below. If not, ensure that your ActiveMQ is started correctly and that the dependencies are loaded accurately.

Basic JMS operations

• In your application, utilize JMS to send a message to a queue or a topic using the "Publish" JMS message processor.

• Verify the same in the ActiveMQ admin portal as well.

• Incorporate the "Listener" JMS message processor in your application to receive a message from a queue or a topic.

Send a message to the queue, and the thread will pause, awaiting a response. If the "reply to" queue is specified, the response will be directed to that queue; otherwise, it will be sent to a temporary queue generated during the message transmission and linked to the JMS Reply To Header.

The request and response of that message are correlated using either the correlation ID or message ID. The consume operation listens, utilizing a JMS selector, for the message with either the correlation ID or message ID that was sent. This approach allows the implementation of a request-response pattern using messaging.

You can also verify the "correlation ID" and the "reply-to" queue for the message in the ActiveMQ portal.

Use case of JMS/message-oriented middleware (MOM).

• Application decoupling

Introducing a Message-Oriented Middleware (MOM) is the most effective way to decouple integrations. Any messaging provider can be employed to achieve this decoupling, enabling the isolation of non-business processing such as logging, exception handling, or other tasks in your application. By sending messages to a queue, the processing can occur in a separate thread within another application, ensuring optimal performance for your application.

• Reliable/Guaranteed delivery

This aspect pertains to the capabilities of a message provider. A message provider can guarantee the delivery of messages to the intended system. Another crucial property in a message provider is message acknowledgment, ensuring that messages persist on the server until their processing has been successfully completed by the message consumer. To acknowledge a message, you can employ the Acknowledge (Ack) message processor in the JMS connector, with various acknowledgment types available for use. For example,

In the "Auto" acknowledgment mode, the message is acknowledged only if the flow execution completes successfully. In the event of any exception within the flow, the message will be redelivered until the maximum redelivery count (configured as specified below and defined by the JMS header JMSXDeliveryCount) is exhausted.

• In "DUPS_OK" acknowledgment mode, similar to Auto acknowledgment mode, acknowledgment occurs automatically by the session, but at a later time, either when a fixed number of messages is received or when a fixed time interval has elapsed since the last acknowledgment was sent. Consequently, your message could potentially be redelivered by the server before acknowledgment.

• In "Immediate" acknowledgment mode, the message is acknowledged as soon as it is received by the consumer, and it is promptly removed from the broker. Therefore, there is no possibility of the message being redelivered in the event of an exception in the flow.

• For "Manual" acknowledgment mode, the acknowledgment is left to the consumer. To achieve this, you can utilize the Ack JMS message processor, as shown in the above picture. The message is deleted from the server only when it has been acknowledged by the Ack JMS message processor in the flow.

Conclusion

In the journey to master JMS integration using Mule 4, we've traversed the intricacies of the JMS connector, unlocking a wealth of capabilities for seamless communication between applications. Through this guide, we've navigated the configuration intricacies, harnessed the power of asynchronous messaging, and explored advanced features like acknowledgment modes. The JMS connector in Mule 4 emerges not just as a tool but as a guide that empowers developers to orchestrate sophisticated integrations with precision.

As we conclude this exploration, remember that mastering JMS integration is an ongoing process of discovery and application. The JMS connector in Mule 4 serves as a compass, offering a guide to innovation, flexibility, and efficiency in integration workflows. Embrace the knowledge gained here, continue to experiment and confidently embark on your journey to mastering JMS integration with Mule 4. Happy integrating!