As a middleware expert Jürgen works at Oracle EMEA Alliances and Channels, responsible for Oracle’s EMEA fusion middleware partner business. He is the founder of the Oracle SOA & BPM and the WebLogic Partner Communities and the global Oracle Partner Advisory Councils. With more than 5000 members from all over the world the Middleware Partner Community are the most successful and active communities at Oracle. Jürgen manages the community with monthly newsletters, webcasts and conferences. He hosts his annual Fusion Middleware Partner Community Forums and the Fusion Middleware Summer Camps, where more than 200 partners get product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl, Jürgen is a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, JAX, UKOUG, OUGN, or OOP.
Berthold Maier works in the T-Systems International department of Telekom Germany as Enterprise Architect. He has more than 19 years experience as developer, coach and architect in the area of building complex mission critical applications and integrations scenarios. Within eleven years as Oracle employee he has held several leading positions including chief architect in the consulting organization. Hi is the founder of many frameworks and take over the responsible for reference architectures around BPM/SOA and Enterprise Architecture Management. Berthold is also well-known as a conference speaker, book author and magazine writer.
Hajo Normann works for Accenture in the role of SOA & BPM Community of Practice Lead in ASG. Hajo is responsible for the architecture and solution design of SOA/BPM projects, mostly acting as the interface between business and the IT sides. He enjoys tackling organizational and technical challenges and motivates solutions in customer workshops, conferences, and publications. Hajo leads together with Torsten Winterberg the DOAG SIG Middleware and is an Oracle ACE Director and an active member of a global network within Accenture, as well as in regular contact with SOA/BPM architects from around the world.
Danilo Schmiedel is one of the leading BPM and SOA System Architects at OPITZ CONSULTING. He has been involved in large integration-, business processes automation and BPM / SOA development projects where he implemented solutions for various customers. His main field of interest is focused on the practical use of BPM and SOA on a large scale. Additionally he works as BPM and SOA project coach. Danilo is a frequent speaker in the German Java and Oracle communities and has written numerous articles about the above topics. Before joining OPITZ CONSULTING Danilo worked as Software Engineer in several international projects. The Leipzig University of Applied Science has awarded his outstanding reputation in 2009.
Guido Schmutz works as Technology Manager for the IT services company Trivadis. He has over 25 years as a software developer, consultant, architect, trainer, and coach. In Trivadis he is responsible for SOA, BPM and application integration, and is head of the Trivadis Architecture Board. His interests lie in the architecture, design, and implementation of advanced software solutions. He specializes in Java EE, Spring, Oracle SOA Suite and Oracle Service Bus. He is a regular speaker at international conferences and is the author of articles and several books. Guido is an Oracle ACE Director for Fusion Middleware & SOA.
Bernd Trops is a Senior Principal Consultant at Talend Inc. In this role he is responsible for client project management and training.
Bernd is responsible for all Talend projects within the Deutsche Post and the introductions of new versions and components.
Before Talend, Bernd was a Systems Engineer working on various projects for GemStone, Brocade and WebGain and therefore has extensive experience in J2EE and SOA. From 2003 to 2007 Bernd Trops worked as a SOA Architect at Oracle.
Clemens worked as Chief Architect for the Shared Service Centre, Global Business Services, Boehringer Ingelheim in architecture, master data, service management and innovation.
At the moment he works with holistic enterprise architecture that provides the methodological platform for the new master data management.
He previously worked as a Platform Architect at Oracle Inc. in the United States, where he helped to develop next product strategy as well as the SOA BPM Suite.
Torsten Winterberg works for Oracle Platinum Partner OPITZ CONSULTING. As a director of the competence center for integration and business process solutions he follows his passion to build the best delivery unit for customer solutions in the area of SOA and BPM. He has long-time experience as developer, coach and architect in the area of building complex mission critical Java EE applications. He is a known speaker in the German Java and Oracle communities and has written numerous articles on SOA/BPM related topics. Torsten is part of the Oracle ACE director team (ACE=Acknowledged Community Expert) and leads the DOAG middleware community.
SOA and User-Interfaces Published: September 30, 2013 • Service Technology Magazine Issue LXXVI PDF
Abstract: The interaction between user-interfaces and services in an SOA 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, we will describe a practical application of Thomas Erl's UI Mediator pattern that will be accompanied by our 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,
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 titled "SOA Design Patterns" from Prentice Hall Publishing. 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:
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
SHIL Solution Design
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 cancelled. 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:
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:
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.