5.6 The Request/Reply Messaging Pattern Communications across an ESB or a MOM are by and large intended to be asynchronous in nature. Applications and services send messages in a "fire-and-forget" mode, which allows an application to go about its business once a message is asynchronously delivered. This does not necessarily preclude the need to perform request/reply operations. Sometimes you need to perform a synchronous request/response operation, such as when you are trying to integrate with a web service client that blocks and waits for a synchronous response to return to it. Often the sender (requestor) can wait for the reply to happen at a later time (asynchronously). Request/reply messaging patterns can be built on top of a MOM to perform synchronous request/reply or asynchronous request/reply. An ESB can further automate this process by managing the details of the request/reply in the ESB container invocation model. The request/reply pattern is introduced now, in the messaging chapter, as we will be referring to it in other discussions throughout the rest of the book. In Chapter 8, for example, we'll see how a synchronous request/response web service can be mapped onto an ESB simply by virtue of how the endpoints are created. Figure 5-18 illustrates a request/reply pattern in its simplest form. Message channels are not bidirectional. To perform a request/reply operation, a requestor must use two channels: one for the request, and one for the response. Figure 5-19. Request/reply pattern across asynchronous messaging channels using correlation 
The key to this pattern is the use of a ReplyTo property that gets carried with the request message. The requestor needs to listen on a "reply" channel that will accept the reply message. The request message that gets sent on the request channel needs to contain the identifier of the reply channel, along with a correlation ID that is used to correlate the request message with the response message. This is typically done using a message property, if the messaging system supports the notion of properties.  | The property name ReplyTo is simply an example of a common convention used in messaging environments. The actual name of the property could be anything, as long as it is consistent across all message requestors and repliers. If you are coding this pattern yourself, it is a good idea to establish a convention and stick with it. In the JMS specification, there is a special property named JMSReplyTo that is reserved for this purpose. In an ESB, these details are hidden by the service container invocation model. |
|
Upon receipt of the request message, the replier extracts the identifier of the reply channel from the ReplyTo property, and uses that to identify the channel on which to send the reply. It also extracts the CorrelationID property and places that in the response message. In an asynchronous environment, multiple requests and responses may occur simultaneously. The requestor uses the correlation ID to match the response with the appropriate request. 5.6.1 The Reply-Forward Pattern Sometimes, a reply does not need to be returned to the same service that initiated the request (Figure 5-19). An ESB uses a more elaborate request/reply model in which a reply from a service invocation can be another destination, or a forwarding address of where to send the message next. This is referred to as the reply-forward pattern. Figure 5-20. In a reply-forward pattern, the recipient of a reply message does not have to be the application or service that performed the request 
| 