Translation of Service Level Agreements: A Generic Problem Definition

Abstract

A Service Level Agreement (SLA) is the electronic equivalent of a real-life contract, which describes expectations from a service and governs its consumption. Ideally, a SLA provides certainty as regards customer experience and Quality of Service (QoS) received. For selfcontained, isolated services this type of certainty is relatively straightforward to achieve. However, for services that are composed by others, or that rely on others to execute, such functional dependencies imply similar non-functional ones. Therefore, SLAs offered by a service to its customers are in turn depending on other SLAs, which the same service establishes in its role as a customer of the services it relies upon. In this paper we explore this dependency between different SLAs, and formalize the problem of converting an agreement for a composed service into individual agreements for the services from which it is composed.

Business Driven BCM SLA Translation for Service Oriented Systems

“…S 1 depends on either S 2 or S 3 . The dependency between S 3 and S 4 is a dependency with recovery time of Δr = e (5,7,10). e(a, m, b) denotes a three point estimate.…”

“…These SLAs need to be translated to depending services as well. The relationship among services can be described using a service dependency graph [7,10]. Starting from the top-level services, which are directly consumed by business functions, the Business Continuity Expert needs to translate the MTO objective down to lower-level services in the dependency graph.…”

An Integrated Approach for Specifying and Enforcing SLAs for Cloud Services

“…With regard to SLA translation, in [17], Kotsokalis and Winkler model the translation of SLA based to service dependency properties. In [5], Chen et al translate response time metrics to CPU requirements.…”

FIT for SOA? Introducing the F.I.T.-Metric to Optimize the Availability of Service Oriented Architectures

“…Metrics to measure granularity, complexity and reuse [15,35,36], performance [5,13] and QoS [28,31] of SOAbased services also rely on design-time data. Most work on operation and optimization has been done on how to handle service level agreements primarily based on design-time data: how to formally describe them [19,34,39,40], technically implement, test and enforce them [4,10,15,17,18,23,25,26,32,33,42,44,45] or how to monitor them [2,20,21]. Contributions available on SLA design deal with isolated approaches: Sauvé et al [38] and Marques et al [27] are in favor of deriving the service level targets directly from the business impact of the given service (i.e.…”