A Template Description Framework for Services as a Utility for Cloud

Brokerage

Li Zhang

, Frank Fowley

and Claus Pahl

Northeastern University, Software College, Shenyang, China

IC4, Dublin City University, Dublin, Ireland

Keywords:

Cloud Broker, Service Brokerage, Service Description, Reference Architecture.

Abstract:

Integration and mediation are two core functions that a cloud service broker needs to perform. The description

of services involved plays a central role in this endeavour to enable services to be considered as commoditised

utilities. We propose a conceptual framework for a cloud service broker based on two parts: a reference

architecture for cloud brokers and a service description template that describes the mediated and integrated

cloud services. Structural aspects of that template will be identiﬁed, formalised in an ontology and mapped

onto a set of sublanguages that can be aligned to the cloud development and deployment process.

1 INTRODUCTION

Organisations like Gartner and NIST (Gartner, 2012;

NIST, 2013) have identiﬁed cloud service brokerage

as a key concern for future cloud technology develop-

ment and research. Cloud brokerage refers to the cus-

tomisation, aggregation and integration of cloud ser-

vices, possibly by third parties. Here, we investigate

some conceptual problems towards the implementa-

tion of a cloud brokerage solution. Integration and

mediation are two core functions that a cloud broker

needs to perform. We propose a conceptual frame-

work for a cloud broker based on two parts: a refer-

ence architecture for cloud brokers and a service de-

scription template that describes mediated, i.e. cus-

tomised, aggregated or integrated cloud services.

Our conceptual reference architecture will extend

the NIST cloud architecture speciﬁcation, taking on

board the NIST and Gartner categorisations. The

NIST architecture is not sufﬁcient as a common ref-

erence framework, as it does not detail how integra-

tion between services – horizontallybetween different

providers and vertically between the different cloud

layers – can be achieved. Equally do current service

modelling and speciﬁcation approaches (Pahl 2005)

not cover adequately the vertical integration across

the cloud layers infrastructure (IaaS), platform (PaaS)

and software (SaaS) (Konstantinou 2009; Mietzner

2008; Rodero-Merino 2010). We deﬁne here a con-

ceptual model for a service description template that

would allow the two dimensions to be covered. Struc-

tural aspects of that template will be identiﬁed, for-

malised in an ontology and mapped onto a set of sub-

languages that can be aligned to the cloud develop-

ment and deployment process.

The paper is organised as follows. The next Sec-

tion 2 deﬁnes the reference architecture. The follow-

ing Section 3 introduces and deﬁnes the service tem-

plate. As this concept plays a crucial role, it will be

investigated in more depth. Furthermore, we outline

a solution architecture for an implementation based

on open-source cloud platforms in Section 4 and also

discuss some trends, before ending with related work

(Section 5) and some conclusions (Section 6).

2 ARCHITECTURE

FRAMEWORK

As already explained, we propose a conceptual frame-

work for an automated architecture for a cloud service

broker based on two parts: a reference architecture for

cloud brokers compliant with the NIST proposal and a

service description template model that describes me-

diated cloud services. While descriptions for Web ser-

vices exist in the format of WSDL, or any semantic

extension like SAWSDL or WSMO, some speciﬁc re-

quirementsfor the cloud context need to be addressed.

Enabling cross-layer description of concerns and fa-

cilitating cloud provisioning and conﬁguration is re-

quired (Fehling 2011). Service description templates

Zhang L., Fowley F. and Pahl C..

A Template Description Framework for Services as a Utility for Cloud Brokerage.

DOI: 10.5220/0004789300600069

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 60-69

ISBN: 978-989-758-019-2

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

(and their instances) are the core artefacts that are

used to describe, select, deploy and manage the dif-

ferent cloud resources, which are made available as

services in an independent way.

2.1 Architecture and Broker Types

Figure 1 describes the high-level architectural setting.

We follow Gartner here in the separation of integra-

tion, customisation and aggregation functions of a

broker. The broker sits between the consumer and a

range of different, independent providers. The role of

the service templates is indicated:

• forming the basis of requests by consumers,

• collected from providers and made available for

customisation, integration, aggregation by broker.

The detailed structure of the templates (operation,

quality, resources, policies as the main description

categories) will be explained on later. Note that while

the structure of the reference architecture might be

easier to agree upon as it brings expected features into

a common framework, requirements for the service

templates are more difﬁcult to establish as they not

only have to describe ’what’ is in the architecture, but

also ’how’ the architectural framework can be con-

verted into an effective solution. Cross-layer support

in a federated context (i.e. vertical and horizontal in-

tegration support) is the critical challenge (Barrett et

al., 2006; Buyya 2010). The reference architecture

thus aims to provide integration in two dimensions:

• Horizontal integration across federated clouds

• Vertical integration across the cloud stack layers

(IaaS, PaaS, SaaS)

We follow Gartner in their terminology. The Gart-

ner categorisation is illustrated in Fig. 1. NIST fol-

lows a similar three-pronged classiﬁcation. They de-

ﬁne a cloud broker as an entity that manages the use,

performance and delivery of cloud services and ne-

gotiates relationships between cloud providers and

cloud consumers. According to NIST, a cloud broker

can provide services in three categories:

• Service Intermediation: A cloud broker enhances

a given service by improving some speciﬁc capa-

bility and providing value-added services to cloud

consumers. The improvement can be managing

access to cloud services, identity management,

performance reporting, enhanced security, etc.

• Service Aggregation: A broker combines and in-

tegrates multiple services into one or more new

services (Benslimane 2008). The broker provides

data integration and ensures secure data transfer

between consumer and multiple providers.

• Service Arbitrage: Service arbitrage is similar to

service aggregation except that the services being

aggregated are not ﬁxed. Arbitrage means a bro-

ker has the ﬂexibility to choose services from mul-

tiple agencies (Benson 2010). The cloud broker,

for example, can use a credit-scoring service to

measure and select an agency with the best score.

2.2 Cloud Broker Interfaces and Access

We envisage the cloud consumer to interact with

the cloud broker in two ways. Firstly, request sub-

mission and cloud service construction: this is pre-

deployment and provisioning. Secondly, service

monitoring and management: this is post-deploying

during the provisioning of the service. Fig. 2 illus-

trates the two layers:

• An Integration Layer allows the construction (ag-

gregation) of a complex or customised cloud ser-

vice based on individual, independent services.

Data and information that is communicated needs

to be integrated through appropriate mediation

and transformation techniques. In addition, the

integration of wider processes is often necessary,

similar to work on document-based service pro-

cess integration in frameworks such as ebXML.

• A Management Layer allows the monitoring and

analysis of broker-provided services. The broker

is often the direct contract partner, resulting in the

need to deal with service-levelagreements (SLAs)

and billing/payment issues at that level. Monitor-

ing provides the quality and usage data for both

quality and payments concerns.

2.3 Broker Features and Requirements

In order to clarify the requirements for a service de-

scription notation for cloud service brokerage, we de-

tail the functions we expect to be performed by the

broker across the cloud layers IaaS, PaaS and SaaS

– see Figure 3. For the pre-deployment, the follow-

ing aspects are relevant. Integration, interoperability

and portability are the key concerns to support the

consumer in creating multi-vendor applications and

to move or migrate between vendors (Bernstein 2009;

Pahl 2013a; Pahl 2013b).

• Portability can be supported and automated at

lower layers by adopting OVF or TOSCA – the

latter a standard which speciﬁcally supports porta-

bility between public and private clouds.

• Expected workload is a concern that should be

considered at design/built-time, as service selec-

tion and later provisioning need to take this into

ATemplateDescriptionFrameworkforServicesasaUtilityforCloudBrokerage

Cloud

Consumer

Cloud

Provider

Cloud

Provider

Cloud

Provider

Cloud Services Broker

Service Integration

Agent: systems integrator (SI)

Application: integrated PaaS, horizontal & vertical

Functions: orchestration, mashup, mediation

Service Customisation

Agent: independent software vendor (ISV)

Application: Analytics, monitoring, user interface

Functions: wrapper, adaptivity

Service Aggregation

Agent: distributor

Application: Marketplace, Cloud provisioning

Functions: discovery, billing

API

~~~~~~~~

~~~~~

~~~~~~~

~~~~~~~~

~~~~~

Operation

Quality

Resources

Policies

Figure 1: High-level Architectural Cloud Broker Setting.

account. This requires workload to be made ex-

plicit at all layers.

• Horizontal interoperability refers to the integra-

tion of services within a cloud layer, requiring

common interfaces. Standards compatibility is a

solution. OCCI is a lifecycle management stan-

dard describing APIs for service management.

• Vertical interoperability requires the integration

of infrastructure, platform and application needs.

Key performance indicators (KPIs) differ across

the layers – while at lower infrastructure lay-

ers network bandwidth and latency are concerns,

further up it is response time or availability per

service. However, higher-level ones need to be

mapped down to lower layers, and vice versa.

Thus, formalised mappings need to be deﬁned.

We see the vertical cloud stack as an implementation

of layering as a SOA principle, resulting in a refer-

ence architecture with applications (SaaS in cloud),

middleware (PaaS in cloud) and infrastructure ser-

vices (IaaS in cloud). Critical is in vertical cloud stack

is the integration of non-functional properties (QoS),

i.e., mappings between the layers. For SaaS and PaaS,

a relevant metric is for instance the service response

time. For IaaS, metrics are based on compute (CPU

load), storage (data size) and network (throughput or

latency). While not covered here in detail, mappings

between layers can be statically ﬁxed. As input, we

can used our work on predicting and deriving e.g.

PaaS-response time from IaaS-metrics like CPU util-

isation or network bandwidth (Zhang, 2013).

For post-deployment management, life cycle sup-

port is crucial, covering the conﬁguration and provi-

sioning as well as on-going monitoring and analytics.

• Resource need to be conﬁgured, based usually

on quality requirements such that the resources

match the needs of the consumer. Selection,

matching and conﬁguration support is necessary.

• The user requirements and the resulting abstract

conﬁguration have to be correlated with the avail-

able resources provided at the time of provision-

ing the services. In addition to the conﬁguration

concerns, this requires lower-level input from re-

source managers and workload balancers.

• Monitoring is an essential part of a provisioning

platform. Monitoring solutions are available –

commercial and open-source. However, due to

the requirement of supporting federated clouds,

the need to collect and integrate monitored data

from different sources arises.

• Like monitoring, the analysis of data gath-

ered requires interoperability between monitor-

ing sources and the analysis tool. The require-

ments are similar with respect to standardisation

and compatibility, e.g. SLA-related data.

This discussion provides a ﬁrst requirements list for

the service template, discussed in the next section.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

Monitoring and Analytics

Graphical Request

Language

Cloud Services Broker

Integration Layer

- Data/Content

- Processes

Management Layer

- Routing

- Portability

- Capacity

- Security

Operation

Quality

Resources

Policies

Cloud Consumer

Figure 2: Cloud Broker Interfaces and Access to Functions.

3 SERVICE DESCRIPTION

TEMPLATES – STRUCTURE

AND FORMALISATION

A service template is an abstract description of a

service’s capabilities, in terms of functional and

non-functional aspects. Different types of tem-

plates to describe the capabilities of cloud resources

have been proposed, often under a different name

such as Recipes (Chef, Cloudify) (Cloudify, 2012),

Blueprints (4CaaSt) (4Caast, 2013) or Manifests

(OVF, CompatibleOne) (Compatible One, 2013). In

Section 5, see Fig. 7 below, we summarise the lan-

guage deﬁnition challenges and requirements pre-

sented in (Pahl et al, 2013). We categorise the service

description languages, such as (CloudFoundry, 2013;

DeltaCloud, 2013; Jclouds, 2013; Libcloud, 2013;

Mosaic, 2013; OpenShift, 2012; Optimis, 2013; sim-

pleAPI, 2013), in terms of the cloud layer support and

speciﬁc features they provide. We categorise the so-

lutions along the following concerns, which form re-

quirements for a template solution:

• System Type: Multi Cloud API, IaaS Fabric Con-

troller, Open PaaS Solution, Open PaaS Provider.

• Distribution Model: Open Source (for all solu-

tions considered)

• Core Capabilities: Multi-IaaS Support, Multi

Language/Framework Support, Multi Stack

• Core Features/Components (development and de-

ployment time): Service Description Language,

Native Data Store, Native Message Queue,

Programming Model, Elasticity & Scalability,

QoS/SLA Monitoring.

• Advanced Features/Components: Service Discov-

ery/Composition, Broker, Marketplace – towards

broker and marketplace features.

We can see a trend towards the upper broker and mar-

ketplace solutions (Mietzner 2008; Rodero-Merino

2010). These demonstrate to some extent a multi-

faceted description with functional and quality as-

pects. However, a comprehensive coverage is not

available. A richer description notation is needed, re-

sulting in additional complexity due to the required

multi-layer support, leaving both vertical integration

and comprehensive to be addressed.

3.1 Template Structure

We propose a 4-part structure for the service descrip-

tion template: operation, quality, resources and poli-

cies. The ﬁrst two cover service-internal aspects – the

functional and non-functional aspects of the service.

The remaining two cover more the service-external

perspective with the resources required and also the

security and compliance requirements. We identify a

4-part hierarchy of concepts, which we will later for-

malise as the core taxonomy of a service description

ontology (Pahl 2007; Papazoglou 2011b).

• Operation – the functional service interface. Its

subconcepts follow WSDL in its structure:

– Service type/interface deﬁnes the interface as

an abstract data type

– Operations that provide service functionality

– Messages and Types to communicate data to

and from the service for operation invocations

• Quality – the non-functional properties. Its sub-

concepts are performance-related concerns:

ATemplateDescriptionFrameworkforServicesasaUtilityforCloudBrokerage

Federated

Cloud

Development

IaaS

Infrastructure

-as-a-Service

PaaS

Platform-as-a-

Service

SaaS

Software-as-

a-Service

Service Integration

(Interoperability and

Portability)

Service Management

(Provision, Configure,

Monitor)

Service

Portability

Workload

Balancing

Horizontal

Interoperability

Vertical

Interoperability

Resource

Provisioning

Resource

Configuration

Monitoring and

Reporting

Analysis and

Auditing

Figure 3: Cloud Broker Features and Capabilities.

– Availability of the service in question

– Latency/Response Time of service/operations

– Bandwidth as another quality concern

• Resources – deployment requirements. Its sub-

concepts are aspects speciﬁc to the provisioning

of a service in a PaaS or IaaS environment:

– Average/peak workload requirements is a typi-

cal example for a conﬁguration requirement

• Policies – the business agreements and con-

straints. Its subconcepts are:

– Security and Privacy concerns in terms of con-

ﬁdentiality, integrity or authenticity

– Compliance and Governance as further rules to

describe to correct alignment of a service to its

execution environment

3.2 Formalisation

We propose to formalise the service template as an

ontology. An ontology is a conceptual model formu-

lated in a formal description language. We utilised in

this context the core of the Semantic Web technology,

the Web Ontology Language OWL. This language is

based on description logics, i.e. has a formal deﬁni-

tion and is supported by various tools including rea-

soners that can even be used at runtime. Using seman-

tic technologies brings us closer to interoperability of

meaningful descriptions in an Internet context.

An ontology is a representation of concepts (or

classes) that are deﬁned in terms of their properties,

i.e. relationships to other concepts. Concepts can be

instantiated into concrete values. Properties can be

object or data valued, depending on whether they re-

fer to another complex object (concept – an exam-

ple is the relationship of a service to another ser-

vice through invocation or inheritance) or data (an ex-

ample is the performance of a service as a numeric

value). Concepts can be arranged into a hierarchy us-

ing a sub/superconcept relationship. This forms the

taxonomy of the ontology. Our ontology has a root

concept, which is ’ServiceTemplate’. Using an ’is-

PartOf’ relationship, the aspects Operation, Quality,

Resources and Policies are connected to ServiceTem-

plate. Individual concerns, such as ServiceType or

Message for Operation or Availability for Quality, are

the subconcepts of the respective four core aspects.

These properties deﬁne a basic hierarchy. However,

we need a richer ontology that addresses the require-

ments outlined earlier, see Figure 4.

• In terms of interfaces and operations, we need

to distinguish the different layers – as ontology

subconcepts of the Operation concept. For IaaS-

Operation, we deﬁne a service API with the cor-

responding operations that is OCCI-compliant.

While VM image management is relatively uni-

form (thus, OCCI is possible as a standard), at the

PaaS layer, we need to provide for standard tools

like databases or application server. For instance

a Tomcat server could be modelled as an instance

of a Web application server concept. Standardised

solutions in terms of APIs/operations would then

only be speciﬁc to a tool category.

• Quality concerns (KPIs for the different layers)

need to be differentiated. We assume each qual-

ity criterion to be qualiﬁed by an attribute (data-

valued property) that indicates the relative cloud

layer to which it applies.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

Service

Template

Operation

Quality

Resources Policies

IaaS

OCCI-compl.

VM Mgmt API

PaaS

Database

Application

Server

Tomcat

Availability

Response

Time

Template

Reference

Rules

Figure 4: Service Template Ontology.

• Required resources can be explicitly or abstractly

speciﬁed by referring to other templates that cap-

ture the required resource. This is facilitated by

a special resources relationship. The need for for-

mality becomes clear as circular resource relation-

ships cannot be tolerated and need to be detected.

• The Policies part needs to link to a special kind of

entities: rules. We propose to utilise the SWRL

language (Semantic Web Rule Language). The

speciﬁed rules can be evaluated at build time and

dynamically veriﬁed.

The ontology is meant to be extensible for particular

circumstances. For concrete resources, instances are

attached. This clariﬁes the deﬁnition of a template – a

template is concept-level in terms of the ontology and

can be instantiated by providing instance-level values.

Templates can be generated from other resources

and provide input to further processing. Based on

SLAs or other legal agreements, some operational,

quality, and policy requirements can be derived that

would deﬁne a partial template. Service integration

plans need to be generated in many cases where a sin-

gle service will not satisfy the need. A service process

needs to be orchestrated in a classical Web service

manner, associated to an integration process connect-

ing abstract resources.

3.3 Sublanguages

While we have proposed a comprehensive ontology

capturing all conceptual aspects of the service tem-

plate language framework, in order to tailor this to

the needs of different actors and components of the

reference architecture, a facilitation through different

languages would be beneﬁcial. As core technical lan-

guages (Figure 5) we can identify:

Operation

Quality

Resources

Policies

Definition

Language

Configuration

Language

Constraints

Language

Service Template

Ontology Languages

Rule Language

Composition Manipulation

Language Language

Graphical

Request

Language

Algebraic Languages

Graphical

Language

Figure 5: Service Template Languages Framework.

• Service Template Deﬁnition Language (Operation

and Quality) addresses service internal aspects

• Service Template Conﬁguration/Instantiation

Language (Resources) addresses ﬁrst type of

external aspects

• Service Template Constraints Language (Policies)

also addresses external aspects, but, as explained,

a rule language rather than an ontology language

needs to be facilitated here.

These core languages can be complemented by

two template manipulation operators – core compo-

sition and non-compositional manipulation (Bensli-

mane 2008), both possibly supported by a graphical

request language:

• Service Template Composition Language (Inte-

gration Processes) is singled out to deal with ser-

vice aggregation by supporting a range of stan-

dard composition operators to allow services to be

orchestrated into a process across different cloud

providers (Pahl 2007).

• Service Template Manipulation Language pro-

vides non-compositional template manipulation.

This could include the reﬁnement/specialisation

of a template, or the merger or restriction.

ATemplateDescriptionFrameworkforServicesasaUtilityforCloudBrokerage

• Graphical Request Speciﬁcation Language. Re-

quests for a speciﬁc service are expressed by end-

users. To facilitate access for different users with

different degrees of technical knowledge, we sug-

gest a graphical request language visualising the

template structure.

The implementation shall follow the ontology op-

erator calculus for architecture manipulation from

(Pahl 2007) on ontology-based architecture and pat-

tern languages that combine composition and abstrac-

tion mechanisms. The conceptual core of the lan-

guages, particularly for the composition and manipu-

lation language is an operator calculus, including op-

erations such as match/select, merge, restrict, reﬁne,

behaviourally compose, abstract/instantiate, to sup-

port the following core manipulation and composition

activities:

• Reﬁnement, i.e. the derivation of a related ser-

vice description that preserve functional prop-

erties (the scope of the service can be tailored

through restrict and union operations).

• Instantiation, i.e. providing concrete values for an

abstract, concept-leveltemplate in order to denote

a concrete service.

• Composition, i.e. the use of aggregation operators

such as sequence, selection and iteration to or-

chestrate a selection of services to form a compos-

ite service process serving a more complex goal.

4 ARCHITECTURE AND

VALIDATION

An implementation architecture for the service tem-

plates is the brokerage test-bed currently developed at

IC4 (a cloud research centre at our university), where

a combination of OpenStack as the IaaS solution and

CompatibleOne as the core PaaS broker solution is

being developed. This serves us as an implemen-

tation to investigate the vertical integration of IaaS,

core PaaS and broker layers. While CompatibleOne

is a broker, the support implemented does not satisfy

the requirements of our needs here – see Sections 2.1

for a CompatibleOne review and 2.3 for a require-

ments discussion. The following architecture (Fig.

6) describes the architectural setup of OpenStack and

Compatible One that we propose to be used as the ex-

perimentation environment.

CompatibleOne (Compatible One, 2013) is an

academic and industry consortium that set out to pro-

vide a framework to allow for portability and inter-

operability of cloud software. The project focusses

on producing a broker platform following the Gartner

Figure 6: OpenStack and CompatibleOne Architecture

deﬁnition of a cloud broker to provide Intermediation,

Aggregation and Arbitration of cloud services. Such

a broker could allow for cloud service consumers re-

quirements to be mapped to cloud vendors’ resources.

The project is committed to the OCCI standard. To

date, the project has produced the CORDS informa-

tion model and the ACCORDS software platform.

• The CORDS model is as an open, object-oriented,

OCCI-compliant representation of cloud comput-

ing entities and can be used to build complex

cloud middleware.

• The ACCORDS platform is a suite of cloud mid-

dleware programs that provide broker services.

Using ACCORDS, a customer can describe ser-

vice requirements in a CORDS-compliant format.

These can be matched to available provider offer-

ings and then ultimately provisioned at run-time

by interacting with the actual vendor resources.

The model includes representations for service level

agreements, pricing structures and transaction man-

agement for usage billing.

OpenStack (OpenStack, 2012) is a cloud enabling

solution that transforms a physical hardware infras-

tructure into an Infrastructure as a service (IaaS). The

platform is a Cloud Platform or IaaS Cloud Fabric

controller. The platform can be used to run cloud

compute and storage infrastructure. The OpenStack

open source siolution makes its services available

through Amazon EC2/S3 compatible APIs and hence

client tools written for AWS can be used with Open-

Stack clouds. Five main services are exposed by

OpenStack: Compute (Nova), Storage (Swift), Imag-

ing (Glance), Identity (Keystone) and Network man-

agement (Quantum).

The adequacy of the proposed service template

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

model can be validated by discussing some scenarios

as implementations in the above testbed architecture:

• Customisation, Aggregation, Integration: these

are the three broker types, which need to be sup-

ported by adequate operators.

We have proposed an ontology-based operator

calculus that provides suitable support. Reﬁne-

ment allows customisation. The composition op-

erators that we propose allow aggregation. And

integration is facilitated by allowing semantic in-

tegration through a rich ontology and a rules-

based approach to control the integration into spe-

ciﬁc environments. Thus, speciﬁcally the ma-

nipulation and composition operators are nec-

essary to fully support service brokerage. An

ontology-based solution helps with integrating

multi-facetted aspects into a coherent manipula-

tion and reasoning framework.

• CORDS and ACCORDS integration: the CORDS

model with its OCCI-based description layer pro-

vides a standards-based platform to enable utilisa-

tion in a concrete OCCI-compliant IaaS solution.

The CORDS model relating to the ACCORDS

platform features can be fully represented in terms

of the service template notation. ACCORDS

services are instantiated service templates. The

OCCI-compliant OpenStack is the execution plat-

form. With CompatibleOne, we have used one of

the most advanced broker platforms available (we

discuss 4CaaSt, another advanced solution, in the

next section) based on our comparison in Fig. 7

earlier. Thus, we can be conﬁdent that the verti-

cal layering problem can be addressed for a rich,

multi-facetted description template.

While we have not fully implemented the proposed

service template model as an extension of the CORDS

matching, our experiments with CompatibleOne sup-

port the feasibility of a full integration of the two

cloud solutions. The experiments validate the scope

that a service description template has to cover for

vertical integration as proposed in Section 4.

5 RELATED WORK

We select 13 speciﬁcation notations here for a more

in-depth description including (CloudFoundry, 2013;

DeltaCloud, 2013; Jclouds, 2013; Libcloud, 2013;

Mosaic, 2013; ?; OpenShift, 2012; Optimis, 2013;

simpleAPI, 2013). Fig. 7 summarises a range of so-

lutions ordered from bottom to top based on the fo-

cus in the cloud technology stack (from basic IaaS

to advanced SaaS marketplace support). We compare

these in terms of their capabilities and components

as comparison categories as discussed in Section 3.

A more detailed, general discussion can be found in

(Grozev, 2012), which also covers systems like mO-

SAIC or jclouds. Our work here is not speciﬁc to any

of the intercloud architecture types identiﬁed there.

Our discussion is also more speciﬁc to languages and

service description, whereas (Grozev, 2012) covers

wider concerns like location-awareness or pricing.

An ontology-based foundation enables reasoning

support. It also acts as an integration, e.g. via ODM

framework with MOF/UML-style notations and via

the predicate logic link to other logic-based lan-

guages. In this respect, our template approach is

a step ahead compared with e.g. the Blueprint ap-

proach of 4CaaSt or the recipes techniques in Cloud-

ify. Ongoing work in the EU Broker@Cloud project

uses an extension of the RDF-based version of USDL

(Kourtesis, 2013), which demonstrates the relevance

of semantic technologies for integration and reason-

ing across platforms, but here our full OWL goes be-

yond the RDF-based USDL formalisation.

The two most advanced ones in terms of bro-

kerage – 4CaaSt and CompatibleOne – shall be dis-

cussed. The 4CaaSt Blueprint approach (Nguyen

2011; Papazoglou 2011b) supports through its dif-

ferent languages a range of cloud brokerage activi-

ties. Blueprints are initially abstract speciﬁcations,

which can be resolved, i.e. mapped to lower cloud

stack layers until the speciﬁcations are ﬁnally de-

ployed using a standard conﬁguration and deployment

manager. Resources and Services are described in

a Blueprint (BP), which is an abstract description of

what needs to be resolved into infrastructure entities.

BPs are stored and managed in a BP repository via

a REST API. A BP is resolved when all requirements

are fulﬁlled by another BP, via the Resolution Engine.

This is a service orchestration feature. A number of

XML blueprint languages are supported: BDL De-

scription Language (for cloud operations and capabil-

ities), BCL Constraint Language (for SLA parameters

deﬁnition), BML Manipulation Language (for oper-

ations, e.g. service match, merge, compose, delete),

BRL Request Language (for user and developer re-

quest deﬁnitions). Blueprints are suitable to support

simple marketplace offering single, isolated services

as a product, but lack the range of brokerage activities

in their toolkit. This entails a further complication –

compositional brokerage needs to be mapped down

the layer, which is non-trivial as particularly quality

aspects are non-compositional in nature.

The CompatibleOne manifests suffer from simi-

lar limitations. The units of a CompatibleOne Ser-

vice Manifest are Image and Infrastructure. An Im-

ATemplateDescriptionFrameworkforServicesasaUtilityforCloudBrokerage

Figure 7: Summary Service Description Comparison.

age consists on a System (the base OS) and a Package

(reﬂecting the software stack conﬁguration). Infras-

tructure covers the classical IaaS concerns Storage,

Compute and Network. An Image is a description

of a manual build of an application, used by devel-

opment and conﬁguraton tools (devops, e.g. puppet

or chef). An Image has an agent that is embedded in

a VM and runs on startup. Agent is a script to run

required conﬁgurations, set up monitoring probes, or

download required components. Cordscript is pro-

prietary CompatibleOne scripting language for ex-

pressing conﬁguration actions. These support meta-

data handling within VMs, managing required link-

ages between VMs, and setting up monitoring probes

in VMs. Cordscript is a statement-oriented language.

A feature under development in CompatibleOne is

a cloud-implementable graph of OCCI category in-

stances. Particularly well solved is the standards-

compliancy at the lower layer (making it a good

testbed), but the manifests only cover core concerns.

The consumer expresses provisioning require-

ments by creating a CORDS manifest. This con-

tains attributes like ID and name. Key element is

a provisioning plan involving nodes and regions af-

fected. The node conﬁguration topology includes im-

age and infrastructure requirements (compute, stor-

age, network). Actions for conﬁgurations and re-

leases can be speciﬁed. Other information concerns

a) account, pricing and invoicing and b) security set-

tings. CORDS is conﬁguration, provisioning and de-

ployment oriented, where our template adds qual-

ity beyond security and governance through policies.

The templates can be seen as higher-level (abstract)

speciﬁcations on top of e.g. a CORDS manifest.

6 CONCLUSIONS

Standards and compatibility are effectively the only

way to make a truly interoperable cloud service bro-

ker work. We can note a trend towards cloud mar-

ketplaces utilising brokerage facilities. The proposed

solution in this paper is a ﬁrst step in this direction

that needs to facilitate language support in terms of

request speciﬁcation languages and also template ma-

nipulation operators that will support central market-

place functions (like matching and selection) – based

on a the reference architecture is the other solution

that deﬁnes how architectural components interact

and how the service templates are processed in this

context. Abstract descriptions of cloud services are

the key to a service brokerage solution allowing to

consider services as commoditised utilities that can

be brokered. We presented a conceptual model for

the service templates. We have deﬁned the core prop-

erties as an ontological model. We have suggested a

range of languages to support this feature.

The proposed OpenStack and CompatibleOne ar-

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

chitecture should serve as an adequate basis to de-

velop a solution based on the languages for service

templates as broker implementation, which remains

future work. On the theoretical side, the full speciﬁ-

cation of the operator calculus needs to be completed,

but can follow (Pahl 2007) here.

ACKNOWLEDGEMENTS

This research has been supported by the Irish Cen-

tre for Cloud Computing and Commerce, an Irish na-

tional Technology Centre funded by Enterprise Ire-

land and the Irish Industrial Development Authority.

REFERENCES

4Caast. 4CaaSt PaaS Cloud Platform. http://4caast.morfeo-

project.org/. 2013.

R. Barrett, L. M. Patcas, C. Pahl and J. Murphy. Model

Driven Distribution Pattern Design for Dynamic Web

Service Compositions. International Conference on

Web Engineering ICWE’06. ACM Press. 2006.

T. Benson, et al. Peeking into the Cloud: Toward User-

Driven Cloud Management. Clouds 2010, 2010.

D. Benslimane, S. Dustdar, A. Sheth. Services Mashups:

The New Generation of Web Applications. Internet

Computing, vol.12, no.5, pp.13-15, 2008.

D. Bernstein et al. Blueprint for the Inter-cloud: Protocols

and Formats for Cloud Computing Interoperability.

Intl Conf Internet and Web Appl and Services. 2009.

R. Buyya, R. Ranjan, R.N. Calheiros. Intercloud: Utility-

Oriented Federation of Cloud Computing Environ-

ments For Scaling of Application Services. Intl Conf

on Alg and Arch for Parallel Processing. 2010.

Cloud Foundry. Open Source PaaS Cloud Provider Inter-

face. http://www.cloudfoundry.org/. 2013.

Cloudify. Cloudify Open PaaS Stack.

http://www.cloudifysource.org/. 2012.

CompatibleOne. Open Source Cloud Broker.

http://www.compatibleone.org/. 2013.

DeltaCloud. Deltacloud REST cloud abstraction API.

http://deltacloud.apache.org/. 2013.

C. Fehling, R. Mietzner. Composite as a Service: Cloud Ap-

plication Structures, Provisioning, and Management.

IT - Information Technology: Vol. 53, No. 4, pp. 188-

194. 2011.

F. Fowley, C. Pahl and L. Zhang. Cloud Brokerage Archi-

tecture – State-of-the-Art and Challenges. Workshop

on Cloud Service Brokerage CSB2013. 2013.

Gartner - Cloud Services Brokerage. Gartner Research.

http://www.gartner.com/technology/research/cloud-

computing/cloud-services-brokerage.jsp. 2012.

N. Grozev and R. Buyya. Inter-Cloud architectures and

application brokering: taxonomy and survey. Softw:

Pract. Exper.. doi: 10.1002/spe.2168. 2012.

Jclouds. jclouds Java and Clojure Cloud API.

http://www.jclouds.org/. 2013.

A. V. Konstantinou et. al. An Architecture for Virtual So-

lution Composition and Deployment in Infrastructure

Clouds. 3rd International Workshop on Virtualization

Technologies in Distributed Computing. June 2009.

D. Kourtesis, K. Bratanis, A. Friesen, Y. Verginadis, A.J.H.

Simons, A. Rossini, A. Schwichtenberg, P. Gouva.

Brokerage for Quality Assurance and Optimisation

of Cloud Services: an Analysis of Key Require-

ments. ICSOC Cloud Service Brokerage Workshop

CSB2013. Springer. 2013.

Libcloud. Apache Libcloud Python library.

http://libcloud.apache.org/. 2013.

R. Mietzner, F. Leymann, M. Papazoglou. Deﬁning Com-

posite Conﬁgurable SaaS Application Packages Using

SCA, Variability Descriptors and Multi-tenancy Pat-

terns. 3rd Internet and Web Appl and Services. 2008.

Mosaic. mOSAIC Multiple Cloud API. http://www.mosaic-

cloud.eu/. 2013.

NIST Cloud Computing Reference Architecture. NIST.

http://www.nist.gov/customcf/get

pdf.cfm?pub id=

909505. Sept. 2011.

D.K. Nguyen, et al. Blueprint Template Support for Cloud-

Based Service Engineering. In Proceedings of the

Service-Wave’11, Poznan, Poland, October 2011.

3 OpenNebula. OpenNebula - Open Source Data Center

Virtualization. http://opennebula.org/. 2012.

OpenShift. Cloud computing platform as a service.

https://openshift.redhat.com/. 2012.

OpenStack. OpenStack Open Source Cloud Computing

Software. http://www.openstack.org/. 2012.

Optimis. Optimis - Optimized Infrastructure Services.

http://www.optimis-project.eu/. 2013.

P. Jamshidi, A. Ahmad, C. Pahl. Cloud Migration Research:

A Systematic Review IEEE Transactions on Cloud

Computing. 2014.

C. Pahl, S. Giesecke and W. Hasselbring. Ontology-based

Modelling of Architectural Styles. Information and

Software Technology (IST). 1(12): 1739-1749. 2009.

C. Pahl, H. Xiong. Migration to PaaS Clouds - Migration

Process and Architectural Concerns. IEEE 7th Inter-

national Symposium on the Maintenance and Evolu-

tion of Service-Oriented and Cloud-Based Systems

MESOCA 2103. IEEE. 2013

C. Pahl, H. Xiong, R. Walshe. A Comparison of On-premise

to Cloud Migration Approaches. European Confer-

ence on Service-Oriented and Cloud Computing ES-

OCC 2013. Springer LNCS. 2013

M. P. Papazoglou, W.J. van den Heuvel. Blueprinting the

Cloud. IEEE Internet Computing, November 2011.

L. Rodero-Merino et al. From Infrastructure Delivery to

Service Management in Clouds. Future Generation

Computer Systems, vol. 26, pp. 226-240. Oct. 2010.

simpleAPI. Simple API for XML. http://en.wikipedia.org/

wiki/Simple

API for XML. 2013.

L. Zhang, B. Zhang, C. Pahl, L. Xu, Z. Zhu. Personalized

Quality Prediction for Dynamic Service Management

based on Invocation Patterns. Intl Conference on Ser-

vice Oriented Computing ICSOC 2013. 2013

ATemplateDescriptionFrameworkforServicesasaUtilityforCloudBrokerage