eChallenges e-2009 Conference Proceedings
Paul Cunningham and Miriam Cunningham (Eds)
IIMC International Information Management Corporation, 2009
ISBN: 978-1-905824-13-7
A Lightweight Semantic Bridge between
Clouds and Grids
Ioannis KOTSIOPOULOS1, Henar MUNOZ FRUTAR2,
Bastian KOLLER3, Stefan WESNER3, John BROOKE1
1The University of Manchester, Kilburn Building, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 161 2756814, Fax: +44 161 2756204, Email: john.brooke@manchester.ac.uk
2Telefónica Research and Development, C/ Emilio Vargas, 6, Madrid, 28043, Spain
Tel: +34 913 374000, Fax: +34 913 374004, Email: henar@tid.es
3Hochleistungzentrum Stuttgart, Universität Stuttgart,
Nobelstraße 19, Stuttgart 70771, Germany
Tel: +49 711 6856589, Fax: +49 711 68565832, Email: {koller, wesner}@hlrs.de
Abstract: Business users want to benefit from the advanced functionality offered by
Grid middleware as well as from low cost computing resources offered by Cloud
providers. Service Level Agreements (SLAs) are central to the establishment of
electronic contracts between two entities. These requirements raise semantic
interoperability issues caused by the lack of well-defined vocabularies. We propose a
solution via the use of a lightweight annotation mechanism called SASLA and a set
of modular ontologies. In this paper, we will discuss how a semantically enabled
Grid infrastructure can use SASLA to dynamically provision resources either from
the locally available resources or from resources offered by Cloud Providers.
1. Introduction
The objective of this paper is to analyse the use of a lightweight annotation mechanism of
Service Level Agreements that allows the extension of current Grid Infrastructure with
resources provided by Cloud providers in a dynamic and automated manner. This will be
necessary for future eBusiness platforms, as the “Software as a Service” paradigm requires
multiple interactions between Business Clients, Service Providers, Grid Providers and
Cloud Providers.
This multi-dimensional interaction very frequently encounters, among other technical
challenges, serious semantic interoperability problems. These problems mainly occur when
the participating entities interpret the terms being used during this interaction in a different
manner. In our case, Business Clients use or understand a different vocabulary from the
engineers in charge of the Grid Infrastructure. Moreover, the Grid terminology is possibly
different from the terms being used by Cloud Providers such as Amazon. If one adds to this
the multi-lingual aspect of this interaction, then we have a truly heterogeneous conceptual
environment where automation seems impossible without a semantic bridge.
The outcome of a business interaction is summarised by a contract which explicitly
defines the terms of the agreement. A major part of such an agreement can be represented
in a Service Level Agreement (SLA), these can be seen as an electronic representation of
contractual bindings between business parties. In this paper, we will discuss the role of
semantics with respect to SLAs and the related challenges and will propose an
infrastructure that uses the additional semantics to link high level business decisions to low
level resource provisioning decisions. However, Grid Computing was built around the
notion of cross-boundaries collaborations based on open standards while Cloud Computing
reinforces the client-server paradigm with relatively limited support for open standards. In
Copyright © 2009 The Authors www.eChallenges.org Page 1 of 8

that respect, the role the proposed business oriented Grid platform, is to provide the tools
and methodologies that will allow business users to take advantage of the both Grid and
Cloud computing paradigms.
2. Objectives
We assume that the scenarios of using compute and storage Clouds only to access company
internal resources or via a client server configuration are too limited. The concept of cross
organisational collaboration introduced by the Grid community in the so called Virtual
Organisations [1] is highly relevant for many applications, in particular if specific skills or
specific resource properties of each participant make the collaboration necessary to achieve
a goal or to compete with competitors in the market. However implementing a distributed
application, built from Grid Services delivered in a “Software as Service” manner, utilising
both physical resources and virtualized Cloud resources is currently a very hard problem.
Apart from the lack of standardized interfaces to access Cloud resources and the wide range
of different Grid middleware and corresponding services realised on top of them,
interoperation is hard owing to the fact that the available XML based standards such as
WS-Agreement [3], WSDL[2], etc. address syntactic issues only and exclude semantic
ones. A typical example is WS-Agreement, which does not differentiate between different
types of users or roles in the company (business, technical, scientific, etc). Moreover, the
specification [3] itself mentions that it is not part of its goals to define the meaning of terms
related to specific domains or even for specific metrics for measuring Quality of Service
terms. In fact, the specification only defines the structure of the information and not the
domain vocabulary that will be used. As a result, the establishment of agreements that
require the participation of Cloud and Grid providers for the provision of a service for
Business Clients requires additional semantic annotation of services. This paper presents an
approach for achieving semantic interoperability with a focus on SLAs in the form of a
lightweight annotation mechanism based on the SAWSDL [3] called SASLA (Semantic
Annotated Service Level Agreements) and use of modular ontologies that allow different
types of users to create agreements using only concepts with which they are familiar.
The proposed approach can be applied for both cross-organisational communication of
SLAs and their interpretation and for mediating between the externally communicated
SLAs and internal (typically more low level) descriptions of tasks. Such descriptions
contain details about how the SLAs are enacted on the local heterogeneous infrastructure or
in mixed mode partially with external resources e.g. when some resources are provided by a
Cloud Provider and cover a wide range of different hardware systems.
3. Methodology
Our approach is based on a pragmatic view of how the distributed computing world
operates and on the demands of current business users. Our methodology is twofold:
a) Conceptualisation Methodology
The idea of using ontologies for enhanced SLA handling is not new, but its realization
failed often due to the immaturity of the semantic concepts/technologies. Projects like e.g.
NextGRIDi thought about integrating ontologies for negotiation, but quickly identified that
at this stage of the project (2004) it was to early for adoption of Semantics to the Grid.
However, times have changed and now there are numerous annotation styles that could
be applied for the annotation of WS-Agreement documents. One of the most popular is
SWAPS (Semantic WS-Agreement Partner Selection), which was presented by Oldham et
al. [8] and aims to enable better syntactical matching for intelligent partner selection using
WS-Agreement. This approach foresees the restructuring of parts of the WS-Agreement
schema, as well as adding new tags to it, so as to provide an invasive approach for
Copyright © 2009 The Authors www.eChallenges.org Page 2 of 8

enhanced negotiation. Obviously the adoption of a proposal that breaks the existing
specifications and aims to replace it would have limited chances to be accepted within the
community as many specifications have inter-dependencies. Consequently the proposed
approach is based on an annotation style amending the existing specification accepted
within the Grid community rather than replacing it. SAWSDL [3] is an example of such an
approach and offers the opportunity to annotate an XML Schema based specification (in
this case WSDL [9]) without “breaking” the specification.
b) Semantic SLA negotiation and Outsourcing
SLA Negotiation in its entirety should be usable both with and without semantic
enhancements. Any proposal of how to enhance SLA Negotiation semantically should be
non-invasive to the protocols or schema used, to allow for flexible usage and optional
addition of semantic information. Besides this, a strong emphasis should be given to the
different levels of negotiated terms, from business level to the plain infrastructure level.
Outsourcing is required when there are inadequate local resources to meet the terms of an
SLA. Cloud providers are dynamically discovered and new resources are added to the
system on demand, while the semantic infrastructure ensures semantic interoperability
problems are addressed.
4. Semantics in the SLA Lifecycle
Terminology mapping is the key to success of Service Level Agreements in eBusiness.
Recent solutions were based on the assumption that both the Service Customer and Service
Provider share a common domain vocabulary, which then usually leads to Service Level
Agreements, containing terms on a plain infrastructure level (e.g. CIM [10]).
This is, from a business viewpoint, simply unacceptable since in most cases a Customer
cannot define its requests on a infrastructure level, as she does not know the infrastructure
of the Provider (furthermore he usually does not want to know it). On the other side,
Service Providers do not want to publish their infrastructure capabilities for reasons of
confidentiality.
Having said this, it is clear that the communication between the two business entities
needs to be based on top of a business level terminology. This therefore implies a burden on
the Service Provider to map statements from this high business level, down to its lower
system level to understand the implications of such requests on his system and its ability to
fulfil such a service. In general, this level approach provides three main problem domains:
• High Level to High Level:
In this case, the level of terms should be the same, but usage of the same terms for
the same parameter is not ensured by that. Whilst someone would talk about
“Duration” the business opponent could talk about “Estimated Execution Time”,
both meaning the same thing. This is a type of translation problem, which could be
solved by using ontologies
• High Level to Low Level:
This case is settled within the Service Provider domain. Having a Customer asking
for Service XYZ with parameter “completion time = 1 hour” is not directly
convertible as it also concerns time required for deployment and provisioning of the
service in the Service Provider infrastructure. This is a mapping problem from the
business world requirements to the lower level infrastructure parameters which is
currently performed by system administrators.
• Low Level to Low Level:
This case occurs, when both the Customer and the Service Provider are operating on
the plain infrastructure level but their terminology is different. A typical example is
the outsourcing of capabilities of a Service Provider to a Cloud Provider. In this
Copyright © 2009 The Authors www.eChallenges.org Page 3 of 8

case, the Service Provider gets into the role of the Customer and the Cloud Provider
is the Service Provider. This could also be solved by infrastructure level ontologies.
5. Business Case
In the discussion above, an implicit assumption is that cross-organisational collaboration is
the key focus and currently realised solutions using Clouds and company internal resources
or in a client/server fashion are only a subset of possible solutions. This assumption is
based on experiences from the BEinGrid [11] and BREIN [6] projects. This assumption can
also be justified by the observation that current Cloud providers deliver mostly virtualized
hardware addressing only the issue of cost savings for significantly varying demand for
computation. The wider problem of cross-organizational collaboration is driven by the
need to share knowledge and capabilities between partners. For our business case, we look
at an application provider offering simulation services inspired by the engineering testbed
of the BREIN project. The clients of the application provider want to define certain high
level Quality of Service terms which are mainly related to the specific applications that they
want to use. For example, the user wants to define the SLA in terms of the problem size
(e.g. the number of nodes in the compute mesh), the expected accuracy of the result to
which the simulation converges and the maximum waiting time for starting the simulation.
In order to reduce complexity in the SLA typically not all variations of the parameters
are allowed but are summarized in packages labeled, for example, as Gold, Silver, Bronze,
terms which have meaning in the language of the client. In a pure Cloud scenario, the
application provider would provide the application in the Cloud to a customer and would
rely on the Cloud provider to provide increases or decreases in computational power as
needed. However, the scenario is typically more complex since confidential information is
involved in the process. For example, before a large computational fluid dynamics (CFD)
simulation (as typically used in the automotive industry) can be started a pre-processing
step needs to be performed. This step includes the generation of the compute mesh from the
CAD data of several elements of the car design, including material properties used for
certain elements in order to provide realistic constraints on their behavior. Since this is
unlikely to done by an external resource provider, the overall simulation workflow typically
contains several providers. Some of them are internal (e.g. the CAD data provider) whereas
others such as the provider of computational resource can be external. So, beside the
contract between the consumer and the service aggregator, several contracts need to be
established between the providers and/or the providers and the aggregator. It is
straightforward to infer that the SLAs with the providers should correlate with the service
level agreed between the provider and the consumer. This model also allows that provider
can rely on services of further sub-providers. So, for example, HLRS as an HPC provider
could deliver compute services with different levels of performance and decide to outsource
the low end computing to a Cloud provider as needed and allowed within the SLA. So this
would mean that a third level of SLA should be signed, with terms derived from the Cloud
provider vocabulary, between HLRS and the Cloud provider.
6. Developments/Results
Our methodology is implemented with the development of the SASLA specification along
with a set of ontologies that capture the business case and can be used for the annotations of
the SLA documents. Moreover, a set of components are developed in order to demonstrate
how SASLA can be used in practice to bridge between business users, Grids and Clouds in
an outsourcing scenario.
Copyright © 2009 The Authors www.eChallenges.org Page 4 of 8

6.1 The Semantic Annotated SLAs and BREIN Ontologies
SASLA is a specification that defines how semantics can be used for the annotation of
Service Level Agreements based on the WS-Agreement document specification. The
annotations are, in reality, references to commonly agreed conceptual models captured in a
machine understandable format called an ontology [4]. To fully implement our proposal, we
propose a set of ontologies that can be used in conjunction with SASLA.
The ontologies developed in the BREIN project [12][13] provide an example of a
modular ontology framework. The BREIN core ontologies act like an upper ontology,
presenting high-level concepts for generic business Grid functionality. The core ontologies
are also split according to the different needs of the business side and the technology side.
The BREIN Business Ontology is populated with terms needed for processes such as
Service Discovery and SLA Negotiation. The Business Ontology builds upon the OWL-S
and the S-BPMN ontology in the description of services and business processes
respectively. The BREIN Technology Ontology describes the technological concepts used
in the BREIN framework. The Technology Ontology builds upon the Grid Resource
Ontology [14] and Semantic OGSA [16] and allows service providers to describe their
available resources, the tasks to be executed, and their schedules.
Domain ontologies extend these core ontologies with domain specific parts required to
describe service profiles, resources and properties in the respective domain. BREIN domain
ontologies are split into two types: domain-specific service and resource ontologies. Service
ontologies describe the business and functional aspects of services, thus they are used by
both client and service provider. The resource ontologies describe the entities belonging to
the internal environment of the service provider, which support the provision of the
services.
6.2 The Proposed Architecture
The architecture described in this section addresses the problem of translating high level
metrics described in SLAs between business customers and service providers into concrete
low level SLAs between a service provider and a Cloud provider. Figure 2 (below)
demonstrates how the BREIN infrastructure components use the annotations found on the
SA-SLA documents. More specifically, an initial SA-SLA document is dealt by the
semantically aware SLA management infrastructure and more specifically from the
Semantic Resource Lifecycle Management (SRLM) component, to schedule the job to
appropriate resources. Semantically aware components are components that can consume
rich metadata by using the semantic capabilities offered by a set of semantic provisioning
components found in the underlying layer of the BREIN architecture. In that sense SRLM
uses the Business Ontology to unambiguously interpret the business terminology used by
the business customer. Such terminology can contain concepts related to timing or duration
of a task, pricing, penalties, as well as other Quality of Service guarantees.
Once the business terms are interpreted by the BREIN infrastructure, SRLM uses a set of
business rules that determine whether to use the local resource to schedule the job or
outsource it to a Cloud Provider such as Amazon. The business rules obviously reflect the
terms of an SLA giving, for example, higher priority to an SLA with high penalties whilst
other SLAs, e.g. for student experiments, might be treated as low priority tasks. The
terminologies of a Grid Provider and a Cloud provider are usually different, hence the
outsourcing task was usually done manually. However, the use of the BREIN Virtual
Engineering ontology can be used to mediate between the two parties. For example, an EC2
compute unit can be clearly defined by the terms of the ontology, making it easier for
SRLM to decide how many EC2 compute instances are required. Apart from the annotation
Copyright © 2009 The Authors www.eChallenges.org Page 5 of 8

of SLA, one could use the same methodology to annotate Virtual Machine configurations,
making the task of resource deployment much easier. The task of finding appropriate
resources (in terms of both software and hardware) is assigned to the Semantic Resource
Broker (SRB). SRB uses the Service Offer Discovery component to discover SASLA
Templates that match a set of requirements defined by the SRB. Once the resources are
found, they are instantiated by the Cloud Manager, and the corresponding jobs are handled
by Job Execution Service.
Figure 1: BREIN Architecture Mediates between Clouds and Grids
One can assume that the complexity of the mapping on the 3rd or further levels
decreases as we get closer and closer to raw resources, e.g. from resource level SLAs at
HLRS and the one described by Amazon in EC2 [15]. So the major challenge is to mediate
between SLAs across providers of complex services (not now tightly coupled to hardware)
and to realise a mapping from high level SLAs expressed on business or customer terms
down to infrastructure terms. The automatic translation of high level to low level technical
details requires a sound understanding of the relationships between them. This task is
carried out by a set of interrelated ontologies that bridge business, technical, service and
resource information. These ontologies, along with the SASLA and a set of supporting
tools, can create.
The BREIN ontology development has been focused toward analyzing the ontology’s
expressive power a new way of bridging Clouds, Grids and business users who want to use
Software as a Service accepting that the extra resources necessary to process semantic
information may reduce efficiency in performance. . We try to reduce this efficiency loss,
thus the SA-SLA annotation mechanism uses a lightweight approach, and the ontologies
have as few rules as possible, to reduce the time in providing answers by reasoners and rule
engines. In our scenarios, the advantages of improving interoperability in the integration of
Cloud and Grid services outweigh the disadvantage in performance reduction.
Copyright © 2009 The Authors www.eChallenges.org Page 6 of 8

7. Business Benefits
Our approach for annotating SLAs is driven by two major design goals (1) to maintain the
compliance with existing specifications (2) to allow the application of a potentially
unlimited number of provider specific ontologies.
The first goal is to permit a ramp up phase in the uptake of semantically annotated
SLAs. This means that for a certain period of time one cannot assume that all consumers of
provided services are able or willing to interpret the provided annotations. The
interpretation of the annotation terms is seen as optional but still keeps a consumer locked
to a certain provider and its SLA description. So the clear benefit of the SASLAs standard,
from a customer viewpoint, is the ability to consume services bound to certain quality
constraints from a larger group of providers which using different terms and formats to
describe resources. The benefit for providers lies in avoiding the provision of many
different flavours of SLA descriptions for different customers and also in enabling a
provider to acti itself as a consumer of another service provider if internal or external. This
hierarchical structure of the collaboration, where a provider of a complex service relies on
other service providers for different parts of a total service provision, is not conceptually
different from a simple consumer to provider scenario. Consequently the same benefits
apply and providers consuming other services also have the ability to switch between
providers using different SLA formats as needed.
The second goal is to allow a provider to freely choose the ontologies applied for
describing internal SLAs and the resultant mapping process enables each provider to realise
a similar service in a completely different way. This freedom in realising the service raises
the possibility of outsourcing some or all parts of the provided services to other providers.
In particular a Cloud Provider might provide parts of the required IT infrastructure. This
allows providers to react quickly to business opportunities, by having a potentially
unlimited number of providers on one hand for dynamically aggregating service offers
beyond the capabilities of their own IT infrastructure and on the other hand to realise new
services by combining internal and external services to develop new products quickly. The
model even allows a service provider that aggregates services to operate completely without
self-owned infrastructure.
The major business motivation for the aggregation of services and the bundling of
several services into a single complex service is to save costs in IT infrastructure capable of
handling peak demand but which is therefore more generally underused. This is achieved
by a more dynamic provisioning environment, able to react more quickly to changing
demands. It is already obvious that the provision of computing and storage Cloud services
has become a commodity offered by a couple of providers with quite marginal differences.
Additionally Open Source projects such as Open Nebula [17] that mimics the Amazon EC2
[15] interface will allow even more providers to enter the market of virtualized resource
provision. This covers not only low and mid range services but also performance oriented
services [18]. Consequently to realise an appropriate spread of workload one could aim for
a cost leadership approach by reducing the resource provisioning costs. One could also aim
to provide aggregated services where the knowledge of how to efficiently aggregate
services and the use of specific services only provided internally are combined. The key
element to reduce the risk for the provisioning of aggregated services is to firstly bind
providers to SLAs and secondly to have a large list of potential providers allowing quick
reaction to underperformance on SLA conformance by switching providers on the fly.
In this manner, a new business role as the Service Integrator arises in the market, that
links together customers and service providers, thus providing infrastructure services (like
computation or storage services) to final customers. Moreover, infrastructure providers
(both Grid and Cloud providers) can take advantage of the more efficient usage of resources
Copyright © 2009 The Authors www.eChallenges.org Page 7 of 8

and outsourcing capabilities available by accessing a wider pool of users and by business-
to-business trading in resource.
8. Conclusions
The main lessons of our work are as follows. Firstly it is necessary to develop a thorough
understanding of the processes involved in the use of resources at a business and at a
resource provider level. This was one of the most time-consuming parts of the work.
Secondly it is vital to have a modular approach to developing the ontology so that it can be
flexibly deployed in different business and resource provider domains. Thirdly, that it is
important to build on current standards proposals to provide solutions that can command
agreement, since both business users and resource providers need guarantees of stability in
deployment that are best served by an evolutionary approach. Developing radical proposals
that break current deployment may be of theoretical interest but is unlikely to be of
practical use. We believe the work we describe lays the foundations for interoperation of
Grids and Clouds and their integration into business processes. Our future effort will be
directed towards optimisation of implementation and engineering reliability and ease of use.
References
[1] B. Koller, L. Schubert, H. Quyen, H. Mersch, P. Wieder, P. Hasselmeyer, "Implementing an SLA
Negotiation Framework", Proceedings of eChallenges 2007.
[2] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana, “Unraveling the Web
Services Web: An Introduction to SOAP, WSDL, and UDDI,” IEEE Internet Computing, vol. 6, no. 2,
2002, pp. 86-93.
[3] GRAAP-WG, “Web Services Agreement Specification (WS-Agreement),” OGF Document GFD.107,
Eds. A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig, T. Kakata, J. Pruyne, J. Rofrano, S.
Tuecke, M. Xu, September 2005
[4] K. Jacek, V. Tomas, B. Carine, and F. Joel, “SAWSDL: Semantic Annotations for WSDL and XML
Schema,” IEEE Internet Computing 1089-7801, vol. 11, no. 6, 2007, pp. 60-67.
[5] T.R. Gruber, “Towards Principles for the Design of Ontologies Used for Knowledge Sharing,” Formal
Ontology in Conceptual Analysis and Knowledge Representation, 1993.
[6] Laria et al. – D4.1.3 – Final BREIN Architecture, Public Deliverable of the BREIN project, 2009
[7] H. Ludwig, A.K., A. Dan, R.P. King, R. Franck, Web service level agreement (WSLA) language
specification. 2003, International Business Machines Corporation (IBM).
[8] Nicole Oldham, Kunal Verma, Amit Sheth, and Farshad Hakimpour. Semantic WS-Agreement partner
selection. In WWW ’06: Proceedings of the 15th international conference onWorldWideWeb, pages
697–706, New York, NY, USA, 2006. ACM.
[9] Web Services Description Language (WSDL) 1.1: http://www.w3.org/TR/wsdl
[10] Common Information Model (CIM) Standards: http://www.dmtf.org/standards/cim/
[11] BEinGRID - Better Business Using Grid Solutions - Eighteen Successful Case Studies Using Grid,
http://www.beingrid.eu/fileadmin/beingrid/pr_folder/Case_Studies/BEinGRID_Case-
Studies_Booklet_VF.pdf, last accessed 15.05.2009
[12] Kotsiopoulos et al. – D3.2.6 - Final Report on BREIN-Scenario Ontologies, Public Deliverable of the
BREIN project, 2009
[13] Kotsiopoulos et al. – D3.2.5 - Final Report on BREIN-Core Ontologies, Public Deliverable of the
BREIN project, 2008
[14] Grid Resource Ontology, http://www.unigrids.org/ontology.html
[15] Amazon Inc., Amazon Elastic Compute Cloud (Amazon EC2), http://aws.amazon.com/ec2/, 2008.
[16] Corcho, O., et al, An overview of S-OGSA: a Reference Semantic Grid Architecture. Journal of Web
Semantics, 2006. 4(2): p. 102-115.
[17] Open Nebula, http://www.opennebula.org/
[18] Cluster On Demand – Access powerful Linux clusters from the internet, http://clusterondemand.com/

i The NextGRID Project, Priority IST-2002-2.3.2.8. Web site, <http://www.nextgrid.org/>
Copyright © 2009 The Authors www.eChallenges.org Page 8 of 8