VieDAME - Vienna Dynamic Adaption and Monitoring Enviroment for WS-BPEL
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.
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.
Online Demo
The current version of the tool
can be found here. We currently do not have a
user documentation, it will be provided soon.
Please note that this is currently the development server because we try to improve our UI. Short downtimes or problems may occur. We will host it very soon a production server. If you find any bugs or anything else, feel free to report it to: florian AT infosys dot tuwien dot ac dot at.