It is the SERVICE that is asynchronous, not the MESSAGING

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

Title: It is the SERVICE that is asynchronous, not the MESSAGING

I am still getting requests from people who confuse asynchrounous service with asynchronous messaging.  Look at this question:

Q1. The draft mentions about the ASAP can work as the underlying solution for async. message. Does it mean ASAP is the only async. message solution for WfXML?

Q2. In M$ solution for WebServices, it generate IAsyncResult for each method in WSDL. Are there any implied or overlapped features between MS.NET and ASAP? The question help us to decide proper WebService platform to work on ASAP-related features. (i.e. MS.NET or Java AXIS) The code is cut from MS.NET generated soap proxy:
public System.IAsyncResult BegincreateProcess(string memID, string proID, object[] args, System.AsyncCallback callback, object asyncState) {
return this.BeginInvoke("createProcess", new object[] {
memID,
proID,
args}, callback, asyncState);

Also, look at this extract from a popular article about ASAP:

[ASAP] will accommodate latency between the request for a resource or service and its actual return

That article also includes this quote from TC member Gavenraj Sodhi:

"Asynchronous communication among Web services is ...",

Both of the above statements are true, but they focus on the aspect of ASAP that if often confused with asynchronous messaging.  It is very very common to confuse the concepts of asynchronous messaging and asynchronous services.  Then people either (1) avoid the group because it appears to be an overlap with other groups, or (2) get disappointed when they find out what the group is really about.  I suggest we include the following clarification promanently on either the main page or as a FAQ item.

Of course, I want to make sure that the TC members agree that this is consistent with the charter and the previous representations of ASAP.  It is possible that I have it wrong.  So I am distributing this to the mailing list first for your comments.  Thank you in advance for taking the time to read and comment on this.

-Keith Swenson

----------------------------------
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 asynchrounously, 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 somthing 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 traveller 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 leter 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 asychronous service, specifying a standard way to ask for the current status of that service, of delivering updated infromation to it, or a standard way to receive notifications from it.  These are unique to ASAP.

-------------------------------------------------------

All this makes me wonder if the word "asynchronous" is really much more problematic than we initially thought.  I have not come up with a better term though.

Keith D Swenson, kswenson@fsw.fujitsu.com
Fujitsu Software Corporation
3055 Orchard Dr.  San Jose, CA, 95134
(408) 456-7667   mobile: (408) 859-1005