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.
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
(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
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
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
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.
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.
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.
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.
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.
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
