![](bg7.png)
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 finite-
state machines: the finite-state machine related to
the negotiation model and necessary for the negotia-
tion implementation and the finite-state machine WS-
Agreement standard. This model defines 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 briefly illustrate
what are the features that mOSAIC offers. The inter-
ested reader can find 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 predefined 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
defined 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-defined 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, defined 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 first one contains the parameters to be used for
evaluation of the policy, the second one is a logical
expression whose variables are the parameters defined
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-
SLANEGOTIATIONANDBROKERINGFORSKYCOMPUTING
617