The world of BPMS is divided into BPEL-lovers and BPEL-haters, and the thing that BPEL-haters seem to hate most is that even the not-yet-final 2.0 version of the OASIS standard “excludes” human tasks. How can you have a “business process” execution language that cannot accommodate human-performed activities? “Out of scope”?! Are you kidding?
Of course, if you’re a BPEL vendor interested in selling to the BPM market, you have to integrate human tasks somehow, and they all do already. It’s just that they all do it slightly differently.
The world of BPMS is divided into BPEL-lovers and BPEL-haters, and the thing that BPEL-haters seem to hate most is that even the not-yet-final 2.0 version of the OASIS standard “excludes” human tasks. How can you have a “business process” execution language that cannot accommodate human-performed activities? “Out of scope”?! Are you kidding?
Of course, if you’re a BPEL vendor interested in selling to the BPM market, you have to integrate human tasks somehow, and they all do already. It’s just that they all do it slightly differently. So last summer IBM and SAP – two of the biggest BPEL-lovers – proposed something called BPEL4People, an optional extension to BPEL 2.0 that would at last standardize human tasks in a BPEL process. They published a couple white papers on the subject, put out a press release, and then went silent. Essentially nothing has been heard from them since.
Recently I began to hear references to BPEL4People again, and I went back to re-read the white papers. They’re nowhere close to a spec, but essentially description of a workflow “model” followed by an outline of how that model, in 5 different use cases, will be implemented in the ultimate BPEL4People specification. The first part basically recites the core concepts of traditional workflow software – activities and tasks, roles and role resolution, deadlines and escalation, worklists and task claiming – familiar to any bank, insurance company, utility, or government agency who has implemented workflow since the late 1980s.
The second part asserts that grafting workflow functionality onto BPEL 2.0 really demands addition of a new activity type – a People activity – to the language. Adding a new activity type is a big deal, since straight BPEL 2.0 engines won’t be able to implement it. Besides, virtually all BPEL-based BPMSs handle human workflow today without a special activity type. Instead, they typically provide a task management service – an out-of-the-box web service that manages human tasks – plus a web application, typically called a Worklist, through which participants view, claim, and perform their assigned tasks. Standard BPEL calls human tasks by invoking the task management service. This service, external to the BPEL, performs task role resolution and state management, and monitors deadlines and escalation logic. When the task is complete (or failed), the task management service calls back the process with the results.
The “obvious” path of least resistance for standardizing human workflow in BPEL, then, would seem to be standardizing the task management service. Because that would not require a new BPEL activity type, it would work from any BPEL 2.0 engine. But that’s not what BPEL4People does. I went back to the white paper authors to find out why.
IBM and SAP have two problems with this path of least resistance. One is philosophical. If they must be mediated through an external service, human tasks are not “first-class” participants in a business process. Another is more down to earth. When BPMS becomes pervasive, tasks will be supplied by application software vendors, and must be able to work with both standard BPMS engines and the application vendor’s own workflow application. The variety of ways in which human tasks integrate with BPEL processes is at the heart of the BPEL4People challenge.
The white paper describes five distinct task definition scenarios and their corresponding interaction patterns between process and task (Figure 1). Four of the five are based on the proposed new People activity type. The task interface in all five scenarios is specified by XML input and output parameters, but not necessarily by a WSDL portType. The key point is that all five are “equally important” to the BPEL4People authors and the proposed standard, they insist, must accommodate all of them.
Figure 1. BPEL4People embraces five distinct process-task interaction patterns. Source: IBM
In Pattern 1, the task is specified inline within a People activity. In Pattern 2, the task is specified inline within the BPEL process, and reusable by multiple activities in that process. Patterns 1 and 2 are similar to traditional workflow engines. They have the advantage of inherent context-sharing between task and process. That means, for example, that when a task assignment is resolved to a particular individual, the process knows who has performed previous tasks in the process instance. This allows assignment either to the same individual (what the white paper calls “chained execution”) or to a different individual (what the white paper calls the “four-eyes principle”), depending on the circumstance. Taken for granted in traditional workflow, context sharing is more difficult in BPEL, where tasks are implemented as remote services.
In Pattern 3, the task is defined externally to the process, and callable by multiple BPEL processes. This pattern allows an application vendor (like SAP) to expose its functionality as tasks that can be called from any number of process engines, including third-party. The interaction protocol between process and task is implementation-specific, allowing vendors to add their own state coordination, context-sharing, and other bells and whistles. Pattern 4 is like 3 except that the task interface is explicitly WSDL. That means things like process-task state coordination – for example, letting the task terminate the process or vice versa – need additional protocol extension. More on this later.
Pattern 5 is like 4, except that the task is callable from a standard Invoke rather than from the new People activity type. But even Pattern 5 is not really what I described above as the typical way BPMS vendors do it today, using a task management service to mediate the interaction between process and task. In BPEL4People Pattern 5, each task has its own WSDL interface, while in the task management service case there is a single WSDL interface common to all human tasks. A motivating use case for Pattern 5, as described by IBM, is the ability to replace a human task with an automated business rule having the same WSDL interface, with no change in the calling BPEL.
In patterns 4 and 5, the task is external to the process, but the two need to coordinate their state, so that one can terminate the other, or at least request termination. This coordination issue is not specific to human tasks, but a general problem with BPEL: BPEL does not have a concept of subprocesses. To standard BPEL, a called subprocess is just like any other invoked service. Any context sharing or state coordination protocol has to be explicitly programmed in both the calling and called process. You certainly don’t get it for free by declaring process (or task) B to be a child of process A. But the BPEL4People white paper is silent on what that protocol is. Interestingly, the BPEL4People authors submitted another BPEL extension proposal for subprocesses (BPEL-SPE) around the same time. While acknowledging extensive “symmetries” between the subprocess problem and the task state coordination problem, IBM and SAP are still not prepared to say whether BPEL4People will rely on BPEL-SPE or implement its own variant of it.
Will BPEL4People succeed? The authors’ current position that a BPMS must support all five interaction patterns to be considered “compliant” is, in my view, overly ambitious and unlikely to be adopted beyond IBM and SAP themselves – if even they can achieve it. For example, task implementation, role resolution, and state management must be provided both in the BPMS itself and externally, and implement a yet-to-be-specified process-task state coordination protocol.
Obviously there is a need for some standardization of human interaction in BPEL, but a less sweeping architecture seems much more likely to be implemented in the end. Standardizing the portType and basic features of the task management service (both its process and Worklist interfaces) would be a more practical approach, perhaps adding something along the lines of a lifecycle state coordination protocol.
