VieDAME -
Vienna Dynamic Adaption and Monitoring Enviroment for WS-BPEL

Last edited: Thu Apr 3 13:41:54 CET 2011

Motivation and Problem Description

Web service processes currently lack monitoring and dynamic (runtime) adaptation mechanisms. In highly dynamic processes, services frequently need to be exchanged due to a variety of reasons. VieDAME allows monitoring BPEL processes according to Quality of Service (QoS) attributes and to replace existing partner services based on various (pluggable) replacement strategies. The chosen replacement services can be syntactically or semantically equivalent to the BPEL interface. Services can be automatically replaced during runtime without any downtime of the overall system. We implemented our solution with an aspect-oriented approach by intercepting SOAP messages and allow services to be exchanged during runtime with little performance penalty costs, as shown in our experiments, thereby making our approach suitable for high-availability BPEL environments.

Problem Description

We address two issues we identified when using BPEL in enterprise systems where monitoring and high-availability play a crucial role:

Firstly, one major drawback of BPEL is its inherently static nature. Basically, if a process definition is deployed into a BPEL environment - the BPEL engine - it cannot be changed dynamically at runtime. Every information is hard-wired after a process is deployed, for example, references to other services (called partner links) used in the BPEL process cannot be changed exchanged without editing and redeploying the process which implies a downtime of the overall system. Although it is possible for the process to bind to partner links at runtime, the process definition would contain a tremendous amount of code that is not related to the business process . A dynamic replacement of partner Web services in the process is, therefore, a necessary approach when the service provider quality in terms of response time (or other QoS) aspects is not good enough and affects the overall quality of the process.

Secondly, the BPEL standard does not provide any means for monitoring a running process. Nevertheless, monitoring of business processes is a very important issue in enterprise systems as they are a key factor for running a business. Currently, it is up to the BPEL engine to provide a monitoring interfaces but currently available engines lack this ability. As mentioned above, the monitoring of QoS is a necessary foundation to decide whether a replacement of a service should be performed and also what kind of QoS-based selection criteria should be used.

 

System Overview and Architecture

The VieDAME system is split into the VieDAME core and the VieDAME engine adapters. The VieDAME core ties together the monitoring, service selection and message transformation facilities as well as provides services such as data store access, scheduling and configuration data, whereas the engine adapters represent the interface to the BPEL Engine. Thus, to support new BPEL engines, it is (only) necessary to implement an engine adapter specifically to the desired engine implementation. The VieDAME environment currently supports ActiveBPEL 3.0, support for Apache ODE and JBoss jBPM WS-BPEL Runtime is planned once they are reliable enough to be used in production environments.

The VieDAME engine adapters are implemented using Aspect-Oriented Programming (AOP) to keep the system dependencies minimized.

click to enlarge

The basic idea of VieDAME is illustrated using the system architecture above:
After deployment of a process definition (1), the BPEL Processor (2) is ready to create new process instances. A new BPEL process instance (2a) is created when one of its start activities is triggered, e.g., by an incoming message.  Interaction with a partner link is initiated by Invoke Activities (2b) that create SOAP Calls (3a). These SOAP calls  are executed by a SOAP Engine (10) that returns the result of the invocation of an arbitrary partner service (11) upon completion of the request. The invoke activity reports the result to the process instance which in turn proceeds to the next activity.

When the VieDAME system is enabled, an additional level of processing is introduced, manifested in the Interception and Adaption Layer (5b), hereinafter referred to as the IAL. Basically, the IAL is created by aspects that are bound to specific joinpoints in the BPEL engine's code  by the definition of pointcuts. The advice code is then woven into the original method invocations by the AOP framework (4) at load time. The IAL provides a bidirectional interface for the Engine Adapter (5a) to tap the communication between the Invoke Activity (2b) and the SOAP Engine (10). The engine adapter in turn provides read-write access to the invocation context, enabling other VieDAME components - such as Monitor (8a) or Selector (8c) - to access and modify invocation parameters and other runtime data.

The first VieDAME component that is called after interception of a partner link invocation by the IAL is the Monitor component. It examines the Invocation Context to find the service name, endpoint address and operation name in order to load a previously persisted service reference or to persist a new service reference for future requests. The Monitor leverages the VieDAME Core (6) and the ORM Framework (7b) respectively to persist objects to a data store (10). Furthermore, the Monitor activates a timer to measure the time elapsed during the actual SOAP call and stores this information together with a reference to the involved service and success/failed flag. A scheduling framework (7a) is used to bulk-insert invocation events in order to optimize data store access.

If the service reference loaded by (8a) is marked as replaceable, the next VieDAME component takes control. The Selector component (8c) determines an alternative partner service by applying some selection algorithm to a list of configured alternative services (9). If an alternative service is found, the Invocation Context is updated with the alternative's endpoint parameters.

Like the Monitor component, Selectors access the data store by using (6) and (7b). The same applies to the last VieDAME component that can be called, the Transformer component. A Transformer (8b) is responsible for compensating the interface mismatch between the original service and the alternative. The Transformer uses transformation rules (e.g., XSLT stylesheets) stored in (9) to perform the required transformations.

After all applicable modifications are applied to the invocation context, the SOAP call is finally proceeded, probably invoking an alternative partner service instead of the original service. The difference between the unaltered invoke (3a) and the advised invoke (3b) is called the Invocation Context Delta, or ICD. A big ICD indicates many differences between the original service interface and the alternative service interface, whereas a small ICD indicates a replica of the original service (i.e., the original partner service and the alternative partner service only differ in their endpoint address). A zero ICD indicates that neither a service replacement nor message transformation was applied. The ICD measured value can be used as an indicator for determining to degree of adaption the VieDAME system has performed and whether the environment running VieDAME uses the adaption facilities at all.

Event Driven Business Process Diagnostics with Events4VieDAME

The upcoming and fully revised version of VieDAME for WS-BPEL provides many forward-looking features in the context of EDBPM (Event Driven Business Process Management). With the integration of Esper, a fully featured, high performance Open Source CEP engine, users can dynamically provision business process events to arbitrary subsystems (e.g. REST endpoints, JMS topics, dashboards or simply logfiles) by using a Groovy templates based Monitor-Listener approach. This template based solution makes it also possible to integrate subsystems that are not known in advance during runtime.

Besides predefined Event Types like ProcessInvocationEvent or OperationInvocationEvent, Events4Viedame provides full access to the payload of the incoming and outgoing messages via the IAL. Using this technolgy allows users not only to perform simple tasks such as determining which of the products sold during the last hour are most interesting to customers in real time, but also to define invocation patterns that can indicate suspicious or fraudulent behavior.

For a first impression of Events4Viedame, refer to the screenshots below. A demo and whitepaper will be available in late March.

Fig. 1 EventMonitor based on predefined Event Types.
Features EPL statement builder via context menu
 
 
Fig. 2 Statement List/State Management Types
 
Fig. 3 Payload Aware Event Monitor Overview. Details on
configured and captured payload namespaces, custom properties
(XPath properties) and listeners Types
 
Fig. 4 Payload Aware Event Monitor Wizard: Namespaces
 
Fig. 5 Payload Aware Event Monitor Wizard: Custom Properties
 
Fig. 6 Monitor and Listener Templates Overview
 
Fig. 7 Sample Listener Templates Detail View
 
Fig. 8 Named Window Overview
 
Fig. 9 On Demand Query Execution
 

Online Demo

The online Demo of VieDAME is currently not available. The fully revised version of VieDAME will be available in late March.

If you find any bugs or anything else, feel free to report it to: moser AT infosys dot tuwien dot ac dot at.

Publications

2011

2010

2008

Prototypes Overview