A service likes to request information from a conversation partner.
How can a service request information from a provider if an immediate response is not available and it cannot accept unsolicited incoming messages?
Have the requestor poll, i.e., inquire whether results are ready, multiple times if necessary.
The Polling conversation involves the following participants:
Polling requires a Correlation Identifier to be agreed between Requestor and Provider. The identifier can either be selected by the Requestor and transmitted with the Request or the participants can use Quick Acknowledgment to transmit the identifier in the Acknowledgment message. The Requestor then includes the identifier in every Inquiry message.
The response to the last inquiry can immediately include the response message or indicate that the results are available (Ack), requiring the initiator of the conversation to make a separate request to retrieve the results.
Polling is significantly more "chatty" than Asynchronous Request-Response". It should only be used when either of the communicating parties cannot support a Asynchronous Request-Response" conversation. Excessive Polling can cause significant load on part of the Provider up to the point where it competes with resources with the actual operation.
Polling causes a delay in the overall conversation because the results are available before the Requestor can realize. The optimal Polling rate depends on the expected latency, the "cost" of a poll, and the time sensitivity of the request. More frequent Polling reduces the delay between the time the results are available and when they are picked up. Unnecessarily frequent polling introduces network and processing overhead. Adaptive polling intervals are conceivable, but run the risk of complicating the conversation. If the Requestor has a good approximation of the minimum processing time, it can delay the beginning of Polling and possibly use a higher Polling frequency without increasing the total overhead:
In reality, the Polling interval will depend on when the results can be meaningfully processed by the Requestor. For example, the Requestor may engage in other interactions whose results are needed for further processing. It makes sense to only poll for results once those steps are completed.
Polling requires the Provider to maintain state at the convenience of the Requestor, which should be considered a form of coupling. It can also limit the scalability of the service provider, for example if responses consume large amounts of memory and initiators are slow to pick up their results. Therefore, the service provider may use additional conversation patterns to terminate the conversation, such as a Lease", so it can relinquish the allocated result storage if the Requestor does not consume the results within a specified length of time. Correspondingly, the Requestor has to be prepared that an Inquiry results in a Not Available message, after which the Requestor should stop the conversation.
Reliable Messaging can often eliminate the need for Polling. The Requestor can consume results whenever it pleases, alleviating the Provider from having to keep results until the Requestor picks them up. Storing results in a message queue is generally more efficient than storing them inside the Provider as Messaging systems are designed to maintain state and use mechanisms such as Message Expiration to manage stale data.
The Requestor can also use a Poll Object  to implement polling internally, turning it into a Polling Consumer . This allows the consumer application to control when the message is read while still using the preferred Asynchronous Request-Response conversation with the Provider.
In real life, participants often mix Asynchronous Request-Response and Polling: if a response does not arrive within a "reasonable" amount of time, the Requestor begins Polling. This can occasionally annoy the Provider.
Example: Project Manager
Some project managers who are wondering why a coding task takes so long keep asking for daily status updates.
Related patterns: Correlation Identifier, Lease, Message Expiration, Messaging, Quick Acknowledgment, Asynchronous Request-Response
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.|