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
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.
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.
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.
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.
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."
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:
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.
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).
To design UI communications in an SOA environment via the SHIL, two types of flow controllers are needed:
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:
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:
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.