SOA and Human Interaction

Automated business processes are an integral part of a SOA. In practice many of these processes require user interaction. The interaction scenario's can be very simple, like manual approval. However, more complicated scenario's like entering data, assignment of tasks to other users and managing long-running processes can appear. An example of a process involving human interaction is given in [1]:

"Imagine a bank's personal loan process. This process is made available on the internet site of the bank using a web interface. Customers can use this interface to enter the data for their loan approval request and to start the approval process. The process performs some checks, and eventually informs the customer whether his or her personal loan request has been approved or rejected. Processing is often automatic and does not require any human involvement. However, there are cases that require bank staff to be involved. An example of such a case is if the online check of a customer's creditworthiness returns an ambiguous result. In this case, instead of declining the request automatically, a bank clerk could check the request and determine whether to approve or decline it. Another example would be if a request exceeds the amount of money that can be approved automatically. In this case, a manual approval step is required, in which a member of the "approvers" group either approves or declines the request."

Nowadays most of this kind of automated processes is based on web services. But how can the given example process be orchestrated using web services? The de facto standard for web services orchestration seems to be BPEL [2]. This standard, however, doesn't specifically cover user interactions. This leaves us with the question: what is the right way to include human interaction in a BPEL process?

Workflow service

Several vendors have solved this problem by implementing people and manual tasks as a ‘normal' asynchronous service (from the perspective of the orchestrating process). The BPEL keeps its orginal functionality and does not need any extensions, but each task needs its own interface specified in the Web Service Definition Language (WSDL [3]). Whenever a task needs knowledge about the process state it must be passed within the invoke call to this task. This means a lot of manual work must be done for each task.

To solve this problem a Workflow Service can be introduced [4]. This service can be called asynchronously from BPEL to perform operations like adding, updating, completing, renewing, routing and escalating tasks. User applications, on the other hand, can communicate with the Workflow Service to acquire the list of tasks for selected users, render appropriate user interfaces, and return results to the workflow service, which forwards them to the BPEL process. A schematic overview is given in Figure 1.

Workflow integration with BPEL

Figure 1 – Workflow integration with BPEL [4]

This approach leaves the BPEL standard 100% the same. The Workflow Service can be implemented within an application server as long as it provides a WSDL interface to the BPEL process engine. The BPEL process doesn't have to know how user tasks are handled, this gives the opportunity to use various kinds of communication channels with users. However, no standard exists specifying the interface of such a Workflow Service. Each vendor implements its own, resulting in non-portable BPEL processes (this is not the only reason for the non-portability of BPEL processes, but that's outside the scope of this article).


IBM and SAP have taken another approach in solving the ‘human interaction problem'. In July 2005 IBM and SAP have released a white paper proposing a BPEL extension named BPEL4People [1]. BPEL4People is defined in a way that is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed.

The scope of BPEL4People is described in five scenario's. First people activities are mentioned. "From the user's perspective, the people activity is a task that is assigned to a user and requires the user to perform some action."[1] This ‘People Activity' can be seen as a special BPEL activity. The second scenario describes the ability to define which people are eligible to start a certain business process. BPEL4People also gives the ability for people to manage long-running processes. For example, when a timeout occurs, a user must be notified. This user has to decide how the process should proceed. The fourth scenario defines that the transition between human and automatic services must be non-disruptive. Finally a couple of advanced interaction patterns are given[1]: "4-Eyes Principle", "Escalation", "Nominations" and "Chained Execution". All four of them are supported by BPEL4People.

BPEL4People describes [1] the following generic human roles interacting with processes:

  • process initiator, the person who actually creates an instance of the process
  • process stakeholder, a person who can influence the progress of a process instance
  • potential owner, a person who can claim and complete a people activity
  • business administrator, is defined for a process and can perform administrative actions on the business process, such as resolving missed deadlines

These generic human roles are associated with a group of people by a so-called people link. A people link commonly contains a query against an organizational directory in order to determine the actual individuals with which it is associated.

Using these definitions a people activity is defined. This new BPEL activity is not performed by a piece of software, but realized by an action performed by a human being. The actor of a people activity is determined by a people link. A people activity can be associated with different groups of people, one for each generic human role. People activities have the same properties as standard BPEL activities, but their implementation is different. People activities are implemented by tasks. So instead of invoking some kind of web service, a BPEL engine must create a task for a certain user. These tasks are "indivisible units of work performed by a human being. They specify an action that a user must perform" [1]. Some properties of a task are a description, a priority, expected data, a deadline and a user interface. See [1] for a detailed description of each of these properties.

Models of interaction between Tasks and Processes

Figure 2 – Models of interaction between Tasks and Processes [1]

With the idea of BPEL4People clear, the question is how to implement these ideas in a real process. IBM and SAP present the possibilities, shown in Figure 2, in their whitepaper. Model 1 and 2 define an inline task used by the people activity. An inline task can be defined in a people activity (model 1) or as a top-level construct of the BPEL process. In this case the same task can be used within multiple people activities. Both models have the advantage of the possibility of context sharing between task and process. This can be used, for example, to implement the "Chained Execution" interaction pattern mentioned in the white paper [1]. The process knows who has performed the previous tasks and can assign the next task to the same person. Or, in the case of the "4-Eyes Principle", to another person.
Model 3 shows an implementation specific definition of a task outside a process without a specific interface. Thus leaving all the communication between process and task implementation specific. In that way application vendors can expose their functionality as tasks which can be called from process engines.
In model 4 the task is also defined standalone, but with an interface specified using WSDL. This is a more generic approach but an extra standard is needed to propagate state changes between process and task. This ‘coordination protocol' can be used for, for example, performing life cycle operations on the task, such as terminating it. However, the authors of the white paper didn't specify a protocol solving this problem.
Model 5 is the most generic case. In this case the task is called with a standard BPEL invoke activity. The BPEL standard remains unharmed, but each task needs its own WSDL definition. The advantage of this model is that, unless the WSDL definition stays the same, the implementation of the task can change. It is even possible to replace a human task with a business rule without the need to change the calling BPEL.
According to the whitepaper all these models have to be supported by a process engine implementing BPEL4People.


The BIG question is: what is the right way to include human interaction in a BPEL process? Obviously there is a need for some standardization of human interaction in BPEL. Just using a Workflow Service means no standardization at all. Each vendor defines its own Workflow Service depending on the specific needs. BPEL4People on the other hand standardizes a lot, but not everything. Some gaps have to be filled in, but it provides a solid base. However, I do not like the fact that BPEL4People extends the existing BPEL standard with new activities and task definitions. BPEL provides a nice orchestration standard on an abstract level. Including links to specialized services (like the people link) instead of only links to ‘abstract services' weakens the abstraction and opens doors for all kind of other extensions.

I think a better approach would be to use the foundations of BPEL4People to standardize the interface of a Workflow Service. This should be done in WSDL. I know, this is not trivial but I think the different scenario's in the BPEL4People whitepaper provide us with a good starting point. Once the Workflow Service is standardized, BPEL processes are portable (as I said: human interaction is not the only reason for the non-portability of BPEL processes, but that's outside the scope of this article) between different vendors. However, vendors can still implement the Workflow Service in their own way, integrate it with application servers, and so on, as long as they apply to the standard interface definition. So, what do you think of a Workflow Service Definition (WSD)?

[1] IBM, SAP. WS-BPEL Extension for People – BPEL4People. July 2005.

[2] OASIS Web Services Business Process Execution Language (WSBPEL).

[3] Web Services Description Language (WSDL), W3C Note 15 March 2001.

[4] Matjaz Juric, Doug H. Todd. SOA Web Services Journal: BPEL Processes and Human Workflow. 12-04-2006.

4 Comments Added

Join Discussion
  1. H. Burema August 17, 2007 | Reply

    Have a look at Athlon in Almere. (car lease firma)
    They use Uniface/staffware, all IT & Business related transactions (cases) are workflow items.
    BPM = workflow + marketing

  2. Johan den Haan August 17, 2007 | Reply

    > BPM = workflow + marketing
    It’s all about definition. What is the difference between a business process and a workflow? Lot’s of discussion have taken place about this.
    Business Process == Workflow?
    Workflow is a specific Business Process?
    Or do we follow the definition of the Workflow Management Coalition: a workflow is “The computerized facilitation or automation of a business process, in whole or part”?
    In the last case WFMS is defined as follows: “A system that completely defines, manages and executes ‘workflows’ through the execution of software whose order of execution is driven by a computer representation of the workflow logic”. This definition is quite old. BPM is defined later on and is, in my opinion, not only about process design and execution but it also encloses process enactment and diagnosis. Diagnosis leads back to design and so a closed circle is created. So BPM is about ‘improvement’.
    However, in the post above when talking about processes and workflow I meant that processes (in BPEL) are representations of business processes whereas workflows could be parts of a process and always involve human interaction.

  3. Derek Roos August 24, 2007 | Reply

    I would even go one step further. Although the BPM label has been attached by many to almost everything under the sun, i believe BPM is indeed going beyond traditional workflow management tools. Main difference, as i see it, is the incorporation of both integration & human workflows in a single paradigm. While everybody is focused on the benefits of BPM in terms of process improvement, I don’t see many BPM investments made as a means to this end – despite impressive claims of the software establishment. Aspects such as scenario simulation & process lifecycle management are at best secondary benefits of BPM.
    As an industry insider, I believe BPM is much more about agile application development (including integration) than anyone currently admits. In this sense, the role of BPM is to constantly position the business process as a whole at the center piece of attention – and this includes more than composing a set of executable workflows (or BPEL schemes). Thus, workflow management as we know it doesn’t fully capture the potential of BPM but documenting processes without (technically) incorporating the ability to execute or automate (parts of) it, is a wasted opportunity.

  4. Herman burema August 24, 2007 | Reply

    Still, I can not visualise that TASKS = Icon and CASES = Icon. Where the business owners move those Icons according to change Rules. Then position those CASES into the workflow the represent a business process (like a oder handling process)
    Icon = BPM object existing out of 1 + 1N orchestrations (published or not as web Services)

Leave a Reply