WfMC Brings Standard Protocols to BPM
Workflow standards group will demonstrate products based on Wf-XML 2.0 protocol and ASAP interoperability at conference this week
The Workflow Management Coalition (WfMC) will conduct a live demonstration on Wednesday of products that have implemented the group's Wf-XML 2.0 protocol for asynchronous workflows.
More Software Insights
- Government Analytics: Set Goals, Drive Accountability and Improve Outcomes
- 2012 IBM Chief Information Security Officer Assessment
The ASAP/Wf-XML 2.0 demonstration will be part of the BrainStorm Group's Business Process Management Conference in San Francisco on June 23, both in front of both a live audience and online observers. Participants who have implemented the protocol include Fujitsu Software Corporation, HandySoft and Staffware. These vendors will participate in a demonstration of a Web commerce scenario that involves a customer, a retailer and a manufacturer. Because Wf-XML is built on ASAP, a protocol for asynchronous services across the Internet, the scenario will simultaneously demonstrate ASAP interoperability.
ASAP, the Asynchronous Service Access Protocol Version 1.0, was developed by an OASIS technical committee. It is a Web services protocol that uses XML and SOAP 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 -- 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, builds BPM and workflow interchange capabilities on top of ASAP's SOAP structure. 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.
ASAP and Wf-XML are tightly integrated, as evidenced by the fact that Keith Swenson, chairman of the WfMC Wf-XML Working Group, is also chairman of the OASIS ASAP Technical Committee. Swenson is chief architect of Fujitsu Software Corporation.
The WfMC, the primary standards body for the workflow community, has a long history. It was founded in 1993 as a non-profit organization of workflow vendors, users, analysts and university/research groups. The architecture the WfMC defined in 1994 still stands today, Swenson said in an emailed interview. What's changed are the delivery protocols: "In that architecture an 'interface 4' was defined to describe how workflow and BPM systems would interoperate at runtime. In 1996 several members demonstrated interoperation using MIME encoding and SMTP messages. In 1997 we defined a CORBA standard interface for the same interface. In 1998 we defined an XML-based implementation called SWAP and in 2000 Wf-XML 1.0. Since this was before SOAP, we now find ourselves redefining again on top of SOAP."
Why two standards, Wf-XML and ASAP, rather than just one? "We realized that parts of SWAP and Wf-XML were too much workflow- and BPM-related," said Swenson, "and that other parts of it would be useful for a generic service. For example, ASAP is useful for a grid service, without that grid service being a workflow service. Seeing that ASAP would have wider applicability, we split the capability into two levels. The generic part of this would be of interest to OASIS, so we took the work there, while WfMC would continue to support the workflow specific extensions."
In some ways Wf-XML is the senior of the two standards: The concepts behind it have been supported for some time, said Swenson. "SAP and Staffware have had implementations of the earlier Wf-XML 1.1 for years. These were not widely used because without the associated security, reliability, and transactional standards which SOAP brings and which were beyond the scope of Wf-XML it was hard to use widely. This is the reason we are moving to be on top of SOAP -- so that these other important pieces will be available.
ASAP supports Wf-XML workflow with most of the existing standards for Web services, including XML, SOAP, WSDL, UDDI, WS-Security, WS-Reliability, and WS-CAF. "ASAP is a specific choreography -- a specific fixed pattern of interaction with specific SOAP calls with well defined meanings," said Swenson. "There is also BPEL, a programming language you can use to implement or describe the ASAP protocol. We don't know of any standard that aims to do what ASAP does: provide a specific pattern of interaction that can be used to easily connect two systems."
In understanding ASAP you should avoid confusing "asynchronous service" and "asynchronous messaging," Swenson cautioned. "A lot of people do that before they understand it. ASAP can use either synchronous or asynchronous messaging when you make the SOAP calls. ASAP is not simply a single round trip. It can be many separate SOAP calls between the connected resources in order to keep the data in sync. The point is that you can have a long-term service, like a home purchase escrow process, and another long-term service, like a home mortgage application, that can be kept in sync over the life of both of these services."
The demonstration this week will involve three vendors and two open-source initiatives in an e-commerce workflow scenario in which a client places an order with a retailer and the retailer relays the order to a factory. Confirmation and status information flows in the other direction, from factory to retailer to client, all after delays that reinforce the asynchronous behavior of the various services involved.
The purpose of the demonstration, said Swenson, is to show that all the technology is available in Java, .Net, and other environments, to begin using the ASAP pattern today: "The ASAP specification is at the 'committee draft' stage and will need some number of months to become a standard. You will start seeing products with early implementations coming soon. We believe that ASAP is ready for use to the same extent that the rest of SOAP infrastructure is ready for use."
There are several ways companies interested in Wf-XML can begin to explore it, said Swenson: "We have a reference client/server that can be used to test implementations written in C# and running in .Net. We also have the EasyASAP open source initiative that provides C++ source to implement ASAP. Unfortunately our Java open-source project has not made as much progress, but we hope to see something there soon. Companies should look to see if one of these projects would give them an easy way to implement the protocol. They should concentrate on the basic ASAP level for now. ASAP is well on toward being a standard, while Wf-XML, because it is built on top of ASAP, must lag a bit behind that."
For links to more information on the demonstration and how to become an observer, see the sign-up form on the WfMC Web site. For more on ASAP, see the public documents of the OASIS ASAP Technical Committee.