Variations on the request-response messaging pattern

In the previous article, we introduced the request-response messaging pattern and best practices to consider when writing applications that implement it.

This article explores how this exchange pattern can be extended further and combined with the publish/subscribe messaging pattern. Publish/subscribe is an event-driven exchange pattern that makes use of topics, instead of queues, to send messages to a set of subscribers.

The following video covers the content presented in this article:

You will remember that the request-response messaging pattern involves requesters putting request messages to a static queue. The message is then consumed by a responding application which completes the processing. The responder sends a response message via a temporary dynamic queue back to the requester. This is just one way to carry out the exchange. This article explores some variations on this already versatile messaging pattern by using different types of destination!

Destinations for messages

There are a wide range of destination types available for solution designers and application developers to leverage. The table below provides a summary.

By using different combinations of these destinations in the request-response messaging pattern, developers can create flexible frameworks to suit an array of use cases.

Static queue-based request-response messaging

The most common request-response exchange uses a static queue for requests and a temporary dynamic queue for responses, which works well for most request-response use cases. However, if you want responses to still be available in the event of a queue manager restart, for example, a static queue or permanent dynamic queue would be more suitable. These queues would also be suitable if you need a single response queue to be shared by multiple requester-responder pairs supporting multiple in-flight conversations or to promote more administrative control over the queues.

Topic-based request-response messaging

You can implement the request-response messaging pattern using topics instead of queues. This is useful for topic-based solutions to achieve the same basic result or where processing multiple copies of a message in differing ways is required.

The requesting application publishes its request to a topic. The request contains the name of the topic to which responders need to send their reply, and the requesting application must be subscribed to it to receive its response. Subscribers of that topic will then receive the request and can publish their response to the response topic specified in the request message.

By having both request and response messages going to topics, it means that you can have multiple copies of your messages – one for every subscription to the topic. This is helpful in a scenario where you want to trigger multiple people to carry out an action and collect responses from them all, such as a travel agent wanting to coordinate bookings for flights, hotels, and excursion providers, and then confirm bookings for a specific customer.

The travel agent would only need to send out the prompt once to one topic, which would send out copies to all the subscribers. These subscribers could then all send their responses to a single topic, subscribed to by the travel agent. Alternatively, the responders could send their responses to different topics, and the travel agent could subscribe to a wildcard to receive them all. As is the case for queue-based solutions, application developers might apply configuration policies to ensure that only the intended parties can publish and subscribe to the request topic.

Topic-queue hybrid request-response messaging

You might also choose to combine topics and queues. One way would be to have the requesting application publish its request to a topic and specify a queue to receive its responses.

As before, this would allow the request to be sent to multiple people and would enable the requester to collect responses on a queue. This would be useful for collecting and processing application forms on a first-come-first-serve basis for example. The opportunity would be advertised on the topic, and subscribers would submit their forms to the specified queue. Since messages are consumed FIFO (first in, first out) from a queue, the requester would be able process the applications in the order that they arrive. If there is a ceiling on the number of responses, this could be enforced either by using a policy to limit the number of subscribers to the request topic (and therefore limit the number of people who are notified of the opportunity), or by using a temporary dynamic queue to collect the responses. Using this destination type would mean that once the maximum number of responses has been received, the requesting application can disconnect, deleting the queue.

Another use case for this would be if you wanted to request a group to carry out an action and receive confirmation from them once complete, which naturally has applications in IoT scenarios, such as in a supermarket. The supermarket manager might only want to know if a single till is open, so would publish a request to the topic, specifying that the responses go to a temporary dynamic queue. Then, once a single message confirming that a till is open is received, the requesting application can disconnect, deleting the queue.

Queue-topic hybrid request-response messaging

You can also put requests to a queue and specify a topic where you want your responses published. Using a queue means that there will only be one copy of the request message, so it can only go to one responder. This responder can then publish its response to a topic where, depending on the policy, it will be received by a number of other parties. This would be useful in an event planning scenario. A request to plan an event would come into the queue, which the event coordinator would pick up and send a message to a topic to prompt several vendors to also offer their services.

Alternatively, permissions could be set such that the response topic can only be subscribed to by a single party (possibly the same one that made the original request), which would be closer to the standard request-response implementation.

Complex request-response implementation example

Once you start playing around with these messaging patterns, you see how they can be scaled up and chained together in complex ways, like in the IBM MQ coding challenge tutorial found in the IBM MQ Developer Essentials learning path.

In the coding challenge example, a ticket reseller application requests batches of tickets from an event booking service, depending on availability, to resell to customers. This example combines both the publish/subscribe and request-response messaging patterns:

• The reseller application subscribes to the topic at which the event booking service publishes its ticket availability.
• The reseller app will then issue a request for some tickets and put that to a static request queue.
• The event booking service will then fulfil the request and send confirmation on the reply-to queue specified in the request (in this case, a static queue is used).

Summary and next steps

This article explored all the ways you can use queues and topics to carry out the request-response messaging pattern, and how different choices in destinations can facilitate different use cases. The scenarios covered here are by no means exhaustive, so be sure to play around with variations to suit your needs!