An introduction to the request-response messaging pattern

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. Here, 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, which 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. This is typically a queue that gets dynamically created by the requesting application. A reply-to destination can also be an administratively created static queue, or even a topic, but 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 and maybe even 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.

As mentioned earlier, the request-response messaging pattern enables the bi-directional transfer of messages between applications, while enabling them to function independently. This bidirectionality is particularly useful in the context of microservices architectures, where microservices need to communicate reliably while remaining decoupled and avoiding propagation of failures.

Crucially, the request-response messaging pattern avoids reliance on specific application instances, which means that the requester and responder only need to know about the queues involved in the exchange, and not each other. In this way, requesting applications aren’t dependant 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 writing an application that will be carrying out request-response, you want it to be reliable and resilient so you can be sure you don’t miss any messages. To ensure this is the case, we’ll look at the best practices you need to incorporate when using the request-response messaging pattern in IBM MQ. While your apps will still work without these features, including them will prevent any unexpected behaviour.

Include a timeout or WaitInterval

Including a timeout or WaitInterval in your request-response application means that when it carries out a ‘get’ operation, it won’t be left waiting at a queue 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. There is a specific issue that might apply to these applications which is explained in depth in this blog post.

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 which specifies that 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 is useful to ensure that time sensitive messages aren’t acted upon once they’re no longer relevant and it helps to 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, and you can read more about them in this 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 from the application 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, we introduced you to the request-response messaging pattern, described how it works, and explained its benefits in a messaging solution. We also covered the features that are considered best practice to implement when developing an application to carry out request-response, so you can engage in robust, asynchronous messaging.