Thisisthepre-peerreviewedversionofthefollowingarticle:SLAsforcloudapplications:AgreementprotocolandREST-basedimplementationbyA.DeBenedictis,M.Rak,U.Villano,whichhasbeenpublishedinfinalforminInInternationalJournalofGridandUtilityComputingandisavailableathttp://www.inderscience.com/filter.php?aid=85910DOI:10.1504/IJGUC.2017.085910

SLAs for Cloud Applications: Agreement Protocol and REST-based Implementation

Abstract—Users with critical data are still reluctant to moveapps and data to commercial clouds, showing a substantiallack of trust in providers. Possible risks linked to availability,performance and security can be mitigated by the adoptionof Service Level Agreements (SLAs) established among cloudservice providers and their customers. User communities arepressing for the adoption of SLAs in cloud environments, andstandardization bodies are working to identify a set of conceptsthat could be used to compare alternative offers.

This paper presents the design of services for the man-agement of cloud-oriented SLAs by means of a REST-basedAPI. Such services can be easily integrated into existingcloud applications, platforms and infrastructures, in order tosupport SLA-based cloud services delivery. After a discussionon the SLA life-cycle, an agreement protocol state diagramis introduced. It takes explicitly into account negotiation,remediation and renegotiation issues, is compliant with all theactive standards on security, and is compatible with the WS-Agreement standard.

The requirement analysis and the design of a solutionable to support the proposed SLA protocol is presented,introducing the REST API used. This API has been adoptedfor the implementation of an SLA Manager that can beeasily integrated in cloud applications. However, it can be alsoadopted in different environments, as it is flexible with respectto the SLA machine-readable representation and compliantwith all existing standards.

Keywords-Cloud, SLA, WS-Agreement, REST, API, SLAmanagement

I. INTRODUCTION

In the last decade, cloud computing has become a main-stream solution for the provision of infrastructure, platformand software services. The possibility to resort to a reserveof apparently infinite low-cost compute resources in an on-demand fashion has attracted individual users, industriesand institutions, letting them free to focus their efforts onsoftware development. However, users with critical data(e.g., financial, medical and sensitive data) are still reluctantto move apps and data to commercial clouds, showing asubstantial lack of trust in providers, as regards availability,performance and security issues.

As the cloud paradigm is founded on the provision of ev-ery resource (from hardware appliances to applications) as-a-service, the capability of negotiating even non-functionalproperties (level of Quality of Service, QoS) with serviceproviders, to be activated on-demand as any other service, isdesirable. This is enabled by the adoption of Service LevelAgreements (SLAs), which serve as a means of formally

documenting delivered services and related performance(and QoS) expectations, in addition to explicitly takinginto account responsibilities, obligations, service pricingand penalties in case of agreement violations [1], [2]. Asdiscussed in [3], in order to be effective, cloud SLAs shouldinclude parameters such as availability, security/privacy,disaster recovery expectations, data location, data access andportability, and several other concepts related to the manage-ment of possible issues arising during service provisioning.

Even if it is clear that the adoption of SLAs would bringbenefits to both involved parties (i.e., the service customerand provider), their use by existing cloud providers is stilllimited. As a matter of fact, the definition of SLA standardsis an active field of research [4], [5], but concrete results areavailable only for SLA representation (e.g., WSAgreement[6], WSLA [7]), and for what concerns the development oftools/environments for their management (e.g., SLA@SOI[8], WSAG4J [9]).

The Authors of this paper are involved in a FP7-ICTprogramme project (SPECS1), which addresses cloud secu-rity through SLAs. The SPECS project intends to improvethe state-of-the-art in cloud computing security by creating,promoting and exploiting a user-centric framework and aplatform dedicated to offer Security-as-a-Service using aSLA-based approach, in particular with respect to negoti-ation, continuous monitoring and enforcement [10], [11].

One of the key points of the SPECS project is theprovision of a solution for the management of the whole life-cycle of SLA contracts. The design that will be presentedin this paper, along with its prototype implementation, has aslightly wider scope, as it stands as a management solutionfor any type of cloud SLA, not necessarily those linked tosecurity, which are the main object of the SPECS project. Inparticular, our proposal is the design and implementation ofa web service for the management of cloud SLAs througha REST-based API.

The WS-Agreement Specification by the Open Grid Fo-rum (from here onwards, WSAG) [6] defines a languageto specify SLAs, and a protocol for their creation based ontemplates for the final agreement. As a first contribution, weextended the WSAG Specification by enriching the proposedstate diagram for the representation of the SLA life-cycle.As thoroughly illustrated in the following, our state diagramtakes explicitly into account phases as Negotiation and SLAImplementation, as well as actions as remediation and re-

1http://www.specs-project.eu

negotiation, which are neglected in WSAG.Moreover, as mentioned before, we proposed a REST-

based API for the management of SLAs according to thismore detailed life-cycle. Currently, most implementationsof WSAG rely on the canonical SOA approach based onSOAP web services, the so-called WS-*. Examples of theseimplementations can be found in several EU projects, as forexample IRMOS2, BREIN [12], Contrail3, and mOSAIC4.However, the use of RESTful architectures is rapidly dif-fusing, promising higher performance and better scalability[13], and a RESTful implementation of the WSAG Specifi-cation has been already presented in [14]. Nevertheless, ourproposal is substantially different from existing work, as itis focused primarily on cloud environments, and implementsan expanded SLA state diagram reflecting the state-of-the-artof SLA standards.

This paper will go on as follows. In the next section, wepresent related work. Then the SLA life-cycle is considered,presenting an extended SLA state diagram. The requirementsof an API for SLA management are discussed in SectionIV. The complete description of our REST API is presentedin Section V. An example of use of the API is shown inSectionVI. The prototype implementation of the API, devel-oped in the context of the the SPECS project, is discussedin Section VII. The paper closes with our conclusions andplans for future research.

II. RELATED WORK

The definition of Service Level Agreement is an activetopic for standardization bodies, because they are at theinterface between cloud user needs and the services andfeatures that cloud service providers (CSPs) are able tooffer. At the state of the art, there are several differentproposals coming out from different institutions. The Eu-ropean Commission has set up a dedicated Working Group(CSIG-SLA) to address the SLA problem, in the contextof the EC directive on Unleashing the Cloud Computing[15] and related activities. The first result obtained by thisgroup is a guideline for standardization bodies that outlineshow standards related to SLA should be organized, offeringexamples of the key concepts to be considered [5].

A more advanced state of SLA standardization is of-fered by ISO 19086 [4], which proposes a standard forthe adoption of SLAs in clouds. The above cited standardintroduces the main concepts related to SLAs, and examplesof guarantees that can be offered. However, their descriptionis very general and leads more to SLAs written in naturallanguage than to automated SLA systems based on machine-readable formats.

WS-Agreement [6], born in the context of grid computing(which relies on a stable middleware, and on a well-defined

2http://www.irmosproject.eu3http://www.contrail-project.eu4http://www.mosaic-cloud.eu

way of using services and representing resources), is theonly standard supporting a formal representation of SLAsand a protocol that aims at their automation. The main limitof such solution is that it was devised in a grid-orientedtechnological context, and that it is not completely fit inother contexts, such as clouds.

The majority of the cloud-oriented FP7 projects (Con-trail5, mOSAIC6, Optimis7, Paasage8) are inclined to adoptWS-Agreement representations, suitably adapted to thecloud context. In one case (see the paper [14] mentionedin the introduction), the implementation approach followedis similar to the one proposed in this paper, in that a RESTAPI is developed to support the WS-Agreement protocol,even if using the “traditional” WSAG state diagram andwith no particular support for clouds. The pros and consof the adoption of a REST architecture [13] are discussedin [16] and [17]. The extension of WS-Agreement to supportrenegotiation is instead discussed in [18].

In service-oriented and cloud environments, several pro-posals addressing the negotiation and monitoring of SLAshave appeared [19], [20]. A survey focusing on the renego-tiation of SLA in clouds is provided in [21]. The problemof the provision of quality of service and SLA facilities ontop of unreliable, intermittent cloud providers is discussed in[22]. Recent proposals in the context of the mOSAIC projecttackle the problem of offering user-oriented SLA services tocloud users [23], [24].

However, to the best of our knowledge, none of the maincommercial IaaS providers (Amazon, Rackspace, GoGRID,...) currently offers negotiable SLAs. What they usuallypropose is an SLA contract that specifies simple grantson uptime percentage or network availability. Moreover,most of the providers offer additional services (for example,Amazon CloudWatch), which monitor the state of targetresources (i.e., CPU utilization and bandwidth). Open CloudEngine software like Eucalyptus, Nimbus and OpenNebula,also implement monitoring services for the private cloudprovider, but do not provide solutions for SLA negotiationand enforcement. A survey of the SLAs offered by commer-cial cloud providers can be found in [25] and [26].

III. THE SLA LIFE-CYCLE

According to current standards on cloud SLAs (WS-Agreement [6], ISO19086 [4], . . . ), the SLA life-cycle ischaracterized by five phases (Figure 1), Negotiation, Imple-mentation, Monitoring, Remediation and Renegotiation.

During the Negotiation phase, a cloud service customerand a cloud service provider carry out a (possibly) iterativeprocess aimed at finding an agreement that defines theirrelationship with respect to the delivery of a service. The

5http://www.contrail-project.eu6http://www.mosaic-cloud.eu7http://www.optimis-project.eu8http://www.paasage.eu

Figure 2. Refined SLA life-cycle

Figure 1. The SLA life-cycle

agreement may specify both functional properties related tothe identification of the service, and non-functional proper-ties such as performance or security. Negotiation typicallyends with the formal acceptance of an SLA (hereafterreferred to as “signature”) by both parties, and it is followedby the implementation phase. During the Implementation,the CSP provisions and operates the cloud service, but alsosets up and provides the customer with the processes neededfor the management and monitoring of the cloud service, thereport of possible failures and the claim of remedies.

After the implementation of an SLA, the Monitoringphase takes place, in which the cloud services covered bythe SLA are monitored in order to enable both the cloudservice provider and the cloud service customer to verify therespect of the SLA constraints. If any SLA violation occurs,i.e., if one of the agreed terms of the SLA is not respected,the cloud service customer may be entitled to a remedy(Remediation phase). Remedies can take different forms,such as refunds on charges, free services or other formsof compensation. Other forms of remedies may requirethat the customer is timely notified and that the cloudservice provider reacts to the service failure within a certain

time frame. Finally, a remedy may be represented by anyeffort to alleviate the harm caused by the failure and mayresult in applying corrections to the system in order toavoid future violations. Finally, during the Monitoring and/orRemediation phases, either the cloud service customer orthe cloud service provider may require a change in the SLA(e.g., if a service provider permits variable terms). This maylead to a Re-negotiation phase, changing the original SLAterms. In this case, up to the signature of the new SLA, theoriginal one is still valid, but once the new SLA is signed,it must be implemented in the place of the previous one.

In Figure 2, we show an SLA state diagram that takes intoaccount the above presented phases and enriches them. Inparticular, it introduces explicitly the concepts of SLA alertand proactive reaction to prevent violations, and so enablesa full audit over the SLA evolution for the benefit of bothservice customers and providers.

The UML state machine in Figure 2 outlines aspectsrelated to possible violations, pro-active reactions and re-negotiations of the SLAs that are supported by state-of-the-art standards. It should be pointed out that the proposeddiagram is compliant with the one proposed in the WS-Agreement specification, while introducing some improve-ments. Compared to our diagram, the WSAG “original”diagram (Figure 3) hides the scheduling of the negotiationprocess and the negotiation itself in the pending state (i.e.,an SLA is pending during all the negotiation process),while we explicitly differentiate between these two statesby introducing the negotiating state. Such state is reachedwhen the actual negotiation process is started, and impliesthe creation of an SLA object, to which an unique ID is

assigned. Moreover, the pending state in the WSAG diagramcompletely hides the Implementation phase, while we makean explicit reference to the achievement of the agreement,which is ratified through the signing of the SLA and triggersthe SLA implementation (signed state). Once signed, andafter that the Implementation has taken place, the SLA entersthe observed state, corresponding to the Monitoring phase.

In the diagram proposed in Figure 2, we separatelyrepresent the management of SLA alerts and violations;alerts represent risky situations that may lead to the violationof some terms included in the SLA. Indeed, during theMonitoring phase, the cloud service provider may check fordeviations from the desired behavior that do not directlycause the violation of an SLA, but that may likely induce itin the near future, if not properly handled. In such situations,the SLA is set in the alerted state, where a diagnosis activityis performed to determine the root cause of the alert andproper countermeasures are identified (e.g., a reconfigurationof the service being delivered), which are later on enforcedwhile the SLA is in the proactive redressing state.

Once the countermeasures have been applied and the alertis no longer active in the system, the SLA returns to theobserved state. If instead a violation occurs, and is detectedwhile in the observed state or even in the alerted state,suitable remedies are applied in the remediating state, asdiscussed earlier in this section.

During the Monitoring and/or Remediation phases, eitherthe customer or the provider may require a change in theSLA. In order to represent this situation, we devised atransition from the reaction macro-state (including both theproactive redressing and remediating states) and from theobserved state, towards the re-negotiating state.

Finally, an SLA may enter the terminating state if (i) anexplicit termination request has been issued by either parties,(ii) an agreement has not been found in the negotiation orre-negotiation phases, (iii) a detected SLA violation impliesthe termination of the SLA.

Figure 3. WS-Agreement State Diagram [6]

IV. REQUIREMENT ANALYSIS OF THE API FOR SLAMANAGEMENT

In this section we discuss briefly the functional require-ments that must be satisfied to enable the management of theSLA life-cycle illustrated in Section III. The solution we aimat designing must allow for the management of SLAs fromtheir negotiation (or re-negotiation) to their termination, bysupporting their implementation and by handling possiblealerts/violations that may arise during their monitoring.

The main design requirement is that all information re-lated to SLAs and their state has to be stored in an SLArepository, and that specific services should be available toquery and to update the contents of such repository. In thepresence of an alert or violation, the API should allow toupdate the state of the involved SLAs.

An overview of the requirements that drove the design ofour REST API is illustrated in the UC diagram in Figure 4,where the Actor represents a generic API user.

Figure 4. Requirements for the management of SLAs

As shown in the figure, the API should provide function-alities for:

• Creating new SLAs. An SLA must be created andassociated with a customer when the negotiation pro-cess starts. The SLA may be built based on a template,provided by the CSP and including the set of negotiablefeatures for each available service. Therefore, if needed,the API should provide support for the management oftemplates.

• Deleting SLAs. If errors occur during the negotiationprocess, an SLA that has not yet been signed shouldbe deleted.

• Updating existing SLAs. When an SLA is in thenegotiating or re-negotiating state, it must be possibieto update its content to reflect ongoing changes. Atthe end of the negotiation process, the SLA must beupdated with the content of the SLA Offer selected bythe customer.

• Accessing and retrieving stored SLAs. Accessingand retrieving stored SLAs must be allowed during allphases of the SLA life-cycle.

• Accessing and updating the state of a stored SLA. Itmust be possible to update the state of an SLA duringthe different phases according to the state diagramreported in Section III.

• Adding and updating annotations to a stored SLA.In order to enable an easy processing of SLAs, itmust be possible to annotate them with additionalinformation.

• Storing and retrieving information on alerts/vio-lations associated to an SLA. The API may offerfunctionalities for archiving and retrieving informationabout occurred alerts and violations for further pro-cessing, if no specific component is designed for thispurpose.

V. A REST API FOR SLA MANAGEMENT

In this section, we present the complete API designedto meet the requirements discussed in Section IV for themanagement of the SLA life-cycle, named SLA API. It canbe easily integrated into existing cloud applications in orderto drive service delivery on the basis of the SLAs agreedwith service customers.

In his “Maturity Model” [27], Richardson classifies theAPIs for services on the web (i.e., for software services builton top of the HTTP protocol) in three incremental maturitylevels, according to the support offered for URIs (L1), forHTTP methods (L2), and for hypermedia (L3). Below theselevels (i.e., at L0), none of the them is supported. Accordingto the Maturity Model, RESTful APIs [28] require level L3as a prerequisite [29]. At the state of the art, only few APIsrespect such requirement; the majority of the commonlyused ones is at L2. Our API sits at L2, since our designaddresses both the use of URIs (to identify the resources)and the full semantic of HTTP methods (to operate on them).We plan to introduce the hypermedia support in the next APIrelease.

In the next subsections, we first present the REST Re-sources our API accesses and manages, and then the oper-ations that it allows to perform on such resources.

A. SLA API: REST ResourcesThe SLA API manages the following types of resources:• SLA: it identifies a WSAG Offer-compliant XML doc-

ument, provided with a unique ID and referring to aspecific End-user.

• SLA template: it identifies a WSAG Template-compliant XML document used as a guideline fornegotiation. Templates are built by the service provider,refer to specific types of services (e.g., web server,storage, etc.) and include all parameters that can benegotiated related to such services.

• SLA state: it identifies one of the possible states of anSLA (according to the life-cycle illustrated in SectionIII).

• Alert: it identifies an alert occurred in the systemrelated to an SLA.

• Violation: it identifies a violation occurred in thesystem related to an SLA.

• Annotation: it identifies an annotation occurred in thesystem related to an SLA.

Our implementation supports different mediatypes forthe representation of resources. In particular, we provideboth the XML (application/xml mediatype) and theJSON (application/json mediatype) format for allresources, except for the SLA resource that is naturallyrepresented in XML. The client can negotiate the preferredformat via HTTP headers. Collections of resources aremanaged by means of a generic envelope for XML and anarray of elements for JSON. Inside the envelope/array, eachitem of the collection is represented by its URL. We definedsuitable data models for the representation of resources inthe supported formats as part of the API documentation. InListing 1 we report, as an example, the data model proposedfor the representation of the SLA state resource, available at[30]. The reader is referred to the WSAG specification forthe data model of the SLA resource.

Listing 1. SLA state data model

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >

<xs:element name="SLAstate" type="SLAstateType"/><xs:complexType name="SLAstateType"><xs:sequence><xs:element name="sla-id" type="xs:string"

minOccurs="1" maxOccurs="1" /><xs:element name="state" type="stateType"

minOccurs="1" maxOccurs="1" /></xs:sequence></xs:complexType><xs:simpleType name="stateType" ><xs:restriction base="xs:string"><xs:enumeration value="negotiating"/><xs:enumeration value="signed"/><xs:enumeration value="observed"/><xs:enumeration value="re-negotiating"/><xs:enumeration value="terminating"/><xs:enumeration value="terminated"/><xs:enumeration value="complete"/><xs:enumeration value="alerted"/><xs:enumeration value="violated"/><xs:enumeration value="remediating"/><xs:enumeration value="proactive-redressing"/></xs:restriction></xs:simpleType>

</xs:schema>

B. SLA API: REST URIs and calls

According to the REST specification, each REST re-source is identified by a URI composed of a base-path

and a resource identifier. A resource identifier may con-tain variable parameters, reported in the documentation asstrings surrounded by curly braces. REST API calls arespecified through related HTTP methods (PUT, GET, POST,DELETE), which perform the traditional CRUD (Create,Read, Update, Delete) operations on resources.

The SLA API uses the cloud-sla base path andmanipulates the resources described in Section V-A. In thefollowing, we provide an overview of the supported APIcalls. The interested reader is referred to the complete APIdocumentation, available at [31], for syntax issues and fora detailed description of data models and response codesemantics.

The main resources accessed and managed by our API areSLAs. The following calls allow to retrieve available SLAs,and to add new elements to the collection of SLAs:

• /cloud-sla/slas– GET: it returns the available collection of SLAs.

The result can be restricted (to perform a searchoperation) by using a suitable query string thatspecifies the number or interval of elements toretrieve.

– POST: this call adds a new SLA Offer to thecollection of SLAs, and returns the URI of thecreated resource. The POST entity body has tocontain a valid SLA Offer in XML format. Thenew SLA is created in the pending state. If noerrors occur the offer is scheduled for negotiation,and the state evolves to negotiating.

In the following, we list the calls that have been designedto manage specific SLAs (identified by the sla-id vari-able), their current state and related annotations.

• /cloud-sla/slas/{sla-id}– GET: it retrieves the SLA identified by thesla-id variable. The SLA can be retrieved onlyusing the application/xml mediatype.

– PUT: it modifies the SLA content identified by thesla-id variable. This call is allowed only whilein the negotiating or re-negotiating states.

– DELETE: this call deletes the SLA identified bythe sla-id parameter if it has not been signedyet.

• /cloud-sla/slas/{sla-id}/state– GET: it retrieves the current state of the SLA

identified by the sla-id variable.– PUT: it updates the state of the SLA identified by

the sla-id variable according to the transitionspecified in the request body (initial and final stateare specified in a proper format). It should ne notedthat the only allowed transitions are those definedby the SLA state diagram of Figure 2.

• /cloud-sla/slas/{sla-id}/annotations

– GET: it retrieves the collection of theAnnotations for the SLA identified bythe sla-id variable.

– POST: it allows to create a new Annotation.The POST entity body has to contain a validAnnotation, represented either in XML orJSON format.

• /cloud-sla/slas/{sla-id}/annotations/{annotation-id}– GET: it retrieves the SLA Annotation identi-

fied by the annotation-id parameter for theSLA identified by the sla-id identifier.

As mentioned in Section IV, for completeness’ sake ourSLA API includes also functionalities for managing theinformation related to SLA alerts and violations. In fact , thisinformation is meant to be processed by specific dedicatedcomponents for diagnosis and reaction purposes, and itsmanagement may be performed by custom components aswell. Nevertheless, in the following, we illustrate the basicAPI calls for storing and retrieving alerts and violationsassociated with an SLA.

• /cloud-sla/slas/{sla-id}/alerts– GET: it retrieves the collection of the alerts

associated to the SLA identified by the sla-idvariable.

– POST: it allows to signal that an alert occurred.The method, if called in the observed state, sets theSLA’s state to alerted, creates an alert resourceassociated to the SLA and returns the URI of thecreated resource. The POST entity body has tocontain a valid alert, represented either in XMLor in JSON format.

• /cloud-sla/slas/{sla-id}/alerts/{alert-id}– GET: it retrieves the SLA alert identified by

the alert-id parameter for the SLA identifiedby the sla-id identifier.

• /cloud-sla/slas/{sla-id}/violations– GET: it retrieves the collection of theviolations associated to the SLA identifiedby the sla-id variable.

– POST: it allows to signal that a violationoccurred. The method, if called in the observed orin the alerted state, sets the SLA’s state to violated,creates a violation resource associated to theSLA and returns the URI of the created resource.The POST entity body has to contain a validviolation, represented either in XML or inJSON format.

• /cloud-sla/slas/{sla-id}/violations/{violation-id}– GET: it retrieves the SLA violation identified

by the violation-id parameter for the SLAidentified by the sla-id identifier.

Finally, in order to support the template-based SLA nego-tiation in compliance with the WS-Agreement specification,

the API includes the following calls that make it possible tomanage SLA template resources.

• /cloud-sla/templates– GET: it retrieves the collection of defined SLA

templates.– POST: it allows to create a new template and

returns the URL of the created resource. The POSTentity body has to contain a valid template inXML format.

• /cloud-sla/templates/{template-id}– GET: it retrieves the SLA template identified

by the template-id variable.Concurrency issues are addressed using the appropriate

HTTP headers: the server responds to GET requests withthe “Last-Modified” header, while the client has to performPUT operations adding the “If-Modified-Since” header.

VI. AN EXAMPLE OF SLA REST API USAGE

In this section, we illustrate the usage of the SLA RESTAPI for the management of the complete life-cycle of anSLA related to a generic cloud service. In order to discussa concrete architecture, we refer to the SPECS framework,whose architecture is sketched in Figure 5 and presentedin detail in [10], [11]. The SPECS framework is composedof three Core modules, devoted respectively to Negotiation,Enforcement and Monitoring. Core services run on top ofthe SPECS Platform, which includes the SLA Platform,responsible for the management of the SLA life-cycle, andthe Enabling Platform, in charge of the deployment andexecution of needed components on cloud resources. Coreservices inter-operate through the SLA Platform services andare orchestrated by a SPECS application. The applicationhelps the SPECS customers negotiate desired services andacts as a gateway between customers and external serviceproviders, whose offered services are enhanced with guar-antees stated in formal SLAs.

Figure 5. SPECS high-level architecture

The API presented in this paper is offered by the SLAManager component of the SLA Platform and is invoked bythe Core modules during the main SLA life-cycle phases.Figure 6 shows the sequence of invocations during thenegotiation phase. It should be noted that we hide theexistence of a Negotiation module in the SPECS Applicationand Core Modules UML life line, as an extensive discussionof the framework behavior is out of the scope of thispaper. As shown in the figure, when the End-user startsthe negotiation, the available templates are retrieved and areused for building possible service offers to display to theEnd-user. The End-user selects the service (i.e., the template)he/she is interested in (e.g., the template built for a webserver service), and a new SLA is created in the pendingstate based on the selected template. If no errors occur, whenthe End-user submits his/her requirements the SLA state isupdated to negotiating, and an SLA Offer is prepared basedon what can be actually offered with respect to End-userrequests. This negotiation process is iterative, and hopefullyterminates with the formal acceptance of an SLA offer bythe End-user, resulting in a further change of the SLA stateto signed. At this point, the SLA is implemented.

Figure 6. Negotiation phase

Figure 7 illustrates the sequence of invocations in thephases of enforcement and monitoring. As shown, the signedSLA is implemented and suitable monitoring systems areconfigured and activated, letting the SLA state be updatedto observed. If an abnormal condition is detected by themonitoring system, a monitoring event is generated andprocessed by the SPECS framework. In case a violationis detected, the state of the SLA is updated to violatedand proper remedies are applied (e.g., computation andapplication of penalties). If it is not possible to recover fromthe violation, the SLA is terminated and the End-user isnotified.

Figure 7. Enforcement and monitoring phase

VII. SLA API IMPLEMENTATION

As mentioned in the previous section, the SLA API isoffered by the SLA Manager, developed in the frameworkof the SPECS project. As the code produced is publiclyavailable and lends itself to be used in different contexts, theSPECS implementation of the API will be briefly describedin the following.

The SPECS implementation of the SLA Manager is rep-resented by a web application made of two components: thefirst one represents the back-end that handles the persistenceof all data, while the second one is the front-end that exposesa REST API. Figure 8 shows the software organization ofthe component, including (i) the SLA Manager API, whichoffers the SLA APIs described in Section V, and (ii) theSLA Manager component, implementing the SLAManagerinterface used by the SLA Manager API component.

Figure 8. SLA Manager Component Diagram

The SLA Manager web application is described throughtwo different class diagrams. The first diagram (Figure 9)represents all the packages and classes that compose theSLA Manager component, while the second one (Figure 10)represents the packages and the classes of the SLA ManagerAPI component.

The development of the web services exposed by theREST API interface has been performed using the JerseyRESTful Web Services framework. All the REST resourcesare mapped under the path “/cloud-sla/*”. This is explicatedin the web.xml file under the WEB-INF folder, file that isread at the start-up of the web application.

Figure 9. SLA Manager Class Diagram

Figure 10. SLA Manager API Class Diagram

<servlet-mapping><servlet-name>Jersey REST Service</servlet-name><url-pattern>/cloud-sla/*</url-pattern>

</servlet-mapping>

Moreover, all the REST resources are representedby specific Java classes under the package“eu.specsproject.slaplatform.slamanager.restfrontend”.This is also explicated in the web.xml file.<init-param>

<param-name>jersey.config.server.provider.packages</param-name>

<param-value>eu.specsproject.slaplatform.slamanager.restfrontend</param-value>

</init-param>

The Figures 9 and 10 show an example of use of the callsused to retrieve an SLA collection, and to obtain a particularSLA from it.

The implementation of the SLA API is publicly availableat [31]9.

9As previously mentioned, this work is part of the activities carried outin the SPECS project, and the API has been developed by the SPECSConsortium.

Figure 11. Get all SLA

Figure 12. Get SLA by ID

VIII. CONCLUSIONS AND FUTURE WORK

In this paper we have proposed a solution for SLAmanagement in clouds that relies upon a suitably definedSLA life-cycle supported by a REST API. The proposedSLA life-cycle is based on current standards on cloud SLAsand is compliant with the WS-Agreement specification, butintroduces some important enhancements. These are relatedto the management of SLA alert and proactive reaction toprevent violations, and enable a full audit on SLA evolutionfor the benefit of both service customers and providers.

The implementation we offer for the proposed REST API(SLA manager), able to support the proposed SLA life-cycle,is publicly available and can be easily integrated into existingapplications to enable the construction of software solutionsfor orchestrating services based on SLAs.

The solution presented can be a basic building block of aframework for SLA-based service management, being com-pliant with current and evolving standardization outcomesin this field. In the near future, we plan to integrate ourimplementation of the proposed REST API with a simplebroker, in order to build up an SLA-based brokering service.Moreover, we are also about to integrate our SLA managerwith monitoring and enforcement solutions able to enrichthe offered services according to the user requirements,expressed at the time of SLA negotiation.

REFERENCES

[1] Cloud Standard Customer Council - CSCC, “The CSCCpractical guide to cloud service level agreements,” April 2012.

[2] T. Trappler, “If it’s in the cloud, get iton paper: Cloud computing contract issues,”http://www.educause.edu/ero/article/if-its-cloud-get-it-paper-cloud-computing-contract-issues, June 2010.

[3] A. L. Diaz, “Service level agreements in the cloud:Who cares?” http://www.wired.com/2011/12/service-level-agreements-in-the-cloud-who-cares/, december 2011.

[4] International Organization for Standardization, “ISO/IEC NP19086-1. Information Technology–Cloud computing–Servicelevel agreement (SLA) framework and technology–Part 1:Overview and concepts,” 2014.

[5] European Commission – C-SIG (Cloud Select IndustryGroup) subgroup, “Cloud Service Level Agreement Standard-isation Guidelines,” June 26 2014.

[6] A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig,T. Nakata, J. Pruyne, J. Rofrano, S. Tuecke, and M. Xu, “Webservices agreement specification (WS-Agreement),” in GlobalGrid Forum. The Global Grid Forum (GGF), 2004.

[7] A. Keller and H. Ludwig, “The WSLA framework: Specifyingand monitoring service level agreements for web services,”Journal of Network and Systems Management, vol. 11, no. 1,pp. 57–81, 2003.

[8] M. Comuzzi, C. Kotsokalis, C. Rathfelder, W. Theilmann,U. Winkler, and G. Zacco, “A framework for multi-level SLAmanagement,” vol. 6275, pp. 187–196, 2010.

[9] “Wsag4j project web site.” [Online]. Available:http://wsag4j.sourceforge.net

[10] M. Rak, N. Suri, J. Luna, D. Petcu, V. Casola, and U. Vil-lano, “Security as a service using an SLA-based approachvia SPECS,” in Cloud Computing Technology and Science(CloudCom), 2013 IEEE 5th International Conference on,vol. 2, Dec 2013, pp. 1–6.

[11] V. Casola, A. De Benedictis, M. Rak, and U. Villano, “Pre-liminary design of a platform-as-a-service to provide securityin cloud,” in CLOSER 2014 - Proc. of the 4th Int. Conf. onCloud Computing and Services Science, Barcelona, Spain,April 3-5, 2014., 2014, pp. 752–757.

[12] S. Taylor, M. Surridge, G. Laria, P. Ritrovato, and L. Schubert,“Business collaborations in grids: The BREIN architecturalprincipals and VO model,” in Grid Economics and BusinessModels, ser. Lecture Notes in Computer Science, J. Altmann,R. Buyya, and O. Rana, Eds., 2009, vol. 5745, pp. 171–181.

[13] R. T. Fielding, “Architectural styles and the design ofnetwork-based software architectures,” Ph.D. dissertation,University of California, Irvine, 2000.

[14] R. Kubert, G. Katsaros, and T. Wang, “A RESTful implemen-tation of the WS-Agreement specification,” in Proceedings ofthe Second International Workshop on RESTful Design, ser.WS-REST ’11. New York, NY, USA: ACM, 2011, pp. 67–72.

[15] “Unleashing the Potential of Cloud Computing in Europe -What is it and what does it mean for me?” [Online]. Available:http://europa.eu/rapid/press-release MEMO-12-713 en.htm

[16] S. Weerawarana, “WS-* vs. REST: Mashing up the truth fromfacts, myths and lies,” QCon San Francisco, 2007.

[17] C. Pautasso, “REST vs. WS-* comparison.” [Online].Available: http://goo.gl/qnRmNZ

[18] S. Sharaf and K. Djemame, “Enabling service-level agreementrenegotiation through extending WS-Agreement specifica-tion,” Service Oriented Computing and Applications, pp. 1–15, 2014.

[19] G. Di Modica, O. Tomarchio, and L. Vita, “Dynamic SLAsmanagement in service oriented environments,” J. Syst. Softw.,vol. 82, no. 5, pp. 759–771, May 2009.

[20] M. A. Serhani, Y. Atif, and A. Benharref, “Towards anadaptive QoS-driven monitoring of cloud SaaS.” IJGUC,vol. 5, no. 4, pp. 263–277, 2014.

[21] A. F. M. Hani, I. V. Paputungan, and M. F. Hassan, “Rene-gotiation in service level agreement management for a cloud-based system,” ACM Comput. Surv., vol. 47, no. 3, pp. 51:1–51:21, Apr. 2015.

[22] A. Cuomo, G. Di Modica, S. Distefano, A. Puliafito, M. Rak,O. Tomarchio, S. Venticinque, and U. Villano, “An SLA-based broker for cloud infrastructures,” Journal of GridComputing, vol. 11, no. 1, pp. 1–25, 2013.

[23] M. Rak, R. Aversa, S. Venticinque, and B. Di Martino, “Usercentric service level management in mOSAIC applications,”in Euro-Par 2011: Parallel Processing Workshops. Springer,2012, pp. 106–115.

[24] A. Amato, L. Liccardo, M. Rak, and S. Venticinque, “Slanegotiation and brokering for sky computing.” in CLOSER,F. Leymann, I. Ivanov, M. van Sinderen, and T. Shan, Eds.SciTePress, 2012, pp. 611–620.

[25] L. Wu and R. Buyya, Performance and Dependability in Ser-vice Computing: Concepts, Techniques and Research Direc-tions. IGI Global, USA, 2011, ch. Service Level Agreement(SLA) in Utility Computing Systems.

[26] S. A. Baset, “Cloud SLAs: Present and future,” SIGOPS Oper.Syst. Rev., vol. 46, no. 2, pp. 57–66, July 2012.

[27] J. Webber, S. Parastatidis, and I. Robinson, REST in Practice,Hypermedia and Systems Architecture. O’REILLY, 2010.

[28] R. T. Fielding, “REST APIs must be hypertext-driven,” 2008.[Online]. Available: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

[29] M. Fowler, “Richardson maturity model: stepstoward the glory of REST,” 2010. [Online]. Available:http://martinfowler.com/articles/richardsonMaturityModel.html

[30] SPECS Consortium, “SLA state XML datamodel.” [Online]. Available: http://www.specs-project.eu/resources/schemas/xml/slastate.xsd

[31] ——, “SLA API Bitbucket repository.” [On-line]. Available: https://bitbucket.org/specs-team/specs-core-sla platform-sla manager-api