Last modified by Keith Swenson 11/27/2008
Public Description (Wiki Format)
Asynchronous Service Access Protocol
A standard protocol that allows long running services (Asynchronous Services) to interact with each other without having to be specifically programmed for this situation. A large collection of ASAP services can be easily configured into an Ephemeral Network to solve a particular problem or handle a particular situation, which is then discarded once the resolution is found. The key to the success of ASAP lies in how easy it is to connect long running services together without programming, so that independent services can be easily combined together in new ways as potential services are added and removed from the environment.
What is an Asynchronous Service?
It is the service that is asynchronous, not the messaging.
Asynchronous Service Access Protocol (ASAP) is about a service that runs asynchronously. An asynchronous service, is one that runs independently from the calling service. This is a service that is started at one point in time, and will continue to work for some time. While duration of the task is one aspect of an asynchronous service, it is not the only one. When a service runs long enough it qualitatively changes to be something different than simply a RPC call that takes a long time. There are services that you would like to be able to start running, and then later come back and modify it, or at least cancel it. These services have the quality that once they are running, they can be communicated to (or from) multiple times.
A common mistake is to think that ASAP is about a simple service that can be invoked at one point in time and receive the response at a different time. This indeed is asynchrony in that the response comes back asynchronously. For example, performing a credit card authorization, the information is sent off to some sort of web service, and an indeterminant amount of time later the response comes back. The standard SOAP RPC pattern provides for a message in followed by a message out. The message could be delivered asynchronously, an example purely for illustration is to think of the SOAP messages being delivered by email. The request is sent off in email, some time later the service picks it up, does the processing, sends the response back by email, and sometime yet later the originator picks up the response. That is the essence of "asynchronous invocation of a web service".
Isn't this covered by other standards?
Here are some examples of asynchronous services:
- A reservation for an airline ticket. At a simplistic level, a reservation is made, a ticket purchased, and the traveler rides the airplane. The real world is not so simple. Plans change, and people call up the airline to change the reservation. You have to then have a "handle" to the reservation in order to be able to do this. This is why the travel agent gives you a "reservation id", so you can easily call back and make changes.
- A courier service delivering a package. Again, the over simplistic view is that the package is given to the courier and one point, and delivered a specified amount time later. In reality, people what to know "where is that package now" and the successful courier firms give you a "call tracking id". Using that ID you can request information about the status of the asynchronous service.
- A customer help desk, where you report a problem, and later want to be able to access information about it.
- A purchase on an on-line store. You make an order, they may need to assemble the order, or break it into separate shipments. Those separate shipment may be given to different couriers. From the purchase id you can access the separate call tracking ids to access the status of the shipments.
What is the common theme to all these? They can take a long time, yes that is true. It is not just that they take a long time, but they take long enough time that someone wants to know what the status is, or something external has changed requiring corresponding modification to the service. In all of these cases, the unifying theme is that they can be accessed multiple times over the course of the service. The service itself runs asynchronously. It can be contacted to find out the status. It might be able to be updated.
No other standards group is taking on the task of specifying a standard way to invoke an asynchronous service, specifying a standard way to ask for the current status of that service, of delivering updated information to it, or a standard way to receive notifications from it. These are unique to ASAP.