ASAP uses the term asynchronous to mean that the requests and responses are not synchronized. In a synchronous exchange, the client asks A and the server answers A, client asks B and the server answers B, and so forth. In an asynchronous exchange, the client can ask A, B then C, and the server can answer B, C then A. For an asynchronous exchange to work, the client must have some means for correlating the responses to the requests. The need for asynchronous arises when the server takes a long time to create its responses.
Why do we need asynchronous services?
Most everything on the Internet is currently based on instant gratification. A client requests a resource; if the server does not respond with the resource within 60 seconds, then the request fails. With the expansion of the Internet to electronic commerce and most notably webservices, there have arisen classes of resources that cannot be created within 60 seconds. Some of these resources take several minutes or even days to create. What we need is an ability for a webservice to respond to client, "The resource you requested is not ready yet. Where do you want me to send it when its done?"
What types of webservices are asynchronous?
Any service that takes more than 60 seconds to respond is a likely asynchronous webservice. Business processes are often asynchronous, especially if they require human intervention or approval. Large data mining queries will often be asynchronous. Remote mobile devices that move in and out of coverage areas are also well suited for asynchronous webservices. Chained webservices, that is webservices that rely on other webservices, can also be asynchronous because, although each service in the chain my respond by itself in less than 60 seconds, the sum of their response times in sequence exceeds 60 seconds.
What is the objective of ASAP?
The objective of ASAP is to provide the minimum functionality necessary to handle an asynchronous exchange in Simple Object Access Protocol (SOAP).
How does ASAP relate to [insert XYZ standards effort here]?
ASAP is designed to be incorporated into standards efforts protocols just as SOAP is. The objective of ASAP is to provide the minimum functionality necessary to handle an asynchronous exchange in SOAP that other standards efforts can employ in achieving their particular business requirements. The ASAP technical committee is working with various other standards efforts. If you know a standards effort that has an asynchronous requirement, then please feel free to contact the ASAP technical committee to discuss those requirements.
If asynchronous services are so common, why form a separate technical committee for ASAP?
Many standards efforts face an asynchronous challenge or have an asynchronous requirement. Without ASAP, each of these standards efforts would be forced to create their own means of handling an asynchronous exchange in SOAP. There would arise a multitude of systems having a multitude of ways of accomplishing essentially the same task. Is that not what we adopted XML and SOAP to avoid? The objective of ASAP is to provide the minimum functionality necessary to handle an asynchronous exchange in SOAP that other standards efforts can employ in achieving their particular business requirements.
Where did ASAP come from?
The roots of the current effot began in 1997 with the Internet Engineering Task Force (IETF) effot named Simple Workflow Access Protocol (SWAP) lead by Netscape, Oracle and others. More than 20 individuals have contributed to the creation of ASAP so far. The current technical committee includes individuals from Amberpoint, British Telecom, Cisco, Computer Associates, Fujitsu, Iway, Lockheed Martin, Research in Motion and The University of Hong Kong.