When dealing with Cloud Computing Services (CCSs) provisioning and usage, different degrees of complexity can be reached, depending on whether service composition is needed to satisfy users' requests. This scenario demands effective ways for modelling CCSs and corresponding Service Level Agreements (SLAs) in order to facilitate service composition, comparison and monitoring. However, current SLA specifications and tools are not well tailored to service composition. In this paper, starting from WSLA, a widely-known SLA description language, we present an extension aimed at modeling contracts and SLAs suitable to support contract owners during service composition and monitoring phases. The proposed WSLA extension is also supported by a tree-graph based tool that can help during SLA and contract composition phases.
Modern Information Technology (IT) environments heavily exploits services
according to a provide-and-consume paradigm, allowing users to perform a wide variety
of tasks. Service terms have to be rendered as contracts that should be effective and
flexible from a strategic point of view as well as workable from an operational
perspective. In this scenario, Service Level Agreements (SLAs) [
In this research, we present a descriptive template for contract and SLA composition that extends WSLA. WSLA is one the several formal specifications developed so far to model SLAs and their subject of application so far and it has been selected since it is XML-based and sufficiently general to cover different domain scenarios). Its proposed extension overcome its expressivity limitations for service and contract composition scenarios and allows us identifying accountability issues more efficiently in the Cloud scenario. We also propose a tool for easing the design and visualization phases in service contract composition, named Contract-Aware Service COmposer (CASCO), specifically tailored to IT contracts. We validated our model, in a SLA composition scenario, by using the tool to calculate five Key Performance Indicators (KPIs) typically adopted in the CCSs: availability, response time and Mean Time To Response (MTTR), Mean Time Between Failure (MTBF), Mean Time To Failure (MTTF).
The paper is organized as follows. Section 2 analyzes existing works on contract representation and SLA management, Section 3 and 4 present the CASCO tool, its design and implementation. Conclusions are presented in Section 5. 2 2.1
A SLA referring to a specific service should consider: a) description of agreeing parties, QoS and obligations; b) matching with required QoS; c) collected metrics (and when and by whom); d) penalties for failures or unmatched SLs; e) responses to nondeliveries; f) providers’ responsibilities; g) effects of technology re-alignments.
SLAs are enforced by management policies, thus ad-hoc frameworks are needed to
ensure that applications and services meet the required SLs at deployment, operation,
support and maintenance stages [
Despite their high-level of expressivity, those approaches are not so suitable for
machine processing and for theintegration with Web Services description languages (e.g.,
WSDL [
Modeling and monitoring aspects related to service chains and networks in many
business ecosystems are usually based on graph models: BPMN [
Therefore, a standardized model would enable to apply templates to every type of
contracts and SLAs, and to categorize contract terms in different services domains.
However, despite their usefulness, SLA standardization policies are still in their
infancy, thus providing IT professionals with just static or semi-structured information
rather than structured contents during the entire service lifecycle [
Contracts for CCSs often result from the composition of underpinning service
contracts, thus their specifications refer to those of composing contracts. Starting from
them, final providers need to automatically obtain the terms of the overall contract, after
defining composition rules. A service-based approach of this problem enables to derive
the final contract from service composition rules, and contract specifications from the
application of these rules on the parameters of each low-level contract and service.
Consequently, services from different providers can be used and composed [
A composed contract is obtained from the integration of other contracts, signed with
different providers [
In order to model this scenario, we introduce three levels of conceptual abstraction: 1) the Contracts Layer, which collects service-provisioning agreements; 2) the Services Layer, which gathers the composing services; 3) the Resources Layer, which contains IT infrastructure components. The links across levels represent dependencies between contracts and services and between services and resources respectively. The links across the same level represent resources topologically composed to deliver a certain service. Thus, different levels of internal visibility of its composing sub-services are possible for a given service, depending on which kind of details are available about them. For instance, sub-services can be described by using their external parameters only (e.g., availability, response time, MTTF, etc.) or by exposing their internal details, thus enabling more precise monitoring. We decided to consider the Services Layer and the Resources Layer as a unique layer at this stage of our research, in order to strictly focus on highlighting the issues arising in service and SLA aggregation. In this way, we just consider contracts in terms of basic composing elements, thus forwarding the subsequent step of service-to-resource mapping to further research developments.
The aspects described so far cannot be fully described by current SLA models and
frameworks, therefore we propose a WSLA extension that introduces SL management
aspects, according to [
SLA calculation and service monitoring.
The contract template described so far can be modeled as a directed tree graph (i.e.,
digraph) where nodes represents template components whilst oriented edges are the
available properties. Edges are labeled with corresponding cardinalities (i.e. how many
nodes having those properties can be repeated). This approach allows representing data
about a single contract, even if with a great level of detail. Therefore, composition
topologies and rules have been introduced as additional elements to WSLA, for
describing SLA and contract composition. Topologies offer an intuitive way of creating service
chains matching users’ requests. We adopted four compositional patterns: series (each
service starts once the previous one stops), parallel (services work simultaneously),
loop (several cycles are needed to complete a service), condition (service execution is
oriented by an initial choice) [
Fig. 1A depicts the contract template while Fig. 1B and 1C show the composition and rule model, respectively. Listing 1 enlists the formal definitions for all the entities mentioned so far, obtained through sets language.
Definitions ∶= / , / , 7 , ℎ ∈ 1, ∶= / , / , 7 , 3B , ℎ ∈ 0, , ∈ 0, ∶= 7 ,
ℎ ∈ 0, ∶= 7 , / , / , ℎ ∈ 0, ∶= 7 , ℎ ∈ 1, ∶= 7 , ℎ ∈ 1, ∶= 7 , / , / , / , ℎ ∈ 0, ∶= 7 , B , ℎ ∈ 1, , ∈ 1, ∶= 7 , ℎ ∈ 0, ∶= ℎ/ ∶= 7 , ℎ ∈ 1, ∶= , ℎ ∈ 0,1 ∶= 7 , ℎ ∈ 0,1 ∶= 7 , ℎ ∈ 1, ∶= 7 , ℎ ∈ 0, ∶= 7 , B , R , S , ℎ , , , ∈ 0,1 ∶ + + + = 1
Listing 1. Contract template (formal definition)
The main goal of CASCO is to test the model proposed in Section 3 and to help customers and providers in composing SLAs both in design and execution phases. During the design phase, composition can be simulated to verify the compliance with requested SLs, as well as to obtain the SLAs of composed services starting from elemental ones. During the execution phase, the system comes in handy since it offers an engine that is able to calculate the result of composite SLAs. The tool has been designed starting from identifying stakeholders for a generic service providing/consuming firm: both managers (general, technical and business, department, human resources, service and contract) and administration personnel have been considered. Different tasks have been identified during the subsequent goals elicitation. For instance, a service manager can use the tool to: 1) insert contracts signed with other companies to buy primary services; 2) access and visualize the service catalogue; 3) insert new primary services; 4) create a new service by composing services from the catalogue; 5) create new contracts to be signed with other companies or final users. The tool exploits a 3-layer architecture (Fig. 4) to clearly separate data management, business logic and user interface components. Moreover, the application complies with the widely adopted Model-View-Controller (MVC) pattern. In order to separate contract visualization issues from user-agent interaction during composition, the tool splits the front end (Presentation module) and the back end (Business Logic and Data Management module) by using XML files describing agreements, topologies and rules. The Presentation module manages user operations and parses input, in order to generate the XML files (Fig. 3). The Manager module is further divided into four subsections. The Parser allows extracting and manipulating data from XML files to store them in the graph database (DB). The Agreement Manager handles contracts and the operations that have to be performed on them. The SLA Compositor creates composed services, defines corresponding measurement metrics and stores output services into the DB. The SLA Control allows accessing services information and parameters for resources and services monitoring.
From an implementation point of view, the digraph model has been defined into a
NoSQL graph DBMS (Neo4j v.1.9.6/v.2.0.0 [
Given a specific topology, services are composed and SL specifications are calculated accordingly. To decide the acquisition of a service as part of a final one, a manager needs to know which constraints the final service undergoes. Indeed, this is necessary in order to evaluate the feasibility, the sustainability, the compatibility of the composite service against the requirements. SLA values are calculated with respect to metrics capable of measuring whether a service is compliant with the contract terms and whether the service can achieve the desired business objectives. If we consider a service composition scenario, in order to perform a suitable SLA composition, metrics must be the same and their measurement units must be commensurable and compatible (e.g., all measures have to be time-related or all measures must be percentages, etc.). We considered five metrics exhibiting a great relevance in cloud scenarios to demonstrate the feasibility of the proposed model by using our ad-hoc developed tool. The selected metrics are: Availability, Response Time, Mean Time To Failure (MTTF), Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR).
Fig. 3 introduces some relevant quantities used in calculating the adopted metrics. We refer to Service Downtime (TSD), as the time period during which a specific service is not available (i.e., it is the time span between the i-th occurrence of a service failure, td,i and the i-th occurrence of its reactivation, tu,i). Similarly, Service Uptime (TSU), is the time interval during which a specific service is working (i.e., the time range between the i-th occurrence of the service start, tu,i, and the i+1-th occurrence of its failure td,i+1). The period between two failures (Time Between Failures, TBF) is the sum of the time needed to have the service up again (Time To Repair, TTR) and the time elapsed before another failure occurs (Time To Failure, TTF), that is: TBF = TTR+TTF.
Availability: it describes how long a service SA is available within its temporal window of analysis. Being TAW the duration of this temporal window and TSD the service downtime period, the availability A is expressed as in (1):
U = VW − YZ /VW (1)
Response Time: it quantifies how long it takes to a service SA to answer client’s interrogation. If we have N interrogations from client, each with its own response time rtSA(t)i, the overall response time RT is the average of the distinct responses rt, as in (2): U =
7]^7 Y\ 7 /
MTTF: it measures the mean time between two consecutive failures for the same service SA. If we have N monitored events (i.e., service failures and restorations), tSAu,i indicates the time from which the service is up for the i-th time and tSAd,i+1 is the time at which the same service fails again, then MTTF (3) is:
U = (3)
MTTR: it measures the mean time needed to repair a specific service SA for N times. Let be tSAd,i the time from which the service is down and tSAu,i the time from which the same service is up again, MTTR is given by (4):
7]^d// Y\a,7b/ − Y\c,7 / U = 7]^d// Y\c,7 − Y\a,7 / (2) (4) U = U + U
MTBF: it measures the mean time occurred between two consecutive failures of the same service. It can be considered as the sum between (4) and (3), as depicted in (5): (5) 5.2
New services resulting from a process of composition [
Complex modeling approaches typically require a multi-year effort to be validated. Both design- and run-time validation activities against functional and non-functional requirements are required. During validation, specific aspects should be checked, such as the suitability of the model to describe properly a significant variety of SLAs, its amenability to be integrated within information systems, its capability to handle managed resources. Therefore, we started with an internal validation. A set of agreements having as metrics the ones described in Section 5.1 has been simulated. Then, the composition rules described in Section 5.2 have been loaded into the tool (within the corresponding XML file, see Section 4). Specific tests have been executed to both evaluate the template feasibility for modeling SLA aspects and the tool usability for IT managers and contract owners. Therefore, 20 Italian users, aging from 30 to 50 y.o. and belonging to technical and juridical areas, have been selected as testers. The candidates have been assigned with three tasks deemed as representative of a concrete deployment scenario for the application. Task 1) to retrieve a service purchased by a company. Task 2) to register an agreement and to compose a new output service. Task 3) to evaluate the application completeness and user-friendliness.
The users were required to fill a questionnaire in order to assess their mood against the proposed system and the features it exposes. A 10-point psychometric Likert scale has been used to measure users’ responses in evaluating each task, according to the easiness in retrieving information, navigational and message clarity, ranging from 1 (i.e., worst evaluation) to 10 (i.e., best evaluation). Table II enlists average scores (AS) for the features evaluated when performing a specific task and mean execution times (MET) for each task (means are computed across all users). At the end of the questionnaire, users’ comments were collected, thus observing their concerns was only about explanatory labels and the localization of the application (which actually is in English to better match references about service contracts and service composition) and do not refer to possible issues in contract and SLA modeling or missing modeling functions. 6
A model for managing SLA information when dealing with contracts and SLA
composition in service-based IT environments has been presented in this paper. An
extension of the widely known, XML-based WSLA framework [
In the near future, this research will be widened and improved by: 1) extending the template (SLAs for BPO contracts); 2) proposing an ontological formalization of the template; 3) adopting rule-based policies to perform real-time monitoring of composed services as in Complex Event Processing (CEP) scenarios.
The research has been partially supported by Engineering SpA and Essentia SpA.