The Workflow Management Coalition (WfMC) Working Group 4 is assembling a demonstration of products that have implemented the Wf-XML protocol. We are looking for people interested in observing this demonstration.

Here are the slides (1MB zipped) from the live demonstration which took place on Monday, February 28 at the BPM Think Tank. This demo was repeated on March 11 at 0800 Pacific time with online observers only.

To become a PARTICIPANT in the next demonstration in the scenario role of Customer, Vendor or Retailer, follow the sign-up instructions here.

The discussion forum for feedback has been set up at www.workflow-research.de/Forums .

• ASAP/Wf-XML 2.0 Cookbook—Updated in Workflow Handbook 2005
  Keith D Swenson, Fujitsu Software Corporation, United States This paper is for those who have a process engine of some sort, and wish to implement a Wf-XML interface. At first, this may seem like a daunting task because the specifications are thick and formal. But, as you will see, the basic capability can be implemented quickly and easily. This paper will take you through the basics of what you need to know in order to quickly set up a foundation and demonstrate the most essential functions. The rest of the functionality can rest on this foundation. The approach is to do a small part of the implementation in order to understand how your particular process engine will fit with the protocol.

• Wf-XML 2.0 (Current Draft) 337kb PDF
  wfxml20.xsd (updated November 2005) 7kb

• ASAP & Wf-XML Demo Scenario June 2004
  Demo_scenario_1k.pdf

• ASAP/Wf-XML 2.0 Cookbook in Workflow Handbook 2004
  This paper is for those who have a process engine of some sort, and wish to implement a Wf-XML interface. At first, this may seem like a daunting task because the specifications are thick and formal. But, as you will see, the basic capability can be implemented quickly and easily. This paper will take you through the basics of what you need to know in order to quickly set up a foundation and demonstrate the most essential functions. The rest of the functionality can rest on this foundation. The approach is to do a small part of the implementation in order to understand how your particular process engine will fit with the protocol.

• http://www.oasis-open.org/committees/asap

• Asynchronous Service Access Protocol (ASAP) Version 1.0
  Working Draft G, June 4, 2004 wd-asap-spec-01g.pdf asap.xsd (updated November 2005) asap.wsdl

• A good resource is the OASIS Cover Page on the subject
  http://xml.coverpages.org/wf-xml.html

• Wf-XML 2.0/ASAP (October 2003)
  ASAP_WfXML_2003_10.zip (zipped 158kb) XML Based Protocol for Run-Time Integration of Process Engines This document will:

  - Provide an executive overview
  - Specify the goals of Wf-XML as an extension of AWSP.
  - Explain how resource (object) model works and how URIs are used to invoke methods of those resources.
  - Specify preliminary details of the interface methods and parameters

• Background Information
  AWSP (Asynchronous Web Services Protocol ) June 2002 (Historical Reference ONLY) (awsp-2002-04-05.zip).( zipped 497kb.) In April 2002 at the San Francisco meeting of WfMC, the AWSP (Asynchronous Web Services Protocol was presented, discussed, and found to meet all the goals that had been identified at the Muenster meeting. These goals specifically were (Layer on top of SOAP, Use XML Schema representation, Multiple Observers, Subscribe/Unsubscribe,Set process instance data). Since that time: this work has evolved into the ASAP technical committee of OASIS, and has been entirely subsumed by that other work. Please use this document only for historical reference, and refer instead to the ASAP working group (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap) for current implementation information.

• What is the relationship between Wf-XML and ASAP
  Wf-XML is designed and implemented as an extension to the OASIS Asynchronous Service Access Protocol. ASAP provides a standardized way that a program can start and monitor a program that might take a long time to complete. It provides the capability to monitor the running service, and be informed of changes in its status. Wf-XML extends this by providing additional standard web service operations that allow sending and retrieving the “program” or definition of the service which is provided. A process engine has this behavior of providing a service that lasts a long time, and also being programmable by being able to install process definitions.

• Why do we need a standard protocol for this?
  Because it is anticipated that process editing tools and process execution tools might be produced by different vendors. A standard way to retrieve process definitions and send definitions will allow a user to match the best process definition tool with the best process execution engine for their needs. We already have groups defining process languages to give a common way to express a particular process definition. Wf-XML completes the job by giving a standard way to pass the process definition between the design tool and the execution engine

• Where did Wf-XML come from?
  The roots of the current effort began in 1997 with the Internet Engineering Task Force (IETF) effort named Simple Workflow Access Protocol (SWAP) lead by Netscape, Oracle and others. This was followed by the WfMC standard known as WfXML 1.0 and WfXML 1.1. Wf-XML was implemented by a number of commercial products. Because it was invented before SOAP, it does not use SOAP message structures. ASAP and WfXML 2.0 are efforts to move the same capability to be on top of SOAP messages, and to conform to other web standards that have come into existence in the mean time.

• What would Wf-XML be used for?
  Wf-XML is an ideal way for a BPM engine to invoke a process in another BPM engine, and to wait for it to completed.

• How can Wf-XML be used by BP Design Tools?
  Wf-XML provides a standard way to retrieve a process definition from a BPM engine, and to provide an updated one to the BPM engine. A process design tool could used this standard web services based protocol to browse processes on remote BPM server. It provides an interface between such a design tool and the BPM engine; this is the traditional WfMC Interface 1 for getting and setting the process definition. There is no other effort known to be proposed for standardizing this interaction.

• Does the protocol automatically convert the Process Definition Format?
  No. The protocol merely communicates the process definition to and from the client and server. The process design tool and the process engine must be able to agree on a format to exchange.

• How hard is it to implement?
  At this point the underlying SOAP support is readily available, and because this uses web service technology in a normal way, it is quite easy to implement the 4 or 5 web service operations that are needed.

• Is it really a web service?
  The common definition of a web service is that the messages that are to be exchanged are defined using WSDL. Since Wf-XML 2.0 is defined using WSDL, we say that Wf-XML is a standard web service. We have been careful to assure this because only by strict adherence to the standard can we have the best chance to benefit from all the other work being done on web service standards.

• Is it compatible with Wf-XML 1.1?
  No. The earlier protocol was not based on SOAP messages. While it is based on many of the same ideas, we felt the conformance to SOAP standards was more important than ability to co-operate with earlier versions of the protocol.

• Who is sponsoring the Demonstration of Wf-XML?
  The Workflow Management Coalition (WfMC) is making the arrangements for the demonstration, and the publication of the results.

Any additional questions - please email kswenson@us.fujitsu.com.