Overall ArchitectureOne important origin of WS-HumanTask was the increasing need to support the creation of human tasks by any requestor in an SOA environment. Traditionally, human tasks are created by workflow management systems in a tightly coupled manner: the workflow management system manages the complete lifecycle of a task with no means to directly impact this lifecycle from the outside (except via processing the task). Especially, no other application can create a human task in such a tightly coupled environment.

WFMS

WorkitemManager

Navigator

WFMS Task Processor

Today's Architecture Resulting Architecture

Navigator

Figure 1- Architectural Impact of WS-HumanTask on Workflow Management Systems

Typically, the component within a WFMS that is in charge of managing the lifecycle of tasks (aka workitem) is called Workitem Manager. Such a tightly coupled environment is depicted in the left side of Figure 1. The right side of Figure 1 shows the significant impact on the overall architecture of a WFMS based on the advent of WS-HumanTask: a workflow management system no longer needs an integrated workitem manager but communicates with a Task Processor. The Task Processor becomes a separate, standalone component of the overall SOA stack. The Task Processor is in charge of managing the lifecycle of tasks and to provide additional features needed when working on tasks. Being a separate component of the SOA stack the Task Processor can also be used by any other requestor to create tasks and interact with tasks.

Conversely, by separating the Task Processor from a WFMS, tasks can be used in the context of a WFMS or any other WS-HumanTask application (also referred to as the Task Parent). The (special) case of a business process interacting with a human task is consequently described separately from the WS-HumanTask specification, that is, in the BPEL4People specification.

In WS-HumanTask tasks are assumed to have an interface. Being based on SOA, the interface of a task is represented as an application-dependent port type referred to as its Task Definition specific interface (or just interface for short – see section 4.2). In order to create task instances (or tasks for short) managed by a particular Task Processor, a port implementing the port type corresponding to a task has to be deployed into the Task Processor before (see Figure 2 showing a Task Definition associated with a port type pT); note, that general deployment functions are out of scope of the specification.

For scenarios requiring only simple tasks, with no custom business logic, e.g. to-do tasks, WS-HumanTask includes the concept of Lean Tasks. Lean Tasks are defined declaratively and can be registered on the Task Processor without needing to deploy new port types. This characteristic also makes Lean Tasks valuable in environments where the Task Processor is locked down or shared among many tenants. It also allows easier interoperability between Task Parents and Task Processors from different vendors.

Task Processor

TaskDefinitionTask

Definition

Task Definition-Specific Interface pT

Task Definition-Specific Interface pT

deploy()

Figure 2 - Task Types Deployed in Task Processor

Once this port type has been deployed any requestor can create and interact with tasks. The requestor creating a task is referred to as the Task Parent. Creation of a task is done by invoking an operation of the port type representing the interface of the task to be created. Usually, port types are used that expose only a single operation; in case more than one operation is defined, which operation of the port type to be used to create a task is outside the scope of WS-HumanTask. Error: Reference source not found shows a Task Parent using operation op() provided by a port of port type pT to create a task (instance).

Task Processor

Task Definition-Specific Interface pT

Task Parent

Task

pT.op()

TaskDefinition

Figure 3 - Instantiating Tasks

In workflow environments, the lifecycle of a task is typically dependent on the workflow system, i.e. tasks have to give up some of their autonomy. For example, when a workflow is terminated prematurely, it must be ensured that a task initiated by that workflow does not continue: the corresponding efforts to continue the work of the task would otherwise be wasted. To automate the corresponding behavior making sure that the lifecycle of a Task Parent and the lifecycles of its initiated tasks are tightly coupled, WS-HumanTask exploits a coordination infrastructure as specified

by WS-Coordination. This requires the definition of a coordination protocol following a particular behavior (see section 7).

Figure 4 graphically depicts how the corresponding behavior is set up. When the Task Parent creates a task by using the specific operation op() of a port of port type pT special coordination context information is passed from the Task Parent to the environment hosting that port. Like any other WS-Coordination compliant coordination context it contains the endpoint reference of (i.e. a “pointer” to) a coordinator to be used by the recipient of the context for registering for the corresponding coordination type. Note that for simplicity we assume in the figure that the Task Processor itself is this recipient of the context information. On reception of the coordination context the Task Processor will register with the coordinator which basically means that it passes the endpoint reference of its protocol handler to the coordinator (see section 7). In turn, it will receive the endpoint reference of the protocol handler of the Task Parent; similarly, for simplicity we assume in the figure that the task parent provides its protocol handler. From that time on, a coordination channel is established between the Task Parent and the Task Processor for the exchange of protocol messages guaranteeing the tight coupling of lifecycles between the task created and the Task Parent. Section 4.7 describes the lifecycle of a task in more detail.

Task Parent

Task Processor

Task Definition-Specific Interface pT

Task

Task Parent’sProtocol Handler

Task Processor’sProtocol Handler

pT.op()

Context

TaskDefinition

Figure 4 - Establishing a Protocol Channel

Most often, tasks are long running in nature and will be invoked in an asynchronous manner. Thus, the Task Parent will kick-off the task and expects the result of the task back at a later point in time. In order to be able to pass the results back, the Task Processor has to know to whom to send these results. For that purpose, the context is extended with additional metadata that specify the endpoint reference for passing the result to as well as the operation on that endpoint to be used by the Task Processor. Figure 5 depicts this by showing that the context contains information pointing to a port of port type pt’ and specifying the name of the operation op’ that has to be used on that port for returning results. Note that this behavior is compliant to WS-Addressing.

Task Parent

Task Processor

Task-Definition-Specific Interface pT

Task

Task Parent’sProtocol Handler

Task Processor’sProtocol Handler

ContextpT.op()

pt’.op’

Callback

TaskDefinition

Figure 5 - Passing Callback Information for Long Running Tasks

Finally, a Task Parent application invoking an operation implemented by a task is allowed to pass additional data along with the request message. This data is called the human task context and allows overriding some of the Task Definition’s elements. Conversely, a human task context is also passed back with the response message, propagating information from the finished task to the Task Parent application, such as the task outcome or the task’s effective people assignments.

Once a task is created it can be presented to its (potential) owners for being claimed and worked on. For that purpose, another kind of application called Task Client is typically used. A Task Client presents to each of its users the tasks available to them. Users can then decide to claim responsibility to perform the work corresponding to the task. Other functionalities typically offered by a Task Client include the ability to skip a task, to add comments or attachments to a task, to nominate other users to perform the task and that like. In order to enable a Task Client to offer these functions on tasks WS-HumanTask specifies the task client interface that has to be implemented by a Task Processor to support Task Clients (see section 6.1). Figure 6 shows the topology resulting from adding Task Clients to the architecture of WS-HumanTask.

Task Parent

Task Processor

Task-Definition-Specific Interface pT

Task

Task Parent’sProtocol Handler

Task Processor’sProtocol Handler

Task Client

Task Client Interface

pT.op()pt’.op’

Callback

TaskDefinition

Figure 6 - Task List Client and Corresponding Interface

Once a user selects a task from its Task Client to work on it the corresponding user interface of that task has to be rendered allowing the user to view application specific information associated with the task and so on. WS-HumanTask does not specify such rendering but provides a container to pass rendering information to Task Clients. A Task Client in turn has to use this information to construct or initiate the construction of the user interface of the task, but the details of that are out of scope of WS-HumanTask. In the case of lean tasks, that rendering is generated by the Task Processor and is not part of task XML definition. From the perspective of the Task Client, the fact the task is a lean task need not be apparent. Furthermore, the task may require the use of business applications to complete the task. Again, the use of such business applications is out of scope of WS-HumanTask but such applications and their use are important ingredients of the overall architecture shown in Figure 7.

Task Parent

Task Processor

Task-Definition-Specific Interface pT

Task

Task Parent’sProtocol Handler

Task Processor’sProtocol Handler

Task Client

Task Client Interface

Task UI Business Application

pT.op()

pt’.op’

Callback

TaskDefinition

Figure 7 - Overall Architecture of a Human Task Infrastructure

The container of rendering information of the task UI is a task’s <rendering> element (see section 4.4). A rendering element specifies its type, which is a QName that denotes the kind of rendering mechanism creating the user interface of the task. All information actually needed to create the user interface of the task is provided in the nested element of the task’s rendering element (see Figure 8). The nested element may also provide information about a business application required to complete the task and corresponding parameters.

<htd:renderings>

</htd:renderings>

<htd:rendering type="Qname_1">

</htd:rendering>

...

<htd:rendering type="Qname_2">

</htd:rendering>

...

<htd:rendering type="Qname_3">

</htd:rendering>

...

...

Task UI 1

Task UI 2

Task UI 3

Figure 8 - Potential Renderings of a Task

For example, Figure 9 shows a rendering of type my:HTMLform. Its QName denotes that HTML forms processing capabilities is needed to render the corresponding user interface of the task enclosing this rendering. The nested element of the my:HTMLform rendering contains the actual HTML form to be rendered. The example further assumes that the forms processor understands the {$...} notation (see section 4.3) to provide values from the task input as data presented in the form.

<htd:rendering type="my:HTMLform">

</htd:rendering>

<FORM ...>Name: <INPUT TYPE="text" NAME="customer"

VALUE={$customer}>Credit Amount: <INPUT TYPE="text" NAME="amount“

VALUE={$amount}><INPUT TYPE="Radio" NAME="Yes" VALUE="A">Approved<BR><INPUT TYPE="Radio" NAME="No" VALUE="R">Rejected<BR><INPUT TYPE="submit" VALUE="Done"></FORM>

Name:

Credit Amount:

Approved

RejectedDone

Frank

100000

Figure 9 - Sample Rendering of a Task

A task may have different renderings associated with it. This allows that it may be rendered for different access channels, or adapt to user preferences, for example. However, the specification of concrete renderings is out of scope of WS-HumanTask.