![](bg2.png)
services hosted on several Cloud providers by hiding
their underlying technical details; (3) It finds the
most suitable Cloud resources taking into account of
user requirements specified by SLA.
The rest of this paper is organized as follows: in
the next section we discuss prior works related to
Cloud service brokering. We also identify how our
work differs from related work. Section 3 presents
the generic architecture of the broker. In section 4
and section 5 we propose a simulation environment
for the broker and present first evaluation results.
Section 6 concludes the paper with a brief summary
and describes our future research directions.
2 RELATED WORK
The problem of multi domain service brokering in
Cloud has received a lot of attention in academia and
industry in the recent years.
(Buyya et al., 2010) presented the architecture of
a federated Cloud computing environment named
InterCloud to support the scaling of applications
across multiple vendor Clouds. The idea behind their
introduced federation concept is to enhance Cloud
providers provisioning capabilities in case of sudden
spikes in workload by leasing available
computational and storage capabilities from other
Cloud service providers. The main components of
the proposed architecture are a Cloud Broker, a
Cloud Exchange and a Cloud Coordinator. A client
initiates a Cloud broker in order to meet the
specified QoS targets, whereas Cloud Coordinators,
acting as gateway between their internal datacenters
and external Clouds, publish their services to the
federation. Cloud Exchange acts as a mediator
bringing together service providers and customers. It
aggregates infrastructure demands from the
application brokers and matches them against the
available resources published by the Cloud
Coordinators. The proposed architectural framework
is still a research vision and its development is
planned in context of the CLOUDBUS
6
project.
However, the simulation results showed that the
federation approach brings significant benefits to
user’s application performance.
(Theilmann et al., 2010) presented a flexible
framework for multi-level SLA management within
Clouds developed in context of the SLA@SOI
2
EU
project. The core framework consists of a Business
Manager and an SLA Manager. The Business
Manager controls all the relations between
customers and providers, whereas the SLA Manager
deals with all the SLA related issues including
negotiation, provisioning and monitoring. Besides
the core framework, a domain-specific Service
Manager provides management functionalities for
the SLA Manager by interfacing the native
provisioning system. The main contribution of the
SLA@SOI framework is that the service quality can
be predicted and enforced at run-time through an
automated SLA management.
(Metsch et al., 2010) implemented a prototype
broker architecture based on a combination of the
core SLA@SOI framework and the RESERVOIR
1
framework. This latter allows an easy and on-
demand provisioning of virtualized infrastructure
resources within a federated Cloud platform. In their
presented architecture, the core SLA@SOI
framework acts as an SLA-based broker, whereas
the RESERVOIR sites act as SLA@SOI third party
providers and candidates for SLA provisioning. The
interoperability between the two Cloud frameworks
is achieved by implementing a standardized Service
Manager interface using the Open Cloud Computing
Interface API (OCCI, 2011).
(Kertesz et al., 2011) investigated the use of
autonomic computing principles for resource
management and SLA enforcement in Cloud
environments. They proposed an SLA-based Service
Virtualization (SSV) architecture, which is built on
three main components: a Meta-Negotiator
responsible for agreement negotiations, a Meta-
Broker for selecting the proper execution
environment and an Automatic Service Deployer for
service virtualization and on-demand deployment.
As the first industry driven project, the TM
Forum
3
Cloud Service Broker Catalyst explored the
role of a value-added service broker by
demonstrating a proof of concept for a trusted and
transparent Cloud management platform.
A market analysis of the current commercial
Cloud broker solutions shows that most products
concentrate on the aggregation and mediation of the
services deployed on well-known public Cloud
providers by providing integrated management and
monitoring interfaces. From the few products
offering additional brokering features, we refer to
SensibleCloud
4
and CloudSwitch
5
. While the former
offers an automated SLA based multi-Cloud
management, the latter allows customer to select the
________________
1
http://www.reservoir-fp7.eu//
2
http://www.sla-at-soi.eu/
3
http://www.tmforum.org
4
http://www.sensiblecloud.com/
5
http://www.cloudswitch.com
6
http://www.cloudbus.org
SLABASEDSERVICEBROKERINGININTERCLOUDENVIRONMENTS
77