Section 7.4. WfXML

7.4. WfXML

One of the goals of the WfMC reference model is to achieve interoperability in heterogeneous processes , or processes that span multiple enactment services, possibly crossing company boundaries and workflow vendor implementations. Heterogeneous processes are common in business-to-business communication. The travel reservation system considered in the section on XPDL, for instance, requires that a travel agency process start airline, hotel and car rental agency booking processes and wait for their completion.

Conceptually, the problem to be solved is to coordinate the activities in one process with those in another, as in the example in Figure 7-6, in which the Supplier process calls the Warehouse process and also synchronizes its activities.

Figure 7-6. A heterogeneous process spans Supplier and Warehouse

The WfMC reference model lists several heterogeneous patterns , described in Table 7-2.

Table 7-2. WfMC heterogeneous patterns

Pattern	Description
Chained	An activity in process A triggers an activity in process B.
Nested	An activity in process A triggers process B to start. Process A waits for the completion of B before resuming.
Synchronized	Process A blocks and waits for process B to trigger it.

7.4.1. WfXML Specification

WfMC's interenactment protocol is a web services model called WfXML.^[*] WfXML is built on Asynchronous Web Services Protocol (AWSP) , a specification from the OASIS group (the same group that maintains BPEL) that offers a mechanism to remotely control and monitor long-running web services (htttp://awsp.info/spec/1/0/). WfXML extends AWSP with the ability to remotely control and monitor long-running workflows. The main components of WfXML/AWSP are shown in Figure 7-7.

^[*] WfMC, "Wf-XML 2.0: XML Based Protocol for Run-time Integration of Process Engines," Version 2.0. October 2003.

Figure 7-7. WfXML components

In this model there are two web services: the one that implements the Observer interface and the Async Web Service (AWS) that implements the interfaces ServiceRegistry, Factory, Instance, and Activity. The AWS is the web service that can be controlled and monitored remotely; the observer web service is the service doing the controlling and monitoring. In the WfMC reference model, an enactment service implements both services; it can control, or be controlled by, other enactment services.

Table 7-3 summarizes the he purpose and functionality of each of these interfaces.

Table 7-3. WfXML components

Interface	Purpose	API
ServiceRegistry	Management of process definitions deployed to the enactment service.	listDefinitions( ) returns a list of process definitions. geTDefinition( ) returns the XPDL for a particular definition. setDefinition( ) changes an existing definition. newDefinition( ) creates a new definition on the enactment service.
Factory	Management of process instances running on the enactment service.	listInstances( ) returns a list of process instances. createInstance( ) instantiates a process definition, thereby launching a new instance on the enactment service.
Instance	Management of a particular instance.	subscribe( ) registers the observer as a listener for instance state change events; the enactment service calls the observer's instanceStateChanged( ) operation as state changes occur. unsubscribe( ) cancels the listener registration. listActivities( ) returns a list of the activities in the instance. changeState( ) forces an instance to pause, resume, or abort. terminate( ) abruptly stops the instance.
Activity	A controller for a process activity instance.	completeActivity( ) finishes a process activity instance that was pending.
Observer	Watches an AWS for events.	instanceStateChanged() is invoked when a process instance changes state.

7.4.2. WfXML Example

In the nested pattern of heterogeneous processing introduced previously, a process running on one enactment service instantiates a subprocess on a second enactment service and waits for it to complete before resuming. The sequence diagram in Figure 7-8 shows how the first enactment service can use WfXML to manage the nested remote process.

Figure 7-8. WfXML example: starting and monitoring an instance

The first enactment service implements the Observer interface so that it can subscribe to instance state events. The service begins by creating an instance of a remote process by calling the createInstance( ) operation of the Factory interface hosted on the second enactment service. Next, the first enactment service registers its instance state change subscription (subscribe( )) and over time is notified of the state change (instanceStateChanged( )). The final event should indicate that the instance has completed, at which point the first enactment service can resume its own workflow instance.

SOME THOUGHTS ON WFXML

WfXML is a good model for general remote process administration and monitoring. A process administrator's portal, for example, can be designed to use ServiceRegistry to deploy new process definitions and Instance to terminate stuck processes.

However, why do enactment services need a general protocol to communicate with each other? Why not have processes deployed on enactment services define their own, application-specific partner links? WfXML is intended as an architected solution, in the spirit of web services choreography, to the problem of multiparticipant process exchange. WfXML enables the creation of a process of processes, combining the activities of multiple participants (e.g., a supply chain process that contains the buyer, supplier, and distribution processes of entirely separate companies). The approach of WfXML is to allow the participating enactment services to control and monitor each other (e.g., supplier starts warehouse process and listens for its completion).