DESARROLLO DE LA ACTIVIDAD Capacitación y taller de tinturado Mocoa:

In this section, we review the proposals which consider the evaluation of SLA to make decisions regarding service execution and, therefore, propose different strategies

to enforce service based on the analysis of the accomplishment of the SLA (including the cancelling of the SLA in case of its violation). These proposals address how op- timising the costs of resources planning or modelling complex scenarios to obtain an utility function to optimise the making decisions.

Hani et al. [86] review the different stages in SLA Management to (with related literature review) to conclude that renegotiation is better than cancelling SLA after SLO violation, so they propose different strategies for renegotiate SLA terms, based on theory’s game or Bayesian learning. At this regard, Czajkowski et al. [33] provide a protocol to manage SLAs for resources planning. They relate the resources assignment with the negotiation mechanisms.

Tokairin et al. [173] propose use QoS and context information to optimize service bandwidth. They describe a protocol for presence and image detection to recognize when young/old people come into some place. Tan et al. [169] propose a mechanism to take decisions over business process execution based on its monitoring (in the con- text of Business Process Intelligence). They propose different metrics around abstract metrics and at different process perspectives (Cost, time, ...). Bobroff et al. [17] analyze a specific cloud scenario to allocate virtual machines in servers following a proposed strategy to ensure that SLA is not violated.

Buyya et al. [22] propose an architecture to allocate jobs from users in a Cloud envi- ronment considering the user QoS requirements (in the form of SLA) and infrastructure services (Amazon EC2 in the scenario). Buyya et al. [21] complement it with an allo- cation strategy for VMs based on SLAs from different providers and requirements as multi-objetive function based on different metrics (price, performance..) and different providers (Amazon, Azure...). In a similar scenario, Y. Gao et al. [67] propose a model to save energy based on job predictions, SLAs (mainly response time requirements and possible violations), power costs, to manage resource in a data center environment. They introduce different mechanisms to avoid NP-hard planning cost.

Also in the cloud domain, Lorido-Botran et al. [110] make an analysis of different techniques to scale virtual machines based on different mechanisms. These techniques are basically based on action-reaction following different criteria, such as the SLA of Cloud services. And Garg et al. [72] propose a mechanism to distribute server load to maximize their use using SLAs documents from providers. The idea is preparing servers in advance without over provision. Linlin Wu et al. [195] propose an strat- egy to plan resources for new users in a SaaS environment. Their strategy considers two different SLA layers (SLA from user requirements/penalties and the SLA for re- source provision) and a profit model based on the cost to execute the plan. Kailasam et al. [92] propose how to optimally manage Cloud resources considering public and private clouds (or different data centers), execution times of tasks, and transfer time. They use some quality measures, included in an SLA to propose an scheduler to make decisions about the processing of tasks in the cloud platform queue. X. Li et al. [108] provide a mechanism to monitor trust over the performance of cloud computing ser- vices, guided by SLAs. They also provide in [109] an architecture to manage multime-

3.7. SUMMARY

dia personalized services based on QoS. They use an SLA broker who analyses cus- tomer requirements and provided QoS in SLAs (they use WS-Agreement) to choose the best platform and monitor it.

Emeakaroha et al. [58] propose an architecture to measure metrics and detect SLA violations in scenarios related to computing services. They define abstract metrics re- lated to performance metrics: CPU availability, RAM and Storage, and different target values. They map performance abstract measures that are guaranteed in the SLA, like Availability, to specific monitoring variables, like Server Downtime in order to mea- sure them without ambiguity. Similarly, Brandic et al. [19] propose a mapping based on WS-Agreement and XSLT. from abstract SLA metrics to the real taken measures.

Hedwiq et al. [88] propose a model for dynamic SLA management. They consider that the SLA is important for planning and providing resources based on the pricing and penalty model and it is required to adapt to the service using (the example are related to evolution of Wikipedia workload) so it is a kind of renegotiation of SLA as they propose to update SLO targets in runtime. They also relate this proposal to the changing pricing model in Amazon computing units.

Leitner et al. [104] propose monitoring SLAs in runtime to predict SLA violation in simple and composed services.

3.7

SUMMARY

In this chapter we have introduced the SLA structure according to WS-Agreement and iAgree, as extension to provide a more human-readable language. We also de- tailed the SLA phases in which SLAs may be during its lifecycle with the aim of de- scribing how these phases are considered in the agreement creation and their status proposed by WS-Agreement. We have provided the most common scenarios of the WS-Agreement protocol about SLA lifecycle. In turn, regarding the management of this lifecycle we have cited the most common operations to support it. Specifically, we have described the different states that agreements and guarantees may have during the WS-Agreement protocol. Such states ease the evaluation of agreements and guar- antees at monitoring in order to detect violations. However, domain-specific moni- toring techniques are not provided by WS-Agreement specification due to its domain- independent purpose. Such a domain-independence of the specification boosts the ap- pearance of a plethora of tools with a diverse support for the creation and monitoring of WS-Agreement documents. At the end of the chapter we have provided informa- tion about most important of these tooling support approaches. Furthermore, we have detailed an extensible framework, Governify, which provides an enriched-text editor for the creation of iAgree documents with edition templates and a dashboard to mon- itor external systems based on the performance measuring and the SLAs. Lastly, we provide an extensive review of works related to the automated analysis and evalua- tion of SLAs. As we discussed, SLA management has been extensively researched in

the computational domain. A diversity of languages and tools have been developed. However, in non-computational domains domains, SLA management is just beginning to be applied. The SLA management in other domains involve the increasing digitiza- tion of SLA documents together with the need to properly manage the information in the SLA to enforce business services.

O

UR

C

ONTRIBUTIONS

4

SLA M

ODEL FOR

BP

S

Everything I do and everything Pixar does is based on a simple rule: Quality is the best business plan, period. John Lasseter (1957–), 2009

4.1

INTRODUCTION

As we have introduced, non-computational services are process-oriented and the software that supports them is usually a process-aware information system (PAIS) such as ERPs, Service Desk Management Systems, CRMs, or business process management systems (BPMSs). However, unlike computational services, there is little work related to the extension of PAISs with SLA-aware capabilities to support non-computational services. A PAIS with SLA-aware capabilities, i.e. an SLA-aware PAIS, is a PAIS that uses explicit definitions of SLAs to enable or improve the automation of certain tasks related to both the SLAs and their fulfillment such as performance monitoring, human resource assignment or process configuration [179].

In this chapter, we formalise the SLAs for BP as a first step to enable such SLA- aware PAIS. To this end, after analysing the modelling requirements of such SLAs, four main aspects involved in their formalisation have been identified, namely: 1) the description of the business process provided by the service; 2) the SLOs guaranteed by the SLA; 3) the penalties and rewards that apply if the guarantees are not fulfilled; and 4) the definition of the metrics used in these guarantees. These SLAs are usually described in natural language so we provide a formalisation for aforementioned as- pects using computational SLAs and techniques used to model the service description together with the process performance indicators and goals. Furthermore, we validate our approach through the modelling of several real BP SLAs.

The contribution of this chapter regarding the scope of this dissertation is high- lighted in Figure §4.1.

ruled

by

supported by

Governify

Business Process

PAIS

Monitoring Adapt

Chapter 4 _{Chapter 5}

Business Process Natural

Language SLA Formalization

iAgree SLA Instance SLA Analysis Chapter 6 Instance SLA Instance SLA Monitoring

Figure 4.1: Contributions background

4.2

AN EXAMPLE SCENARIO

IT maintenance tasks are commonly outsourced agreeing to an SLA. We take as an example of these SLAs the definition of statements of technical requirements (STR) of a public company which belongs to the Andalusian Autonomous Government, from now on APC, acronym of Andalusian Public Company. Statements of technical re- quirements are described in natural language and include information about the ser- vices required as well as their SLA. The statement of technical requirements docu- ment of this example is defined for the Technical Field Support for the Deployment of the Corporative Telecommunication Network of the Andalusian Autonomous Gov- ernment. It is presented in a 72-page document written in natural language including the SLAs defined for five of the required services, namely: 1) field interventions; 2) incidents; 3) network maintenance; 4) installations and wiring; and 5) logistics. In par- ticular, we focus on the field interventions (FI) service. The term field intervention refer- ences to the fact of requiring the presence of a technician at any headquarter of the APC for different reasons: troubleshooting technical assistance, installations supervision or restructure. From a high-level perspective, the FI service is performed as follows: the APC requires an FI, which can have different levels of severity, from the contractor staff. Then, the contractor plans the FI and performs it at the infrastructure location. In some cases, the contractor must provide some required documentation and, if such documentation is considered incomplete or inadequate by the APC, it needs to be re- submitted by the contractor until it fulfills the APC’s quality requirements.