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.