Redes temáticas

To overcome the above problem, some approaches have recently been proposed to support adaptation of service compositions in a proactive way [40][87][105][135].

These approaches extend the functionality provided by adaptable system based on reactive adaptation with the prediction and prevention of general unwanted behaviour in the execution of the service composition.

A proactive adaptation approach may work by observing a single internal fault in order to predict and prevent future faults or by monitoring the system status in order to assess the risk of a first fault. Nevertheless, dynamic service composition techniques which use proactive adaptation methods usually outperform reactive adaptation approaches due to the ability to avoid faults.

Some approaches have been proposed to support multilayered monitoring and adaptation of service compositions [57][122][144]. The work in [122] uses adapta- tion taxonomy and templates (patterns) created during design time to represent possible solutions for adaptation problems.

The work in [57][144] dynamically identifies cross-layered adaptation strategies for software and infrastructure layers. In [110] the authors propose approaches based on aspect-oriented to support adaptation of service compositions with sup- port for QoS aspects.

One of the first works to use a proactive solution for dynamic service composi- tion was PREvent [87], which was designed to support prediction and prevention of SLA violations in service compositions based on event monitoring and machine learning techniques. The prediction of violations, however, is calculated only at defined checkpoints in a composition based on regression classifiers prediction models. It is important to support changes in compositions due to problems that may occur in any part of the composition, as supported by ProAdapt.

In order to predict the probability that a change will actually effect the running service the work presented in [111] presents a methodology named change impact

probability (CIP). In order to compute the CIP, the authors provide a grading model for QoS values and changes that depends upon the degree of influence on the SLA. Next, a prediction is made to assess how long the service will remain at a given QoS level. Another model is then used to compute the possible start time of each service in the composition. Finally, this information is used to compute the CIP function and thus the probability of a change affecting the service composition in execution. The main problem of this work is that it does not consider structural changes of the service composition or the requirements defined for the whole composition. It also needed to better define a threshold for the CIP function.

The works in [105][135] advocate the use of testing to anticipate problems in service compositions and trigger adaptation requests. The approach in [135] supports identification of nine types of mismatches between services to be used in a composition and their requests based on predefined test cases.

The work in [105] is similar to the work in [111] commented above in a way that it tries to diminish the impact of unnecessary changes triggered by proactive adaptation using a combination of online testing and monitoring technique in order to determine failure probability within a confidence interval. The approach is constituted of five main steps as presented in Figure 2.7, namely (1) Determine Representative Data, (2) Determine Current Confidence, (3) Execute Tests, (4) Predict Failure Occurrence, (5) Decide on Proactive Adaptation.

The first step determines which of the data points collected so far are repre- sentative of the service that is being observed. This is important because during the execution of online tests, the service might have changed or new monitoring data might have been collected (from the SBA instances running in parallel).

Figure 2.7: Steps performed by to achieve proactive adaptation with confidence

This means that some of the data will not be representative anymore or that new, representative data should be considered. In step 3, test cases are generated and executed in order to gather additional, representative data points for failure prediction. After the previous steps have established a set of representative data that exhibits the required confidence for failure prediction, Step 4 predicts the actual occurrence of the failure. Step 5 decides on the actual proactive adapta- tion of the SBA instances. The decision on such an adaptation is based on the predicted failure probability from Step 4. For example, proactive adaptation is triggered if the prediction is above a predefined threshold.

The solution takes into consideration two different approaches to start the described steps. The first one considers triggering step 1 as soon as the monitoring process discovers a failure. This strategy has the clear disadvantage of delaying the adaptation, but it reduces the cost related to testing since it is triggered when the potentials need for a proactive adaptation occurs. The second approach triggers step 1 after each change of a partner of the SBA. Here, one the contrary of

first approach, adaptation can be performed early, on the other hand, the testing routines could be intensive and the collected data may never be used. Moreover, the creation of test cases is not easy and the paper does not specify how test cases are created for modified compositions. Additionally, the work is focussed only on service binds, which means that structural changes in a workflow are not considered and new services cannot be dynamically found.

Online testing is also employed in [127]. The work presents an online testing and monitoring framework focused on dynamic selection of service operations by using quality prediction. Such proactive quality prediction is performed by selecting test cases and performing online testing in parallel of the execution of the service-based system to gather additional evidence for failure on top of the monitoring process.

Similar to the approach presented in this report, in [18] the authors advocate that the management of service compositions during runtime needs to consider the structure of a composition and the dependencies between the participating services, and propose an approach that determines the impact of each service in a composition on its overall performance.

The solution presented in [106] uses a combination of proactive adaptation techniques along the phases of the service life-cycle. The core concept is to use these techniques to determine deviation from requirements based on monitored failures. In the approach, functional and nonfunctional requirements are formal- ized and the service composition also needs to be formalized in order to support automated checks. The approach attempts to solve the problem of whether the failure of a single service leads to a violation of the composition as a whole.

of some service operation invocation deviates from its assumption the past mon- itoring data together with the assumptions about the not yet invoked services operations and the service composition specification is checked against the gen- eral requirements (SLA).

Figure 2.8: Requirements Monitoring Steps performed by to achieve proactive adaptation with confidence (extracted from [106])

If the requirements are still satisfied, the composition can continue its exe- cution, as depicted in Figure 2.8, otherwise it must be adapted. The approach manages to cover adaptation along service life-cycle and formalisation of func-

tional and nonfunctional requirements allow proactive runtime check of service compositions. However, the solution covers only one-to-one maps and does not specify how options to replace services are discovered. Moreover, it does not consider different adaptations for multiple parallel executing instances.

A solution that combines proactive adaptation and reactive adaptation is presented in [72]. The approach presents a new model to represent service com- position in order to include execution state of each service within the composition in order to provide self-protecting and self-healing. The work firstly introduces the notion of an execution instance as a memory structure to record information concerning a single execution of the composite service.

Figure 2.9: Structured view of an example of execution instance (extracted from [72])

Figure2.9 presents a workflow and tree view of an execution instance as de- fined in [72], where leaf nodes are referred to partners in WS-BPEL, while other nodes present control logics. The execution instance maintains information de- fined as attributes on nodes and edges as QoS Feature and Execution Feature. A QoS feature is a set of quality parameters associated with service nodes and control nodes. An execution feature contains control and execution information related to edges. The notion of execution instances is also used in the work

described in this thesis to support independent adaptations. The execution in- stances used by ProAdapt, however, are a bit more flexible to support structural changes, faster computation of candidate operations, and faster verification of SLA satisfaction of logic regions and the composition as a whole.

The work presented in [72] constitutes a two-stage adaptation model that in- cludes How, Where, and When adaptation actions take place. The adaptation is performed by three actions, namely (a) request redirection, (b) request recon- struction, and (c) execution instance revision. The request redirection (a) is the action involved in proactive adaptation and triggered by new service request. The request reconstruction (b) is performed in a reactive way and triggered by arrival of a failed or error response. The execution instance is revised (c) both in proactive and reactive way by updating the QoS features.

More specifically, the required service is invoked directly if it is a dependable one. The request is redirected on condition that an alternative service can be found (the execution instance is updated accordingly). In the case of undepend- able or no alternatives, the approach suggests the review of quality setting (with a user) or the termination of the current execution. The adaptation process can be triggered by a service change either if a recommended service is founded to be unusable in the future execution or if a service is identified as possible threat to break constraints defined in the SLA.

The combination of a proactive approach with a reactive approach presented in [72] proved to be useful when dealing with QoS deviations. The defined concept of execution instances provides a way to formally represent system requirements as well as to store dynamic system state. However, the work does not specify how a service community could work. This may have a great impact on the solution,

specifically regarding the time to select a substitute service. Moreover, it does not consider changes at composition itself or the service composition SLA as a whole.

This previous sections present a comprehensive review of the related work to this thesis in the specific context of adaptation for service compositions. By introducing the related work in a simple but efficient categorisation, it was easier to present the approaches in a close to evolutionary way. Starting from static approaches, passing from reactive adaptation and finally ending in the dynamic and proactive adaptation approaches. By analysing the previous discussed works, it seems that while there are some contributions about how to dynamically adapt service compositions, these ideas are still scattered and cannot be envisioned in practice yet. The next section addresses the problem of services selection, regardless of the other adaptations concerns involved.