OASIS Asynchronous Service Access Protocol (ASAP) TC
Completed
Describing a standard way to start, manage, and monitor long running services
Table of Contents
- Announcements
- Overview
- Technical Work Produced by the Committee
- External Resources
- Mailing Lists and Comments
- Additional Information
Open source initiatives launched for ASAP:
EasyASAP for C++ and AxisASAP for Java.
WfMC is implementing a protocol on top of ASAP known as Wf-XML 2.0 which extends the basic generic service to include some workflow functionality.
Also, check the WfXML discussion forum for subjects related to ASAP.The purpose of the OASIS ASAP TC is to create a very simple extension of Simple Object Access Protocol (SOAP) that enables generic asynchronous webservices or long-running webservices.
For more information, see the TC Charter and FAQ
Technical Work Produced by the Committee
Wiki for OASIS ASAP TC member collaborationAlthough not produced by the OASIS ASAP TC, the following information offers useful insights into its work.
Call for Participation in OASIS Asynchronous Service Access Protocol (ASAP) TC.
CoverPages, 5 August 2003
asap: the list used by TC members to conduct Committee work. TC membership required to post. TC members are automatically subscribed; the public may view archives.
asap-comment: a public mail list for providing input to the OASIS asap Technical Committee members. Send a comment or view archives.
It is the SERVICE that is asynchronous, not the MESSAGING
The first thing to be clear about is that the Asynchronous Service Access Protocol (ASAP) is about a service that runs asynchronously, it is not simply about asynchronous messaging. An asynchronous service, is one that runs independently from the calling service. This is a service that is started, 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 made when finding out about ASAP is to think that this is simply about a service that can be invoked asynchronously, and the response can come 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".
Many people respond to ASAP by saying that other web services technical committees are already standardizing this area, and that ASAP is a redundant effort. That is usually because these people think ASAP is about asynchronous messaging. It is important to understand that certain types of services, when they have the potential to take a long time, are qualitatively different than simply taking a long time. They become something that needs to be able to be communicated to again.
For example, consider 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.
As a second example, consider 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 third example is a customer help desk, where you report a problem, and later want to be able to access information about it.
A fourth example is 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.
Providing Feedback: OASIS welcomes feedback on its technical activities from potential users, developers, and others to better assure the interoperability and quality of OASIS work.