Business
Object Workshop IIIBusiness
Object Workshop III
See also RainMan: A Workflow System for the Internet by the same authors.
Abstract
The OMG BODTF has issued an RFP for a workflow standard, and by the time this workshop is held, the initial responses to the RFP will be in. We outline a set of important requirements that can be used to evaluate the responses. We also analyze the current version of the dominant workflow standard from the Workflow Management Coalition (a workflow industry consortium), and enumerate its weaknesses in the context of workflow execution across a heterogeneous, distributed infrastructure. The OMG BODTF needs to be aware of these weaknesses in order to avoid them in its own upcoming workflow standard.
Workflow systems are essential to corporate organizations that need to automate their business processes. They allow organizations to specify, execute, and efficiently monitor their business processes over enterprise-level networks. This has the net effect of improved throughput of processes, better utilization of organizational resources, and efficient tracking of processes. By separating the specification of a business process from the specifications of its constituent tasks, workflow systems provide flexibility in the design of process-based applications. Many workflow systems are commercially available [Silver95]; FlowMark [FlMa], VisualFlo[VisFlo], InConcert [InConc] and ActionWorkflow [ActWork] are among the notable examples.
The relationship between workflow technology and business objects technology is emerging as an area of significant interest. On one hand, workflows can be used naturally to script together business objects within the context of larger processes (i.e., a workflow 'invokes a' business object). This relationship is a special case of the problem of application invocation in workflow systems. On the other, workflows may themselves be business objects (i.e., a workflow 'is a' business object). Together, the two relationships indicate a recursive relationship between workflows and business objects. It is now clear that workflow technology must be supported as an intrinsic part of a distributed business object infrastructure. Consequently, the OMG Business Object Domain Task Force has issued an RFP for a workflow management standard (BO RFP2, formerly CF RFP9), and the first round of submissions are expected from about 25 vendors by August, 29th 1997. Revised submissions are due by the end of the year.
The intent of this paper is to present a set of essential requirements for interoperable workflow execution across a distributed business object infrastructure. Interoperability is critical for two reasons. First, proprietary workflow systems have flooded the market causing users to demand standards-compliance. Second, global connectivity (as demonstrated by the Internet) has opened up the possibility of inter-organizational workflow applications. At the present time, the dominant workflow standard is the Workflow Reference Model defined by the Workflow Management Coalition (WfMC), an industry-wide consortium of workflow vendors. WfMC defines a generic workflow architecture and a set of interfaces based on a two-tier client server model [WfMC].
Despite its acceptance by vendors of current workflow systems, it is our view that the WfMC standard contains pitfalls that must be avoided by submissions made in response to the OMG workflow RFP. In this paper, we propose a set of requirements that the OMG workflow standard should meet to be suitable for a distributed business object infrastructure. Next, we identify the architectural decisions that make the WfMC Reference Model unsuitable for such requirements.
In this workshop last year, Schulze et al [Schu96] presented an initial case against the WfMC Reference Model. They rightly identified the heavyweight 'engine' approach as being incompatible with the distributed object model and a primary bottleneck in terms of performance. In its stead, they recommended the adoption of a lightweight workflow infrastructure based on distributed object design. Our paper analyzes the WfMC Reference Model in greater detail and identifies further problems with the WfMC approach. Our views, combined with those of Schulze et al, could serve as a basis for evaluating submissions made in response to the OMG Workflow RFP.
The important challenge faced by workflow systems at this time is to enable support for distributed or decentralized workflows (Figure 1). We define distributed workflows as process-based applications that can easily execute in a wide area network environment (such as the Internet) across heterogeneous platforms and environments. A typical distributed workflow is described below.
Figure 1: Distributed Workflows: Heterogeneous Servers, Participants, and Applications on a WAN
Consider a virtual team of IT consultants from different companies, scattered across the globe. The team is working on a special project that requires the use of a specific workflow to ensure the quality of project deliverables. The consultants themselves may be mobile and intermittently connected to the network via portable computers or personal digital assistants. Irrespective of her location, the project leader may want to monitor and alter the workflow at any time. Similarly, irrespective of location, specific work items assigned to a participant must appear on his worklist during workflow execution. The workflow may contain automated steps that involve the looking up and updating of network databases, sending email and faxes, and printing documents on printers that are physically accessible to mobile participants. The workflow may also interact with a variety of other subworkflows, running on heterogeneous machines on the network, either by way of nesting or simple triggering. Finally, each participant in this workflow may also be simultaneously participating in many other workflows on the network.
Based on scenarios such as the one above, the following requirements for a distributed workflow infrastructure seem appropriate:
To summarize, a distributed workflow infrastructure must be based upon the principles of loose-coupling between heterogeneous workflow backends and heterogeneous workflow participants/service providers. It must allow significant autonomy to workflow participants and service providers with respect to how they receive and perform work. The relationship between the workflow backends and participants should be based on a peer-to-peer execution model, as opposed to a tightly-coupled client server model.
In this section, we present a quick overview of the components of the WfMC Reference Model and the interfaces between them (Figure 2).
Figure 2: WfMC Reference Model
The WfMC Reference Model (shown in Figure 2) defines five components:
Next, the WfMC Reference Model defines interfaces between the components:
While the WfMC standard represents a necessary step in the direction of workflow system interoperability, the current version of the standard has significant weaknesses that limit its value in a heterogeneous, distributed environment. Most of the weaknesses in the standard stem from the monolithic nature of the workflow server, which impedes the flexibility and scalability of workflow systems. In this section, we describe the shortcomings of the WfMC architecture.
The Workflow Server in the WfMC Reference Model is responsible for all of the following functions (Figure 3):
Figure 3: Monolithic Workflow Server
Centralizing all of these functions in a single logical entity results in a system architecture that is inflexible and unscalable. A few examples serve to illustrate the point.
Worklists cannot be shared by heterogeneous workflow backends
Since user worklists are hidden within the workflow server and are not externally addressable, processes are only able to send work items to worklists that reside in the same workflow server. Thus, in order for a participant to participate in multiple workflows running on heterogeneous servers, she must have an identity and a worklist maintained separately inside each workflow server she wishes to receive work from. In addition, the workflow client application must now manage multiple client connections to each of these workflow servers in order to receive work (Figure 4). This is not a scaleable solution, since it overloads the client application with unnecessary functionality whenever a participant wishes to participate in a large number of workflow applications from different servers. Because of the complexity in the client, this architecture is not suitable for workflow participation using thin clients and tier-0 devices (personal digital assistants). In effect, this architecture is analogous to a (hypothetical) electronic mail delivery architecture where recipients must explicitly connect to sender machines to collect their e-mail.
Figure 4: A dedicated connection to each Workflow Server
Disconnected operation is difficult
Even though work items are logically owned by the workflow participants, the WfMC architecture assigns the task of managing work items to the workflow server. Consequently, the participant interacts with a remotely located work item, and each interaction between the participant and an associated work item results in a remote access (usually an RPC). While this design has potential benefits when work items must implement some server-side functionality, it imposes severe constraints on disconnected workflow participation, since the network must be constantly available for the participant to do any work.
The WfMC standard also involves workflow servers in client-side application invocation, via the proposed Interface 3. For example, if a participant needs to invoke a local application such as a word processor as part of a work item, the workflow server that owns the work item must invoke the word processor on the participant's behalf on the participant's machine via the proposed Interface 3. The consequence of this intrusive approach is that participants can work only when directly connected to the workflow server - they cannot operate in a disconnected mode.
Premature binding of activities by the workflow server
The WfMC architecture makes clear distinctions between how a workflow server assigns work items to human participants, how the server invokes applications, and how the server invokes subworkflows on other workflow servers. For human participants, the server assigns work items to the participant's worklist (which is resident on the server itself), and expects the participant to explicitly 'pull' the contents of the worklist via Interface 2. For application invocation, the server uses Interface 3 (which is currently unavailable but will presumably be a synchronous RPC mechanism). For subworkflow invocation on another workflow server, the server 'pushes' a request to the receiving server via Interface 4.
Effectively, even though humans, applications, and other workflow servers play the role of generic service providers to a owner workflow server (the server on which workflow executes), three different communication paradigms (pull, RPC, and push) are introduced by the WfMC model to deal with the issue of service provider invocation. In addition to being redundant, such artificial distinctions cause a lack of transparency in how activities are actually implemented. The consequence of drawing such distinctions is that the owner server must make early judgments about the actual implementation of an activity. It either knows that the activity is manual and treats it as a leaf-level work item, or it knows that the activity is an application invocation and issues an RPC, or it knows that the activity is an embedded workflow and issues a 'push'. Such an approach precludes late-binding of activities.
For true distributed workflow execution, the workflow should belong in the domain of the owner workflow server and the implementation of activities should belong in the domain of a participant or service provider (human, application agent, or other workflow server). The owner workflow server should hand over the request for an activity to the service provider (through a generic interface), and let the service provider decide how the activity is actually implemented. The WfMC approach shifts the ownership of activity implementation to the workflow server that owns the workflow, where it does not belong, and thus undermines the autonomy and flexibility of the participant or service provider [Ludwig].
In addition to the architectural shortcomings described earlier, the specification of the published WfMC interfaces are client-oriented. They describe how a particular client application (such as a process definition tool, a monitor, a workflow client) communicates with the workflow server. This is an unusual perspective. Instead, the proper object-oriented approach would define the methods on a workflow server interface. This would offer a uniform and logical view of the services provided by a WfMC-compliant workflow server. Presumably, the WfMC defines the interfaces from the perspective of client applications in order to enforce access control on the workflow server; however, access control to the server based on a client's identity is really the domain of an authentication system, and should be addressed orthogonally.
Segregating APIs for implicit access control at the expense of a clear definition of the workflow server interface has ramifications. In many cases, the same functions on the workflow server are repeated across multiple WfMC interfaces, resulting in significant redundancy between them. For example, process control functions appear in Interfaces 2, 4, and 5. To compound the problem further, the redundant methods are specified differently in each of the interfaces.
The WfMC Reference Model ties itself very closely to a physical workflow system architecture characteristic of current workflow products. The standard defines a client-server system architecture where the workflow server is monolithic and centralizes critical workflow services such as process management, activity distribution, worklist management, and directory services. It does not define the individual interfaces to any of these services. While centralizing workflow functionality in one location offers important benefits such as tracking and possibly transactional support for workflow applications, the monolithic architecture of most centralized servers does not address the needs of distributed workflows on a WAN which must necessarily execute in a distributed manner.
The monolithic architectures further seem to indicate that traditional workflow systems were designed explicitly for single-vendor environments. In this homogeneous environment, all workflows would be specified using a single, proprietary workflow specification model, executed on a proprietary workflow environment, and utilize human and computational resources registered in a single directory service or name space. With the advent of global connectivity and the strong push for open standards within and across enterprises, these assumptions need to be revised. Specifically, the decision of not exposing the interfaces to worklists from the workflow server end needs to revisited by WfMC. The same is true of the decision to use three different communication models and interfaces to invoke humans, applications, and other workflow servers.
The responses to the OMG Workflow RFP should address the problem of distributed and decentralized workflow execution via inter-operable workflow components that reside across a global network infrastructure. The responses should be judged for their scalability, flexibility, and interoperability, and specifically on how they address the requirements outlined in Section 2. A workflow standard needs to emerge that enables interoperable workflows across dispersed individuals, multiple organizations, scattered network resources, and completely heterogeneous computing and networking platforms. We hope this paper will provide valuable input to the OMG evaluation process for the Workflow RFP.
Business
Object Workshop III