A participant invokes an operation on a service, which can take a long time to process.
How can a client be sure the service accepted a request, even if processing the request takes a long time?
- Some operations provided by a service may take a long time, leaving the client in a state of uncertainty whether the message has been successfully accepted and processing has started, or whether the message was invalid or has not even been received.
- Conversations often benefit from a "fail fast" rule by detecting failures as soon as possible. Following this rule, a service should return an error message as soon as possible so that the consumer is aware of the failure.
- In the positive case the requestor of a service might also want to know that things are going well and the request is being processed. It's much easier to wait for something when you know it is on the way.
The service provider sends Quick Acknowledgment message shortly after receiving the request, followed by the operation results later.
The Quick Acknowledgment conversation involves the following participants:
- The Requestor initiates the conversation by sending a Request message to the Provider
- The Provider waits for incoming Request messages and after quick validation of the message sends an Acknowledgment message. After processing the request the Provider provides the results to the Requestor. Transmitting the results can use a simple Result message in case of a Asynchronous Request-Response conversation, but other conversation styles such Polling are also possible.
The acknowledgment message often contains additional information, such as a Correlation Identifier, which can be used to refer to the same conversation in subsequent messages, e.g. if the Requestor wants to use Polling to check whether the results are available.
Some communication standards use quick acknowledgment messages for each message exchanges, i.e. every message that is sent between participants causes an Acknowledgment to be sent in return (see RosettaNet example below).
Example: Ordering from Amazon
Most on-line stores such as Amazon use Quick Acknowledgment by sending an almost immediate order confirmation both as part of the HTTP request, as well as per e-mail ("Thank you for your order"). The acknowledgment also contains an order number that serves as Correlation Identifier. Time-consuming activities such as stock availability checks or credit card verification are performed after the acknowledgment. Additional e-mail messages notify the initiator of progress or potential error conditions, using implied Subscribe-Notify semantics.Example: RosettaNet Request Quote
The RosettaNet Implementation Framework (RNIF) requires an explicit Quick Acknowledgment for all messages. For example, when using Asynchronous Request-Response 4 messages are exchanges as shown below. RosettaNet requires this even if the transport is a bidirectional, connection oriented channel such as TCP/IP, to be independent from whether the lower-layer transport includes guaranteed delivery. In RosettaNet the acknowledgment message also confirms that the recipient has successfully parsed the message and validated the message schema.
Source: RosettaNet Implementation Framework: Core Specification Version: Validated 02.00.00 13 July 2001
If asynchronous channels are being used, it is possible that the Requestor receives the Quick Acknowledgment message after actual response message. RosettaNet specifies this not to be an error:
[...] it is possible that for a given request, the Receipt Acknowledgment can arrive after the response message. This MUST NOT be deemed as an out-of-order message. If the response is received before the Receipt Acknowledgment and the request action requires non-repudiation of receipt, then any of the following suggested approaches MAY be followed.
A response that arrives before the Receipt Acknowledgment MAY either be queued for processing until the Receipt Acknowledgment is received or processed immediately. If the response is processed immediately, then the process SHALL NOT be completed until the Receipt Acknowledgment is received, since the Receipt Acknowledgment contains the digest information for non-repudiation of receipt. These approaches are suggestive only and the implementer is free to choose a similar approach as long as the result is the same (i.e., the response SHALL NOT be rejected unless a timeout occurs waiting for the Receipt Acknowledgment).
Related patterns: Correlation Identifier, Polling, Asynchronous Request-Response, Subscribe-Notify
