A Plug-in Architecture for Self-Adaptive Web Service Compositions Anis Charfi∗ , Tom Dinkelaker† and Mira Mezini† ∗ SAP Research CEC Darmstadt, Germany Email: {fi † Software Technology Group Technische Universit¨ t Darmstadt, Germany a Email:
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 Term Paper on Classification of Services
Problem: narrow exposure of managers to the variety of service industries; managers perceive their service as unique; management personnel is usually inbred; as a result, marketing thought in the field of services is underdeveloped. E. g. , hoteliers often spend their whole life in the industry or even one company, most airline managers have grown up in the commercial aviation industry, bankers ...
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 orchestration engines do not provide automated support for detecting and reacting to such situations and handling them can only be done through manual human intervention, i.e., the fault must be detected, the web service based process that threw the fault needs to be undeployed, certain changes should be applied either to the process itself or to its deployment configuration (e.g., replacing the faulty partner service, changing the setting of the interactions to be secure, etc), and then restarting the composite service. Such an approach is inappropriate because the operation of the composite service is discontinued, because certain processes may be interrupted in the middle of a business transaction, and also because of the huge administrative overhead.
The Business plan on Service Marketing Report Of Sushi Restaurant
Tomodachi operates in the central business district with over 10 competitors around the vicinity. However, Tomodachi has been able to remain relatively competitive and active by maintaining its differential advantage as the only modern Japanese restaurant with a world class sushi train as well as an a la carte menu to cater for a full Japanese dining experience. Our service report analyzes ...
The remainder of this paper is organized as follows. Sec. II presents background knowledge and an example. Sec. III motivates the need for self-management in composite web services. Sec. IV presents the proposed architecture. Sec. V illustrates the proposed approach with examples and Sec. VI evaluates it. Sec. VII reports on related work and Sec. VIII concludes the paper. II. BACKGROUND AND E XAMPLE Aspect-Oriented Workflow Languages: In [9], aspectoriented software development [10] concepts are introduced to workflow management and workflow languages. In addition, the AO4BPEL [7] language is presented as a proofof-concept together with a compliant BPEL orchestration engine supporting the dynamic composition of aspects and processes.
AO4BPEL is an XML-based language. Aspects consist of one or several pointcut and advice. The pointcut language of AO4BPEL is based on XPath, which is used to select activity joint points (i.e., points corresponding to the execution of activities) and internal join points (i.e, points inside the execution of activities such as the point where the outgoing message of an invoke activity is generated).
An advice is a BPEL activity that implements some crosscutting logic, e.g., call to a monitor. Special constructs may be used inside the advice to access the input and/or output data of the join points, the respective SOAP messages, as well as reflective information. Further, an aspect may declare partners, variables, fault handlers, etc. Example: In Fig. 1, a simple travel process (index 1) is shown. This process interacts with a flight service (e.g., “Berlin Air”) and a hotel service (e.g., “Star Hotel”) to
The Research paper on Business process management Case Study
1.How would you define “business process management”based on this video and text reading? How would you compare it to business process re-engineering, continuous improvement, and total quality management approaches? Answer: -Business Process Management is most often associated with the life cycle of a business process. The process life cycle spans identifying and improving processes that deliver ...
find and create vacation offers that match the needs of a customer. Another process is responsible for booking once the customer has selected one offer. At index 2, an aspect is shown, which measures the execution time of all calls to partner services. This aspect defines a pointcut that matches all interactions with a partner (the XPath expression //invoke).
Thus, when the process executes and invoke activities are reached (index A and B), the advice of the aspect at index 2 is executed. This aspect defines an around advice that wraps the original invoke join points into a sequence. The latter starts a timer, then executes the original join point activities using the placeholder activity proceed, and finally stops the timer. The proceed activity always executes the currently intercepted process activity. Thus, when the pointcut matches the invocation of the flight service (index A), proceed invokes the “Berlin Air” service (index a).
When calling the hotel service (index B), proceed invokes the “Star Hotel” service (index b).
At index 3, a second aspect is shown, which replaces invocations of the flight partner “Berlin Air” by invocations of “Air Munich”. Such a replacement aspect can be activated at runtime, which changes the execution of currently deployed processes.
To replace the flight partner, the pointcut must match only the invoke activities that interact with that specific partner (here //invoke[@partner=”flight”]).
When the original invocation of the flight service is reached (index C), the associated around advice is executed. In contrast to the previous aspect, this advice does not call proceed, thus the advice completely replaces the original join point activity and invokes an alternative partner instead (index c).
III. P ROBLEM S TATEMENT Several adaptation needs arise in the context of the example presented in the previous section. First, certain partner services may become unavailable, e.g., due to a connection loss (Example 1).
The Essay on Based Cost Process Activity Costing
Purpose: In 1994, the Office of the Assistant Secretary of Defense, Director of Defense Information, issued the Framework for Managing Process Improvement, A Guide to Enterprise Integration, providing Department of Defense functional managers with the processes and procedures that should be applied when conducting process improvement projects throughout the DoD. Since that time there have been ...
Second, the configuration of certain non-functional properties in the partner services may be updated, e.g., to require message encryption through an update to the respective WS-Policy file (Example 2).
Third, a partner service that committed to a certain quality of service, e.g., through a Service Level Agreement (SLA) may fail to provide what was promised (Example 3).
As a result, the process will perform badly and may even violate its own SLAs in front of clients. We call the three self-adaptation requirements mentioned so far generic requirements as they arise in any service composition scenario independently of what the service composition at hand does. On the other hand, there are also application-specific requirements, which depend on the concrete composition scenario and are relevant in that context only. For instance, in the context of the travel booking process it might be necessary to monitor delays in issuing the travel documents and react to that automatically either by sending them by rapid post or by sending an e-mail to the customer and asking him to collect the documents at the airport (Example 4).
Most web service composition approaches and tools are not able to support the self-adaptation examples mentioned above. Some recent works have extended orchestration engines with self-adaptation capabilities [2], [1], [3], [4] whereas others provided process transformation tools to add self-healing logic in the BPEL processes [5], [6]. However, these works are still limited in several regards. First, they are limited with respect to extensibility as they come with a predefined set of self-adaptation features that cannot be extended.
For example, the orchestration engine may support the automatic replacement of a partner in case of a failure but it does not provide any appropriate means that allows users to add support for other requirements such as monitoring and reacting to partner policy updates. If such means are provided at all then adaptation could happen only statically [5], [1], i.e., one has to stop the orchestration engine and/or running BPEL processes, apply certain modifications, and restart the engine and/or the BPEL processes. It is not possible to hot-deploy the self-adaptation logic. Further, as most existing approaches introduce self-management features at the level of the BPEL engine, they cannot support application-specific requirements such as Example 4. IV. A P LUG -I N A RCHITECTURE FOR S ELF -A DAPTATION This section presents the proposed architecture and explains the development of self-adaptation plug-ins based on that architecture. A. Overview The overall architecture is presented in Fig. 2.
The Essay on Client Service Activities of Grey Advertising
Shaiful Azim, Director, Operation, GREY Bangladesh Ltd. and Abdullah Mohammed Ibrahim, Assistant Professor in Marketing, Department of Business Administration, Northern University Bangladesh. This report has not been previously submitted to any other University/Collage/Organization for any academic qualification/certificate qualification/certificate/diploma or degree. The work I have presented ...
The orchestration engine can be extended by special self-adaptation plug-ins using two kinds of extension points: implicit and explicit. Every process activity is an implicit extension point where the plug-in can execute adaption logic. At the explicit extension points, the architecture may be extended with web services that are provided by the self-adaptation plug-in (e.g., for monitoring or for diagnosis so that the plug-in can decide if adaptation is needed).
These services can be deployed locally on the same application server as the BPEL engine. Each plug-in follows a well-defined objective (e.g., selfhealing in case of policy updates).
It consists of several aspects and infrastructural services. A plug-in is developed by domain experts, e.g., an administrator. A plug-in can be deployed to the orchestration engine at runtime through an administrator console. Inside the plug-ins, two types of aspects are used: monitoring aspects, which collect information and decide based on it whether adaptation is needed and adaptation aspects, which handle the erroneous situations and events detected by the monitoring aspects. The monitoring aspects are able to activate and deactivate the adaptation aspects at runtime.
Self-Adaptation Plug-ins
Implicit/Explicit Extension Points
Figure 2.
The Plug-In Architecture.
The rationale behind using aspects and especially dynamic AOP is manifold. First, AOP provides implicit extension points at every join point in the process, at which one can add additional adaptation activities, skip existing activities, etc. Using activity join points as implicit extension points allows unanticipated adaptation of the BPEL processes. Second, the automatic composition of aspects into workflows enables the integration of the logic of self-adaptation plugins into the functional logic of processes. Third, AOP keeps the self-adaptation logic separated from the functional logic. This separation improves the design of the application as conditional statements for self-management can be avoided in the processes. Forth, dynamic AOP enables the adaptation of running processes, i.e., stopping running compositions is not needed. Our architecture is easily extensible. Some plug-ins may be delivered with the engine and further plug-ins can be built on demand by providing aspects and if needed infrastructural services. The plug-ins can be created at anytime, deployed and undeployed using the architecture’s hotswap capabilities implemented by dynamic AOP. The aspect-aware orchestration engine used in our architecture takes care of managing all active plug-ins and their dependencies.
The Essay on Discussing the customer service policies
In my assignment I will provide information about customers services levels, customer satisfaction, what is customer services , I will give examples and evidence about different institutions and their customers services levels and policies .I want to start with the definitions of customer services and customers service policies. Customer service is the provision of service to customers before, ...
B. Implementation We use the dynamic AOP language AO4BPEL [7] and the respective engine to implement our architecture. In the following, we describe the development process of selfadaptation plug-ins, which consists of three steps according to the sense-think-and-act paradigm: Sensing: The developer analyzes the application for concrete problem scenarios for which the self-adaptation plug-in should provide a solution. Then, the developer implements the sense part using a pointcut, which selects those process activities that need to be monitored. In List. 1, a generic template for monitoring aspects is shown leaving unspecified the sense logic in line 3. At this place, the developer must specify a concrete pointcut for detecting relevant events (e.g., invocation of some partner service) for his scenario.
Sensing Thinking
Listing 1.
Generic monitoring aspect
Thinking : Next, the developer implements the think part using advice logic, e.g., a fault handler can be used to identify failures in invocations. This advice is associated with the pointcut implementing the sense part. Further, this think advice provides logic that performs the decision on an adequate self-adaptation plan, i.e., it selects and activates an appropriate adaptation aspect using special language constructs of AO4BPEL. For taking that decision, the plugin may need to provide helper web services (infrastructure services).
These services are integrated in our architecture using the explicit extension point (cf. Fig 2).
The advice implementing the think part identifies critical situations by following one of three possible strategies: 1) pre-examination, 2) post-examination, and 3) wrapping. Pre-examination proactively ensures that certain process activities will not fail or will be replaced by alternative activities. Pre-examination can be used e.g., to detect changes of the partner policies (Example 2) that will likely result in a failure when invoking a partner. Post-examination is performed after the monitored activities are executed. Postexamination can be used e.g., to detect SLA violations and the delays in issuing travel documents (Examples 3 and 4).
Depending on the result of the condition evaluation, the think part decides on the activation of one or more adaptation aspects (line 5).
In case the condition is evaluated to false, the advice does not perform any further actions; in case of pre-examination, the intercepted join point will be executed without modifications. Wrapping ensures that a process activity will not fail by encapsulating it into a wrapping activity (e.g., a scope with a fault handler) that captures problematic situations when the original activity is executed. Wrapping is used when we cannot decide via pre-examination if the activity will fail or not, e.g., when invoking an external partner service. To ensure self-adaptation, the original activity that possibly fails is wrapped into a structured BPEL activity (e.g, scope) that provides additional logic to capture possible errors of the original activity (e.g., a provided fault handlers captures failures of the original activity).
The wrapping strategy uses the advice type around that replaces the original activity with the structured activity, which internally calls the replaced action by using proceed. List. 3 shows the generic structure of a monitoring aspect that employs wrapping.
Acting : The developer implements the act part in form of an adaptation aspect, which uses pointcut-and-advice to change running processes, e.g., one can replace the faulty partner service. The generic structure of an adaptation aspect is shown in List. 4. A pointcut is used to select join points where adaptation actions need to be applied (line 3).
These join points correspond to the implicit extension points of our architecture. Adaptation actions are specified in an around advice that replaces the original join points by alternative activities to solve the problem (line 6).
Join points to adapt Adaptation Action
List. 2 shows a generic template for pre/post-examination aspects. The advice of such an aspect is structured as follows. First, a dynamic condition is evaluated (line 4 in List. 2) to decide whether the sensed event will lead to a problematic situation (pre-examination) or whether it indicates that a problematic situation has already occurred
When the adaptation actions depend on the dynamic execution context of the process, pre-defined adaptation aspects are not feasible. E.g., when a partner’s security policy has changed so that a new encryption algorithm is required, then the adaptation aspect must secure the outgoing messages according to the new policy. However, as the new policy is only available at runtime the adaptation aspects must be generated. In such cases, the self-adaptation plugin has to provide an aspect generator service that extends our architecture via the explicit extension points. Providing an aspect generator is possible if the source language is fixed, which is the case for WS-Policy and related assertion languages (e.g., WS-SecurityPolicy) as well as for WSLA. One approach to implementing such a generator consists in defining aspect templates, i.e., incomplete parameterized adaptation aspects, for each type of policy assertion. The generator checks all assertions in the policy file and for each matching one it generates an adaptation aspect by setting the parameters of the aspect template based on the policy attributes.
Extensions to AO4BPEL: AO4BPEL supported only the manual activation and deactivation of aspects via the administrator interface. However, to implement our architecture the monitoring aspects should be able to activate and deactivate adaptation aspects programmatically. Therefore, we extended AO4BPEL with new activities for activating and deactivating aspects from an advice of another aspect: activate and deactivate. Both take a string with the aspect name as parameter. Another variant of the activate activity takes a file name (WS-Policy or WSLA file) as a parameter and generates the necessary aspects for making the composition side compliant with the policy (e.g., by generating aspects for encryption if the policy requires that) or for monitoring the SLA of a partner. V. E XAMPLES We developed three generic self-adaptation plug-ins supporting the automatic replacement of faulty partner services (Example 1), the automatic detection and reaction to partner policy updates (Example 2), and the automatic monitoring of partner SLAs and replacement in case of violations (Example 3).
Further, we developed an application-specific adaptation plug-in for the travel agency scenario (Example 4).
Due to space limitations, we present only the plugins for examples 2 and 3 in the context of the scenario of Sec. II. A. Self-adaptation to policy changes This plug-in consists of a monitoring aspect that is shown in List. 5 and a set of dynamically generated adaptation aspects that configure the client side middleware so that the requirements of the new policy are satisfied [11]. Further, we had to develop two infrastructural web services (the explicit extension points): the policy web service and the aspect generator service, which generates a set of aspects based on a given policy in WS-Policy. The policy web service, which is based on Apache WS Commons [12], allows extracting a policy from a WSDL file, interpreting it, and detecting changes to the policy.
It also allows building the intersection of the partner policy with the composition-side policy. The policy-based aspect generator service uses aspect templates and XSLT to emit a set of aspects that enforce a given policy. In List. 5 the pointcut (lines 3–5) matches all interactions with the partner flight (the sense part).
The before advice (lines 6–40) implements the pre-examination logic to detect changes of the partner policies. The advice checks whether a new policy is available by calling the operation isNewPolicyAvailable (lines 18–21) on the policy Web Service. If that condition is evaluated to true the advice gets the new policy by calling the operation getServicePolicy on the policy Web Service (line 27) and uses the second variant of the activate activity (lines 32–34) to generate and activate adaptation aspects based on the new policy (the act part).
For example a profiling aspect that measures the average response time by wrapping all interactions with a partner it structured as follows. It uses an appropriate pointcut (the sense part) like the aspect shown in Fig. 1. For the think part, the profiling aspect defines an around advice that nests the invocation of the partner service using the proceed activity between two calls to a measurement Web Service that records data about the partner performance such as start and end time of the invocation. The other monitoring aspect in this plug-in is shown in List. 6. It contains post-examination logic, which is used in this scenario to check after each interaction with the partner whether that partner has violated its SLA. In case of a violation, this aspect “decides” to replace the unreliable partner using an adaptation aspect. The pointcut in this example (the sense part) matches all interactions with the monitored flight service (lines 9–11).
For the think part, this aspect implements an after advice with post-examination logic (lines 12–36) that checks after calling the partner whether the SLA has been violated. The detection of SLA violations is based on the outcome of the current call and the previously collected data. For that purpose, the operation checkSLA of the condition evaluation service is called.
If the SLA has been violated the advice activates an adaptation aspect (line 32) that replaces the unreliable partner. VI. E VALUATION We evaluated our architecture based on the evaluation criteria for autonomic computing systems presented in [13]. We chose a qualitative evaluation because no general-purpose evaluation framework exists for comparing architectures of autonomic computing systems. Quality of service Different QoS metrics ensure that a system reaches its goal. Our approach supports measuring and enforcing service-level agreements (SLAs) and we have demonstrated this for several examples. New QoS metrics can be easily supported in our approach without affecting the infrastructure by providing a new plug-in and if necessary further infrastructural services. Costs In our approach there are education costs as the implementors of self-adaptation plug-ins have to learn AO4BPEL.
However, as AO4BPEL uses BPEL as advice language the education costs are limited and these costs have to be paid only once. The once acquired knowledge can then be used to implement further self-adaptation features. As in our approach new features can be added at runtime, there is a gain as business processes are not discontinued, i.e., there is no loss due to a downtime of business processes. There is a general performance overhead due to AOP support, which is around 2 % in comparison to the process execution without aspect support [7]. The overhead for executing a certain functionality e.g., for sensing in the advice compared to having that functionality directly in the process is less than 0.5% of the process execution time [7].
B. SLA Monitoring This plug-in consists of a set of generated monitoring aspects for profiling and for detecting SLA violation, and one adaptation aspect for replacing the partner service that violates its SLA. Further, this plug-in provides four infrastructural web services: an SLA web service, a measurement web service, a condition evaluation service, and an SLAbased aspect generator service. The SLA Web Service supports retrieving the SLA of a partner and extracting the relevant data. The measurement Web Service is used by the monitoring aspects to collect data about the QoS for each interaction with the partner. The condition evaluation service is used by the monitoring aspect to find out whether a certain SLA parameter (e.g., average response time) is violated.
The SLA-based aspect generator service is also based on aspect templates. The relevant SLA metrics are extracted from the WSLA files of the partners when a BPEL process is deployed. For each SLA property stated in the WSLA file of the partner web service one profiling aspect is generated using the SLAbased aspect generator service. This aspect collects data that is relevant for the SLA property at hand such as response time. Another generated monitoring aspect checks for SLA violations after invoking the monitored partner based on the data collected by the profiling aspects.
Granularity/Flexibility Our architecture supports fine granularity as every process activity can be monitored and adapted. Further, our approach allows monitoring/adapting all instances of a given process or selected instances only. The approach is also quite flexible as the logic of selfadaptation plug-ins can be deployed and removed from processes at anytime during the execution. Failure Avoidance Our architecture improves failure avoidance not only at the service call level (by automatically replacing partners) but also at any activity level (e.g., data assignment, sequence/flow activities, etc).
Our approach does not support failures that are not at the process level such as failures at the engine level. Degree of Autonomy Our architecture allows to adapt process to failure scenarios that have not been anticipated in the process design. It does not address reacting to failure scenarios that have not been anticipated in plug-ins. Still, advanced learning techniques could be provided as new intelligent plug-ins. Adaptivity Adaptivity in our architecture is implemented by the adaptation aspects, which introduce both structural (e.g., adding new partner links and variables) and behavioral adaptations. Adaptations happen at runtime thanks to the hot-swap capabilities of our engine.
Sensitivity Too high sensitivity can lead to situations where constantly changes are applied to the system. In our architecture sensitivity can be controlled through additional reasoning logic in monitoring aspects. Stabilization In certain architectures, a self-adaptation triggers another self-adaptation the system may continuously change until it is stabilized. In our architecture, repetitive self-adaptations are prevented since adaptation activities of the aspects are not subject to self-adaptation again. The evaluation framework of [13] defines other criteria that are less relevant for our context such as Time to Adapt and Reaction Time, which is in our case feature dependent, and Benchmarking which was not considered because there is no standard BPEL benchmark.
VII. R ELATED W ORK Self-Adaptation by preprocessing: Several approaches transform the BPEL process to add self-adaptation logic. Their advantage is that the transformed processes run on a standard engine. In [5], Modafferi and Conforti present an approach, in which WS-BPEL processes are annotated with recovery information. Based on these annotations a pre-processing tool transforms the BPEL process and adds new activities that implement the respective recovery actions. This approach frees the BPEL designer from writing complex BPEL code to implement the self-adaptation functionality. Exactly five self-adaptation features are supported such as activity timeout and repeated execution of an activity in fault case. However, this work is not extensible as further features would require modifications to the process transformation tool and additional annotations.
The TRAP/BPEL framework [6] adds autonomic behavior to BPEL processes by transforming them so that they use generic proxies to interact with partners. The proxy provides self-adaptation behavior based on some high-level policies defined in a configuration file. This approach supports only the substitution of failing partner services. It is not extensible, i.e., every new self-adaptation feature would require modifying the transformation tool. Self-Adaptation by late binding service calls: Bianculli et al. [14] propose an architecture for self-adaptive Web service compositions in which each service has an associated repudiation. During service calls, the engine monitors QoS and pushes repudiation data to a registry. For each service call, a specialized service call mechanism first checks for a low repudiation of the called partner. In case the repudiation is low another partner is selected from a registry.
In comparison, this work can monitor/adapt only service calls and not other BPEL activities. Further, new self-adaptation features cannot be added. In [1] an approach is proposed to supervise BPEL processes by combining aspects and policies. WS-Policy policies are specified in a deployment descriptor and transformed to supervision rules that are automatically enforced by an AOP-based framework implemented with AspectJ on top of ActiveBPEL. This approach is more declarative than ours but it uses aspects to change the engine and not the processes. Further, it is not easily extensible as the implementors of self-adaptation features must know the engine implementation and new features can only be added before delivering the BPEL engine to the customer. Adaptation at runtime is not supported as AspectJ uses static weaving. Applicationspecific self-adaptation is not supported.
Self-adaptation by modified process representation: In [4], a modified BPEL engine is presented. It supports the detection of various web service faults and their recovery based on special self-healing policies. This engine is not extensible as new self-adaptation features can only be provided through extensions to self-healing policy language, which also means that the engine implementation interpreting the new policies has to be modified. In [3], Moser et al. present the VieDAME environment, which is an extension to the ActiveBPEL engine that allows the monitoring of BPEL processes w.r.t. some quality of service attributes and also the replacement of partner services according to various strategies. Like our approach, the work in [3] allows the replacement of partner services at runtime. However, it supports only adaptation related to interactions with partner as it is implemented with an aspectoriented approach that intercepts SOA messages. It is also not extensible, i.e., it does not provide means to offer further self-adaptation features.
VIII. C ONCLUSION In this paper, we presented a plug-in architecture for selfadaptive Web Service composition. Self-adaptation plugins consist of monitoring and adaptation aspects, which realize the sense-think-act paradigm and may also provide infrastructural services. We presented a proof-of-concept implementation using AO4BPEL and built several plugins according to the proposed architecture. Our approach is extensible as further self-adaptation requirements can be easily added, open as the self-management logic is visible to end users, and it also allows the dynamic adaptation of running processes. Further, our approach supports applicationspecific self-adaptation scenarios. As in this paper we focused only on self-healing and self-configuration, our future work will address self-optimization and self-protection. ACKNOWLEDGMENTS Part of the work is conducted in the context of the CASED research center for advanced security at TU Darmstadt (www.cased.de).
This work was partly supported by the feasiPLe project, Federal Ministry of Education and Research (BMBF), Germany. Christian Fuest has implemented certain parts of some of the concepts presented in this paper in the context of his Master’s thesis [15].
REFERENCES
[1] L. Baresi, S. Guinea, and P. Plebani, “Policies and Aspects for the Supervision of BPEL Processes,” in Proc. of CAiSE, ser. LNCS, vol. 4495. Springer, June 2007, pp. 340–354. [2] A. Lins, F. Antonio, J. dos Santos Junior, and N. Rosa, “Improving Transparent Adaptability in Web Service Composition,” in Proc. of IEEE International Conference on ServiceOriented Computing and Applications (SOCA07), 2007. [3] O. Moser, F. Rosenberg, and S. Dustdar, “Non-Intrusive Monitoring and Service Adaptation for WS-BPEL,” in Proc. of the Int. Conference on World Wide Web, April 2008. [4] S. Subramanian, P. Thiran, N. C. Narendra, G. K. Mostefaoui, and Z.
Maamar, “On the Enhancement of BPEL Engines for Self-Healing Composite Web Services,” in Proc. of the International Symposium on Applications and the Internet (SAINT).
IEEE Computer Society, 2008, pp. 33–39.
[5] S. Modafferi and E. Conforti, “Methods for Enabling Recovery Actions in WS-BPEL,” in Proc. of Int. Conference on Cooperative Information Systems (CoopIS), ser. LNCS, vol. 4275. Springer, November 2006. [6] O. Ezenwoye and S. Sadjadi, “TRAP/BPEL: A Framework for Dynamic Adaptation of Composite Services,” in Proc. of Int. Conference on Web Information Systems and Technologies (WEBIST), 2007. [7] A. Charfi and M. Mezini, “AO4BPEL: An Aspect-Oriented Extension to BPEL,” World Wide Web Journal: Recent Advances on Web Services (special issue), March 2007. [8] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin, “Aspect-Oriented Programming,” in Proc. of the 11th European Conference on ObjectOriented Programming (ECOOP), ser. LNCS, vol. 1241. Springer, June 1997, pp. 220–242. [9] A. Charfi, “Aspect-oriented workflow languages: Ao4bpel and applications,” Ph.D. dissertation, Darmstadt University of Technology, Darmstadt, Germany, 2007. [10] AOSD, “Aspect-Oriented Software Development Community and Conference,” http://www.aosd.net. [11] A. Charfi, B. Schmeling, A. Heizenreder, and M. Mezini, “Reliable, Secure and Transacted Web Service Composition with AO4BPEL,” in Proc. of the 4th IEEE European Conference on Web Services (ECOWS).
IEEE Computer Society, December 2006, pp. 23–34. [12] Apache, “Apache WS Commons,” http://ws.apache.org/ commons/, 2006. [Online]. Available: http://ws.apache.org/ commons/ [13] J. McCann and M. Huebscher, “Evaluation Issues in Autonomic Computing,” LNCS, pp. 597–608, 2004. [14] D. Bianculli, R. Jurca, W. Binder, C. Ghezzi, and B. Faltings, “Automated Dynamic Maintenance of Composite Services Based on Service Reputation,” LNCS, vol. 4749, p. 449, 2007. [15] C. Fuest, “Self-adaptive Web Service Composition with AO4BPEL,” Master’s thesis, Technische Universitt Darmstadt, Fachbereich Informatik, 2008.
