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

Page 1 of 8

SOA programming model for implementing Web

services, Part 8: Human-based Web services
Level: Intermediate

Matthias Kloppmann (Matthias-Kloppmann@de.ibm.com), Senior Technical Staff Member, IBM

Stefan Liesche (liesche@de.ibm.com), WebSphere Portal and Workplace Foundation Lead Architect, IBM
Gerhard Pfau (gpfau@de.ibm.com), Senior Technical Staff Member, IBM
Marcia Stockton (mls@us.ibm.com), Senior Technical Staff Member, IBM

21 Oct 2005

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.

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.

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 2 of 8

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

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

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 3 of 8

(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

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 4 of 8

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

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 5 of 8

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

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

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 6 of 8

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

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.

Summary
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

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 7 of 8

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.

Resources
Learn

Access the following resources for excellent background on the subject of human-based Web services:
 "Introduction to the IBM SOA programming model" (developerWorks, June 2005) is the first in this series of
articles that addresses how to implement SOA for an On Demand Business.
 Business Process Execution Language for Web Services version 1.1 is the standard for formally specifying
business processes and interaction protocols.
 "WS-BPEL Extension for People" (developerWorks, August 2005) is a joint white paper published by IBM and
SAP about the features that can be composed with the BPEL core features for human user interactions and
suggests future directions for the standardization of human tasks.
 "Business process choreography in WebSphere: Combining the power of BPEL and J2EE" is a paper that shows
how IBM WebSphere Application Server provides a BPEL4WS-compliant execution environment, also called
the process choreographer environment.
 "WebSphere Application Server Enterprise Process Choreographer: Concepts and
Architecture" (developerWorks, October 2002) uses scenarios to show how to benefit from using Process
Choreographer in today's business environment.
 Learn more about IBM Websphere Process Server.
 IBM Websphere Portal Server integrates business processes and portal users with orchestrated workflow.
 "SOA programming model for implementing Web services, Part 5: Service-oriented user
interfaces" (developerWorks, August 2005) explains user-facing Web services.
 The third article in this series, "Process choreography and business state machines" (developerWorks, July
2005), covers the approach to service composition that defines services as business processes using BPEL.
 Check out the upcoming WS-BPEL standard.

Visit the developerWorks SOA and Web services zone for extensive how-to information, tools, and project updates on
SOA and Web services technologies.

Browse all the SOA and Web services articles and free SOA and Web services tutorials available from
developerWorks.

Discuss

Participate in the discussion forum.

Get involved in the developerWorks community by participating in developerWorks blogs.

About the authors

Matthias 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 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.

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008
SOA programming model for implementing Web services, Part 8: Human-based Web ser... Page 8 of 8

Gerhard 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 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
mls@us.ibm.com.

IBM and WebSphere are registered trademarks of International Business Machines Corporation in the United States, other
countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both. Other company, product, or service names may be trademarks or service marks of others.

http://www.ibm.com/developerworks/webservices/library/ws-soa-progmodel8/ 2/19/2008