SLA NEGOTIATION AND BROKERING FOR SKY COMPUTING

Alba Amato, Loredana Liccardo, Massimiliano Rak and Salvatore Venticinque

Dipartment of Information Engineering, Seconda University of Naples, Aversa, Italy

Keywords:

SLA, Negotiation, Cloud, Agents.

Abstract:

Cloud computing represents an opportunity for IT users to reduce costs and increase efﬁciency providing an

alternative way of using IT services. Elastic provisioning plays an important role by giving the possibility

to get the best resources conﬁguration that satisﬁes the application requirements. Even if there are many

Cloud Providers, with a rich and various offer of technological solutions, above all at IAAS, however there is

neither support of SLA negotiation, nor of SLA management yet. One of the most important issue in such a

context is the lack of negotiation interfaces and mechanisms by current providers for dynamic provisioning,

which instead only make available a conﬁguration form to submit the request for a speciﬁc resource among

the available ones. In the following we propose the design of a tool for SLA based dynamic provisioning of

Cloud Resources at IAAS, that offer to the user negotiation and brokering facilities by integrating multiple

models. We present a prototype implementation of our architecture using the mOSAIC framework.

1 INTRODUCTION

Cloud computing represents an opportunity for IT

users to reduce costs and increase efﬁciency provid-

ing an alternative way of using IT services. In this

scenario elastic provisioning plays an important role

by giving the possibility to get the best resources con-

ﬁguration that satisﬁes the application requirements.

Even if there are many Cloud Providers, with a rich

and various offer of technological solutions, above all

at IAAS, however there is neither support of SLA ne-

gotiation, nor of SLA management yet. This is due to

two main issues. The ﬁrst problem concerns a seman-

tic gap between the application requirements at user

side and the service level at IAAS. This gap deals with

the performance parameters that describe the appli-

cation (e.g: memory usage, throughput, turnaround,

...) and the ones which characterize the Cloud re-

source at IAAS (e.g: CPU architecture, main mem-

ory, number of cores, disk space ...). This issue is ad-

dressed by deﬁning a mapping between high level to

low level performance indexes (C Emeakaroha et al.,

2010), but it is out of the scope of this paper. The

second issue is the lack of negotiation interfaces and

mechanisms by current providers for dynamic provi-

sioning, which instead only makes available a conﬁg-

uration form to submit the request for a speciﬁc re-

source among the available ones. In fact, the absence

of standards for Cloud solutions that ensure portabil-

ity among different vendors’ technologies represents

an additional barrier for the development of such kind

of services. To overcome these problems it is funda-

mental to have a general purpose set of speciﬁcations

and facilities for cloud that are vendor independent,

platform neutral. A ﬁrst proposal of standard in Cloud

is represented by OCCI (Open Cloud Computing In-

terface) that is a protocol and API for management

tasks. This solutions is aimed at the fulﬁllment of

three requirements: integration, portability and inter-

operability for common tasks including deployment,

autonomic scaling and monitoring still offering a high

degree of extensibility

. Here we focus on a solution

that is ready to work now, for overcoming the cur-

rent limitation of the Cloud offer, that does not allow

the users to access the Cloud market by a business

interface. In the following we propose the design of

a tool for SLA based dynamic provisioning of Cloud

Resources at IAAS, that offer to the user negotiation

and brokering facilities by integrating multiple mod-

els. We present a prototype implementation of our

architecture using the mOSAIC framework.

2 RELATED WORK

In this section, we brieﬂy describe several related

works and classify their approaches for concurrent re-

source negotiation with multiple providers. In par-

www.occi.org

611

Amato A., Liccardo L., Rak M. and Venticinque S..

SLA NEGOTIATION AND BROKERING FOR SKY COMPUTING.

DOI: 10.5220/0003964406110620

In Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CloudSecGov-2012), pages 611-620

ISBN: 978-989-8565-05-1

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

ticular we focus our attention on protocols that are

the set of rules that govern the interaction deﬁning

the types of entities that can participate in the nego-

tiation, the status, the events that cause the change

in status and the correct actions of the participants

in particular situations. The contributions discussed

propose negotiation protocols, which are extension of

either Contract Net Protocol or Rubstein’s alternat-

ing offers protocol. Aknine et al. (Aknine et al.,

2004) propose an extended version of the contract-

net protocol (CNP) to support concurrent many to

many negotiation processes enabling an agent to man-

age several negotiation processes in parallel. This

approach introduces a two phase negotiation pro-

cess. In the proposal exchange phase both sides ex-

change proposals/counter-proposals until one agent

sends Pre-Accept/Pre-Reject to the other. In the pro-

posal formalization phase an agent sends its formal

proposal if it is pre-accepted, or the counter-proposal

otherwise. Besides this approach optimizes the length

of the negotiation processes among agents, reduces

the contractors’ decommitment situations, enables the

detection of failures of an agent participating in a ne-

gotiation process and prevents a negotiation process

with blocked agents. Chhetri et al. (Chhetri and al.,

2006) present a multi-agent framework with a two-

layered architecture, that combines the alternate offer

and the CNP protocols. In this approach a coordina-

tor agent is used: to decompose the negotiation into

individual service utilities that are forwarded to the

individual negotiation agents that negotiate with mul-

tiple providers iteratively over multiple rounds, to co-

ordinate the negotiation for different services and to

analyze the service composition with the aim of map-

ping the QoS requirements of the user request into the

QoS requirements of all services within the composi-

tion selecting the best combination.

Siebenhaar et al. (Siebenhaar and al., 2011) pro-

pose an extension of CNP approach that combine ser-

vices from multiple providers negotiating individual

QoS parameters across multiple tiers using a two-

phase protocol. The composition of services is co-

ordinated and managed by a Coordinating Entity that

in turn creates several Negotiating Entities according

to the number of services in the composition request

with the task to negotiate concurrently with multi-

ple providers over the QoS parameters of a partic-

ular service. In the second phase of the protocol,

multiple overbidding is allowed and time-dependent

strategies, which stop the overbidding process if nec-

essary, are applied. Sim and Shi (Sim and Shi, 2010)

propose an approach based on Alternate Offers pro-

tocol in which there is a management of multiple

one-to-many concurrent negotiations between a user

and multiple resource providers, and of intermediate

contracts between users and providers that can apply

a time-dependent strategy and can renege on a con-

tract during the negotiation by paying a penalty fee.

Dang and Huhns (Dang and Huhns, 2006) propose

an extension of the alternate offers protocol in order

to support several negotiation processes in parallel in

case of many-to-many negotiations. Sim (Sim, 2010)

proposes an extension of the alternate offers protocol

that supports multiple complex negotiation activities

in interrelated markets between user agents and bro-

ker agents, and between broker agents and provider

agents. In our approach, given the nature of the prob-

lem, the negotiation is one-to-one. In particular we

have two kind negotiations:

• The brokering managed by cloud agency among

the available offer from supported providers;

• The negotiation between users and SLA applica-

tions.

For the management of brokering is used an imple-

mentation of Contract-Net Protocol for a dedicated

cloud application while for the management of SLA

negotiation we develop components that enable us to

implement any model of strategic trading is us. As

an example, in this paper, is used an extension of

Contract-Net Protocol that allows the user to build the

offer by selecting the favourite proposals.

3 SLA NEGOTIATION IN THE

SKY COMPUTING PARADIGM

In order to provide a solution for the SLA negotiation

at IAAS in the current Cloud context we conceived

the architectural model that is shown in Figure 1. The

negotiation problem is addressed here in two steps, by

two independent components, which interact accord-

ing to a well deﬁned protocol:

• A Cloud Application supports the implementation

of many negotiation models. It allows the user to

select the requirements to be negotiated and the

model of negotiation to be used.

• An autonomic Cloud broker (Cloud Agency) ac-

cepts an SLA template and a set of brokering

rules, by which it provides the best proposal for

that request.

The SLA negotiation allows the user to access the

Cloud market by an high level business interface.

The user can choose among the supported negotia-

tion models. The negotiation interface allows to del-

egates a lot of stuff to the application and to focus

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

612

Figure 1: Architectural Model for SLA Negotiation.

on the desired solution in terms of requirements, ser-

vice levels and business parameters. The application

supplies also to the lack of mechanisms for dynamic

resource provisioning at provider side, by implement-

ing a complex logic, that is reconﬁgurable and pol-

icy driven. A this level the user is going to deﬁne

high level and low level requirements which are nec-

essary for running his Cloud applications. Here we

do not provide high level to low level mapping, hence

only low level parameters can be deﬁned. For this

purpose we identiﬁed three sets of information: i)

mandatory requirements, ii) negotiation model and

negotiation parameters, iii) brokering rules and pa-

rameters. The retrieval of proposals and the broker-

ing among them, by the rules deﬁned at iii) is dele-

gated to Cloud Agency. The provisioning service by

Cloud Agency is used to get all proposals, which are

necessary as an input for the SLA negotiation imple-

mented at application level. Cloud agency provides

a vendor-agnostic interface to a number of providers

and technologies available in the Cloud market. It im-

plements a very simple negotiation protocol, charac-

terized by a limited interaction, that is described in

the following section. This means that Cloud Agency

will make a ﬁrst choice among the retrieved propos-

als which are compliant with the mandatory require-

ments i), and according to some brokering rules and

those parameters, which do not need to be negotiated.

The brokering solution enable to ﬁnd the best offer-

ings respect to a given set of chosen parameters and

rules, in the context of the negotiation, instead, the

goal is to offer to the ﬁnal user more than a single

choice, so that it is possible to involve him in the ﬁ-

nal decision about the resources to be acquired. An

example for Cloud negotiation could look for a Vir-

tual Machine with i) speciﬁc CPU architecture and a

ﬁxed amount of memory, ii) any number of cores to

be negotiated, iii) brokering the best price among the

proposals which satisfy i) and ii). The cloud appli-

cation has an intermediary role between the user and

the broker, implementing the negotiation protocol to-

ward the users and the brokering protocol toward the

cloud agency and offers both a REST-based interface

for enabling the SLA negotiation and a Web interface

that embeds the REST requests. SLA are represented

trough the WS-Agreement standard, even if the ne-

gotiation protocols are not standard compliant, in fact

Ws-Agreement does not offer big support in terms of

Negotiation protocols and it is Web Services based,

while we need a REST interface. The Cloud Appli-

cation we propose is developed in order to be able to

scale with the number of parallel requests, moreover

it should be able to ﬂexibly support new kind of pro-

tocols.

4 SLA BROKERING: CLOUD

AGENCY

Cloud Agency is a multi agent system (MAS) that

accesses, on behalf of the user, the utility market

of Cloud computing to maintain always the best re-

sources conﬁguration that satisﬁes the application re-

quirements. This system is being designed and de-

veloped within the research activities of the FP7 mO-

SAIC project. It is in charge to provide the collec-

tion of Cloud resources, from different vendors, that

continuously meets the requirements of users appli-

cations. According to the available offers, it gener-

ates a service level agreement that represents the re-

sult of resource brokering and booking with available

providers. The user is able to delegate to the Agency

the monitoring of resource utilization, the necessary

checks of the agreement fulﬁllment and eventually

re-negotiations. Cloud Agency will supplement the

common management functionalities which are cur-

rently provided by IAAS Private and Public infras-

tructure with new advanced services, by implement-

ing transparent layer to IAAS Private and Public

Cloud services;

Cloud Agency will support the Cloud user in two

different scenarios:

• Deployment: to discover and buy the available

resources needed to run Cloud applications,

• Execution: to monitor and eventually to recon-

ﬁgure Cloud resources according the changed re-

quirements of the Cloud Application.

Here we focus on the ﬁrst one by which Cloud re-

sources at IAAS are brokered among the available

SLANEGOTIATIONANDBROKERINGFORSKYCOMPUTING

613

proposal from many heterogeneous providers.

4.1 An OCCI Extended Model for

Cloud Provisioning

Obtaining a common interface is the focus of the

OCCI group that has deﬁned a model for Cloud man-

agement at IAAS. OCCI deﬁnes entities, API and pro-

tocol. The speciﬁcation of Cloud API is a Resource

Oriented Architecture (ROA) that uses Representa-

tional State Transfer (REST)protocol. The OCCI core

meta-model (Nyr n et al., 2011) provides means of

handling abstract Cloud resources. The heart of the

OCCI Core Model is the Resource type. Any resource

exposed through OCCI is a Resource or a sub-type

thereof. A resource can be e.g. a virtual machine, a

job in a job submission system, a user, etc. The Re-

source type contains a number of common attributes

that Resource sub-types inherits. The Resource type

is complemented by the Link type which associates

one Resource instance with another. The Link type

contains a number of common attributes that Link

sub-types inherit. Entity is an abstract type, which

both Resource and Link inherit. Each sub-type of En-

tity is identiﬁed by a unique Kind instance. The Kind

type is the core of the type classiﬁcation system built

into the OCCI Core Model. Kind is a specialization

of Category and introduces additional resource capa-

bilities in terms of Actions. An Action represents an

invocable operation applicable to a resource instance.

The last type deﬁned by the OCCI Core Model is the

Mixin type. An instance of Mixin can be associated

with a resource instance, i.e. a sub-type of Entity, to

”mixin” additional resource capabilities at run-time.

To be compliant with the OCCI standard it is neces-

sary to extend the core model using inheritance at two

points: mixin: to provide IAAS resources with moni-

toring and provisioning capabilities and entity: to rep-

resent those new concepts, which are introduced by

the services we are going to describe. Cloud Agency

extends the OCCI model by autonomic and dynamic

services, it is necessary that they new functionalities

can be deployed in user’s Cloud. In Figure 2 the

new entities and mixin, an their relationship with the

OCCI core model are shown. Among the entities, a

Call for Proposal (CFP) describes the list of resources

which are necessary to run a Cloud application. A

Cloud customer deﬁnes the values of those attributes

of OCCI Compute, Storage and Links which are sig-

niﬁcant for his application requirements. A CFP will

include also the negotiation rules to select the best of-

fer among the ones proposed by providers. A Pro-

posal is a candidate for a Service Level Agreement

(SLA). It includes an instance for each resource in the

Figure 2: OCCI Extended model.

CFP with all the attribute speciﬁed, including other

information such as the cost and service levels. It

can be accepted or refused by the customer. An SLA

is an accepted proposal, it is agreed by the customer

with one provider. Among the new mixin, a Vendor

is committed to get an offer for resource provision-

ing, to accept or refuse that offer, to get information

about a resource or to perform an action on it against

a speciﬁc Cloud provider or technology. A Broker is

an intermediary that provides information and assists

in ﬁnding the right cloud-based solution. It receives a

CFP, asks to vendors for available offers, brokers the

proposal that best serves the user and allows to close

the transaction. The Meter is a mixin that monitors

some parameters chosen by user and gives the mea-

sure of performance indexes for those parameters. It

can be deployed into the Cloud, within a Virtual Ma-

chines, to dynamically complement the user’s Cloud

resource with this new capability. We need to run

Meter instances on any resource to perform locally

specialized algorithm to take measures. An Archiver

collects measures from Meters and stores them in a

knowledge base. It provides metrics and performance

statistics computed on the knowledge base. A Tier is

a mixin that use statistics provided by the Archiver, it

detects critical conditions such as SLA violations, re-

source saturation or underutilization and then informs

the user or autonomically performs required reaction

as new provisioning or management.

4.2 Cloud Agency: Static View

According to our extended OCCI model Cloud

Agency is both a mixin itself and a collection of those

mixins presented before. It can run anywhere, also

in an user’s Resource, if it has been implemented as

a deployable software component. Cloud Agency

has been implemented as a Multi Agent systems. The

different components of the agency architecture is

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

614

Figure 4: Sequence diagram to start a call for proposal.

Figure 3: Cloud Agency Components Diagram.

shown in Figure 3. Execution environment for agents

and communication facilities are provided by the Jade

agent platform(Bellifemine et al., 2003). Jade has

been chosen as a platform to provide an execution en-

vironment of software agents, an Agent Communica-

tion Channel (ACC) and some protocol implementa-

tion to support communication. AMS and DF provide

standard services of FIPA compliant agent platforms:

a name server for agents and a yellow pages registry

for publication and discovery of agent base services.

Blue components represent agents, which implement

the new OCCI MIX-INs. They embed the interaction

protocols of the deployment and execution scenarios.

Agents will communicate among them via standard

ACL (Agent Communication Language) over HTTP,

or over other transport protocols if it is necessary.

In order to allow a straightforward specialization of

agents’ behaviors we deﬁned abstract interfaces for

brokering, monitoring, reconﬁguration and resource

management. These abstract interfaces can be im-

plemented by developers who want to extend Cloud

Agency by new brokering algorithm, new monitor-

ing technologies, new reconﬁguration models or by

supporting more Cloud provider. These implementa-

tion become plug-ins of CA, which are automatically

used by agents through their general interfaces. The

OCCI/RESTFull Message Transfer Protocol (MTP)

extends the OCCI HTTP rendering (Metsch and Ed-

monds, 2011).

The call for proposal template includes a list of

OCCI resources whose parameters can be initialize

with a value, a wildcard or can be associate to a bro-

kering rule.

4.3 Cloud Agency: Dynamic View

The Provisioning service of Cloud Agency im-

plements the FIPA Contract-Net protocol(FIPA TC

Communication, 2002). It is a minor modiﬁcation

of the original contract net IP pattern in that it adds

rejection and conﬁrmation communicative acts. In

the contract net IP, one agent (the Initiator) takes the

role of manager which wishes to have some task per-

formed by one or more other agents (the Participants)

and further wishes to optimize a function that char-

acterizes the task. This characteristic is commonly

expressed as the price, in some domain speciﬁc way,

but could also be soonest time to completion, fair dis-

tribution of tasks, etc. For a given task, any num-

ber of the Participants may respond with a proposal;

the rest must refuse. Negotiations then continue with

the Participants that proposed. Cloud Agency uses

asynchronous messages RESTfull messages to start

a transaction, to notify a Proposal and to agree or

refuse. The message encoding is an extension of the

OCCI HTTP rendering model described in (Metsch

and Edmonds, 2011). The message body is a CFP

document. This message triggers the interaction di-

agram of Figure 4. In Figure 4 the Cloud user pre-

pares a CFP to be sent to the Cloud Agency. The ac-

knowledge of Cloud Agency conﬁrms the correctness

of the request and its acceptance for being processed.

Cloud Agency contacts all vendors, which provide a

bid for that kind of resource. When the available bids

have been connected from the Vendor Agents, Cloud

Agency returns asynchronously the best proposal that

satisﬁes the CFP requirements. In particular the bro-

ker choose the best proposal among the received ones

SLANEGOTIATIONANDBROKERINGFORSKYCOMPUTING

615

Figure 6: Sequence diagram to notify the availability of a new SLA.

Figure 5: Sequence diagram to notify a new proposal.

and notify the availability of the result to the client

5. When the client has been notiﬁed, it can use the

location URL from the notiﬁcation of the available

proposal to get the content of the proposal and, by the

same message, it can add a query string to the HTTP

request to agree or refuse the proposal. The client

sends an HTTP GET request to the Cloud Agency.

The message is forwarded to the right agent broker

that fulﬁlls the request by forwarding the message to

the right Vendor Agent. An acceptance or a refuse of

the proposal terminates the transaction, and the broker

agent itself. In case of agreement the Vendor Agent

allocates the related resources and returns a notiﬁca-

tion about the agreed SLA to the client according to

the sequence diagram of Figure 6. After that the re-

sources are available for the application deployment.

5 SLA NEGOTIATION: THE

mOSAIC APPLICATION

As outlined in section 3, while the cloud agency has

the role of managing the brokering, offering it trough

a Contract-Net Protocol, implementation of the Nego-

tiation Protocol is delegated to a dedicated cloud ap-

plication. Such an application has the following main

requirements:

• it has an intermediary role between the user and

Cloud Agency, implementing the negotiation pro-

tocol toward the users.

• it is able to ﬂexibly support many negotiation

models.

• it offers a Web interface to its Final Users.

• it is based on SLA negotiation, implementing a

complex logic, which is reconﬁgurable.

We implemented such solution using the mOSAIC

framework, which is perfectly integrated with the

cloud agency (they were born together), whose details

will be described in the following sections, for what

is strictly necessary to understand the application.

5.1 Flexible Negotiation Models

The cloud application manages a negotiation instance

for each user, negotiation steps are modelled trough a

ﬁnite-state machine (FSM). The solution adopted in

order to implement the FSM model in mosaic will

be based on already existing components that can

be easily adapted to support different kind of FSMs.

Changing Negotiation models implies only the need-

ing of sending set of conﬁguration information to al-

ready available components. Thanks to the services

offered by mOSAIC it is possible to implement such

an approach by a little development effort: state in-

formation will be stored in cloud-based storage sys-

tem (this is typical of mOSAIC as it will be shown

later), the FSM events will be represented trough mes-

sages, while the FSM advances will be deﬁned trough

a set of Policies. Policy evaluation identiﬁes the ad-

vances in the negotiation FSM model. The proposed

approach is ﬂexible, in fact it is possible to change the

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

616

Negotiation Model, just changing the set of policies

stored in the dedicated component.

It would be possible to support a different Ne-

gotiation Model for each different user. As already

said, our SLA management solution use two ﬁnite-

state machines: the ﬁnite-state machine related to

the negotiation model and necessary for the negotia-

tion implementation and the ﬁnite-state machine WS-

Agreement standard. This model deﬁnes the states

assumed by an SLA during its management. The

WS-Agreement FSM is managed independently by a

dedicated mOSAIC component (SLAstore, described

later), from now on when we refer to an FSM we refer

to negotiation FSM.

5.2 mOSAIC Application and mOSAIC

Services

In order to illustrate and motivate the way, by which

we developed the application, we brieﬂy illustrate

what are the features that mOSAIC offers. The inter-

ested reader can ﬁnd detailed description of the mO-

SAIC Solution in (Rak et al., 2011), (Int, ), (Craciun

et al., 2011). In mOSAIC a Cloud application is

modeled as a collection of components that are able

to communicate each other and that consumes/uses

Cloud resources (i.e., resources offered as a service

from a Cloud Provider). Components may be of-

fered by the mOSAIC Platform (i) as COTS (Com-

mercial off-the Shelf) solutions, i.e., common tech-

nologies embedded in a mOSAIC Component, (ii) as

Core Components, i.e., tools which enable applica-

tion execution and composing the mOSAIC platform,

(iii), as Service Components, i.e., tools offered by

mOSAIC Platform in order to perform predeﬁned op-

erations , or (iv) as new components that can be devel-

oped using mOSAIC API. In last case a component is

a Cloudlet running in a Cloudlet Container (Craciun

et al., 2011), (Int, ). mOSAIC Components are inter-

connected trough communication resources, such as

queues. The mOSAIC Platform offers some queu-

ing system (rabbitmq and zeroMQ) as COTS com-

ponents, in order to enable component communica-

tions. Moreover, mOSAIC Platform offers some Ser-

vice Components in order to help Cloud application to

offer their functionalities as a service, like an HTTP

gateway, which accepts HTTP requests and forwards

them on application queues.

5.3 Negotiation Application mOSAIC

Components

As anticipated we built up our applications as a mO-

SAIC Application, which directly communicates with

the Cloud Agency. It is a component-based applica-

tion, in which each component has a different well

deﬁned role. Communication between components

will take place through messages. In Figure 7 there is

the application architecture in terms of interconnected

components, which will be described in detail in the

following subsection. Each component implements a

well-deﬁned functionality:

• SLAgw and SLAstore, which provides SLA man-

agement.

• TradeProtocolState and SLApolicy, which

implements the negotiation model.

• CAgw, which interacts with Cloud Agency and as-

sumes decisions on agreement.

In the following we propose a brief description of the

behavior of each component, while next subsection

tries to outline how they interoperate for the negoti-

ation application. The SLAgw has both the role of

offering the application as a Web application and im-

plements a REST-based interface. The SLAgw REST

API, accepts essentially the following methods: i)

submit, with which a Customer submits the agree-

ment or template to Provider, ii) check, with which a

Customer requests the status of SLA agreement, iii)

sign, with which a Customer accepts the agreement,

iiii) terminate, with which a Customer requests the

termination of SLA agreement.

Through these methods SLAgw-based applica-

tions are able to implement many different negotia-

tion models: the submit method will be used to im-

plement many different kind of requests to the un-

derlying application. Moreover check, sign and

terminate represent the mandatory operations for

SLA management protocols. SLAstore is the compo-

nent that stores an agreement or template with related

timeout. It is a component that manages features such

as: the capability of taking trace of the signed SLAs

and the status of all the exchanged SLAs. In fact,

as anticipated, during a SLA management, a SLA

can assume several states, deﬁned by WS-Agreement

standard. SLAPolicy is a component that acts as a Pol-

icy Decision Point. It retrieves information, on which

performs a policy evaluation and if the evaluation is

positive, generates the resulting action, correspond-

ing to the policy. A policy is represented in JSON

as a triple of Parameter, Expression, Action lists.

The ﬁrst one contains the parameters to be used for

evaluation of the policy, the second one is a logical

expression whose variables are the parameters deﬁned

before, and action represents the message to be sent if

the policy evaluation results true. TradeProtocolState

has the role of taking track of the states of the negotia-

SLANEGOTIATIONANDBROKERINGFORSKYCOMPUTING

617

tion (storing them in the Key Value cloud storage) and

acting consequently to the action requests generated

by the SLApolicy component. During the negotiation

process, it communicates with SLApolicy, requiring

an evaluation policy operation and with CA which

interacts with the Cloud Agency. Moreover it sends

out messages to the SLAstorage, both forwarding the

new message request sent by the SLAgw and gen-

erating new ones in order to update WS-Agreement

SLA states. CAgw has the role of Cloud Agency

Client or gateway: it receives messages from the other

components, containing information needed to imple-

ment the Contract-Net protocol, then it invokes Cloud

Agency APIs.

5.4 mOSAIC Application Global

Architecture

The application behaviour can be brieﬂy summarized

on the base of the messages exchanged by the compo-

nents which have been described above and connected

as in Figure 7. The SLAgw receives the messages

from the ﬁnal users trough its SLA-oriented API. All

the negotiation messages are sent trough the submit

REST call, except the ones needed to effectively sign

the SLA. By a web interface the user can interactively

send request and check responses. Each message sub-

mitted by the SLAgw is intercepted by the Trade-

ProtocolState component, which forwards to the SLA

storage all the messages containing a new or updated

WS-Agreement. Moreover it sends a message to the

SLApolicy in order to know how to update the lo-

cal storage. On the basis of the policy evaluation,

which generates Action messages, the TradeProtocol-

State updates the local storage with the new negotia-

tion state and, eventually, it sends out messages to the

SLAstorage, in order to update the WS-Agreement

state and/or sends messages to the CAgw in order to

starts up requests for the negotiations.

6 NEGOTIATION MODEL

IMPLEMENTATION

As outlined above, the application is ﬂexible re-

spect to complex negotiation models, but to make

it easier to understand, we will focus on a simple

proposal-based negotiation model. It is an exten-

sion of Contract-Net Protocol that allows the user to

choose the best offer by selecting the favourite pro-

posals among a set of available one. It is realized

performing many parallel Contract-Net and adding a

step for booking the proposal that best ﬁt the user’s

Figure 7: Application architecture.

Figure 8: Negotiation Model.

need, without locking the other choices. The con-

sidered negotiation model is shown in 8. It is im-

plemented by several steps. The customer submits a

CallForProposal (that consists of several features) to

the provider by an agreement template. The provider,

once received the template, performs a check and he

can reject it or send a template with the supported

options . The customer, once received the template,

decides to reserve a proposal or to refuse it. If he

submits a proposal (that is a SLA), it can be reserved

or refused. If a reservation is performed, a time out

is set for a SLA agreement. A timeout is a spec-

iﬁed period of time that will be allowed to elapse

before an customer sign event occurs. If this event

takes place before a timeout, the sign operation is per-

formed otherwise not. Such a model is associated to

the FSM shown in 9, before offering a detailed de-

scription of the FSM implementation few considera-

tion are needed. All the events are labelled with mes-

sages, note that messages from users (submit, sign)

are explicitly expressed, while the others are labeled

as internals (just to do not overload this picture of con-

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

618

Figure 9: Finite-State machine.

cepts). Internal message names are reported in the

table 10, which describe the SLApolicies deﬁned, as

actions to be performed. SLA policy evaluation fol-

lows the simple rule of getting the State, getting the

request and sending out an action message which con-

tains the next state and the actions to be performed.

Policies are represented in table 10, ﬁrst column con-

tain the parameters to be retrieved from the KV store

(always the same), the second column the expres-

sion to be checked, third column the message to be

sent if the expression is true. Note that when a pol-

icy is true all the others are false. The FSM works

as follows: when the ﬁnal user submits a template

the ﬁrst time (the black point) a new ID is created

in the KV store by both TradeState and SLAstorage,

in order to maintain state information and startup the

procedure. The TradeState component, when a sub-

mit message of a new WS-Agreement has been re-

ceived, updates the KV store with a new key (using

the Ws-Agreement ID) and a value which contains

state information (null at start) and the submitted re-

quest, then it sends an evaluation message to SLApol-

icy. As shown in the FSM and in the policy table, in

case of null state SLApolicy emits a message which

says that the next state is NewCFP and the action

is CAcfps. As a consequences TradeState updates

the KVstore with NewCFP, forwards the message to

SLAstore (that now creates the WS-Agreement state)

and prepares the messages to the Cloud Agency. This

step strictly depends on the resources to be negoti-

ated: for each possible value of the WS-Agreement

template to be independently negotiated, TradeState

creates a CFP and sends a request to the CAgw. As

a result multiple parallel negotiation will take place

trough the Cloud Agency. Note that from now on each

tie a new CFP will be submitted by the Final User, it

will be discarded, until the FSM arrives to the avail-

ability of new options. For each result obtained (i.e. a

proposal of the Cloud Agency Contract Net protocol)

a new message is sent to the TradeState component

by CAgw. As shown in the FSM and in the policy ta-

ble, after the receiving of the ﬁrst proposal the FSM

moves in the OptionsAvailable. TradeState creates a

Ws-Agreement template which has as an option the

Proposal received. Each new proposal received by the

CAgw is added to the WS-Agreement template, en-

riching it. Note that it is up to the user, that can look

at the options available trough the check REST call,

to wait for other proposals, or cleanup the procedure,

submitting a new CFP. In the latter case new proposals

will be discarded by TradeState. When the Final User

accepts a Proposal, he submits the proposal to the sys-

tem and Tradestate receives the WS-Agreement an,

verifying that it is not a template, but a SLA, moves

to the reserve steps. Since now the procedure is com-

pletely locked, the only actions allowed are accept or

refusal by each of the two parts, as can be seen look-

ing at both FSM and policy list. Note that, in order to

have a limited dimension of the policy list, only the

main policies are written in the table, while some of

them (the most part of the ones that lead to just dis-

card the message) are simply skipped.

Figure 10: Negotiation Model Implementation Policies.

7 CONCLUSIONS

Support for negotiation of Service level Agreement is

a weakness in cloud market nowadays. In fact, at the

state of art only few providers are able to offer dynam-

ically conﬁgurable SLA services. In this paper, which

includes results of the mOSAIC project, we have

SLANEGOTIATIONANDBROKERINGFORSKYCOMPUTING

619

shown how it is possible to build a complex negoti-

ation system, which is independent from the cloud

provider technologies and allows the user to negoti-

ate the best Cloud service, that is compliant with his

requirements. The solution proposed adopts a broker-

ing system, the Cloud Agency, in order to acquire au-

tonomically resources from providers on the basis of

SLA evaluation rules. Moreover a dedicated applica-

tion offer to the user negotiation facilities by an inter-

active interface and according several policies, which

can be conﬁgured in a ﬂexible way. The application

offers a REST-based interface to ﬁnal users that im-

plements a console for the management of SLAs com-

pliant with the WS-Agreement model.

ACKNOWLEDGEMENTS

This work has been supported by the FP7-ICT-2009-

5-256910 (mOSAIC) EU project and by the MIUR-

PRIN 2008 Cloud@Home: a New Enhanced Com-

puting Paradigm.

REFERENCES

Aknine, S., Pinson, S., and Shakun, M. (2004). An extended

multi-agent negotiation protocol. Autonomous Agents

and Multi-Agents Systems, 8(1):5–45.

Bellifemine, F., Caire, G., Poggi, A., and Rimassa, G.

(2003). JADE: A White Paper. EXP in search of in-

novation, 3(3):6–19.

C Emeakaroha, V., Brandic, I., Michael, M., and Dust-

dar, S. (2010). Low level metrics to high level slas -

lom2his framework : Bridging the gap between mon-

itored metrics and sla parameters in cloud environ-

ments. Information Systems Journal, 2:48–54.

Chhetri, M. and al. (2006). A coordinated architecture for

the agent-based service level agreement negotiation of

web service compositions. In The Australian Software

Engineering Conference. Springer.

Craciun, C., Rak, M., and Petcu, D. (2011). Towards a cross

platform cloud api. components for cloud federation.

In van Sinderen F. Leymann, I. I. M. and Shishkov, B.,

editors, Procs. CLOSER 2011 - 1st International Con-

ference on Cloud Computing and Services Science,

pages 166–169. SciTePress – Science and Technology

Publications.

Dang, J. and Huhns, M. (2006). Concurrent multiple-issue

negotiation for internet-based services. IEEE Internet

Computing, 10(6):42–49.

FIPA TC Communication (2002). Fipa contract net interac-

tion protocol. Available at http://www.ﬁpa.org.

Metsch, T. and Edmonds, A. (2011). Open cloud computing

interface - http rendering. http://ogf.org/documents/

GFD.185.pdf.

Nyr n, R., Edmonds, A., Papaspyrou, A., and Metsch,

T. (2011). Open cloud computing interface - core.

http://ogf.org/documents/GFD.183.pdf.

Rak, M., Venticinque, S., Aversa, R., and Di Martino, B.

(2011). User centric service level management in mo-

saic application. In Europar 2011 Workshop. IEEE.

Siebenhaar, M. and al. (2011). Concurrent negotiations in

cloud-based systems. In Proceedings of the 8th Inter-

national Workshop on Economics of Grids, Clouds,

Systems, and Services (GECON2011).

Sim, K. and Shi, B. (2010). Concurrent negotiation and co-

ordination for grid resource coallocation. IEEE Trans-

actions on Systems, Man, and Cybernetics, Part B:

Cybernetics, 40(3):753–766.

Sim, K. M. (2010). Towards complex negotiation for cloud

economy. In 5th International Conference on Ad-

vances in Grid and Pervasive Computing (GPC 2010),

pages 395–406.

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

620