Abstract

Right now the software industry is like a cacophony of birds, proudly singing their individual themes. While each member of the chorus is producing wonderful sounds and melodies, there is no cooperation and little harmony between the parts. What we need is a conductor capable of shaping these individual voices in to a coherent theme, as John Williams molds dozens of instruments into symphonies.

There is a developing interest in the interoperability of workflow systems and large component software systems. Workflow systems handle business processes using computer automation, coordinating the efforts of hundreds of employees. Languages for design to facilitate component synthesis in software accomplish the same task with independent programs and databases. These languages will want to integrate workflow systems along with other computerized software. All of this is taking place as computing continues in the development of distributed heterogenous networks, and the lines of communication between these types of systems grow apace.

SWAP

SWAP Basics

SWAP is built around three interfaces: the Process Definition, the Process Instance, and the Observer.

Each Process Definition is a specification of a service provided to companies, such as a financial function or a information search.  Clients using SWAP-supporting tools will have a menu of Process Definitions to choose from, each of which is associated with a Unique Resource Indentifier (URI).  By using this menu of services, clients can create Process Instances by sending an HTTP request to the URI.

Process Instances represent actual tasks invoked by clients using SWAP.  Each Process Instance has a URI as well.  While it is in progress, a Process Instance can be stopped, restarted, altered or eliminated by HTTP requests. Data can be sent or results can be checked.

The Observer is any interface which can receive reports from a Process Instance which has completed its work.  The Observer's URI is provided to the Process Instance, and the Process Instance will notify the Observer of state in a number of different situations. Although the client can keep sending messages to a Process Instance to check whether it has completed or not, the IETF views this as an unnecessary waste of resources on the part of both client and work provider.

The interfaces and actors described in the SWAP protocol may be modeled by a food court at a shopping mall. The clients are the customers, and the service providers (e.g. a bank, a travel agency, or a research center) are the food vendors. The services provided are the various foods and drinks offered by each vendor. The basic idea of the food court is clear: the customers wish to select and order food items of interest from the vendors. Similarly, the clients imagined in the SWAP protocol are interested in obtaining services and results from other suppliers, agencies, or groups.

The SWAP protocol defines the language of interaction between customers and vendors. The Process Definition, Process Instance, and Observer interfaces can also be modeled by the food court. The Process Definitions are the items on the menus of the various vendors. Basic information is available from the menu: description and cost. Further information may be obtained by inquiring about the item to one of the staff. By itself, the menu description doesn't do anything but inform the customer (the description is distinct from the food itself). The Process Definition is similar: most clients will likely know only the URI at first, they can query the Process Definition interface for more information, and the Process Definition does no work by itself.

The Process Instances are like actually food orders, placed by the customer (using the menu) with the intent of receiving food or drink. Many people can place orders with a vendor at one time, and those customers may request similar items. A customer may make specific requests or specify certain aspects of their order. Customers may even check on the status of their order, change it, or cancel it. They do not, however, have any knowledge about the details of the preparation (the kitchen is closed), nor do the know exactly when the order will be ready. This is the black-box behavior envisioned by the SWAP protocol. Clients can control and monitor Process Instances they have created, but they don't know how the work is done. A provider could be handling many Process Instances invoked by one Process Definition at one time.

The Observer interface is a chosen by the client to receive notification of a completed order. At many food courts, the customer can wait at the counter for the food, listen for their number over a speaker system, or carry an electronic beeper back to their table. When the vendor has completed the order, they signal the customer, and the customer picks up the food. This is very similar to the Observer interface. As described in the protocol, the Observers could be email addresses, ftp servers, even phone numbers. The provider signals the observer when the work is completed, and the client checks the results.

Because workflow systems are designed to handle a wide variety of tasks, the analogy can’t be stretched much further. There are several more performers in the SWAP system apart from these interfaces, such as the Activity Observer, Work Items, and Work Item Factories. The Activity Observer is created when a Process Instance is waiting on the results of one or more other systems. It allows clients and providers to look up information on both the calling process and the sub-processes. Work Items are a type of Process Instance, which don’t do any work but represent a task being accomplished by a person. Work Item Factories are the Process Definitions which create Work Items.

A large portion of the draft protocol covers the methods defined by SWAP for the interactions of these interfaces. SWAP intends to utilize HTTP 1.1 format for messaging. The protocol document answers questions about user authentification, error-handling, and data structures. Anonymous messages are allowed in HTTP, but most workflow systems will use authenticated messages in order to protect their resources (time, money, and information). All SWAP-defined methods will handle exceptions and error situations in their return values. Attention is given to the interpretation of numbers, booleans, and data/time values.

There are two basic methods, shared by several of the interfaces. One is PROPFIND, a method which returns en masse all the values of the interface (either default or previously set values alike). This includes such things as the name, the URI, the description, the state of a process, or the results. The other is PROPPATCH, a method for setting any number of the interface values. This includes setting the priority of a Process Instance, or notifying an Observer of results.

The Process Instance interfaces respond to the messages PROPFIND, PROPPATCH, TERMINATE (self-explanatory), SUBSCRIBE (a message from an observer), UNSUBSCRIBE, and GETHISTORY (which returns a transaction log of the Process Instance).

The Process Definition interfaces have the message PROPFIND, but not PROPPATCH. They also implement CREATEPROCESSINSTANCE and LISTINSTANCES.

Observers interfaces should receive PROPFIND, PROPPATCH, and three signals from their associated Process Instance. COMPLETE for a normal completion, TERMINATED for a terminated process, and NOTIFY for any events prior to completion (requests for data, intermediate results, etc.).

SWAP also defines PROPFIND, PROPPATCH, and COMPLETE for Activity Observers, and it defines PROPFIND and CREATEPROCESSINSTANCE for EntryPoint Interfaces (referenced by Process Definitions when there are multiple ways of creating a Process Instance).

The charter of the IETF working group posits the completion of the SWAP specifications, goals, and requirements by September, 1999. Although a tentative date of November, 1998 was set for the draft version of the goals and scenarios documents, they are not yet available. The requirements document delves into the terminology of SWAP and goals for the interoperability of SWAP with other workflow management systems. It also places priority on scalability, security considerations, and quality of service.

There are two principle differences between SWAP and the CHAIMS Protocol for Autonomous Megamodules (CPAM). SWAP by itself makes no estimate of the amount of time needed for the completion of a task, while CPAM gives client programs the ability to call ESTIMATE on ongoing processes to determine the amount of time required. Perhaps a CHAIMS compliant wrapper of SWAP would need to come up with estimates for each Process Instance beforehand. SWAP makes use of the Observer interface as a sort of replacement for giving an estimate. CHAIMS megaprograms make all requests to megamodules directly, so perhaps a wrapper megamodule for SWAP procedures would create an Observer interface for each Process Instance it creates on behalf of a request from a megaprogram.

The other CPAM primitives (SETUP, GETPARAM, SETPARAM, INVOKE, EXAMINE, EXTRACT, TERMINATE and TERMINATEALL) can be easily replicated by similar methods in the SWAP protocol. SWAP data information is designed to be easily parsed rather than readable, so transitions to and from CPAM data should likewise be simple.

OMG jFlow

jFlow addresses the requirements for interoperability between different workflow object implementations in a CORBA environment. The interfaces specified are intended to be sufficiently general to support a wide range of application domains. These domains include healthcare, electronic commerce, manufacturing, insurance, finance, transportation, printing and publishing. JFlow specifies interfaces for workflow execution control, monitoring, and interoperability between workflows defined and managed independently of each other. The interfaces are based on a model of workflow objects which includes their relationships and dependencies with requesters, assignments, and resources.

The core of jFlow is a set of interfaces that a compliant system must implement and support. Systems then use these interfaces over IIOP to communicate and interact. A UML class diagram of the primary interfaces follows:

The core workflow interfaces are:

• WfRequester, links the immediate owner of a request for a WfProcess, i.e., it receives significant events such as ’complete’. A single requester can have many processes associated with it and is often the object that starts the process. There are two usage scenarios for the association of a WfProcess with a WfRequester: nesting of workflow processes— a WfActivity is a WfRequester and may therefore request that a WfProcess be its performer, i.e., implementation. In this case, the WfActivity would be registered as the requester with the implementing sub-process when the WfProcess is created and would receive notifications of status changes of that sub-process; upon completion of the sub-process, the WfActivity would enter completed state; Linking a workflow process to another (initiating or controlling) application— when used as a linked process the requester should be a WfRequester which is not the linking WfActivity. Requesters that are not activities are roles or adapters for external clients.

• WfProcessMgr, provides factory and location support for WfProcess; it is used to create instances of a workflow process. It provides access to the meta information about the context a process requires and the result a process produces. A process manager is identified by its name which is unique within a given business domain; it could located, e.g., via name using the OMG Naming Service, via name and other attributes (e.g., category) via the OMG Trader Service, or other infrastructure mechanisms.

• WfProcess, is the performer of a workflow request issued by a user or automated actor such as WfActivity as a WfRequester. All workflow objects that perform work implement this interface. This interface allows work to proceed asynchronously while being monitored and controlled. The WfProcess interface specializes WfExecutionObject interface by adding an operation to start the execution of the process, an operation to obtain the result produced by the process and relationships with WfRequester and WfActivity. When a WfProcess is created it enters ’open.not_running.not_started’ state. When it has successfully finished processing, it enters ’closed.completed’ state. Additional state changes can be performed using the change_state operation provided by WfExecutionObject. In general, the context of a WfProcess is set when it has been created (using an appropriate WfProcessMgr factory) and before it is started. The context includes information about process navigation data, the resources to use and the results to produce. The result of a WfProcess is derived from the process context and from results of WfActivities contained in the WfProcess. Derivation of result data is left to the implementation of the WfProcess. A WfProcess is created (using a WfProcessMgr) by a user or automated resource and associated with a WfRequester. WfProcess always has one WfRequester. A WfProcess will inform its WfRequester about status changes such as modifications of its state and its context using the requester’s receive_event operation. A WfProcess can contain zero or more WfActivity objects. The WfActivity objects represent steps in the process to be performed. The steps are assigned to WfResources or become WfRequesters that use and create WfProcesses as sub-processes. The performing of the work represented by a WfProcess may take anywhere from seconds to months to even years for major projects. Operations are provided to monitorthe status of the process and to control execution of the process. Execution of a WfProcess is initiated using the start operation; execution can be suspended (and resumed) and terminated or aborted before it completes. While the work is proceeding, the state operation on the WfProcess may be used to check on the overall status of the work. More detailed information on the status of the process can be obtained by navigating the relationship to the WfActivities contained in the WfProcess and using the status inquiries supported by this interface (see below). The get_result operation may be used to request intermediate result data, which the may or may not be provided depending upon the details of the work being performed.

• WfActivity is a step in a process that is associated, as part of an aggregation, with a single WfProcess. It represents a request for work in the context of the containing WfProcess. There can be many active WfActivity objects within a WfProcess at a given point in time. The WfActivity interface specializes WfExecutionObject with an explicit complete operation to signal completion of the step, and with an operation to set the result of the WfActivity. It also adds relationships with WfProcess and WfAssignment. The context of an activity is set by the containing WfProcess before the activity is activated; the context is derived from the context of the WfProcess and results of other activities. An activity produces a result that can be used to determine which follow-on process steps to activate. It can also be used to determine the result of the WfProcess. In general, this overall result is not set until the process is closed; however, in-process, intermediate results may be available. The set_result operation is used to feed back activity results into the process. A WfActivity is a requester of work. Activities can be assigned to resources which participate in the execution of that work; a WfAssignment represents the association of a WfResource with a WfActivity and is used to indicate the nature of the assignment. Zero or more resources can be assigned to an activity. Work items can be assigned to WfResources that accept or reject the work. Candidate resources include people or automated actors (see the section on WfResource for details). WfExecutionObject, is an abstract base interface that defines common attributes, states,and operations for WfProcess and WfActivity. Operations are provided to get the current state and to make a transition from the current state into another state. Operations such as suspend, resume, terminate, and abort are also provided for specific state transitions. The interface includes name, description, priority, and key attributes. It also provides an operation for monitoring WfExecutionObject executions by returning event audit records that represent the history of the execution. Other operations include methods for getting and setting context.

• WfAssignment links WfActivity requests for resources to potential or actual WfResources. This interface may be specialized by vendors to support context-sensitive creation and negotiation of assignments. Assignments are created as part of the resource selection process before an activity becomes ready for execution. The lifetime of an assignment is limited by that of the associated activity.

• WfResource is an abstraction that represents a person or thing that will potentially accept an assignment to an activity. Potential and/or accepted WfAssignments are links between the requesting WfActivities and WfResource objects. Basically, the WfResource facilitates creating relationships between generic entities and will evolve to serve the role of the adapter pattern to allow greater ease of creating relationships.

• WfEventAudit, is a common interface for recording workflow events. Several

subtypes of this interface are defined to record change of the state of a workflow

object, process data associated with it, and change in the assignment of resources to

WfActivities.

To start a given workflow process, a Requester that is responsible for the process must either be created or selected from the set of existing Requesters. Next, An appropriate Process Manager (the process factory, as in the Factory Patter) is identified and the Process is created using the create_process operation of that manager. The Requester is associated with the Process when it is created and will receive status change notifications from the Process. When the Process is instantiated it might create a set of Activities representing the steps necessary to complete the process. Additionally context data may be used to parameterize the process (i.e identify resources to be used by the process, etc.). The Process is actually started by invoking its start operation; the process implementation will use context data and build-in logic to determine which Activities are to be activated. It may also initiate other (sub-) Processes. When an Activity is activated, its context is set and resources may be assigned to it by creating Assignments linking it to Resources; the resource selection mechanism is not defined here, but an implementation might, e.g., use another Process to determine which resources to assign to a particular Activity, using the Activity’s context information and other process parameters. An Activity might be implemented by another (sub-) Process, i.e., it can be registered as the Requester of that Process; the sub-process can be initiated when the Activity is activated. In this case, the Activity is completed when the sub-Process completes and the result of the Activity is obtained from the result of the Process. An Activity can also be realized by an application that uses Activity’s the set_result and complete operations to return results and signal completion of the Activity. When an Activity is completed, its results will be used by the workflow logic to determine follow-on Activities; the results can also be used to determine the overall result of the container Process. A Process is completed when there are no more Activities to be activated; it will signal its completion to the associated Requester and make available the results of the process. A small but important footnote is that intermediate results may be accessible while the Process is running, which may in turn be used to determine the degree of completion and what is causing any delays. The overall status of a Process can be queried using the state, get_context and get_result operations. The Requester associated with a Process also receives notifications about status changes of the Process. More detailed information on the status of the process steps can be obtained by navigating the step relationship between Process and its Activities and using the status inquiries provided by the Activity interface. Navigation of nested workflows is supported by the process relationship between an Activity (which is a Requester) and potential sub-Processes. Whenever an Execution Object (Process or Activity) performs a (workflow relevant) status change, an EventAudit is recorded. For each Execution Object, the history of Event Audit items can be accessed to analyze the execution history of that object. Event Audits might be published using the OMG Notification Service. Perhaps one useful extension would be to extend this history functionality to create more analytical features about the history and use this analysis to predict current processes. For example, an excellent starting place might be to keep a record of completion type for a given type of Process and then use that information as a prognosticator for how long a currently running Process would probably have left or how long a given Process would take to run.

References