For providers of composite services, service level agreements (SLAs) provide a means to guarantee a certain service quality to prospective customers. Usually, violating SLAs is associated with costs. However, the means necessary to ensure SLA conformance also generate costs. Oftentimes, it is therefore optimal from a business perspective to violate certain SLAs sometimes, instead of trying for the high (and expensive) road of always satisfying each one. In this paper we will sketch a framework for the prediction of SLA violations and for determining whether an adaptation of the process makes sense economically. If this is the case adaptation actions are triggered, which adapt the composition on either on instance, structural or environmental level. The ultimate goal is to implement a closed-loop system, which self-optimizes the costs resulting from SLA violations.
Service-oriented architectures are at their core about the integration of systems. This new paradigm is used by Software-as-a-Service providers, which deliver basic IT functionality such as customer relations management or business intelligence as composite services. One important notion for the seamless integration of such outsourced IT services are agreements about the quality that these services need to provide (QoS), typically de ned within legally binding Service Level Agreements (SLAs). SLAs contain Service Level Objectives (SLOs), concrete numerical QoS objectives which the service needs to ful ll. If SLOs are violated, agreed upon consequences (usually taking the form of penalty payments) go into e ect. However, ful lling SLAs can also lead to costs for the service provider (e.g., because the composite service provider needs to use more expensive services itself, or because of the costs inherent to optimizing its service composition). It is therefore not trivial for the provider to decide to what extend the service's SLAs should be ful lled, or which SLAs should (temporarily) be violated for economical reasons. Even more, these decisions should optimally be automated, to allow for fast reactions to changes in the business environment.
In this overview paper we will present a high-level framework for
optimizing adaptations of service compositions with regards to SLA violations. We use
techniques from the area of machine learning [
The work described in this paper is currently ongoing. However, some
important fundamental work has already been published. In [
The remainder of the paper will be structured as follows. Section 2 contains the main contribution of the paper, a description of a system for cost-optimal adaptation of composite services. In Section 3 we give a brief overview over relevant related work. Finally, Section 4 will conclude the paper. 2
A high-level overview of our approach is depicted in Figure 1. The system
implements an optimization cycle in the Autonomic Computing [
Service Composition
Adaptation Actions
Database Adaptation Executor
4.
Execute
1.
Monitor Composition
Monitor SLA Database
Cost-Based Optimizer 3.
Plan
2.
Analyze Composition
Analyzer Metrics Database 3x + 4y - 2z Our approach is based on the following assumptions: (1) service providers have explicit SLA(s) with their customers, including concrete numerical target values for SLOs and penalty payments for SLA violations; these payments can be staged, i.e., more severe SLA violations can lead to more severe penalties, and (2) there is a database of possible adaptations available, including the costs of these adaptations; costs can be both one-time costs (such as a downtime) or continually (such as increased costs for using more expensive services). The implementation of this database of possible adaptation actions needs to be supported by strong tools, which allow for the generation of the most important actions in a semiautomated way. Costs of adaptation actions can be derived using simulation or analysis of historical data. In the following, we are assuming an autonomous system, however, in some situations the role of the optimizer or executor can also be adopted by a human.
Composition Monitor: The foundation of all work presented here is the ability
to gather accurate runtime data. This includes: (1) QoS metrics such as response
time or availability of the services used, (2) runtime payload data, such as
customer identi ers or ordered items, and (3) technical parameters of the execution
environment, such as the availability of the composition engine, or the CPU load
of the machine running the composition. The Composition Monitor component
is used to collect this monitoring data from various sources (e.g., an external
QoS monitor [
Composition Analyzer: The data collected by the Composition Monitor is then
used to generate prediction models for SLA violations. Prediction models are
used to estimate at runtime if a given running instance is going to violate one or
more of its SLAs. They are associated with checkpoints in the composition model,
at which the prediction is done. Simply put, a prediction model is a function
which uses all execution data which is already available at the checkpoint and, if
possible, estimations for all missing data, and produces a numerical estimation
for every target value in the provider's SLAs as output. In earlier work we have
used simple decision trees to implement such models [
Cost-Based Optimizer: The Cost-Based Optimizer can be seen as the core of the system. This component needs access to all SLAs, as well as a database of possible adaptation actions. The optimizer has to ful ll two important tasks in the system. Firstly, it uses the prediction models generated before to predict concrete QoS values for every running instance and compares the predicted values with the respective SLOs. If SLA violations would occur it checks the Adaptation Actions database for any possible action to prevent the violation, and applies them if it is cost-e cient to do so. This involves solving an optimization problem to decide which combination of actions both prevents most SLA violations and is cheapest to implement. Secondly, if more than a certain threshold of SLA violations (in a given time frame) have been monitored, the component tries to improve the composition itself, i.e., it tries to optimize the composition for every future instance. The main di erence is that on composition level more possible adaptation actions exist (mainly because adaptation on this level is less time-critical, so that adaptations which involve e.g., a system downtime are also feasible).
Adaptation Executor: The Adaptation Executor is responsible for applying the adaptation actions as planned by the Cost-Based Optimizer. Generally, we consider the classes of adaptation actions (action classes) depicted in Figure 2. As discussed before, adaptation can happen either on instance (level 1, i.e., adaptations which a ect only a single instance) or structural level (level 2, i.e., adaptations which a ect all future instances), and can consist of rebinding base services (R*, i.e., switching from one used service to another), restructuring the composition (S*, e.g., parallelizing some parts of the composition) or adapting the execution environment (E, e.g., upgrading the virtual machine running service composition). Generally, actions of type E always a ect all future instances, and are therefore only applicable on level 2. 1 http://msdn.microsoft.com/en-us/library/aa373083(VS.85).aspx Instance
Level Composition
Level
R1 instance-level rebinding
S1 instance-level structural change comrpeobsRinit2idoinn-glevel csotrmucptousrSaitl2iocnh-alenvgeel enecvxiheroacEnnutgmioeennt
Obviously, the concrete execution of adaptation actions depends greatly on
the action class. For applying adaptations of type R* we can use the means
provided by the execution environment (such as dynamic rebinding as discussed in
earlier work [
We will now brie y discuss some key related work. QoS monitoring of atomic
services is discussed in [
In this paper we have sketched the architecture of a closed-loop system, which autonomously optimizes service compositions with regard to SLA violations, taking into account the costs caused by the adaptation. Our next steps will be the implementation of an rst end-to-end system, which includes prototypes for all four main components of the system. Furthermore, we will de ne a preliminary model for capturing the costs of adaptation actions.