Request Reply Messaging

The Request-Reply messaging pattern is different from the Publish-Subscribe messaging pattern because each time the subscriber consumes a message it sends a response to the publisher. For more information see Publishing Messages that Request Replies.

This section provides an overview of the basic steps that required to implement a request reply messaging model using Guaranteed messages. Note that client applications must use a mechanism to correlate the request message with the reply message. Using the CorrelationID message property is one possible mechanism to achieve that goal.

  1. Publishing Guaranteed Request Messages
  2. Replying to Guaranteed Request Messages
  3. Receiving Reply Messages
  4. Request Reply Example

If you're doing Request/Reply messaging with Multi-Node Routing (MNR), you must use the Request/Reply methods of the Solace APIs to prevent possible race conditions associated with subscription propagation.

Publishing Guaranteed Request Messages

To send a Guaranteed message that requires a corresponding reply from a consuming client, perform the following steps:

  1. Create the message and set the following message properties:
    • a Persistent or Non-Persistent delivery mode
    • a unique ReplyTo destination. This is the destination a consuming client must send the reply to the request message to. This ReplyTo destination can be temporary (that is, a temporary Topic or Queue), or it can be durable (for example, a durable Queue or a Topic subscription assigned to a durable Queue).
    • a Topic or Queue destination to publish the request message to (see Destination). (Note: When using JCSMP, the destination is not a message property; instead it is passed in when the send() method is called.)
    • (optional, but recommended) a unique CorrelationID. A correlation ID enables a response to be matched to the request. When used, the implementation of correlation ID matching is the responsibility of the application.

      For information on setting message properties, see Setting Message Properties.

  2. Add the message content. For more information, see Adding Data Payloads.
  3. Send the request message. For more information, see Sending One Message at a Time.

Replying to Guaranteed Request Messages

To send a Guaranteed message as a reply to a received Guaranteed request message, perform the following steps:

  1. Receive the request message.

    To receive the request message, a replying client must use a Guaranteed Message Flow to bind to the provisioned endpoint that the published message is enqueued to. (For information, see Creating Flows.) The endpoint to bind to could be one of the following:

    • A Queue that matches the messages’ Queue destination.
    • A Queue that is assigned a Topic subscription that matches the message’s Topic destination.
    • A Topic Endpoint that is assigned a Topic subscription that matches the message’s Topic destination.
  2. Get the following properties from the received request message so that they can be used to form the reply:
  3. Create the reply message and set the following message properties:
    • a Persistent or Non-Persistent delivery mode
    • a destination to publish the reply message to. This is the ReplyTo destination (either a Topic or Queue) that is obtained from the request message. : (When using JCSMP, the destination is not a message property; instead, it is passed in when the send() method is called.)
    • (optional) a CorrelationID that matches the Correlation ID (if provided) in the request message.

      For information on setting message properties, see Setting Message Properties.

  4. Add the message content. For more information, see Adding Data Payloads.
  5. Send the reply message. For more information, Sending One Message at a Time.

Receiving Reply Messages

The process for receiving a reply message that is sent in response to a request is essentially the same process that is used to receive other Guaranteed Messages:

After a replying client has received the request message, processed it, and returned a reply message in response, a receiving client can consume the reply message through a Flow that is bound to the provisioned endpoint that the reply message will be enqueued to. (For information, see Creating Flows).

Although it is not a requirement, the receiving client can be the same client that originally sent the request that the reply was sent in response to.

Request Reply Example

It is important to note that in this example that Topic subscriptions are first added to the provisioned durable endpoints so that the replying client can receive the request and the requesting client can receive the corresponding response.

Process for Issuing Requests and Receiving Replies