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?
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 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 AmazonMost 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.
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
Want to keep up-to-date? Follow My Blog.
Want to read more in depth? Check out My Articles.
Want to see me live? See where I am speaking next.
|© 2003, 2019 • All rights reserved.|