Jürgen Kress

Jürgen Kress

Biography

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.

Contributions

rss  subscribe to this author

Berthold Maier

Berthold Maier

Biography

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.

Contributions

rss  subscribe to this author

Hajo Normann

Hajo Normann

Biography

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.

Contributions

rss  subscribe to this author

Danilo Schmiedel

Danilo Schmiedel

Biography

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.

Contributions

rss  subscribe to this author

Guido Schmutz

Guido Schmutz

Biography

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.

Contributions

rss  subscribe to this author

Bernard Trops

Bernd Trops

Biography

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.

Contributions

rss  subscribe to this author

Clemens Utschig-Utschig

Clemens Utschig-Utschig

Biography

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.

Contributions

rss  subscribe to this author

Torsten Winterberg

Torsten Winterberg

Biography

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.

Contributions

rss  subscribe to this author

Bookmarks



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.

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.

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.

img

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.

img

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:

  • 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.

img

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).

img

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 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:

  • 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.

Conclusion

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.

Takeaways

  • 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.