|HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT|
A service has identified a conversation partner.
How can a consumer request information from a provider?
Use two messages, a request message and a response message.
The Asynchronous Request-Response conversation involves the following participants:
As with most conversations, when using Asynchronous Request-Response over asynchronous message channels, the requestor is responsible for matching the Response message to the appropriate Request. Because the asynchronous nature of the conversation, the Requestor can engage in more than one Asynchronous Request-Response conversation at one time, which results in response messages potentially arriving in a different order than the requests were sent. This can happen because some requests may be processed more quickly (or by a different service instance) than others. The Requestor should therefore equip messages with a unique Correlation Identifierto tie the messages to the conversation.
The Asynchronous Request-Response conversation has a single state, "Waiting for response". The service provider does not have to keep a conversation state because all it does is process a Request and subsequently send a Response message. This makes the Asynchronous Request-Response conversation stateless from the Provider's perspective and also implies that subsequent conversations can be serviced by different Providerinstances.
The Requestor can avoid tracking the conversation state if the response message contains all data necessary for the initiator to process it, "flattening" the conversation into a Pipes and Filters-style message flow.
Some Providers allow the Requestor to pass through additional data of their choice, which the Provider copies from the Request message to the Response message. This can help the Requestor avoid keeping local state, but it also increases network traffic and can cause security concerns as the Requestor could be manipulated by injecting data into Response messages.
The Requestor must be prepared to handle the following error conditions:
Comparing with Fire-an-Forget
The similarity between the implementation of Request-Response and the use of two Fire-and-Forget interactions highlights the fact that the patterns convey more than simply the technical solution -- they convey the intent behind the solution. If the fact that the response message returns to the original initiator is purely coincidental, one would express the interaction as two Fire-and-Forget interactions, highlighting the fact that the sameness of initiator and recipient of the second message is coincidental and is not core to the intent of the solution.
Comparing with Remote Procedure Call
This basic conversation is often compared to (or confused with) Remote Procedure Invocation, also known as Remote Procedure Call (RPC). However, the two patterns' intent is quite different: RPC's purpose is to invoke a method on another component and to return the results to the invoker. Asynchronous Request-Response does not tie specific semantics to the exchange of messages. The message exchange may be used to invoke a method, query information, or the reply may simply acknowledge the receipt of a message. RPC is also often tied to a synchronous client-side programming model, which makes the conversation look like a method call on the client side. This provides convenience for developers, who are used to working with synchronous method calls, but can result in brittleness and poor performance as the simple programming model masks the inherent challenges of the networked interaction, such as latency, partial failure etc.
|© 2003, 2017 • All rights reserved.|