DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Scalable Support Request Analysis Using Embeddings, HDBSCAN, and Tiny LLMs
  • KV Cache Implementation Inside vLLM
  • When Retries Become a Denial-of-Wallet
  • The Bill You Didn't See Coming

Trending

  • Detecting Plan Regression in SQL Server Using Query Store
  • How to Interpret the Number of Spring ApplicationContexts in Integration Tests
  • A Deep Dive into Tracing Agentic Workflows (Part 2)
  • Why Your Test Automation Is Always Behind the Code And the Architecture That Fixes It

How To Use JMS ActiveMQ With Mule 4 - Part 4

In this blog, we will see how to use the Mulesoft JMS connector to perform the Request-Reply pattern using the JMS publish Consume operation.

By 
Anand Joshi user avatar
Anand Joshi
·
Aug. 17, 21 · Tutorial
Likes (4)
Comment
Save
Tweet
Share
18.0K Views

Join the DZone community and get the full member experience.

Join For Free

This is the fourth part of the JMS ActiveMQ with the Mule4 series. You can read previous parts here: Part 1; Part 2; Part 3. In this post, we will learn about the JMS Request-Reply pattern and how to use it in Mulesoft.

JMS Request-Reply/Response pattern in Mule : 

Request-Reply or Request-Response is one of the mainly used messaging patterns, where a requestor application sends a request, a replier application receives the request and returns a reply back to the requestor, and the requestor receives the reply. It is a synchronous message communication method.

For implementing Request-Response Pattern we require 2 Queues:

A  Request Queue which Requestor uses to send the request message to the Replier.

A Response Queue which Replier uses to send the reply message to the Requestor.

Below steps are involved in the exchange of messages using this pattern:

1.  Requester publishes the message to the Request queue.

2. Consumer subscribes to the message from the Request queue. 

3. Once the processing is completed, the consumer will send a response back to the Response queue. 

4. The requestor will subscribe to the message from the Response queue.               

In Mulesoft, Publish consume operation is used to implement the Request Reply pattern.

Publish  Consume:

This operation combines the functionality of the JMS Publish and Consume Operation. It allows the user to publish a message to Request Queue and then wait for a response. If we set reply-to queue, then the response will be sent to that queue otherwise it will be sent to a temporary queue, created when the message is being sent.

JMSReplyTo header of the outgoing message contains the ID of the destination on which the application waits to consume a response.

Let's try to understand the functioning of publish consume operation by a demo for which we will create mule flows as shown in the below image:

Mule Flows

First flow JMS-flow1 has an HTTP listener, we receive the message by triggering the HTTP endpoint, then we log it using a logger, then we are using JMS Publish Consume operation and in the end, we are using a logger to log the correlation_ID of the consumed message. 

By looking closely at the configuration of the publish consume in the below image, we can find that the destination is set to testQueue1 and Request-Reply Pattern is set to CORRELATION_ID. For the Reply-To field, we select Edit Inline and set the destination Name as testQueue2 and destination type as Queue.  In other words, testQueue1 is the Requestor Queue and testQueue2 is the Response Queue.

Configuration of the publish consume

JMS-flow2 has a JMS On New Message Listener and listening to the queue testQueue1 (where the message is published by publish consume operation of JMS-Flow1). Next, we have a logger which is used to print the received message.

In the below image we can see that in the On New message configuration Request Reply pattern is set as CORRELATION_ID:

New message configuration

So, when we hit the HTTP endpoint URL, flow JMS-Flow1 receives the message and logs it, then publish consume operation publishes the message into the queue (testQueue1) and waits. As soon as the message gets published into the queue, the On New Message listener (JMS-Flow2) will pick up the message and processes it. Once this is done the publish consume operation resumes and continues the flow JMS-Flow1.

Here, after publishing a message to the destination queue (testQueue1), the Publish Consume operation consumes a message from Response Queue (testQueue2) using a selector that expects a message with the same correlation ID that was used to publish the request message. 

We can see there are no messages in both the queues before running the request.

Destination and Response queues before running the request

The request triggered by the postman is shown below.

Request triggered by the postman

When the request is triggered from the postman,  JMS-Flow1 starts, and as we set a breakpoint at Publish Consume Operation. We can see that message is received and there is a correlation ID associate with it. The publish-Consume will publish the message to the requestor queue testQueue1. And after that, the control immediately passed to JMS-Flow2.

Publish Consume operation of JMS-Flow1 publishing the message

As the On New Listener of JMS-Flow2 is listening to the Requestor Queue (testQueue1) continuously for a new message, it will immediately pick the message published by Publish Consume operation of JMS-Flow1. We can see that it is the same message by looking at the payload and the Correlation_ID.   As soon as the processing of the JMS-Flow2 was completed the control moved back to publish consume operation of JMS-Flow1.

Publish-consume operation consumes the message

Once the control is moved to JMS-Flow1, the publish-consume operation consumes the message from the response Queue testQueue2 and we can see that the Correlation-ID is the same. And the processing ends here.

The same Correlation_ID through whole processing

We can see that Correlation_ID is the same across the whole processing.  We can verify all these details by looking at the below logs:

INFO  2021-07-21 20:28:48,205 [[MuleRuntime].uber.06: [jms-demo].jms-Flow1.CPU_LITE @7c71e8cc] [processor: jms-Flow1/processors/0; event: 2e899bf0-d2a1-11eb-b894-c8b29becab99] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Received Message is :     {

"message": "This is a demo"

}

INFO  2021-07-21 20:29:41,909 [[MuleRuntime].uber.02: [jms-demo].jms-Flow2.CPU_LITE @167b2ab6] [processor: jms-Flow2/processors/0; event: 2e899bf0-d2a1-11eb-b894-c8b29becab99] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Message Received is : {

"message": "This is a demo"

}  

INFO  2021-07-21 20:30:01,819 [[MuleRuntime].uber.06: [jms-demo].jms-Flow1.CPU_LITE @7c71e8cc] [processor: jms-Flow1/processors/2; event: 2e899bf0-d2a1-11eb-b894-c8b29becab99] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: Publish Consume Flow Done for Correlation ID : 2e899bf0-d2a1-11eb-b894-c8b29becab99

On the ActiveMQ console, by looking at the Messages Dequeued column we can confirm that both the queues have successfully delivered 1 message.

Messages Dequeued column

This is how we can use JMS publish-consume operation to perform the Request-Response pattern in Mulesoft.

Requests

Opinions expressed by DZone contributors are their own.

Related

  • Scalable Support Request Analysis Using Embeddings, HDBSCAN, and Tiny LLMs
  • KV Cache Implementation Inside vLLM
  • When Retries Become a Denial-of-Wallet
  • The Bill You Didn't See Coming

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook