SOA programming model for implementing Web services, Part 8: Human-based Web services

The involvement of people in service compositions is a relatively new facet of Service-Oriented Architecture (SOA), expanding the ways software can model how humans work and interact in a business. This article describes functions offered by the Human Task Manager of IBM WebSphere® Process Server and their use in a portal.


Matthias Kloppmann, Senior Technical Staff Member, IBM

Matthias Kloppmann photoMatthias Kloppmann is a Senior Technical Staff Member with IBM Software Group's laboratory in Boeblingen, Germany. He is the lead architect for Business Process Choreography. Since Matthias joined IBM in 1986, he has worked on a variety of projects, focusing on the architecture of workflow systems and Web services. Matthias holds an Master of Science in computer science and electrical engineering from the University of Stuttgart.

Stefan Liesche, WebSphere Portal and Workplace Foundation Lead Architect, IBM

Author photoStefan Liesche is a Certified Senior IT Architect in the IBM Development Laboratory in Boeblingen, Germany. He has 11 years of experience in the software development field. He holds a master of science degree in computer science from University of Hildesheim, Germany. He joined IBM in 1998 as part of the services group where his speciality was designing large-scale end-to-end e-business solutions for complex environments. Stefan has been working with IBM WebSphere Portal for years. He first worked on the construction of large-scale portal solutions before joining the WebSphere Portal development architecture team. He is the Lead Architect of Workplace and Portal Foundation.

Gerhard Pfau (, Senior Technical Staff Member, IBM

Author photoGerhard Pfau is a Senior Technical Staff Member and a member of the IBM Academy of Technology. He works as the lead architect of the Human Task Manager component of Business Process Choreographer in the IBM development lab in Boeblingen, Germany. Gerhard has worked on the architecture of Business Process Choreographer since its inception. He has published many articles and has given talks at various conferences. Before working on business process architecture, Gerhard was the lead architect for IBM's SAP J2EE Connector.

Marcia Stockton, Senior Technical Staff Member, IBM

Author photoMarcia L. Stockton is a Senior Technical Staff Member and Master Inventor with the IBM Software Group in Research Triangle Park, North Carolina (residing in California). She is also a senior IEEE member. Marcia leads the Software Group Architecture Board's Programming Model Workgroup, where she drives horizontal integration initiatives and promotes programming model simplification across Lotus®, Rational®, WebSphere, DB2®, and Tivoli® products. Her 73 filed U.S. patents range from networking, Web, security, privacy, multimedia, wireless, pervasive devices, to radio frequency ID. She recently led efforts to define the architecture for identity management and for edge server distributed programming. She joined IBM in 1988 after five years developing networking software. She earned a B.A. from Swarthmore College in 1975. You can contact Marcia at

21 October 2005

Also available in Chinese Vietnamese

User interfaces for the Service-Oriented Architecture

Total automation of business processes, while desirable, in practice is unachievable, because certain activities requiring human judgment or human expertise -- such as the manual handling of exceptional situations or the approval of requests -- are always performed by people. In the context of the overall business process, a human task is a service like any other task, except that it is realized by a human activity (instead of a program) and performed by a person (instead of a computer).

Thus, within the SOA programming model, human activities can be realized as Web services. When invoked, the service notifies an individual of a task to do and passes the input data in an appropriate form. After the task is completed and there is a result, the service returns to its caller, passing the result as output data. That the result actually involved work by a person may be completely transparent to the caller. The scenario employs asynchronous invocation to support long-running services; a remote procedure call (RPC)-style synchronous invocation is not suitable for human tasks (or any other long-running service).

Rendering a human task as a Web service has the additional advantage that automation, or a combination of automated and human steps, can be substituted for the human implementation without recoding the remainder of the business process. This is not to suggest that human workers will be replaced by software or that future computers will command human slaves! Rather, modeling a human-implemented activity as a Web service is a reasonable design choice, because the alternative – performing several steps in a business process choreography and simply stopping whenever human expertise is needed, then restarting the choreography at a later step, without any logical connection between the two disconnected choreography sequences – has many obvious deficiencies.

As an example, consider an insurance claims handling process. Somewhere in the process the claim must be approved before paying compensation to the claimant. In its rudimentary form, a human being receives the claim information and decides whether to approve the claim, reject it, or involve an adjuster. Without altering the overall business process flow, that step can be replaced by a service in which business rules automate routine approvals while deferring more difficult decisions to humans. Human experts, now unburdened of routine clerical chores, are freed to focus their unique skills on complex cases. This change improves both the business results and the job satisfaction of human workers.

The transparent encapsulation of a human task as a Web service is not always desirable, though. Consider a more complex process where two different people need to approve a request (known as the four eyes principle or separation of duties). Such tasks need explicit representation as human tasks, not opaque Web services, because the rule used to select the second approver necessarily excludes the first approver.

The BPEL4People extension for the Business Process Execution Language for Web services provides the extensions needed to extend business processes with embedded human tasks. It also addresses scenarios where human tasks are rendered as opaque stand-alone Web services that can be invoked from a BPEL process or a program written in Java™, for example.

The following section describes the programming model for human tasks.

Human tasks

A human task component type implements a human task to involve people both in business processes and in arbitrary service choreographies. Human tasks run within the Human Task Manager, a special container for human tasks within WebSphere Process Server.

To support this usage scenario, a human task has a simple interface with exactly one operation. The operation has an input message, an output message, and zero or more fault messages. Figure 1 shows, as an example, the interface of an approval task.

Figure 1. Approval Task interface
Approval Task interface

The task's display name, description, and documentation can also be specified as properties. The display name is the human-readable name of the task that business people can understand; it represents the task on a task list. For example, an approval task could be named Credit Approval. The description briefly summarizes what the task is for and what to do with it -- for example, approve or reject a request for credit. The documentation property provides more detailed information. Each property -- display name, description, and documentation -- can be rendered in multiple languages to enable a diverse and multinational work force.

Tasks also have access control over who is allowed to do what. From a business perspective, it's significant that only the right people can perform an approval. In a company where, for example, all approvers belong to the group approvers in the company's people directory, the staff definition for the potential owners of the approval task might be the following:

Figure 2. Approval Task staff settings
Approval Task staff settings

(Note: This screen would be seen only by a developer or a business process analyst when first defining a human task, not by individuals who are subsequently performing those tasks.)

Several roles for people can be defined with respect to a task. Potential owners are those who are eligible to work on the task. One or more administrators are responsible for task management. Another set of people -- in addition to the owner and administrator – can have the privilege of reading or editing task data. Finally, those who are authorized to create task instances can also be specified.

At run time, the staff settings of a task are used to retrieve the matching set of users from the company's people directory by, for example, issuing an Lightweight Directory Access Protocol (LDAP) query or sending a request to the WebSphere user registry.

Service Level Agreements (SLAs) with customers may require that stages in a business process abide by time constraints. If a human task progresses too slowly to meet SLAs, the Human Task Manager has the ability to send escalation notifications. Each task can have its own escalation settings. Figure 3 illustrates escalation settings for an approval task.

Figure 3. Approval Task escalation settings
Approval Task escalation settings

Escalations, similar to timers, can be defined for different task states. An escalation, which starts when the task reaches a given state, does nothing until a specified duration elapses. If the task has progressed as expected, the escalation is cancelled as superfluous. If it hasn't progressed, the escalation triggers a previously defined action and, for example, sends an e-mail to one or more specified escalation receivers.

In the example in Figure 3, an escalation is scheduled when the task becomes ready; that is, after it has started. After a certain period of time, if no potential owner has claimed the task, the escalation fires and informs the potential owners by e-mail that that work awaits them.

After an owner claims the approval task, a chain of escalations becomes active. If a claimed task couldn't be completed in time, the escalation chain sends notifications up the management chain. This gives a business administrator the opportunity to reassign the task to somebody else.

Human tasks are presented on users' individual work lists. A user sees only the tasks he or she is supposed to see, as specified using staff settings (outlined above). In large applications with many users and many concurrent tasks, a user needs the ability to arrange his or her task list according to criteria. Task lists can be sorted by name, priority (see only tasks of a certain priority; or see high-priority tasks first), and business relevance. To facilitate sorting and filtering, the business can also define task types and arbitrary custom properties (name-value pairs).

Portals have been widely adopted to connect people to IT systems in today's enterprises. Employees interact with a portal user interface (UI) to perform their jobs, collaborate with colleagues, and interact with customers, partners, and suppliers. Human tasks, combined with a portal UI, offer an efficient way to implement human participation in business processes.

Figure 4. Task list portlet
Task list portlet

In the integrated portal environment, one can both access a task list (see Figure 4) and work on tasks. There is a task page defined by a portal administrator associated with each task. The user navigates to those pages by simply clicking on the task in a task list.

Figure 5. Portal task UI settings
Portal task UI settings

The portal launches the associated task pages only when the user is working on (has claimed) a given task by passing the link to that task to a portlet. It provides a task page reference to a portlet. The portlet in turn displays the link for navigation, uses the reference to retrieve task-relevant information for the user, and returns the result to the human task.

Users can launch multiple task pages for different tasks of the same type or of different types. When a user completes a task, the task page closes and disappears from the user's navigation automatically. Users can close and relaunch task pages as required. All task pages close when the user session ends.

Users working on a task can also exploit an array of collaborative capabilities offered by the portal, such as instant messaging, user profiles, and so on. For example, to facilitate collaboration, the Human Task Manager can list other colleagues doing related tasks. A UI illustrating these capabilities is shown in Figure 6.

Figure 6. Task page
Task page

Task pages are typically populated with several kinds of portlets. Task-processing portlets connect the user to the task; they retrieve task input messages for display to the user and deliver data entered by the user as task output messages. Task-processing portlets (see Figure 7) can be generated automatically from task interface specifications (for example, recall the Figure 1 interface example).

Figure 7. Process Portlet Development Wizard
Process Portlet Development Wizard

Supporting portlets help the user gather information required to complete a task. They typically don't interact with the task directly, but use collaborative portlet capabilities to interact with, for example, task-processing portlets on the task page.


Human-based Web services provide the ability to transparently include people as the service implementations in arbitrary service-oriented applications. Human tasks, as introduced with WebSphere Process Server, provide the infrastructure for human-based Web services. They are based on the staff functions known from classical human workflow systems, with their functionality extended to include sophisticated escalation and notification capabilities, as well as the ability to specify WebSphere Portal-based user interfaces for human tasks. More information on how WebSphere Portal is used to provide user interfaces for SOA applications can be found in Part 5 of this series, "Service-oriented user interfaces" (developerWorks, August 2005).

The Human Tasks concept has gained industry recognition, and its standardization is ongoing. A joint paper published by IBM and SAP (see Resources for a link to the Web page) suggests future directions for the standardization of human tasks. It describes an extension to the upcoming WS-BPEL standard (see Resources) that includes human tasks to involve people with business processes.

This article has focused on human tasks as a means of human-based service implementation in the context of business processes and service-oriented applications. Other, more client-centric usage scenarios exist outside the scope of this paper in which humans use applications to interact with human-based and automated services. An example is a task list used by a person to create and manage automated or human-based tasks. The "Service-oriented user interfaces" article details additional scenarios not covered in this paper.





developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services, WebSphere
ArticleTitle=SOA programming model for implementing Web services, Part 8: Human-based Web services