AGENT BASED CLOUD PROVISIONING AND MANAGEMENT

Design and Prototypal Implementation

Salvatore Venticinque, Rocco Aversa, Beniamino Di Martino

Department of Information Engineering, Second University of Naples, Naples, Italy

Dana Petcu

Institute e-Austria, Timisoara, Romania

Keywords:

Cloud, Agents based services, SLA negotiation, Resources provisioning.

Abstract:

When interoperability and portability of applications across heterogeneous Clouds are supported, autonomous

services which can automatically manage collection, negotiation and monitoring of Cloud resources represents

an added value for users within the sky computing paradigm. We describe here the design and the prototypal

implementation of an Agency that can access the computing utility market relative to the state-of-art of Cloud

computing, on behalf of the user, to maintain always the best resources conﬁguration that satisﬁes the appli-

cation requirements. This system is in charge to provision the collection of Cloud resources, from different

providers, that continuously meets the requirements of user’s applications. According to the available offers,

it generates a service-level agreement that represents the result of resource negotiation and booking with avail-

able 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.

1 INTRODUCTION

Cloud computing is an emerging paradigm that, due

to an intensive use of the virtualization approach, of-

fers resources on which users have full administrative

control. A relevant issue affecting this paradigm is

related to the mandatory choice of a proprietary so-

lution that the user is asked to take when he wants

to Cloudify his applications. The EC-FP7-ICT mO-

SAIC project (www.mosaic-cloud.eu) intends to im-

prove the state-of-the-art in Cloud computing by cre-

ating, promoting and exploiting an open-source Cloud

application programming interface and a platform tar-

geted for developing multi-Cloud oriented applica-

tions. The main beneﬁt of using the mOSAIC soft-

ware package will be a transparent and simple access

to heterogeneous Cloud computing resources and the

avoidance of lock-in proprietary solutions. Once the

portability across multiple Cloud is supported many

facilities could be provided to improve performability

of Cloud applications, or in order to optimize costs

and quality of Cloud resource to be bought by switch-

ing between different Providers and technological so-

lutions, or using an heterogeneous collection of them

according the sky computing approach (Keahey et al.,

2009). In this context automatic SLA-oriented re-

source provisioning can represent a solution to ne-

gotiate and manage a collection of inter-connected

and virtualized computers and storages between re-

source providers and consumers (or between resource

providers and a third-party broker)(Sim, 2010). The

most relevant issues to be addressed during this ac-

tivities are: the deﬁnition of an uniform SLA model,

that is used to manage internally the ones used by

heterogeneous providers; the understanding of users’

requirements in terms of Cloud resources which are

necessary to run his applications, and are compliant

with constraints like costs; the periodic benchmark-

ing model and check of the fulﬁllment of the SLA

by providers; a knowledge model of current and his-

torical information about Cloud; the rules and the

actions for automatically detect the bottlencks and

apply the solution in terms of reactions. Here we

present the design and a ﬁrst prototypal implemen-

tation of an important component of the mOSAIC

framework that we called Cloud Agency (R. Aversa,

2010) that allows to the user to delegate to the Agency

the necessary checks of SLA fulﬁllment, the monitor-

ing of resource utilization and eventually necessary

re-negotiations. Even if security is a mandatory issue

184

Venticinque S., Aversa R., Di Martino B. and Petcu D..

AGENT BASED CLOUD PROVISIONING AND MANAGEMENT - Design and Prototypal Implementation.

DOI: 10.5220/0003395901840191

In Proceedings of the 1st International Conference on Cloud Computing and Services Science (CLOSER-2011), pages 184-191

ISBN: 978-989-8425-52-2

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

for the authentication of involved parties and certiﬁ-

cation of SLAs actually it is out of the scope here.

The second section presents related work on Cloud

resource provisioning and management. In the third

Section we discuss the requirements of the Cloud

Agency design. The fourth section the architecture

of the provisioning subsystem of the mOSAIC plat-

form is described. In the ﬁfth section we provide de-

tails about the multi agents model we have designed.

Finally prototypal implementation and APIs are de-

scribed.

2 RELATED WORK

The brokering of Cloud providers whose offers can

meet the requirements of a particular application is

a complex issue due to the different business models

that are associated with such computing systems. Ac-

cording to (R. Buyya and Brandic, 2009) a market-

oriented resource management is needed in order to

regulate the supply and demand of Cloud resources,

providing feedback in terms of economic incentives

for both Cloud consumers and providers, and pro-

moting QoS-based resource allocation mechanisms

that differentiate service requests based on their util-

ity. The current Cloud computing technologies offer a

limited support for dynamic negotiation of SLAs be-

tween participants. There is no mechanisms for au-

tomatic allocation of resources to multiple compet-

ing requests. Furthermore, current Cloud comput-

ing technologies are not able to support customer-

driven service management based on customer pro-

ﬁles and requested service requirements. It is im-

possible, according to (R. Buyya and Brandic, 2009),

to derive appropriate market-based resource manage-

ment strategies that encompass both customer-driven

service management and computational risk manage-

ment to sustain SLA-oriented resource allocation. An

attempt to deﬁne several QoS metrics is presented in

(B. Cao and Xiang, 2009): response time, availabil-

ity, reliability, cost and reputation are considered. A

reference of SLA model is provided in (Sim, 2010)

where SLA objectives (SLOs) are used to compose

an SLA. A number of service levels and performance

metrics for each resource results in multiple SLOs for

every service. The work presented in (A. Kertesz,

2009) represents a ﬁrst proposal to combine SLA-

based resource negotiations with virtualized resources

in terms of on-demand service provision. The archi-

tecture description focuses on three topics: agreement

negotiation, service brokering and deployment using

virtualization. It involves multiple brokers. A Cloud

multi-agent management architecture is proposed in

(Cao et al., 2009). It includes requestor agents, QoS

agent, provider agent and agent manager. In particular

the QoS agent is dedicated to the submission of QoS

information about services. A simpler agents based

architecture has been proposed in (X. You and Yu,

2009). It is simpler than the one described in this pa-

per and consists of only three parts: consumer agent

delegated by the consumer to obtain a maximal ben-

eﬁt for him, resource agent delegated by the resource

provider to publish the prices and to adjust them ac-

cording to the relationship of supply and demand in

the market system and the market economy mecha-

nism responsible for balance the resource supply and

the demand. New SLA-oriented resource manage-

ment strategies must be designed for Clouds in order

to provide personalized attention to customers. Ser-

vice requirements of users can change over time, due

to continuing changes in business operations and op-

erating environment, and thus may require amend-

ments of original service requests. Effects due to

concurrent negotiation activities between broker and

provider agents in multiple Cloud resource markets

have to be considered. The negotiation that outcome

between broker and provider agents inﬂuence the ne-

gotiation outcomes of broker and consumer agents in

a Cloud service market. The implementation that was

presented in (Sim, 2010) is very interesting from this

point of view because it is supporting dynamic nego-

tiations.

3 REQUIREMENTS

SLA Negotiation with multiple Cloud providers is

a ﬁrst example of complex application that could be

delegated to a third party, represented by a broker in

a market based context. A broker intermediates be-

tween users and providers in order to negotiate the

best SLA for both consumer and vendors. On user be-

half it can search for available Cloud services, which

are compliant with user needs; check of trustiness of

providers; decide with whom to negotiate, accord-

ing to user requirements and past experiences; ne-

gotiate the best price for the same offer by differ-

ent providers; negotiate multiple SLAs, with different

providers, to overcome the lack of one compliant offer

by a single provider. Since consumers’ requirements

can potentially vary over time it needs to support dy-

namic re-negotiation of SLA. Some mechanisms to

reconﬁgure virtual resources are already available, but

it needs policies and protocols for changing the SLA

parameters, to include new amendments and with-

draw previous ones. Re-negotiation is another ser-

vice that can be provided to solve some inconsisten-

AGENT BASED CLOUD PROVISIONING AND MANAGEMENT - Design and Prototypal Implementation

185

cies between the SLA and the real user’s requirements

which can change dynamically. Dynamic SLA re-

negotiation has actually limited support. Issues to be

investigated are: withdraw of an SLA and negotia-

tion of a second one; deletion of an SLA objective;

addition of an SLA objective; redeﬁnition of SLA pa-

rameter; negotiation of boundaries within which the

SLA can be re-negotiated at the same price or with a

pre-deﬁned price adjustment.

Monitoring the utilization of Cloud resources is an-

other service that can be delegated. Providers moni-

tor utilization of their resources for billing, to change

bid prices in order to optimize proﬁt, to not exceed in

resource allocation beyond the capability of fulﬁll the

agreements. On the other hand, the user, who has con-

ﬂicting interests with providers, needs to trust a third

party that can be delegated to monitor the satisfac-

tion of the agreed service levels. Monitoring process

should provide information about under-utilization of

cloud resources, in order to negotiate cheaper agree-

ments; saturation of resources, to not let the users’ ap-

plications work under the QoS level granted to users’

clients; unbalanced utilization of Cloud resources, in

order to check the correctness of negotiated param-

eters, or to tune the execution of applications in the

Cloud; violation of SLA by providers.

4 MOSAIC PROVISIONING

SYSTEM

The Provisioning services of the mOSAIC framework

are in charge to implement a set of functionalities for

resources negotiation and management. These facil-

ities can be used by the mOSAIC Runtime Engine,

if the developer uses the mOSAIC SDK to imple-

ment his applications and wants to delegate the re-

source management. Otherwise these services can be

invoked independently by the user application, if it

has the knowledge itself about how to use the provi-

sioning facilities in a custom way. Two set of func-

tionalities ar provided: methods which can be used

to get information about the booked Cloud resources

and services to build a speciﬁc workﬂow for resource

(re)negotiation. The identiﬁed actions will be avail-

able to the other components of the mOSAIC frame-

work and to the user application by two packages of

APIs. A component diagram representing the Provi-

sioning sub-system of the mOSAIC framework and

its connection with the other components is showed

in Figure 1. The CloudAgency is a multi agent sys-

tem that is responsible for SLA management: nego-

tiation, re-negotiation, monitoring. The Negotiation

Figure 1: Components diagram of the Provisioning Subsys-

tem.

Module that implements different policies for com-

posing the more effective SLA according to the appli-

cation requirements and the Vendors’ proposals. The

Vendor Module which can be implemented by differ-

ent technologies to support the interaction with Cloud

Platforms to acquire and to instantiate resources. The

Semantic Engine that is able to discover in the Net-

work new Cloud Services and Providers and to up-

date the list of available ones if they are supported by

mOSAIC. The Negotiator Interface and the Vendor

Interface are abstraction of the Negotiation Module

and the Vendor Module. They allow mOSAIC de-

velopers to implements different policies, without be-

ing aware about the agents technology and about the

Cloud Agency implementation.

4.1 Semantic Engine

One of the most challenging goals of the semantic en-

gine is to design and develop semantic-based Cloud

services discovery. This component searches in the

Network for Semantic description of Cloud services

and resources. WSDL, WSDLS-S, semantic annota-

tions are processed in order to discover new available

providers which are supported by mOSAIC. The Se-

mantic Engine uses the mOSAIC Cloud Ontology and

a reasoning module to identify he resource/service

type, the Cloud platform interface and the bindings

to the provider. An example can be represented by

a new Cloud Provider that offers a storage that can

be used by an Amazon S3 compliant interface. In

this case the new available service is published in the

DF (Directory Facilitator) and will be taken in con-

sideration by the Mediator Agent during the broker-

ing. Reasoning will be based on syntactic and struc-

tural schema matching. The input will be an on-

tology describing the Cloud knowledge that include

CLOSER 2011 - International Conference on Cloud Computing and Services Science

186

resources, techniques, technologies and services de-

scriptions. This can be achieved on the syntactic level

through a service description language (like WSDL),

or on the semantic level, through service ontologies

(like in OWL-S and WSDL-S). Semantic matching is

possible since services descriptions are semantically

annotated based on concepts from ontologies adopted

for modeling the speciﬁc domain of application. The

result of a semantic discovery is a new set of ex-

ploitable Cloud services and providers. Semanti En-

gine and Cloud Ontology are two speciﬁc outcomes

of the mOSAIC project and are not further addressed

here.

4.2 Cloud Agency

As it is shown in Figure 2 the Cloud Agency archi-

tecture is composed of different components. The

Agent Platform provides the environment for exe-

cuting agents and the basic facilities to manage the

agent life cycle. It also provides communication fa-

cilities which are used to implement agents interac-

tion protocols. A group of agents interact to pro-

vide the mOSAIC services which can be used by a

set of APIs. The DF is an agent whose presence is

mandatory in every agents platform designed accord-

ing to the FIPA(A. Grama and Sameh, 2000) stan-

dard. It provides yellow pages. Here it is used to pub-

lish the available services and resource provided by

the Vendor Agents. The AMS is an agent that man-

ages agent names and agent addresses. Also the AMS

is a mandatory component of FIPA standard agents

platforms. mOSAIC Agents are new components of

the agency which have been designed according the

framework requirements discussed above. A Client

Agent is in charge to receive request from the user,

from the application or from the mOSAIC runtime. It

acts as access point for the Cloud Agency services.

Figure 2: Component diagram of the Cloud Agency.

It receives the user requests and cooperates with the

Negotiator in order to broker Cloud services and re-

sources with the requested quality levels. The Nego-

tiator Agent receives from the Client an SLA Tem-

plate (a call for proposal) and splits the SLA Template

in different objectives which will be forwarded by the

Mediator Agent. It receives different proposals from

one or more Vendors. The Negotiator Agent uses the

Negotiator interface to parse the SLA Template, to

evaluate the proposals and to compose the ﬁnal SLA

to be returned to the Client Agent. The Mediator

is a broker that, for each call for proposal coming

from the Negotiator Agents, searches in the DF for

the available vendors which can answer to that call. It

contacts each Provider Agent and requests a bid for

the needed resources. Once it obtains responses from

Provider Agents, it assesses the following: the QoS

provided; the quality of the provider itself (request-

ing historical data from an Archiver Agent). After

he assessed the bid responses, they are forwarded to

the the Negotiatior that puts together a contract with

the winning providers on behalf of the client. The

Negotiator Agent could try to optimize the contract

by applying different trade-offs among performance,

availability or costs, but within the bounds speciﬁed

by the client. The Archiver Agent maintains statis-

tics about the mOSAIC system. It use Benchmark-

ing Agents to measure QOS parameters and to store

their values. It also can be used by external compo-

nents, such as the mOSAIC runtime, or the applica-

tions, to store and to load statistics. Benchmarking

Agents collect measures about the QOS parameters

to be monitored. They can perform measures execut-

ing into the Cloud, within each virtual machine. The

Monitoring Agent is responsible to use the statis-

tics in order to check the compliance of the current

performances with the Service Level deﬁned in the

SLA. It can also inform users’ own applications or re-

negotiation services about the real utilization of the

acquired resources in order to detect critical working

condition (e.g.: saturation or underutilization). The

Negotiator Interface will be implemented by the Ne-

gotiator Module, that represents the brain of the Ne-

gotiator Agent. It is used to update the received pro-

posal and combine them in order to generate the ﬁ-

nal SLA. The Vendor Agent talks on one side with

the Mediator and on the other side with the Cloud

Provider. Such as a wrapper, or a driver, it translates

the speciﬁc provider protocol into the uniform proto-

col used inside the mOSAIC framework. It accepts

bid requests from the Mediator and try to propose a

contract for the resources it can provide. The Ven-

dor Interface will be implemented outside the Cloud

Agency to support multiple Cloud technologies. The

Vendor Interface will be implemented by the Vendor

Module that is aware about a speciﬁc Cloud technol-

ogy and is able to interact with a particular provider in

order to ask for proposals, accept them and instantiate

AGENT BASED CLOUD PROVISIONING AND MANAGEMENT - Design and Prototypal Implementation

187

resources getting the bindings to be used by applica-

tions or by the mOSAIC runtime.

5 AGENTS’ BEHAVIOURS

The cooperation among agents has been designed

adopting well deﬁned Agents Interaction Protocols of

the FIPA standard. They have been combined as fol-

lows. The Client Agent implements a standard FIPA

Contract Net Interaction Protocol with the Negotia-

tor Agent. It submit a call for proposal using an SLA

Template that describes the application requirements

and gets the SLA proposal for acceptance or refusal.

The Mediator implements the standard FIPA Broker-

ing Interaction protocol. The sub protocol used to talk

with vendors is again the standard FIPA Contract Net

interaction protocol. The Vendor Agent implements

the Standard FIPA Contract Net interaction protocol

at Provider Side.

5.1 ClientAgent

The automata representing the behavior of the Client

Agent is shown in the Figure 3.

Figure 3: Client Agent.

• State0: it’s the ﬁrst state of our Client Agent. In

this state the agent is ready to receive application

requirements. The event 1 corresponds to the re-

ception of requirements and on its occurrence the

client send the Call For Proposal message to the

Negotiator Agent.

• State1: in this state the agent waits for a message

from the Negotiator and if it’s a propose message

the client gets the SLA Proposal, it’s represented

by event 2. Other events are:

1. 101 −→ the client receives a REFUSE message

2. 100 −→ the client receives a FAILURE message

3. 105 −→ the SLA in the message is unreadable

4. 200 −→ the protocol is incorrect

• State2: the client waits for the user to accept,

refuse or renegotiate the SLA. If the user agrees

the SLA is signed and sent to the Negotiator, event

3 is generated. Else if the user refuses the SLA

proposal, event 102 is generated. Finally if the

user wants to renegotiate the SLA event 6 is gen-

erated.

• State3: the client waits for a reply message from

the Negotiator. If the message is an inform mes-

sage than the client updates the SLA (it’s within

the message) and launches event 4. If it receives

a FAILURE the message event 103 is launched,

unreadable content is associated to the event 104

and unknown protocol/message is associated to

the event 201.

• State4: it’s the ﬁnal state, it informs that the

resources are available and starts the Monitor

Agent.

• State5: it shows the failure/refuse or unknown

messages received from the Negotiator. This state

launches the event 5.

5.2 Mediator Agent

The automata representing the behavior of the Medi-

ator Agent is shown in Figure 4.

Figure 4: Mediator Agent.

• State0: the Mediator waits for a proxy or a sub-

scribe message. When it receives a proxy mes-

sage it searches for the available vendor agents

who can provide the required resource/service and

launches event 3. Otherwise if it does not ﬁnd any

CLOSER 2011 - International Conference on Cloud Computing and Services Science

188

vendors it throws event 101. If it receives a mes-

sage with unreadable content event 103 is gener-

ated. If the Mediator receives a subscribe mes-

sage it sends the SLA that is within the message to

the vendor by an accept proposal message. Event

200 means an unknown message/protocol.

• State1: the mediator sends the objective to the

Vendor (event 2 is generated). If it cannot insert

the objective into the message, it throws the event

104.

• State2: in this state the Mediator waits for the

vendor’s reply. If it receives a propose message

the Mediator sends an inform done proxy mes-

sage to the Negotiator Agent and then it sends the

reply message sub protocol message to the Nego-

tiator. To this last message the Mediator attaches

the Vendor’s bid and launches the event 3. If it re-

ceives a refuse message, it throws an event 101. If

it receives an unknown message/protocol it gener-

ates an event 201.

• State3: the Mediator waits for the vendor’s re-

ply, if it is an inform done (this message contains

the SLA signed by vendor) the mediator sends an

agree message with SLA attached to the Negotia-

tor. The associated event is event 5. If the vendor

receives a failure message it generates event 107

or event 200 if the message is an unknown mes-

sage/protocol.

• State4: in this state the Mediator manages the un-

known message/protocol, failure message, refuse

message and events 103, event 104 (events associ-

ated with Input/Output error on message content).

5.3 Negotiator Agent

The automata representing the behavior of the Nego-

tiator Agent is shown in Figure 5.

• State0: the Negotiator waits for the CFP message

and extracts from the SLATemplate the objectives

list. Then it starts the event 1. Other events are:

1. 200 −→ unknown message/protocol

2. 101 −→ unreadable content of message

• State1: if all objectives are processed event 6 is

launched, else the Negotiator sends a proxy mes-

sage to the Mediator and launches the event 2.

Event 101 represents unreadable objective.

• State2: in this state the Negotiator waits for the

Mediator’s reply. If the reply is an agree mes-

sage the Negotiator launches the event 3, else if

the message is a refuse message we have event

100. If it receives an unknown message/protocol

we have event 200.

Figure 5: Negotiator Agent.

• State3: the Negotiator waits for a message from

the Mediator. The association between event and

message are:

1. 102 −→ f ailure not match

2. 4 −→ in f orm done proxy

3. 200 −→ unknownmessage/protocol

• State4: the Negotiator waits for the

reply message sub protocol from the Nego-

tiator. In this way it can update the archive. In

this case event 5 is launched. If the objective

within the message is unreadable it launches

event 104, if the message is unknown or out of

protocol, event 200 is launched.

• State5: this state produces the SLA and sends it

to the client by a propose message (event 7), if the

Negotiator cannot set the content of the message

it launches an event 105.

• State6: the Negotiator waits for the client’s re-

ply. If the reply is a cfp the Negotiator updates

the objectives list and launches event 12. If the

content of the cfp message is unreadable it gen-

erates event 105. When the negotiator receives

an accept proposal message (the content of this

message is the SLA signed by the client) it sends

the SLA to the Mediator by a subscribe message,

event 8 is generated. Event 200 represents an un-

known message/protocol.

• State7: the agent waits for the mediator’s reply.

If it receives an agree message (it contains the

SLA signed by client and vendor) it sends the

SLA to the client by an inform message, event

9 is launched. When this does not happen and

it receives a failure message, event 101 is gen-

erated. Event 200 represents an unknown mes-

sage/protocol.

AGENT BASED CLOUD PROVISIONING AND MANAGEMENT - Design and Prototypal Implementation

189

• State8: this state manages the unknown mes-

sage/protocol, failure, refuse message. In this

state a message is sent to the Client and to the

Mediator to restore their State0. Event 10 is

launched.

6 PROTOTYPAL

IMPLEMENTATION

A prototypal implementation of the Cloud Agency

has been developed using the JADE technology.

JADE is a FIPA compliant agent framework that sup-

ports development and execution of agent based ap-

plications. DF and AMS are provided by JADE as

mandatory components of the agent platform. Agents

can execute in a single instance of the Jade plat-

form or can be distributed on multiple machines. The

Cloud Agency can execute on the user machine or in

the Cloud. According to the model described above

agents exchange message to communicate among

them. Persistent information about resources, moni-

toring, transactions are stored in a database accessible

by a common interface. The services provided by the

agency can be used by a request-inform protocol. An

ACL message over http must be sent to the Client to

ask for a services and to get the response. A ﬁrst im-

plementation of the mOSAIC APIs for provisioning

has been provided in Java, but any language could be

used. At the bootstrap each available implementation

of Vendor Agent is created. The Vendor publishes

in the DF the services that he can provide. On the

other hand the client is able to look for all supported

resources that can be acquired. Actually we have a

Vendor for the Perf-Cloud platform (E. P. Mancini

and Villano, 2009) that is able to provide virtual ma-

chine as Cloud resource. Perf-Cloud is our own mO-

SAIC Cloud environment. It is under construction

and intends to offer common capabilities of the cur-

rent IaaSs. We are going to develop agent vendors for

other kinds of commercial and open platforms and for

heterogeneous cloud resources like storages. If the

user wants to use services of our prototype interac-

tively, we provide a GUI that allows to specify the

values for each relevant parameter of the resource to

be acquired. Actually the user can deﬁne the con-

ﬁguration of one or more virtual machines (memory,

number of CPU, connection speed) and submit the re-

quest. In Figure 6 the Jade Sniffer shows the mes-

sage exchange among Jade implementation of Client,

Mediator, Negotiator and Vendors. User’s request is

translated into an SLA template that follows actually

a simple model deﬁned for experimental purpose. The

SLA template is sent to the Negotiator Agent to begin

Figure 6: Implementation of the interaction protocol in

Jade.

a new transaction. The transaction is univocally iden-

tiﬁed by a code that is univocally and automaticaly

generated a this step. The code is used as conversa-

tion ID in all communications among agents which

collaborate to complete that transaction. The Nego-

tiator ask for an offer to the Mediator that satisﬁes

the requirements of the single objective (a virtual ma-

chine) requested by the user. In the current imple-

mentation the Mediator chooses one provider among

the available ones and forward the request. The re-

ceived offer is stored into the database and is returned

to the Negotiator Agent. The Negotiator module is

responsible combine offers in order to verify if all re-

quirements are satisﬁed and to build the best contract

for the client. Actually the negotiation algorithm is

very simple. The negotiator module checks that all

values of the parameters in the SLA template are less

equal than the ones of the offer. When this does not

happen the contract is built too, but a FAILURE is

notiﬁed. Additional information is attached to spec-

ify the reasons of the failure. The user can refuse

or accept the contract, also in a FAILURE status if

the failures are considered not relevant. In Fig. 7 it

is shown the graphical user interface that allows the

user to view the SLA, to get the status and to accept

or refuse it. When the SLA is accepted the negotia-

tor is notiﬁed and he ask to the mediator to conﬁrm

the offer and the allocate all the acquired resources.

At this moment the agent vendor in the described ex-

ample asks to the Perf-Cloud provider to allocate the

VM and to start it. When the VM is started the Perf-

Cloud provider returns the binding to the resource in

the form of a ssh URL and credentials. The bind-

ing is attached to the SLA and the contract turns into

a READY status. A reconﬁguration is supported ac-

cording to a simple withdraw-negotiate model. We

mean that if users need a more powerful machine they

must negotiate a new SLA. After that they must ask

CLOSER 2011 - International Conference on Cloud Computing and Services Science

190

Figure 7: Client Agent.

for a withdrawal of the old one. The agency allows to

the users to withdraw a single objective of a compos-

ite SLA if the provider supports this action.

7 CONCLUSIONS

In this paper we presented the design and the prototy-

pal implementation of agent based services for Cloud

resource provisioning. It is a component of a frame-

work that aims at supporting development of portable

multi-Cloud applications. A set of synchronous APIs

have been designed to be used within a Cloud Ap-

plication or by an interactive graphical user interface

in order to ask for heterogeneous Cloud resources

to multiple providers. APIs can be implemented as

XML requests over HTTP in order to be indepen-

dent from the chosen technology and to support the

utilization of different programming languages. The

current solution based on the Jade technology is al-

ready available. At the state the art negotiation is the

ﬁrst working service of the agency. Monitoring of re-

source utilization, checking of fulﬁllment of the SLA,

re-negotiation will be next services to be designed

and integrated. Furthermore a number of commer-

cial Cloud providers and open Cloud platforms will

be supported. Finally an expert system will allow se-

mantic discovery of new Cloud services and resources

in order to increase the market within which the nego-

tiator can look for, exploiting also intelligent services

composition.

ACKNOWLEDGEMENTS

This research is supported by the grant FP7-ICT-

2009-5-256910 (mOSAIC).

REFERENCES

A. Grama, V. K. and Sameh, A. (2000). Foundation for

intelligent physical agents.

A. Kertesz, G. Kecskemeti, I. B. (2009). An sla-based re-

source virtualization approach for on-demand service

provision. In VTDC09 - The 3rd International Work-

shop on Virtualization Technologies in Distributed

Computing.

B. Cao, B. L. and Xiang, Q. (2009). A Service-Oriented

Qos-Assured and Multi-Agent Cloud Computing Ar-

chitecture, volume LNCS 5931 of CloudCom 2009,

High Performance Computing: Paradigm and Infras-

tructure, pages 644–649. Springer-Verlag Berlin Hei-

delberg.

Cao, B.-Q., Li, B., and Xia, Q.-M. (2009). A service-

oriented qos-assured and multi-agent cloud comput-

ing architecture. In Jaatun, M. G., Zhao, G., and Rong,

C., editors, CloudCom, volume 5931 of Lecture Notes

in Computer Science, pages 644–649. Springer.

E. P. Mancini, M. R. and Villano, U. (2009). Perfcloud:

Grid services for performance-oriented development

of cloud computing applications. In Proc. of Emerging

Technologies for Next generation GRID (ETNGRID-

2009/WETICE-2009).

Keahey, K., Tsugawa, M., Matsunaga, A., and Fortes, J.

(2009). Sky computing. IEEE Internet Computing,

13:43–51.

R. Aversa, B. Di Martino, M. R. S. V. (2010). Cloud agency:

A mobile agent based cloud system. In Procs. 2010

International Conference on Complex, Intelligent and

Software Intensive Systems, pages 132–137.

R. Buyya, C. S. Yeo, S. V. J. B. and Brandic, I. (2009).

Cloud computing and emerging it platforms: Vision,

hype, and reality for delivering computing as the 5th

utility. 15(6):599–616.

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

economy. In Bellavista, P., Chang, R.-S., Chao, H.-C.,

Lin, S.-F., and Sloot, P., editors, Advances in Grid and

Pervasive Computing, volume 6104 of Lecture Notes

in Computer Science, pages 395–406. Springer Berlin

/ Heidelberg.

X. You, X. Xu, J. W. and Yu, D. (2009). RAS-M: Resource

Allocation Strategy Based on Market Mechanism in

Cloud Computing. 2009 Fourth ChinaGrid Annual

Conference.

AGENT BASED CLOUD PROVISIONING AND MANAGEMENT - Design and Prototypal Implementation

191