Write for OTN
Earn money and promote your technical skills by writing a technical article for Oracle Technology Network.
Learn more
Stay Connected
OTN Architect Community
OTN ArchBeat Blog Facebook Twitter YouTube Podcast Icon

SOA and User Interfaces

by Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmeidel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg

Overcoming the challenges to developing user interfaces in a service oriented architecture

Part of the Industrial SOA article series

October 2013

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.


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.

Asynchronicity Enables Stabile Interfaces

Figure 1 illustrates the most basic example of interaction between a user-interface and a process. Data is gathered via a series of Webpages and transferred into a process as input parameters. The process call, which can be considered identical to a service call, is designed for synchronous response behavior in order to evaluate the result and return directly to the waiting page. This pattern is frequently encountered in practice but is not the method of choice in an SOA. What is the issue with this architecture variant?

The answer appears straightforward if you consider the reasons why SOA was chosen as an architecture principle for process implementation. SOA promises a high level of flexibility, and the process offers rapid implementation of change requests. What happens when flexibility is crucial and the process has to be changed, so that the result can only be returned after a delay of a time period X instead of immediately?

As a new requirement, for example, a time-intensive activity that contains a user interaction via mailbox is being added. The implementation "breaks" the user-interface, as the system was working synchronously and the delayed response has now caused blocking (or timing out for Web applications).

In practice, the call for synchronous interaction with services violates the principle of loose coupling. "Rapid asynchronicity" may be able to fulfill the requirements and replace synchronicity successfully. We have noticed very little difference between the response times of synchronous versus rapid asynchronous service calls, as bottlenecks are typically caused by network latency.

Figure 1: The standard basic approach that collects all of the data, triggers the process, and awaits the results.

The Mailbox Approach

Since the Asynchronous Message Exchange pattern can play an important role when calling processes, let us consider the reverse scenario in which a process asks a user a question. Direct communication from the server to the user is not possible, since the process runs on a server. Communication always needs to be issued from the user's computer.

Figure 2 illustrates the mailbox approach, which is implemented similarly in all process and workflow cycle environments. The process determines the actor, which can be a person or role, and deposits a task in their task list. The process then waits until the actor removes the task from their mailbox and returns it as processed. Any type of complex data can be transported, and some environments permit the embedding of entire screen areas for data entry for display to the user.

In many cases, a clear benefit can be achieved by using the mailbox approach. Process knowledge can be extracted from individual employees and hardwired applications and made explicit in the form of processes. The operation of several complex applications can then be extensively standardized using a higher-level process control. Opportunities for monitoring individual process instances are also created, allowing transparency within the company to be increased significantly.

Figure 2: A work list application (mailbox) for long-running processes is shown.

Erl's Pattern & SHIL

Thomas Erl formulated the solution proposal we devised for this problem under the name "UI Mediator pattern" in his book SOA Design Patterns (2009, Prentice Hall). The pattern describes the problem and the principle behind the solution at a highly abstract level. From a practical viewpoint, we will describe an implementation variant of the UI Mediator pattern that has been successfully implemented in previous projects, called the "service human interaction layer."

Requirements for Synchronous (Human) and Asynchronous (Process) Equalization

A solution that can fulfill these requirements to apply the UI Mediator pattern in the SOA environment is required, in conjunction with BPEL or BPMN:

  • duplicate implementation of the business process logic and business rules in the front-end are not required
  • the required screen flows are linked synchronously

The second requirement is at the heart of the service human interaction layer (SHIL). The SHIL simulates synchronicity to the users (Figure 3), although it technically works asynchronously. Users no longer have to remain watchful for new tasks appearing in their mailbox, as the SHIL transparently performs this function . The number of mailbox entries can then be reduced to a minimum, allowing users to work at their own pace within the framework of a currently pending task and not within a list of delicate tasks.

Figure 3: A UI mediator simulates synchronicity to users.

To be "synchronous" means that users can work on specific user-interfaces and immediately (synchronously) receive a response to the requests to the triggered server, rather than having to wait for an "asynchronous" response. Humans like to work synchronously with a system, while an automatically running business process perceives users only as "asynchronous services." When a process requires information that isn't immediately available, the process issues the request asynchronously and waits until someone can provide the response. The SHIL resolves this conflict between preferred communication mechanisms (Figure 4).

Figure 4: The service human interaction layer (SHIL) is shown as an implementation of the
UI Mediator pattern.

SHIL Solution Design

To design UI communications in an SOA environment via the SHIL, two types of flow controllers are needed:

  • micro-flow controller
  • macro-flow controller

The micro-flow controller is usually a UI controller similar to those used in Struts, JSF, and Spring Web Flow, and implements all use case-related screen flows and GUI-human interactions in the front-end. Individual screen flows can be started using defined flow IDs, such as "free-flying" Websites that can be externally triggered (macro view).

Positioned between the GUI and the business process layer, the macro-flow controller controls communication between the GUI and the process. Note that the screen flow control of the GUI should not be implemented in these cases. A macro-flow language such as BPEL or BPMN is not suitable, due to their rigidity. The actual page flow remains in the application (micro-flow).

If a use case with UI interaction is required in the process layer, the macro-flow controller intervenes on an event-driven basis and informs the micro-flow controller on which use case or front-end flow to execute. Notification of the logical name of the functional screen flow is generally sufficient. This transparent intermediate layer is known as the SHIL.

The SHIL is a typical cross-sectional aspect that can be easily inserted into the GUI interaction using aspect-oriented programming (AOP). The intention of transparency means that the mediation layer cannot contain any application logic. The data used for correlation, such as the user's session ID, is included in the message header of the payload. The permanent Flow ID, which the GUI can use to select and start the next micro-flow, is agreed to and transferred to the SHIL by the BPEL or BPMN layer. The decision on which micro-flow (use case) to execute next is made solely on the UI side, in the micro-flow controller.

The consistency of the process must be maintained whenever a transaction is canceled. If a user suspends processing, closes the browser, or otherwise interrupts the connection, processing must be able to be resumed at another time. The use of the mailbox is therefore of crucial importance in this solution scenario. The SHIL interacts with the mailbox, and is only notified of newly received messages and the corresponding flow ID via a push from the process.

In summary, the following features of the SHIL can be derived:

  • The SHIL is a pure mediation layer that regulates the message flow between the UI and the BPEL or BPMN process, using techniques such as AOP and calls to the HumanTask service.
  • The SHIL cannot store any application logic.
  • The SHIL is a cross-sectional aspect that can be integrated transparently into the GUI control using AOP methods.
  • The decision on which micro-flow to execute next is made solely in the UI, based on information transmitted by the BPEL or BPMN business process.
  • All process messages require an additional header for transporting the flow ID and the correlation ID, through the processes to the SHIL.
  • The mailbox (workflow service) is used as a buffer for fault handing and prevention, such as counteracting terminations by end users.
  • The SHIL implements the emulation of the synchronous behavior in short asynchronous processes (<10 seconds) on the GUI side with a blocking "wait" message.
  • The SHIL regulates the cancellation and notification on the UI side for longer-running processes.

Using the SHIL

Instead of being controlled by mailboxes, users should be able to synchronously communicate with the server for as long as possible. The following scenario describes how a user actually experiences the interaction with the process, once the SHIL is in place:

  1. The process is initiated after the first use case has been fully processed in the UI.
  2. The SHIL intervenes and creates all of the necessary correlations, such as the user session and process instance IDs.
  3. Three different scenarios can occur, depending on the amount of time required for processing:
    • If the process takes less than one second to finish, the SHIL forwards the response directly to the user-interface that displays the next page.
    • If processing takes between one to ten seconds, the SHIL presents the user with a "wait" dialogue that jumps to the results page.
    • If over ten seconds pass and a timeout occurs, the SHIL rejects the "wait" dialogue and provides the user with an apology explaining that the desired convenience could not be provided by pseudo-synchronization.
  4. A new task is then asynchronously added to the user's mailbox the next time the process reports.


The classic workflow approach of using work lists naturally lends itself to the integration of processes with user-interfaces. Existing interfaces can be easily extended using "mailboxes," which use task assignments to provide users with a means of intervening in a process cycle. This approach is also appropriate whenever cross-role operation is possible or advisable, which technically uses proprietary workflow systems or BPEL/BPMN-based solutions. Nowadays, every piece of BPM software includes the corresponding functionalities.

However, when working with processes that repeatedly deposits a task in the same mailbox at brief intervals with no role change, more convenience can be achieved for the operator by applying the UI Mediator pattern. Quasi-synchronous operating behavior is simulated to the operator, even though the system is internally asynchronous. The convenience gained comes at the increased cost of implementation.

For custom build projects, it is important to be aware of two considerations. Firstly, applications must be designed specifically for interactions with running processes. Secondly, calls from technical departments for immediate, synchronous responses are often better implemented by using rapidly responding asynchronous architecture patterns, in order to achieve the desired flexibility.


  • The automation of business processes usually requires human participation in the process cycle.
  • In most cases, classic workflow solutions (such as BPEL/BPMN with workflow services) that integrate users using mailbox approaches are sufficient.
  • Applying the UI Mediator pattern provides users with more convenience by simulating quasi-synchronous operating behavior.
  • Technical calls for immediate (synchronous) responses are often better implemented by applying rapidly responding asynchronous architecture patterns.