As mentioned above, ProAdapt is a proactive adaptation framework to support dynamic reconfiguration of services compositions execution instances in order to improve the performance, reliability, and general conformance of the compositions instances with their requirements. To accomplish these ambitious goals ProAdapt continuously monitor and analyse events of interest generated in the execution environment in order to detect and prevent faults that could potentially lead to compositions failures (see Section 2.1 for a review of faults and failures).
Figure3.1 summarises the general adaptation process adopted by ProAdapt. As show in the picture, various events are continuously monitored and reported to be analysed. During the analysis phase, the framework verifies the reported events, together with running execution instances, templates, and default bind- ing information, to assess the need for adaptation and to perform any required preprocessing, such as marking service operations as potentially unavailable. Fi- nally, during the decision and enacting phases any executions instance, template, or binding information can be modified.
Events Monitoring
Analisis Decisions and
Enactions Templates
Binding Information Execution Instances
Figure 3.1: ProAdapt Overview
compositions. As described in Section 1.2, an execution engine is the piece of software responsible for the execution of business processes described in the form of executable service compositions. Different service compositions can be de- ployed in an execution engine, and for each request of a particular composition, a private session must be maintained in order to individually and correctly parse input and output parameters.
In the same way that a Web Service Description (WSD) contains the abstract part for the general definitions of the web service and a concrete part for the binding information (see Section1.1), for each service composition SCn deployed in an execution engine, we have (a) an abstract composition template Tnconsisting of the workflow logic and (b) a set of binding information containing each deployed service operation STn.
The abstract template Tn contains invoke activities pointing to abstract web service definitions. While executing a services composition SCn, the execution engine uses the binding information STn to identify the actual concrete operation
to be invoked. Without a way to dynamically update the binding information, compositions are bound to use the same set of concrete operations, which results in great issues when such operations degrade their performance or present any fault. Thus, the binding information available for each deployed service compo- sition is usually the main concern of adaptation frameworks.
This general approach of changing the binding information STn for the service
composition SCn, however, is limited and presents some problems. First, it means that any change performed in the binding information STn will have impact in all
private sessions created for the service composition SCn. In other words, micro adaptations focussed in particular sessions are not possible, reducing the relia- bility of the business process in certain circumstances. Second, because changes in the template itself are not covered, this approach only supports replacing the binding information of one concrete operation with another.
This means that it is not possible to use a group of candidate operation as replacement of a single deployed operation, or use a single candidate operation as replacement for a group of deployed operations. The common adaptation approaches focus only on faults enclosed to a service composition context. In other words, faults observed for a private session are not shared across service composition in an attempt to prevent potential faults and failures. Moreover, because the usual approach is concerned with the reaction to internal faults, other events of interest for the adaptation process, such as the appearance of better services or new requirements, are not covered.
In order to solve these issues, instead of limiting adaptations to the binding information of service compositions triggered by internal faults, ProAdapt uses independent adaptable service composition execution instances that may be up-
dated not only by monitoring internal faults but any event of interest, including faults and changes in the execution context or requirements. In addition, sim- milarly to the work presented in [26], ProAdapt supports workflow evolution, accepting changes in the workflow for running instances. Differently from the proposal in [26], however, we are able to cope with exceptional or unplanned event that affects only a specific instance of a workflow, but our strategy is lim- ited to finding a set of service operations that are semantically equivalent to logic regions defined in the workflow.
Execution Engine Request SC r SC1 SC2 . . . SCn Deployed Service Compositions Reques t SCs Request SCr EI2r EI1r Exe cu ti o n In stan ce s EIms Requester 1 Requester 1 Requester 2 Requester 2 Requester m Requester m WS1 WS2 . . . WSk Web Services
Figure 3.2: Illustration of the Execution Engine accessing Execution Instances of Service Composition.
Figure3.2 illustrates the concept of independent execution instances used in ProAdapt. As show in the figure, for each request m of a deployed service compo- sition SCn, an execution instance EImn is created.Then, the execution engine can invoke web services according to what is defined inside the execution instances.
Unlike current execution engines that rely on a general templae and binding information for each service composition, as described above, each of our execu- tion instances EIn
m includes a copy of the composition template Tn the binding information STn. In this context, for reasons of performance and optimisation,
a STn is still maintained for Tn, but each execution instance EI
n
m contains its private template Tn
m and binding information STnm.
With this modification, adaptations enclosed to a particular instance are now possible, without losing support for general or parallel adaptation. For example, considering three execution instances (a) EIr
1, (b) EI2r, and (c) EI1sfor the service compositions SCrand SCs, changes in the local template for (a) T1r or its binding information Sr
T1 have no impact in the local templates for (b) T
r
2 and (c) T1s or the binding information Sr
T2 and S
s T1.
It is possible, however, to flood the need for adaptation across parallel exe- cution instances of the same or different service composition by accessing their particular template and binding information. Moreover, considering a set of de- ployed service compositions {SC1, SC2, ..., SCn}, future execution instances can benefit from previous processed information by changing the default templates Tx,1 ≤ x ≤ n or the default binding information STx,1 ≤ x ≤ n, which are both
used to create the execution instances.
Faults are recurrent events for service compositions, and as explained in Sec- tion 2.1, these faults may lead to dissatisfaction and can result in lost opportu- nities for business processes. Reacting to faults after they are observed incurs in obvious penalties, thus, preventing and avoiding faults is a very important feature for adaptable service-based systems. Perhaps the most important fea- ture of ProAdapt is indeed the ability to proactively identify potential fault points
in execution instances based on the monitored events and prevent such faults to occur. Moreover, even in the absence of faults, ProAdapt may decide to proac- tively optimise service composition. Resulting in faster, cheaper or more reliable processes.
ProAdapt currently supports the prediction of faults and failures caused by QoS deviation and unavailability of operations. Service composition execution instances must comply with predefined SLA parameters, such as maximum re- sponse time or cost for the whole composition. QoS deviations of deployed oper- ations, mainly in the form of delayed response time, can lead to nonconformance of the SLA.
In order to handle this issue, ProAdapt uses a QoS aggregation function that is able to predict the expected QoS parameter values for the whole execution instance and thus trigger adaptation when detected a possible SLA nonconformity and, therefore, trigger the need for adaptation when a possible SLA discrepancy (i.e., nonconformance) is detected. To prevent invoking unreachable operations (unavailable or broken network link), the framework supports the prediction of unreachable operations using failure spatial correlation[51].
In this work, the spatial correlation is considered as the strong availability correlation between operation, services and providers. In other words, if an op- eration is unavailable in one part of a service composition, it will most likely be unavailable for other parts of the composition that also use the same operation. Moreover, if the whole service or provider is unavailable, it would be wise to proactively replace all deployed operations offered by the unavailable service or provider to avoid the almost certain faults.
served QoS values of service operations, ProAdapt attempts to avoid executing changes in a composition in the situations in which QoS faults generated by one or more deployed operations can be compensated within the composition by other deployed service operations.
Example: when the observed response time of an operation is greater than its expected response time, the approach verifies the implication of this fault in the execution instance as a whole in order to assess the need for adaptation. This verification considers service level agreements (SLAs) specified for the whole com- position and QoS parameter values obtained from previously invoked operations as well as expect values for the yet to be invoked operation in order to identify if a QoS fault can be compensated or accommodated. ProAdapt is ultimately con- cerned with the correct execution of the composition under defined constraints. Internal faults can be overlooked if the service level agreement (SLA) defined for the composition remains satisfied.
The next section presents the ProAdapt architecture and describes its main components.