Request-response messaging pattern: An introduction

Request-response is a simple yet versatile messaging pattern that facilitates a conversational exchange in an asynchronous framework. Whereas queues and topics enable the movement of data in one direction, request-response extends this further by allowing bi-directional communication.

Consider an application that needs a user's credit score before it can process an order. The application would send a request message to a credit score service via a queue, but it also needs to receive a reply so it can continue processing appropriately. This is where request-response comes in. To refresh your understanding of all of the enterprise messaging patterns, watch the video below.

In this article, we’ll review how the request-response messaging pattern works and the benefits it can bring to your messaging solutions.

How does request-response messaging work?

As with any other messaging pattern, there are producing applications and consuming applications. However, in the case of request-response, the producer is also a consumer and the consumer is also a producer. To reflect this configuration, the applications involved in this messaging pattern are known as requesters and responders.

One key difference with the request-response messaging pattern is that it requires an additional reply-to destination, which is where the requesting application will receive its response. The requesting application typically creates this queue dynamically. A reply-to destination can also be an administratively created static queue or even a topic. However, it is most often a temporary queue as these make efficient use of messaging resources.

For a request-response exchange to work, the requester and responder need to share the address of the reply-to destination. Since a responder is often a service that is used by multiple concurrent requesters, the reply-to destination will likely be unique for each requester. It might even be unique for each message processed. By convention, the requesting application shares the reply-to destination address in the request message itself using a reply-to property. The responder can then use this address to determine where to send the response message.

The following animation illustrates how messages are exchanged between requesting and responding applications in the request-response framework.

The request-response messaging pattern enables the bi-directional transfer of messages between applications while allowing them to function independently. This bidirectionality is particularly useful for microservices, which need to communicate reliably while remaining decoupled and avoiding propagation of failures.

Crucially, the request-response messaging pattern avoids reliance on specific application instances. This means the requester and responder only need to know about the queues involved in the exchange, not each other. In this way, requesting applications do not depend on a specific instance of a responding application. Put simply: if a particular responder fails, it won't affect the requesters' ability to receive a response.

Request-response application best practices

When you write a request-response application, you want it to be reliable and resilient so you don't miss any messages. To ensure this is the case, review these best practices for using the request-response messaging pattern in IBM MQ. While your apps will still work without these features, including them will prevent any unexpected behavior.

Include a timeout or WaitInterval

Including a timeout or WaitInterval prevents your request-response application from waiting indefinitely at a queue during a 'get' operation for a response that might never arrive (maybe due to failures upstream).

Set the WaitInterval attribute to the approximate time (in milliseconds) that you want your application to wait for a suitable message. A suitable message refers to a message that satisfies the criteria that is specified in the MsgDesc parameter of the MQGET call. If a suitable message isn’t received within the specified wait time, the application will get a MQRC_NO_MSG_AVAILABLE error. You can read more about the WaitInterval property in the IBM MQ docs.

It's important to include a timeout in all your applications, but more so for those doing request-response in a uniform cluster. A specific issue might apply to these applications (learn more in a blog about special considerations for JMS request-response in uniform clusters).

Include an expiry time

All messages that your application puts on the queue should have an expiry time on them. The expiry time is a duration expressed in tenths of a second. If the message has not been picked up from its destination queue before this time has elapsed, it will be deleted. Setting an expiry time ensures that time-sensitive messages aren't acted upon once they're no longer relevant. It also helps prevent queues from becoming full.

Use transactions

When engaging in a request-response interaction, both the requesting and responding applications need to use transactions. A transaction involves an application only committing to act on a unit of work once it is certain it can carry it out successfully. You can read more about them in the introduction to local transactions using MQ and JMS article.

There are three key points at which your applications must either commit or rollback:

1. The requesting application must commit its request once it is certain it wants to make it. Without committing, the responding application won’t be able to see the request.
2. The responding application then must commit its response, so that it is available for consumption by the requester.
3. Finally, the requesting application must either commit to consuming the response, or rollback if it is unable to process it for some reason.

Use a temporary dynamic queue

As part of the request-response messaging pattern, the requesting application will generate a temporary location to receive its response. While there are many types of temporary locations that your application can generate, a temporary dynamic queue is created by default.

Using temporary dynamic queues results in low overheads for your MQ admin because these queues are automatically disposed of once they're no longer in use. The requesting application generates the temporary dynamic queue in the same queue manager that it is connected to. The address of this temporary queue is then provided in the request message so that the responding application knows where to deliver its response. Once the requesting application has finished its interaction and disconnects from the queue manager, the temporary dynamic queue is discarded.

Summary and next steps

In this article, you learned about the request-response messaging pattern, how it works, and its benefits in a messaging solution. You also learned the best practice features to implement when developing an application to carry out request-response messaging. These practices enable you to engage in robust, asynchronous messaging.