7.1. The Reference Model The WfMC reference model[*] describes at a high level the main pieces of a workflow management system. The model's overall structure is depicted in Figure 7-1. [*] D. Hollingsworth, "The Workflow Reference Model : 10 Years On," in Workflow Handbook 2004. Lighthouse Point, FL, Future Strategies, 2004.
In Figure 7-1, the boxes represent components and the arrows interfaces. Here are its components:
Process definition tools A process definition tool is an editor used by a business analyst or developer to compose a business process definition. Typically this tool is graphical, allowing the user to build the process by dragging and dropping boxes and arrows onto a design canvas. But the WfMC model does not require that the tool be graphical, nor does it prescribe a particular graphical representation language; there is nothing like BPMN (described in Chapter 6) in the WfMC world. The tool could just as well be a text editor. The key requirement is an ability to export the process definition in a standard form, which in turn can be executed by the workflow enactment service.
Figure 7-1. WfMC reference model 
Workflow enactment services and constituent engines An enactment service runs workflow processes. The service accepts as input process definitions imported from process definition tools. It creates and manages the overall execution of instances of these processes. A process does not run in isolation, and hence the enactment service provides open interfaces to external (client and invoked ) applications and administration and monitoring tools that read the state of and participate in the execution of a process. A service can have multiple workflow engines, where each engine does the actual processing for one or more instances; the precise relationship is not adequately stated in the WfMC documentation. When the execution of a process can be distributed to multiple enactment services, an interface exists for communication between services.
Workflow client applications Workflow client applications provide an interface for human beings in the organization to participate in the workflow process. Each activity (or step) in a process is either manual or automatic. A manual activity is assigned to a person for execution. A worklist client application finds, categorizes into work lists, and prompts for the completion of, manual activities for a specific person. For example, it shows a bank manager all pending application approvals, grouped by account type and sorted by priority; further, for each approval activity, the application allows the bank manager to either approve or reject, and the result is sent to the process instance, which then resumes its flow, the pending manual activity having completed.
Invoked applications An invoked application is an external application called by the process in an automatic activity. A process does not run in isolation but interfaces with real systems (such as CRM , ERP , and mainframe) and infrastructure components (including email, fax, imaging, and document management) using a variety of communication mechanisms (such as J2EE, COM, web services, MOM, and JDBC).
Administration and monitoring tools In the WfMC model, administration and monitoring covers various forms of workflow system management, including the management of users and roles (creation and maintenance of human process participants) and the monitoring of process instances (getting and setting state, and aborting stray processes).
The model's interfaces can be categorized into three groups, which are examined in greater detail in the remainder of this chapter:
XML Process Definition Language XPDL is the XML process definition format for exchange between a process definition tool and the enactment service. An XPDL document specifies one or more process definitions, each of which is a set of activities and transitions.
Workflow Application Programming Interface WAPI is the API, with bindings in C, CORBA IDL, and COM Automation, for interaction between the enactment service and workflow client applications , invoked applications, and administration and monitoring tools. A workflow client application uses WAPI to discover manual activities assigned to a particular user or user group; additionally, it uses WAPI to complete or reassign activities. WAPI's invoked application interface extends the enactment service with adapters (also known as tool agents) to perform automated activities by calling specific external systems or polling them for events. As for administration and monitoring, WAPI includes functions to query and set the state of in-flight processes, enable or disable process definitions, and abort running instances.
NOTE For administration and monitoring, the WfMC has also published a specification for common workflow audit data (CWAD) . According to this specification, when events in processes, activities, and manual work items occur, the workflow engine is required to capture them and persist them in a form that complies with the abstract CWAD data model. The data can then be queried for administrative, business monitoring, or business reporting purposes. (For example, what is the average duration of a particular manual activity? When is the last time a particular process was run?) CWAD event types are mapped to WAPI and WfXML services. When the WAPI function WMChangeWorkItemState is called, for instance, the engine must record the CWAD event WMChangedWorkItemState. CWAD is not a core topic in the study of the WfMC, and hence is not discussed further in this chapter.
Workflow XML WfXML is a web-service-based communication language used between enactment services. WfXML allows enactment services to exchange information about process definitions, process instances and activities, and to cooperate in the execution of processes. The reference model adopts the notion of a heterogeneous process, whose activities span multiple enactment services. For example, in a three-step process, Steps 1 and 3 are bound for service A, and Step 2 is targeted for service B. This notion and its implementation with WfXML is described in the later section on WfXML.
The sequence diagram in Figure 7-2 illustrates the main types of interactions in the reference model. The scenario involves three activities: one manual, one automatic, and one executed on a separate enactment service. Figure 7-2. Component interactions in the WfMC reference model 
In the automatic activity, the enactment service (Enactment Service 1, the main service) calls the Invoked App adapter to start the external interaction with External System. The enactment service then repeatedly calls getStatus until the invoked application has retrieved a result from the external application. In the manual activity, the service assigns an activity to a particular person. The Worklist App, which provides a user interface to the enactment service for the user, retrieves from the service all activities for that person. The Worklist App application prompts the user to complete the manual task, and notifies the enactment service of this with completeActivity. The interservice activity involves an exchange of messages (perform activity, activity complete) between the two enactment services, 1 and 2. Along the way, an administration and monitoring application watches the activities by calling into the main enactment service (e.g., getActivityState, which retrieves the state of a given activity). |
