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
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Efficient API Communication With Spring WebClient
  • Memory Management in Couchbase’s Query Service
  • How to Build Slack App for Audit Requests
  • Idempotency in Distributed Systems: When and Why It Matters

Trending

  • How Can Developers Drive Innovation by Combining IoT and AI?
  • Navigating Double and Triple Extortion Tactics
  • Optimizing Serverless Computing with AWS Lambda Layers and CloudFormation
  • Optimizing Software Performance for High-Impact Asset Management Systems

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
17.7K 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

  • Efficient API Communication With Spring WebClient
  • Memory Management in Couchbase’s Query Service
  • How to Build Slack App for Audit Requests
  • Idempotency in Distributed Systems: When and Why It Matters

Partner Resources

×

Comments
Oops! Something Went Wrong

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

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

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 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!