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
Cloud, Agents based services, SLA negotiation, Resources provisioning.
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 configuration that satisfies 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 fulfillment and eventually re-negotiations.
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 ( 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 benefit 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 definition 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 fulfillment 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 first 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 fulfillment, the monitor-
ing of resource utilization and eventually necessary
re-negotiations. Even if security is a mandatory issue
Venticinque S., Aversa R., Di Martino B. and Petcu D..
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 certifi-
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 fifth section we provide de-
tails about the multi agents model we have designed.
Finally prototypal implementation and APIs are de-
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-
files 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 define 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 first 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-
efit 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 influence 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-
SLA Negotiation with multiple Cloud providers is
a first 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
reconfigure 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-
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; redefinition of SLA pa-
rameter; negotiation of boundaries within which the
SLA can be re-negotiated at the same price or with a
pre-defined 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 profit, to not exceed in
resource allocation beyond the capability of fulfill the
agreements. On the other hand, the user, who has con-
flicting 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.
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 specific workflow for resource
(re)negotiation. The identified 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-
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
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 specific 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 specific outcomes
of the mOSAIC project and are not further addressed
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 final 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 specified
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 defined 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 fi-
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 specific 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 specific Cloud technol-
ogy and is able to interact with a particular provider in
order to ask for proposals, accept them and instantiate
resources getting the bindings to be used by applica-
tions or by the mOSAIC runtime.
The cooperation among agents has been designed
adopting well defined 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 first 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-
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 final state, it informs that the
resources are available and starts the Monitor
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 find any
CLOSER 2011 - International Conference on Cloud Computing and Services Science
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
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-
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-
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
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 first 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 define the con-
figuration 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 defined for experimental purpose. The
SLA template is sent to the Negotiator Agent to begin
Figure 6: Implementation of the interaction protocol in
a new transaction. The transaction is univocally iden-
tified 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 satisfies
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 satisfied 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
notified. 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 notified and he ask to the mediator to confirm
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 reconfiguration 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
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.
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
first working service of the agency. Monitoring of re-
source utilization, checking of fulfillment 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
This research is supported by the grant FP7-ICT-
2009-5-256910 (mOSAIC).
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
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-
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-
Keahey, K., Tsugawa, M., Matsunaga, A., and Fortes, J.
(2009). Sky computing. IEEE Internet Computing,
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