A Plug in Architecture for Self Adaptive Web Service Compositions

Only available on StudyMode
  • Topic: Aspect-oriented programming, Aspect-oriented software development, Service level agreement
  • Pages : 18 (5887 words )
  • Download(s) : 10
  • Published : January 29, 2013
Open Document
Text Preview
A Plug-in Architecture for Self-Adaptive Web Service Compositions Anis Charfi∗ , Tom Dinkelaker† and Mira Mezini† ∗ SAP Research CEC Darmstadt, Germany Email: {first.lastname}@sap.com † Software Technology Group Technische Universit¨ t Darmstadt, Germany a Email: {lastname}@st.informatik.tu-darmstadt.de

Abstract—Several approaches have been proposed to introduce self-management capabilities for web service compositions. However, most of these works are limited as they are not extensible, i.e., new self-adaptation features cannot be supported, and even if that is possible then still this cannot be done dynamically while the composite services are running. In addition, many of these works are not based on the service composition standard WS-BPEL. In this paper, we propose a plug-in architecture for self-adaptive web service composition, in which self-adaptation features are well-modularized in aspect based plug-ins. Our approach supports applicationspecific adaptation scenarios, is easily extensible, and allows self-adaptation logic to be hot-deployed on running process instances. We have implemented this architecture and several plug-ins using the dynamic aspect-oriented workflow language AO4BPEL. Keywords-Aspect-Oriented Programming; Autonomic Computing; Self-Healing; Service Composition; BPEL;

cesses to integrate self-healing logic [5], [6]. However, these approaches have limitations with respect to extensibility, flexibility, and scope. First, most existing approaches come with predefined self-adaptation features and adding further self-adaptation features by a third-party is not possible. The problem with current approaches is that self-adaptation logic is tightly coupled with the execution logic inside the engine implementation and therefore the adaptation logic cannot be extended by a third-party. Second, in the works that allow extending the engine with new self-management features the logic of these features cannot be integrated dynamically with already-deployed or running web service compositions. Third, existing approaches do not support applicationspecific self-adaptation features. As example for such features in the context of a travel booking process could involve the monitoring of delays in issuing travel documents by partner services and reacting to that automatically by sending the documents by a rapid post service. In this paper, we propose a plug-in architecture for selfadaptive web service composition, which tackles the three problems discussed above. Self-adaptation plug-ins are implemented by means of two types of aspects: monitoring aspects detect erroneous situations and actions that may cause missing predefined goals whereas adaptation aspects perform corrective actions. We have implemented this architecture using the AO4BPEL language [7], an aspect-oriented workflow language providing similar features as dynamic aspect-oriented programming (AOP) [8]. Moreover, in this paper, we have extended AO4BPEL with special support for dynamic plug-ins through generating, activating, and deactivating aspects at runtime. The proposed architecture is easily extensible as new selfadaptation features may be easily implemented by providing the respective monitoring and adaptation aspects. These features can be plugged and un-plugged on demand and even at runtime thanks to the dynamic weaving capabilities of the AO4BPEL engine. Further, our approach supports application-specific self-adaptation scenarios and we have used it to build several application-specific self-adaptation plug-ins as well as three generic plug-ins.

I. I NTRODUCTION The context of composite web services is very dynamic and several kinds of changes and faults may arise after deploying a composite service. For example, one of the partner services may go down, it may be updated to require new policies, etc. When such situations happen the composite web service will not operate appropriately and runtime faults will be thrown. Most available web service...
tracking img