Service APIs Client-Service Interactions Request and Response Management Service Implementation Service Infrastructures Service Evolution

Request/Acknowledge

A client would like to manipulate a file or document, launch a business task, or notify a system about an interesting event. Requests don't need to be processed right away. If a response is required, it doesn't need to be delivered as soon as the request has been processed.
How can a web service safeguard systems from spikes in request load and ensure that requests are processed even when the underlying systems are unavailable?
Temporal coupling is considered to be relatively high when a request must be processed as soon as it's received. The implication is that the systems (e.g. databases, legacy or packaged applications, etc.) behind the service must always be operational. If systems have been taken off-line, perhaps for maintenance reasons, then client requests will be rejected. High temporal coupling also leaves systems vulnerable to the effect of unanticipated spikes in request load. Since the capacity of a system (i.e. memory, CPU, disk, network bandwidth, number of database connections) is usually based on average loads, a spike can cause excessive resource utilization leading to systemic failures.
The web service could attempt to mimic the fire-and-forget characteristics of queues by not returning a response (a.k.a. One-Way or In-Only message exchange pattern). In this approach, the service receives a request, processes it, but doesn't provide a response. While this eliminates temporal coupling and blocking on the client, it doesn't let the client know whether or not a request has been received and if it will be processed. It also doesn't alleviate problems related to unavailable resources (e.g. databases) or request spikes. How then can a web service behave like a queue while also providing immediate client feedback?
When a service receives a request, forward it to a background process, then return an acknowledgement containing a unique request identifier.
Request/Acknowledge: When a service receives a request, forward it to a background process, then return an acknowledgement containing a unique request identifier.
Request/Acknowledge services typically perform the following steps:
  1. Receive request
  2. Authenticate client credentials (optional)
  3. Authorize client for requested operation (optional)
  4. Validate request (optional)
  5. Generate Request Identifier or URI
  6. Store and Forward request
  7. Return an acknowledgement
The Request/Acknowledge/Poll variation on this pattern allows clients to poll for results at their leisure.
Request/Acknowledge/Poll: The Request/Acknowledge/Poll variation on this pattern allows clients to poll for results at their leisure.

Request/Acknowledge/Callback (a.k.a. Request/Acknowledge/Relay) can be used when the status updates or final results for a request must be delivered as soon as possible to one or more recipients. In this variation of Request/Acknowledge, the request processor pushes a Representation or Callback Message to a Callback Service.
Request/Acknowledge/Callback: The Request/Acknowledge/Callback can be used when the status updates or final results for a request must be delivered as soon as possible to one or more recipients.