The Workflow Management Coalition (WfMC) has announced a multi-vendor interoperability demonstration for Wf-XML 2.0 and the OASIS Asynchronous Service Access Protocol (ASAP). The interop demo will be held June 23, 2004 at the BrainStorm Business Process Management Conference in San Francisco.

ASAP is currently a Working Draft specification being developed by an OASIS Technical Committee. This TC was chartered to create a very simple extension of Simple Object Access Protocol (SOAP) that enables generic asynchronous webservices or long-running webservices.

ASAP is a "web services protocol that can be used to access a generic service that might take a long time to complete. Existing web services protocols protocols work best when the service can provide an answer quickly, within a minute or two at the longest. ASAP is useful when the answer might take longer than this — for example services that last from minutes to months in duration. The service being invoked might be fully automated, a manual task that a person performs, or any mixture of the two. This capability to handle both automated and manual activities is what makes ASAP particularly suited for B2B and intra-organizational service request scenarios."

Wf-XML Version 2.0 was produced by the Workflow Management Coalition (WfMC), and extends the ASAP model to include BPM and workflow interchange capabilities. Wf-XML "introduces the concept that factories themselves may be added and removed. The concept of a container resource is defined, and operations are defined to list factories and to create new ones.

A business process engine "is a special type of asynchronous service: it has the ability to be started, to involve people in that process, and to complete some time later. One BPM engine can be easily linked to another BPM engine using Wf-XML. Wf-XML extends ASAP by including the ability to retrieve the process definition, and to monitor the current state of a running process instance. Wf-XML 2.0 both simplifies and strengthens the implementation of asynchronous services to support business process interoperability."

The Interoperability Demonstration will involve products that have implemented the Wf-XML 2.0 web commerce protocol, and will include scenarios with Customer, Retailer and Manufacturer. "All clients and servers will be internet; demonstration client each have a simple UI to invoke the asynchronous services from a web form. Each implementation exposes a factory that can be called with a specified context structure, and should return a specific result structure within a few seconds."

Demo Overview

Worldwide Interoperability Demonstration of ASAP and Wf-XML 2.0

• "ASAP is a web services protocol that can be used to access a generic service that might take a long time to complete — for example services that last from minutes to months in duration. The service being invoked might be fully automated, a manual task that a person performs, or any mixture of the two. This capability to handle both automated and manual activities is what makes ASAP particularly suited for B2B and intra-organizational service request scenarios.

• Wf-XML 2.0, from the Workflow Management Coalition (WfMC) extends this to include BPM and& workflow interchange capabilities. A business process engine is a special type of asynchronous service: it has the ability to be started, to involve people in that process, and to complete some time later. One BPM engine can be easily linked to another BPM engine using Wf-XML. Wf-XML extends ASAP by including the ability to retrieve the process definition, and to monitor the current state of a running process instance..." [from the Brainstorm Conference description]

About ASAP

From the Asynchronous Service Access Protocol (ASAP) Version 1.0 (Working Draft G, June 4, 2004):

"A standard protocol is needed to integrate asynchronous services across the Internet and provide for their interaction. The integration and interactions consist of control and monitoring of the services. Control means creating the service, setting up the service, starting the service, stopping the service, being informed of exceptions, being informed of the completion of the service and getting the results of the service. Monitoring means checking on the current status of the service and getting an execution history of the service. The protocol should be lightweight and easy to implement, so that a variety of devices and situations can be covered.

The Asynchronous Service Access Protocol (ASAP) is a proposed way to solve this problem through use of Simple Object Access Protocol (SOAP), and by transferring structured information encoded in XML. A new set of SOAP methods are defined, as well as the information to be supplied and the information returned in XML that accomplish the control and monitoring of generic asynchronous services.

This document will: provide an executive overview; specify the goals of ASAP; explain how the resource (object) model works; explain how uniform resource names (URI) are used to invoke methods of those resources; explain how to encode data to be sent or received; and specify preliminary details of the interface methods and parameters..."

[Summary:] "This protocol offers a way to start an instance of an asynchronous web service, monitor it, control it, and be notified when it is complete. This service instance can perform just about anything for any purpose. The key aspect is that the service instance is something that one would like to start remotely, and it will take a long time to run to completion. Short-lived services would be invoked synchronously with Simple Object Access Protocol (SOAP) [SOAP] and one would simply wait for completion. Because certain service instances last anywhere from a few minutes to a few months, they must be invoked asynchronously.

How does it work? You must start with the URI of a service definition called a factory. A SOAP request to this URI will cause this service definition to generate a service instance, and return the URI of this new service instance that is used for all the rest of the requests. The service instance can be provided with data (any XML data structure) by another SOAP request. The current state of the service instance can be retrieved with another SOAP request. The service instance can be paused or resumed with another SOAP request. There is also a pair of requests that may be used to give input data to the service instance, and to ask for the current value of the output data.

What happens when it is done? The service instance runs asynchronously and takes whatever time it needs to complete. The originating program can, if it chooses, keep polling the state of the service instance in order to find out when it is complete. This will consume resources unnecessarily both on the originating side as well as the performing side. Instead, the originator may provide the service instance with the URI of an observer. When the service instance is completed it will send a SOAP request to the URI of each observer. This allows the originator to be put to sleep, freeing up operating system as well as network resources while waiting for the service instance to complete..."

ASAP and Wf-XML

From Interface 4 (Interoperability) draft 'Wf-XML 2.0: XML Based Protocol for Run-Time Integration of Process Engines':

"AWSP offers a way to start an instance of an asynchronous web service (AWS), monitor it, control it, and be notified when it is complete. This service instance can perform just about anything for any purpose. The key aspect is that the service instance is something that one would like to start remotely, and it may take a long time to run to completion. Short-lived services could be invoked synchronously with SOAP and one would simply wait for completion, but because these process instances could last anywhere from a few minutes to a few months, they must be invoked asynchronously.

Wf-XML extends this in the special case that the asynchronous service is being invoked on a process engine. The Service Factory maps to a Process Definition; the Service Instance maps to a Process Instance. Process engines provide some additional capabilities for monitoring the process. First of all, because it is a process, and not simply an opaque service, there is a process diagram. This diagram can be retrieved for introspection. Second, since the process is composed of activities, one can ask the activities for their current values. An activity may itself represent an invocation of a yet another remote service, and the address of that service instance may be retrieved. Thirdly, the process definitions can be edited, removed, or added.

AWSP has established that a standard protocol is needed to connect asynchronous services, whether they are implemented as process engines or not. Wf-XML provides a way to merge process-oriented tools into the generic invocation framework. A process definition tool now has a standard way to retrieve or update a process definition. A process-monitoring tool can do the same for tracking process instances, and can follow links to sub-processes as well as sub-sub-processes..." [from the Executive Summary, "Wf-XML 2.0: XML Based Protocol for Run-Time Integration of Process Engines"]

From the Workflow Management Coalition (WfMC) Announcement

Wf-XML is built upon OASIS ASAP, so it is simultaneously a demonstration of ASAP interoperability. The ASAP/Wf-XML 2.0 demonstration will take place at BrainStorm's Business Process Management Conference in San Francisco on June 23, 2004 both in front of an audience and online with observers around the world.

Participants who have implemented the protocol include Fujitsu Software Corporation, HandySoft and Staffware who will demonstrate the scenarios of Customer, Retailer and Manufacturer.

"The ASAP standard gives companies real-world benefits of business process interoperability without programming," said Keith Swenson, chairman of the WfMC Wf-XML Working Group, chair of the OASIS ASAP Technical Committee and chief architect of Fujitsu Software Corporation. "An example of quick, easy connections between systems supporting long-term processes would be the process cycle of buying a home, involving all players from the mortgage lender through geology reports to title search and closing. Soon Wf- XML 2.0 will be available to extend ASAP with functionality specifically for BPM engines."

"Wf-XML 2.0 addresses the significant hurdles that companies have faced in attempting to optimize business processes across organizations using different BPM engines," said Jon Pyke, WfMC chair and CTO of Staffware. "We value Fujitsu's active support in the development of Wf-XML 2.0 and the Web commerce demonstration that we will use to highlight the role of Wf-XML 2.0 and ASAP in enabling business process interoperability across some of the industry's most widely recognized BPM engines."

ASAP is a web services protocol that can be used to access a generic service that might take a long time to complete. Web services protocols allow a remote service to be accessed in a standard way. Existing protocols work best when the service can provide an answer quickly, within a minute or two at the longest. ASAP is useful when the answer might take longer than this _EMMM for example services that last from minutes to months in duration. The service being invoked might be fully automated, a manual task that a person performs, or any mixture of the two. This capability to handle both automated and manual activities is what makes ASAP particularly suited for B2B and intra-organizational service request scenarios.

Wf-XML 2.0, from the WfMC, extends this to include BPM and workflow interchange capabilities. A business process engine is a special type of asynchronous service: it has the ability to be started, to involve people in that process, and to complete some time later. One BPM engine can be easily linked to another BPM engine using Wf-XML. Wf-XML extends ASAP by including the ability to retrieve the process definition, and to monitor the current state of a running process instance.

Over 1000 observers, mostly IT users, have registered to watch the demonstration, and be informed of the results.