|
Table of Contents
Announcements
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.
Overview
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
ASAP Specification
Wiki for OASIS ASAP TC member collaboration
External Resources
Although 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
Mailing Lists and Comments
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.
Additional Information
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.
|
