When two applications communicate via Messaging, the communication is one-way. The applications may want a two-way conversation.

When an application sends a message, how can it get a response from the receiver?

Send a pair of Request-Reply messages, each on its own channel.

Request-Reply has two participants:

1. Requestor – Sends a request message and waits for a reply message.
2. Replier – Receives the request message and responds with a reply message.

The request channel can be a Point-to-Point Channel or a Publish-Subscribe Channel. The difference is whether the request should be broadcast to all interested parties or should only be processed by a single consumer. The reply channel, on the other hand, is almost always point-to-point, because it usually makes no sense to broadcast replies–they should only be returned to the requestor.

When a caller performs a Remote Procedure Invocation, the caller's thread must block while it waits for the response. With Request-Reply, the requestor has two approaches for receiving the reply:

1. Synchronous Block – A single thread in the caller sends the request message, blocks (as a Polling Consumer) to wait for the reply message, then processes the reply. This is simple to implement, but if the requestor crashes, it will have difficulty re-establishing the blocked thread. The request thread awaiting the response implies that there is only one outstanding request, or that the reply channel for this request is private for this thread.
2. Asynchronous Callback – One thread in the caller sends the request message and sets up a callback for the reply. A separate thread listens for reply messages. When a reply message arrives, the reply thread invokes the appropriate callback, which re-establishes the caller's context and processes the reply. This approach enables multiple outstanding requests to share a single reply channel, and a single reply thread to process replies for multiple request threads. If the requestor crashes, it can recover by simply restarting the reply thread. An added complexity, however, is the callback mechanism that must re-establish the caller's context.

... Read the entire pattern in the book Enterprise Integration Patterns

Related patterns:

Command Message, Correlation Identifier, Document Message, Remote Procedure Invocation, Event Message, Guaranteed Delivery, Message, Message Channel, Message Sequence, Messaging, Point-to-Point Channel, Polling Consumer, Publish-Subscribe Channel, Return Address

Further reading:

• Will the real asynchrony please stand up?
• Can You Say "Synchronous Asymmetry or Asynchronous Symmetry"?
• Correlation and Conversations

• » Read the latest in My Blog
• » Get more insights from My Articles
• » See me live in my Upcoming Talks

You can reuse the following elements under the Creative Commons Attribution license: pattern icon, pattern name, problem and solution statements (in bold), and the sketch. Other portions are protected by copyright.

Enterprise Integration Patterns
The de-facto language for designing asynchronous, distributed systems. Over 100,000 copies sold.

The Software Architect Elevator
Rethink the role of architects as a connecting element across organizational layers. Acquire the technical, communication, and organizational skills to succeed in this new role.

Cloud Strategy
Make your cloud migration a success by translating high-level goals into conscious decisions with well-understood trade-offs.

Platform Strategy
Platforms can boost innovation through harmonization, but they aren't easy to build. Learn from over a decade of designing and rolling out IT platforms.