Reading Time: 9 minutes

The communication between enterprise applications can be categorized as synchronous and asynchronous. Synchronous communication means that both client and server must be available at the same time to establish a connection and exchange messages. However, such a setup is not suitable to develop loosely coupled enterprise applications where reliability is more important than performance, that is, asynchronous data transmission is preferred over synchronous.

The blog post will explain the working principle of asynchronous interaction model or JMS, and five different flows that can help publish and receive messages using Mule 4. 

Message delivery modes in JMS 

latest report
Learn why we are the Leaders in API management and iPaaS

In an enterprise architecture, a single application may exchange data with only one application or a group of applications at a given instant. In the former case, we have point-to-point message delivery mode, while the latter will work on publish/subscribe mode. 

Point-to-point (queue)

In this type of messaging, exchange of messages happens between a single sender (producer) and a single receiver (consumer) via a queue. Once the sender publishes a message, it is retained in the queue until the receiver consumes that message. The diagram below shows this delivery mode. 

Publish/subscribe (topic)

Here we can have multiple receivers that receive the same message simultaneously, given that they have subscribed to the message broker via topics. When a message is sent, the topic publishes to all the subscribers and retains it until it is consumed. A subscriber can be durable or non-durable. The messages are stored persistently for a durable subscriber and can be recovered if the message broker fails. However, for a non-durable subscriber, the messages are not stored, and no message is delivered if the consumer connection is lost. 

The diagram below shows the publish/subscribe delivery mode. 

Overview of JMS module in Mule 4 

Before understanding Mule flows that we can construct in Anypoint Studio to publish and consume JMS messages, it is important to know a general process of establishing the communication. For this demonstration, we recommend the ActiveMQ message broker. Once a connection is established using ActiveMQConnectionFactory, we create a session. A session allows us to create a message, message sender, and message consumer. After that, we can execute the flows to follow point-to-point or publish-consume delivery modes. 

In Anypoint Studio, the JMS module has the following components: acknowledge, consume, publish, publish-consume, on new message, and recover session. 

Publish and consume messages using JMS queue

Flow # 1  

The flow for publishing a message begins with a listener component that posts a message to the queue. The publish component belonging to the JMS module follows it. The required library function in configuring the publish component is ActiveMQ client. Once the component is configured to the localhost, a connection is established. Finally, the set payload component allows to define the message content, which is published to the queue. 

Flow # 2

The other part of this process is the flow to consume messages from the queue. The listener component here gets the message from flow # 1. The second component consumes the message, and whatever message is consumed is set as the payload in the third component of the flow. Finally, the message consumed is published to another project queue which is MULE.JMS.TEST.OUT in this case. 

Note: for this demonstration, we have two different queues in ActiveMQ, MULE.JMS.TEST.IN and MULE.JMS.TEST.OUT respectively. The messages consumed in MULE.JMS.TEST.IN queue are published to MULE.JMS.TEST.OUT. 

Publish and consume messages using JMS topic 

It is interesting to note that the flows for a topic are very similar to that of the queue. However, the difference lies in their configuration. When configuring a topic for consuming messages, we can add multiple subscribers to it. As mentioned earlier, a subscriber can be durable or non-durable. Another feature we need to discuss here is “no local.” By checking this box, we can ensure that we do not receive a copy of the published message if we are the sender. 

Similar to the consume message flow for the queue, we have MULE.JMS.TEST.TOPIC and MULE.JMS.TEST.OUT. The messages consumed from MULE.JMS.TEST.TOPIC are published to MULE.JMS.TEST.OUT. 

Publish-consume messages using JMS queue

The publish-consume operation creates a request-reply communication pattern between system applications. The flow remains incomplete until the destination application returns a reply to the request made.

Flow # 1

Flow # 2

When the message is forwarded to the publish-consume component in flow #1, it is passed to the On New Message component in flow #2. The payload is retrieved in set payload component and then returned to flow # 1. From there, it is finally published to the MULE.JMS.TEST.OUT which marks the end of the process. 

Conclusion

Asynchronous communication is essential to develop loosely coupled enterprise applications that exchange data and perform various operations. Mule 4 allows to publish and consume JMS messages as demonstrated in this blog post through five different scenarios – publish messages in a queue, consume messages in a queue, publish messages in topic, consume messages in topic, and publish-consume messages in queue. By incorporating these flows, various applications in an enterprise can be integrated together to align the processes taking place in an enterprise.  

Check out this blog post to learn more about asynchronous messaging patterns.