There are a variety message exchange patterns that can be used to implement an SOA. Know them and when to apply them. It can mean the difference between an SOA that scales and performs vs. one that doesn't. The traditional synchronous request/response may not always be the most appropriate in all scenarios. Here are some examples of other types of MEPs:

• Asynchronous request/response using a callback--the consumer sends a request and provides a reference to a callback service as part of the request; instead of responding synchronously to the request, the service responds asynchronously by sending the response to the callback service
• Publish/subscribe--consumers register their interest in receiving some data that the service provides by subscribing to the service; whenever the service gets or creates that data, it publishes it to all subscribed consumers. This is somewhat of an extension of the asynch req/resp with callback MEP. The difference is that the pub/sub MEP is used in more of a one-to-many type of scenario, i.e. the service has some data that may be applicable/consumed by multiple consumers; whereas the asynch req/resp with callback is used in more of a one-to-one scenario, i.e. the consumer is requesting some data or functionality that is specific to it (not applicable to other consumers) and doesn't want/need to wait for the response to return immediately
• Request and poll--the consumer sends a request to the service but doesn't want/need to wait for the response so the service returns some type of identifier that the consumer can use later to poll the service for the response. This MEP is useful for when you're trying to achieve the behavior of the asynch req/resp with callback but can't provide a callback service perhaps because firewall settings don't allow inbound messages.
• One-way push, aka "fire and forget"--the consumer sends the service a request and doesn't need a response so it just fires it off and forgets about it; perhaps it would be more accurate to call it a message instead of a request since the consumer's not expecting a response. Also it doesn't have to be the consumer firing off the message, it can be the service doing that as well. This is in fact the publish half of the pub/sub MEP for scenarios that don't have any type of guaranteed delivery requirements.

Read the original blog entry...