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.
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
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.
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.
- O. Moser, F. Rosenberg, S. Dustdar (2011). Domain-Specific Service Selection for Composite Services. IEEE Transactions on Software Engineering, IEEE Computer Society. (forthcoming)
- O. Moser, F. Rosenberg, S. Dustdar (2010). Event Driven Monitoring for Service Composition Infrastructures, 11th International Conference on Web Information Systems Engineering (WISE'10), Hong Kong, China; 12.12.2010 - 14.12.2010; Springer, LNCS 6488 (2010), ISBN: 978-3-642-17615-9; S. 38 - 51.
- O. Moser, F. Rosenberg, S. Dustdar (2008) VieDAME – Flexible and Robust BPEL Processes through Monitoring and Adaptation, Informal demo, Proceedings of the 30th International Conference on Software Engineering (ICSE'08), 10-18. May 2008, Leipzig, Germany
- O. Moser, F. Rosenberg, S. Dustdar (2008) Non-Intrusive Monitoring and Adaptation for WS-BPEL. Proceedings of the 17th International World Wide Web Conference (WWW'08), 21-25. April 2008, Beijing, China.