Abstract: The
interaction between user-interfaces and services in an Service Oriented
Architecture is an often-neglected topic. This article focuses on the
particular challenges that need to be overcome when creating
user-interfaces while entire process chains have to be called and
interacted with. After outlining some general architectural
considerations, the authors describe a practical application of Thomas
Erl's UI Mediator pattern that will be accompanied by their own
technical experience.

Introduction

In the
simplest scenario, a user's interaction with a business process consists
of initiating the process and awaiting the result. However, processes
very rarely run completely automatically, meaning human intervention in a
process cycle is an important requirement. The WS-HumanTask
specification can fulfill this requirement in the SOA environment. A
standardized API that is defined for a workflow service can be used to
fill a mailbox with tasks. If the process automation language BPEL is
used, the BPEL4People specification defines how this mailbox
functionality can be used directly in the process cycle by means of the
WS-Human Task. Of course, this is possible from BPMN, too.

For
example, if manual approval or the input of additional data is needed
during a process cycle, the process can determine the correct actor and
deposit the task in their mailbox via the task service. The HumanTask
service provides a Web service API for this functionality. The users
receive the entries in their mailbox and process the pending tasks
sequentially, while the process resumes its work in the background.

Human Interaction & Mailboxes

This
solution concept is flawless from a technical viewpoint, but its
handling is unfamiliar to many users. Workflows can even be perceived as
disruptive for short processes that lack role changes, since
conventional data-driven application systems can provide immediate
responses without detouring to a mailbox. Process control is embedded in
the interface control.

Users are their own process masters when
such conventional applications are used, whereas a mailbox-supported
solution subjects the users to the restrictions of a prescribed process.

Anyone
designing classic BPMN or BPEL processes with mailbox interaction
understands that users will be faced with a long list of tasks in their
mailbox, which often require mechanical and repetitive interactions.
Nowadays, many technical departments are aware of this issue, and
provide assistance to the users whose daily processes need their
requirements recorded.

With the advent of SOA and loose coupling,
work processes are further automated and process control is gradually
shifted to the back-end. Excessively close coupling of processes and
interfaces should be avoided, since processes can also be subject to
frequent adaptations due to flexibility. Decoupling via the mailbox is
generally the most effective solution.