A SEMANTIC DISCOVERY FRAMEWORK TO SUPPORT

SUPPLY-DEMAND MATCHMAKING

IN CLOUD SERVICE MARKETS

Giuseppe Di Modica and Orazio Tomarchio

Dipartimento di Ingegneria Elettrica, Elettronica e Informatica, Universit`a di Catania,

Viale Andrea Doria 6, 95125 Catania, Italy

Keywords:

Cloud Computing, Pricing Models, Negotiation, Ontology, Semantic Rules.

Abstract:

To date a few, big providers dominate the market of Cloud resources. They provide proprietary solutions

through inﬂexible pricing and SLA schemes. On the research side, the community is working to deﬁne spec-

iﬁcations and standards on several aspects of the cloud technology. When standards will get mature, interop-

erability among clouds will be a reality. Customers will be no more locked-up to any proprietary technology

and new players will have the chance to enter the market. The competition challenge will be played on the real

capability of providers to accommodate customers’ requests in a ﬂexible way and to supply high and differen-

tiated QoS levels. In this market scenario a mechanism must be devised to support the matchmaking between

what providers offer and what customers’ applications demand. In this work we propose the deﬁnition of a

semantic model that helps customers and providers to characterize their demands/offers, and provide semantic

tools performing the matchmaking in such a way to maximize both the provider’s proﬁt and the customer’s

utility.

1 INTRODUCTION

Cloud computing has recently emerged as a new

paradigm for delivering utility computing services

(Buyya et al., 2008). In cloud environments, infras-

tructures, platforms and application services are avail-

able on-demand and companies are able to access

their business services anywhere and whenever they

need. The real success of the cloud is mostly due

to the considerable business opportunities that it pro-

duces for both consumers and providers of virtualized

resources. On the one hand, the providers see in the

cloud model a way to maximize the use of their com-

puting assets and thus minimize the maintenance cost;

on the other hand, the “pay-per-use” business model

allows consumers to pay for only what they actually

use, without any initial investment.

In addition, cloud computing is making the shift

from product to service-oriented economy a reality:

from a technical point of view, composition of (dy-

namic) cloud services allows to provide customized

complex services to consumers; from an economic

perspective, value is just created by the intercon-

nection of various distributed service providers that

jointly contribute to an integrated solution that meets

individual customers needs. A complex services typ-

ically involve the composition of several component

services (and eventuallycomputingresources) offered

by a multiplicity of providers. These technologi-

cal and organizational trends drives competition be-

tween different service platforms and service (cloud

resources) market places.

However, today we are still far from an open and

competitivecloud and service market, where cloud re-

sources are traded as in conventional markets. The

main technological reason lies in the lack of interop-

erability of existing cloud technology (Parameswaran

and Chaddha, 2009). Another not technological, yet

equally important reason is that to date cloud re-

sources are offered according to strict pricing mod-

els and rigid Service Level Agreements (SLA). In

a future open cloud market, users (customers) will

demand for ﬂexible pricing and resources’ usage

schemes to meet their speciﬁc computing needs. Au-

tomated negotiation mechanisms should be adopted

allowing customers to bargain with providers for dif-

ferentiated levels of quality of service (Badica et al.,

2007).

In this paper we discuss about the need of more

ﬂexible charging models for cloud resources’ usage,

533

Di Modica G. and Tomarchio O..

A SEMANTIC DISCOVERY FRAMEWORK TO SUPPORT SUPPLY-DEMAND MATCHMAKING IN CLOUD SERVICE MARKETS.

DOI: 10.5220/0003929305330541

In Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CLOSER-2012), pages 533-541

ISBN: 978-989-8565-05-1

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

together with advanced negotiation protocols to bet-

ter support the public cloud model. We believe that,

in order to build an effective matchmakingprocess be-

tween supply and demand, a structured model to de-

scribe resources’ business features and applications’

requirements is needed. To this purpose, we propose

two ontologies for describing the resources offered

by cloud providers on the one hand and the require-

ments expressed by customers on the other one. The

ﬁnal aim is to efﬁciently include pricing models, ne-

gotiation capabilities and service levels into resource

publish/discovery mechanisms, that can then be en-

riched with tools to enable providers to easily char-

acterize and advertise their resources, and customers

to easily describe application requirements. A seman-

tic matchmaking algorithm has been devised enabling

customers to search for those cloud resources that best

meet their requirements.

The remainder of the paper is organized as fol-

lows. In Section 2 the background context is intro-

duced and the issues inspiring this work are discussed.

Section 3 describes in details the approach proposed

for the deﬁnition of a cloud service discovery frame-

work. In particular Section 3.1 discusses the two on-

tologies for the characterization of cloud service de-

mands/offers, Section 3.2 and 3.3 provides details on

the mapping and the matching processes respectively.

We conclude our work in section 4.

2 RATIONALE

The commercial success of cloud computing is wit-

nessed by the individual success of few, very big

companies that in the past years have made, and are

currently making, huge proﬁts by virtualizing and

selling their unused computational resources. Ama-

zon has imposed as the main IaaS provider on the

market. Microsoft and Google (respectively with

the products “Azure” and “App Engine”) dominate

among the PaaS providers. SalesForce.com provides

the most famous example of business application de-

livered through the SaaS model. These players are

dominating the market by imposing their own propri-

etary solutions (e.g., Amazon’s “.ami” for the virtual

machines’ format speciﬁcation and “EC2” API for

the management of virtualized resources), which as

a matter of fact have become the de-facto standards,

thus fostering what in economics is known as the phe-

nomenon of vendor lock-in. It is not easy for the

users to put their application on a commercial cloud,

and then migrate it to another cloud in the case that

they are not satisﬁed with the provided service per-

formance level.

The idea of putting together unused computational

resources to be organized and delivered according to

an “on-demand” basis has also spread among open,

non commercial contexts. For instance, volunteer

computing (also called Global computing or Pub-

lic computing) uses computers, voluntarily offered

by their owners, as a source of computing power

and storage to achieve high-performance distributed

scientiﬁc computing (Anderson and Fedak, 2006).

Some (Aversa et al., 2010) have proposed to build

a cloud infrastructure upon voluntarily shared com-

puting resources, claiming that the cloud computing

paradigm is applicable also at lower scales, from the

single contributing user (sharing his desktop) to re-

search groups, university campus, public administra-

tions, social communities that make available their

distributed computing resources to the Cloud. For ob-

vious reasons, the service level offered by this spe-

ciﬁc kind of clouds could never compete with that of

commercial clouds (contributing peers can voluntar-

ily join/leave anytime); nevertheless the chance to ac-

cess resources at no charge (or at very low rates) will

attract many users. Again, in order for this volunteer-

based cloud paradigm to be successful, interoperabil-

ity among the open contexts must be accomplished.

The road that leads to cloud interoperability is

long. In a desirable scenario, the user should be

able to build up its own application independently of

the speciﬁc cloud that it is going to run onto, deﬁne

the application requirements (both functional and not

functional) in a standardized way, search for the cloud

provider that best meets his requirements, negotiate

for the service, deploy the application, monitor the ap-

plication performance, moving it to another cloud in

the case that the service performance does not meet

his expectation.

Several issues need to be addressed in order

to pose the basis for fully interoperable scenarios.

The research community is focused on several cloud

management’s aspects: provisioning, metering and

billing, privacy, security, identity management, qual-

ity of service (QoS), service level agreements (SLA).

Some works propose real speciﬁcations, and pro-

mote their adoption as standards by the cloud com-

munity, while others advice best practices that should

be adopted when dealing with speciﬁc cloud man-

agement issues. The Ditributed Management Task

Force (DMTF) has developed the Open Virtualization

Format (OVF) speciﬁcation (DistributedManagement

Task Force, 2010), which is a packaging speciﬁca-

tion designed to address the portability and deploy-

ment of virtual appliances across multiple virtualiza-

tion platforms. The aim is to deﬁne a standard way

for packaging together virtual machines, data and ap-

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

534

plications that should be deployed and run on any

cloud provider. Within the Open Grid Forum (OGF),

the Open Cloud Computing Interface (OCCI) Work-

ing Group is developing practical solution to inter-

face with cloud infrastructures exposed as a service

(IaaS). The group has deﬁned the OCCI speciﬁca-

tion (The Open Grid Forum, 2011), which is an ex-

tensible API that allows the deployment, monitor-

ing and management of virtual workloads (like vir-

tual machines). The Storage Networking Industry

Association (SNIA) has created the Cloud Storage

Technical Work Group for the purpose of develop-

ing an architecture related to system implementations

of cloud storage technology. The main output of the

group’s activity is the Cloud Data Management Inter-

face (CDMI) (The Storage Networking Industry As-

sociation, 2011), a functional interface that cloud ap-

plications can use to create, retrieve, update and delete

data elements from the cloud. The National Institute

of Standards and Technology (NIST) push towards

the adoption of the computing cloud model in indus-

try and government. NIST aim is to foster cloud com-

puting systems and practices that support interoper-

ability, portability, and security requirements that are

appropriate and achievable for important usage sce-

narios. It has identiﬁed a set of twenty ﬁve use cases

(The National Institute of Standards and Technology,

2010) that seek to express portability, interoperabil-

ity and security concerns that cloud users may have.

The Cloud Security Alliance (CSA) was created to

promote the use of best practices for providing secu-

rity assurance within cloud computing. CSA is very

much concerned with issues like identity and access

management, that are thoroughly discussed in an ofﬁ-

cial document that has been released (The Cloud Se-

curity Alliance, 2011). The Open Cloud Consortium

(OCC) is an organization supported by several enter-

prises and academic partners that develops reference

implementations, benchmarksand standards for cloud

computing. It has developed the MalStone Bench-

mark (The Open Cloud Consortium, 2011) for large

data clouds and is working on a reference model for

large data clouds. The Cloud Computing Use Cases

group works to deﬁne use cases for cloud computing.

It is a collaboration of cloud consumers and cloud

vendors trying to make steps towards keeping cloud

computing open. The group has published a white

paper (The Cloud Computing Use Cases group, 2011)

that highlights the capabilities and requirements that

need to be standardized in a cloud environment to

ensure interoperability, ease of integration and porta-

bility. The provided use cases demonstrate the per-

formance and economic beneﬁts of cloud computing,

and are based on the needs of the widest possible

range of consumers. The latest version of the paper

focuses on four main topics: how consumers use the

cloud; how applications are built in the cloud; security

in the cloud; requirements for Service Level Agree-

ments in the cloud.

Independently of the speciﬁc aspects addressed by

these research efforts, they all share the same objec-

tive: interoperability among clouds. When such a

target will be accomplished, a new scenario of busi-

ness opportunities will open up to the old and the

new stakeholders that will want to proﬁt from the

open market of the cloud-based resources. The Eu-

ropean FP7 project Reservoir (Reservoir Consortium,

2011) is one of the ﬁrst successful attempts to create

an interoperable federation of cloud providers, span-

ning across different administrative domains, IT plat-

forms and geographies, aiming at sharing their indi-

vidual resources to respond to the users’ demand. In-

teroperability is the means by which also small com-

panies can federate to each other to share their re-

sources and propose themselves as an alternative to

the big players. In the forthcoming interoperable sce-

narios the competition for acquiring new customers

will be shifted to the ground of the overall QoS that

cloud providers are able to offer. The challenge for

the cloud providers will be answering at best the real

needs of their customers. This will yield to a di-

versiﬁcation of the offerings in terms of (to cite a

few) adopted security models, performance monitor-

ing tools, SLA templates, resource negotiation proto-

cols and pricing models.

In this paper we focus on the last two of the just

cited aspects. In particular we address the need to

support customers when choosing the “best” cloud

offer among the wide range offers that they are pre-

sented with. On the other side cloud providers, when

offering their resources, should be able to differen-

tiate at best their offer, by presenting the customers

with a wide selection of ﬂexible negotiation and pric-

ing models. Such an offering diversiﬁcation will yield

beneﬁts to cloud providers too.

3 CLOUD SERVICE DISCOVERY

FRAMEWORK

The future cloud economy will have to take care of

the vast set of requirements (functional and non func-

tional) of those applications that potentially might get

beneﬁts if “cloudiﬁed”. In order to best match the de-

mand of these applications, the market of cloud ser-

vices will have to broaden its range of offerings. On

the cloud providers end, a great competitiveness fac-

tor will be the capability of realizing such a differen-

ASEMANTICDISCOVERYFRAMEWORKTOSUPPORTSUPPLY-DEMANDMATCHMAKINGINCLOUD

SERVICEMARKETS

535

Application requirements' domain Resource features' domain

AR5

AR4

AR1

AR2

AR6

AR3 RF4RF3

RF2

RF1

RF5

RF8

RF7

RF6

RF9

RF10

1:Mapping

2:Matching

Figure 1: Mapping and matching.

tiation.

One of the key elements on which the competi-

tion will be based is the pricing model applied to

charge the cloud service’s usage. The main cloud

paradigm’s claimed strength is that resources (com-

puting, storage, network) can be accessed on an On-

Demand basis, and customers can be charged accord-

ing to the actual resources’ usage time. Providers

also propose their customers an alternative pricing

model based on the Resource Reservation, which on

the cloud provider’s end provides an instant economic

beneﬁt (they receive an immediate payment for the

reservation), and on the customer’s end allows to save

on the resource price, provided that the resource it-

self is intensively (densely) used. Other providers

(mostly providing services for the business manage-

ment) adopt a price model that takes into account

the number of end users of the service. The cus-

tomer is then charged by month and by the number

of end users that the application will have to serve

(we refer to this model as End-User-Based). Finally,

almost all commercial providers propose a Free-Of-

Charge model, which is nothing but a try-before-buy

strategy (some refers to this model with the name

”freemium”).

In the forthcoming cloud economy generation

other pricing models might result more attractive for

both the providers’ and the customers’ needs (e.g.,

customized models, time-oriented models). Another

key element on which competition will focus is the

negotiation protocols’ schemes offered to carry on

a service transaction. The market of virtualized re-

sources is today dominated by very big commercial

providers that impose their charging models, price

quotes, resource availability level, data security level

for the resources that they put for sale. As for the

resource cost aspect, for instance, customers can ac-

quire a resource just at the price that it is advertised

at, with no chance for them to negotiate on the price.

Amazon has launched the Spot Instances model. This

model enables the customer to bid for unused Ama-

zon capacity. Depending on the provider’s business

strategies and on the amount of unused resources,

other negotiation models (e.g., auction-based) might

be employed. We argue that, similarly to what hap-

pens in some goods markets, providers should be

given the possibility to tune their selling strategies ac-

cording to the resources’ demand and supply levels.

Finally, in the future the cloud offers will strongly

differentiate on the service performance level. The

performance features that cloud providers advertise

are usually vague, sometimes focused on virtual ma-

chines computation speed, ignoring other aspects

such as the storage and network services performance

(like, e.g., access time to stored data and network

bandwidth).

All providers guarantee a very high level of re-

source availability (from 99% upwards), prevent any

user data loss by allocating extra back-up storage,

support customers to face any technical issue, provide

them with feedbacks on the performance of the deliv-

ered services. Their commercial offers are built on

top of the just cited QoS parameters. The competi-

tion among the providers is played on both the price

at which the resources are leased and the capability

of sustaining the promised, guaranteed service lev-

els. Some providers further differentiate their service

offer. Besides provisioning what we call a standard

basic service level, some of them also offer a pre-

mium service level, which provides more guarantees

than the basic and adds extra services. In the future,

in order to satisfy the customers’ heterogeneous and

dynamic business requirements, the cloud providers

might be encouraged to propose new models. To

cater for more ﬁne-grained customer requirements,

providers might want to propose customizable plans

of service levels, that will enable customers to build

their own desired service level provisioning scheme.

Let us now change perspective, and imagine to

look at things with the customer’s eye. Customers

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

536

would like to have the possibility to characterize and

specify application requirements under their business

perspective, i.e., in a form that is aligned to the ob-

jectives being pursued by the their own business poli-

cies. According to the customer’s business objectives

to be accomplished, and to how much mission-critical

the application is, the application to be deployed may

require either a guaranteed service level or a best ef-

fort. If the former is to be chosen, again, dependingon

the business requirements of the application, a choice

has to be made between a basic or a premium service

level. Further on, the choice of the pricing model that

best ﬁts must be made according to the application’s

proﬁle, i.e., the application’s speciﬁc usage pattern:

if such pattern is “dense” (resources are intensively

used within a timeframe), reserved-based solutions

are to be preferred; otherwise, the on-demand pric-

ing model may result more convenient. Finally, the

budget availability is the most compelling among the

requirements. All the choices must be made check-

ing that the budget they require is compatible with the

customer’s investment capability. For example, a ser-

vice level might ﬁt a given application’s proﬁle, but

might not be affordable for the customer; on the con-

trary, a more affordable service level would make the

customer save money, but might not ﬁt the strict ap-

plication’s requirements. In most cases a compromise

has to be searched for.

The provider and the customer perspectives are

quite different. The former seeks to maximize the

proﬁt and the utilization level of the IT asset that they

have invested in. The latter just needs to make ﬁne-

tuned searches on the market in order to discover the

service ﬁtting their speciﬁc business needs. We have

then designed a service discovery framework that ex-

ploits semantic mechanisms to favour the matchmak-

ing of the providers’ offer and the customers’ de-

mand. Two ontologies have been developed to char-

acterize respectively the provider and the customer

perspectives. In particular, an ontology semantically

describes the features of the resources being offered

by cloud providers, the other one describes the ap-

plication’s business requirements demanded by cus-

tomers. Since each ontology contains semantic con-

cepts belonging to two different domains, we have de-

vised a mapping process that transforms application

requirements into “semantically” equivalent resource

features, i.e., features that best represent the applica-

tion requirements in the domain of resources. The

mapping’s purpose is to put application requirements

and resource features on a common semantic ground

(that of cloud resources) on which a semantic proce-

dure will try to make the match.

Figure 1 depicts the two semantic domains, along

with the mapping and matchmaking processes. In

the ﬁgure, the ﬁlled circles represents, respectively,

real requests issued by customers (within the ap-

plication requirements’ domain) and real offers ad-

vertised by service providers (resource features’ do-

main). Through the mapping process the application

requirement AR

is transformed into its “equivalent”

resource feature offer RF

(empty circle) in the of-

fers domain. Such resource feature does not neces-

sarily coincide with a real offer, but rather represents

the ideal offer that would perfectly match the consid-

ered application requirement. In the next step, the

matchmakingprocedure will explore the resource fea-

tures’ domain in order to search for concrete offers

that show a semantic afﬁnity to RF

(those covered by

the gray area in the ﬁgure). The ﬁnal outcome of the

entire process will be a list of concrete offers, sorted

by the semantic afﬁnity degree, that may satisfy the

needs represented by AR

In the following subsections we provide an

overview of the two ontologies, respectively describ-

ing the application requirements and the resource fea-

tures domains, and some details on how the mapping

and matchmaking processes work.

3.1 Ontology Design

We have designed two simple and extensible OWL-

based (W3C, 2009) ontologies that may be of help

to semantically characterize the resources offered by

cloud providers and the requirements expressed by

customers. This is a very ﬁrst attempt to deﬁne the

base for a more comprehensive and complete ontol-

ogy framework, but we believe it is sufﬁcient to give

the reader a rough picture of the idea being proposed

in this work.

3.1.1 Resource Features’ Ontology

In its current state the resource features’ ontology fo-

cuses on the concepts that, according to us, best repre-

sent the cloud resources from the providers’ business

perspective, i.e., the pricing model, the service perfor-

mance level and the negotiation model.

The ﬁgure 2 depicts a comprehensive view of

the developed ontology. Ellipses represent ontology

classes. A solid arrow models an is-a relationship be-

tween two classes, while arrows with dashed lines are

object properties deﬁned among classes. Basically, a

cloud Offer is the main concept of the ontology. An

offer regards the provisioning of a cloud Service, that

can be in the form of IaaS, PaaS of SaaS (Infrastruc-

ture, Platfom, Software - as a Service). Among the

features that an offer can exhibit, we have depicted

the Pricing Model that will be used to charge the

ASEMANTICDISCOVERYFRAMEWORKTOSUPPORTSUPPLY-DEMANDMATCHMAKINGINCLOUD

SERVICEMARKETS

537

Offer

PriceModel

NegotiationModel

ServicePerformanceLevel

Service

IaaS

SaaS

PaaS

OneToOne

OneToMany

AlternateOffer

SpotLike

FreeOfCharge

EnglishAuction

DutchAuction

ContractNet

Charged

OnDemand

Reservation

EndUserBased

BestEffortGuaranteed

Basic

Premium

Customized

provides

hasPriceModelhasPerformanceLevel

hasNegotiationModel

hasNegotiation

Figure 2: Resource features ontology.

customer, and the Service Performance Level asso-

ciated to the provisioning of the service that the offer

refers to.

The Pricing Model is partitioned into two dis-

jointed concepts(classes): Free of Charge and

Charged. Free of Charge represents the category of

services offered for free (see “try-before-buy” strate-

gies). Charged embraces all pricing models that

charge the customer for the service usage. In this

tentative ontology, Charged is furtherer subclassed

by the On-Demand, Reservation and End-user-Based

concepts. The three sub-concepts represents the pric-

ing categories currently adopted by commercial cloud

providers, as earlier discussed at the beginning of the

section. As depicted in the ﬁgure, the Charged class

is linked to the NegotiationModel class by means of

the hasNegotiationModel property. This link mod-

els the negotiability of the price of any non-free of-

fer. The service provider is allowed to select the ne-

gotiation model that accommodate at best its vend-

ing strategy’s objective. In particular, there are two

big categories of negotiation models: the OneToOne,

which models private negotiation models between a

customer and a provider, and the OneToMany, repre-

senting all the public negotiation schemes in which

many customers compete to acquire the resource of-

fered by one provider.

As regards the Service Performance Level class,

it is subclassed by the Best Effort and Guaranteed

classes. The former represents the category of ser-

vices for whose performance no guarantee is pro-

vided; the latter represents the services for which a

basic guarantee is offered, those for which a premium

level guarantee is provided, and those allowing for a

customization of the performance level to be deliv-

ered. The object property, linking the Customized

class to the OneToOne class, models the possibility

for the provider to select the preferred negotiation

scheme to be used when contracting with the cus-

tomer for the QoS to be delivered.

3.1.2 Application Requirements’ Ontology

In the Figure 3 the ontology deﬁning the application

requirements is depicted. A dashed arrow originating

from a concept (ellipse) and pointing to a box repre-

sents a concept’s data property, whose range of val-

ues is indicated within the box itself. Basically, a cus-

tomer can request Computing resources, a Platform

or a Software application. The Price branch models

the fact that, for a request, the customer can specify

if he is willing to pay or he is just looking for a free-

of-charge service. In the ﬁrst case, the customer may

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

538

Request

Computing

Platform

Software

Price

ChargedFree

ConsumptionPlan

UtilizationPlan

Short, Long

High, Low

PriceNegotiation

Model

Public Private

BudgetAmount

High, Low

hasValue

hasUtilizationPlan

hasDuration

hasConsumptionPlan

hasDensity

hasPrice

canNegotiate

hasBudgetAmount

Figure 3: Application requirements ontology.

want to also specify the amount of the budget at his

disposal. At this stage, two qualitative values are al-

lowed (“High” and “Low”) but a more detailed speci-

ﬁcation for the budget requirement will be introduced

in the future. Also, the customer may specify if he is

looking for services that are either privately or pub-

licly negotiable.

In the case of Computing resources, the customer

is given the possibility to specify whether he has a

plan for utilizing the resource (UtilizationPlan con-

cept), and a timeline for that plan (hasDuration data

property). A resource consumption plan, indicating

how ”dense” will be the consumption of the resource

for the duration of the plan, may also be speciﬁed.

These parameters aim to model what in section we

earlier referred to as application proﬁle.

3.2 Mapping

The mapping process is a simple procedure that ap-

plies a list of mapping rules. Rules have been deﬁned

using the Semantic Web Rule Language (SWRL)

(Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet,

S., Grosof, B., and Dean, M., 2004). The objective

of each rule is to transform a speciﬁc application re-

quirement into the ideal, best matching resource fea-

ture. As mentioned before, the mapped feature does

not have to necessarily correspond to a real feature of

a concrete offer. The task of searching for the real

feature that best matches is committed to the match-

making process, of which we provide details in the

next section.

A group of chained semantic rules drive the map-

ping from individuals of the Application require-

ments’ ontology to individuals of the Resource fea-

tures’ ontology. A rule engine takes a request in in-

put, applies the sequence of rules and incrementally

builds up the ideal offer. For the sake of brevity, we

report only a subset of these rules:

1. request : Request(?request)

∧ of fer : Of fer(?of f er)

→ hasMatchedOf fer(?request, ?of fer)

2. hasMatchedOf f er(?request, ?of fer)

∧ request : Computing(?request)

∧ of fer : provides(?of fer, ?service)

→ of fer : IaaS(?service)

3. hasMatchedOf f er(?request, ?of fer)

∧ request : Plat f orm(?request)

∧ of fer : provides(?of fer, ?service)

→ of fer : PaaS(?service)

4. hasMatchedOf f er(?request, ?of fer)

∧ request : Software(?request)

∧ of fer : provides(?of fer, ?service)

→ of fer : SaaS(?service)

5. hasMatchedOf f er(?request, ?of fer)

∧ request : hasPrice(?request, ?price)

∧ request : canNegotiate(?price, ?negotiation)

ASEMANTICDISCOVERYFRAMEWORKTOSUPPORTSUPPLY-DEMANDMATCHMAKINGINCLOUD

SERVICEMARKETS

539

Co-re

Co-id

(a)

Co-id

Co-re

(b)

Root

Co-re Co-id

(c)

Root

......

Co-idCo-re

(d)

Figure 4: Concepts comparison.

∧ request : Public(?negotiation)

∧ of fer : hasPriceModel(?of fer, ?priceMod)

∧ of fer : NegotiationModel(?negModel)

→ o f fer : hasNegotiationModel(?priceMod, ?negModel)

∧ of fer : OneToMany(?negModel)

Rule 1 just states that, given a generic request in

the application requirements’ domain, a correspond-

ing ideal offer exists in the resource features’ domain.

Rules 2 through 4 handle the different type of cloud

services that can be requested. Rule 5 maps a request

for a generic cloud service, for whose price the cus-

tomer is willing to negotiate in a public auction.

3.3 Matchmaking

After the mapping process has elaborated the ideal of-

fer, the matchmaking process will start exploring the

domain of the real offers in order to ﬁnd those whose

features best meet the initial application requirements.

In particular, for each offer advertised in the market,

the matchmaking process will evaluate the semantic

afﬁnity between that offer and the ideal offer. The se-

mantic afﬁnity will reveal how close a real offer is

to the customer expectations. The semantic afﬁnity

will be a value in the range [0,1], being 1 the highest

achievable afﬁnity. This will allow us to present the

customer with a list of concrete offers (sorted by the

afﬁnity criteria) that will ease the task of selecting the

best offer. The function that calculates the semantic

afﬁnity is the following:

A = Serv

∗ W

serv

+ Price

∗ W

price

+ Per f

∗ W

per f

Neg

∗W

neg

The overall afﬁnity between the ideal offer and a

real offer is obtained by summing up four components

which, respectively, represent the sub-afﬁnities eval-

uated on each offer’s feature: service, price model,

performance level and negotiation model. So, for in-

stance, the addendum Price

∗ W

price

represents the

sub-afﬁnity evaluated on the price feature. In particu-

lar, Price

is the outcome of the semantic comparison

between the price concepts exposed by the two indi-

viduals (the offers), whileW

price

is a weight factor that

can be employed to privilege the price criteria in the

evaluation of the overall afﬁnity.

We now provide some details on the

semantic comparison of concepts. Let

(Serv

, Price

, Perf

, Neg

) be a generic of-

fer, where Serv

, Price

, Per f

,Neg

represent the

semantic concepts characterizing the offer. In order

to evaluate the overall semantic afﬁnity of two offers

(the ideal offer that is the outcome of the mapping

process) and O

(a real offer in the market place),

couples of homologous concepts (i.e., referring to the

same feature) must be compared. So, Serv

o−id

will

be compared to Serv

o−re

, Price

o−id

will be compared

to Price

o−re

, and so on. In general, the concept C

o−id

must be compared to its homologous C

o−re

. Let us

now focus on that branch of the ontology tree to

which the generic concept/featureC refers to.

In the ﬁgure 4 we have depicted the four differ-

ent cases that are relevant to our evaluation. Let us

analyze all the possible cases:

• the two concepts are semantically equivalent (ﬁg-

ure 4(a)): they are assigned an afﬁnity of 1;

• C

o−id

is the father ofC

o−re

(ﬁgure 4(b): their afﬁn-

ity will be 1 as well;

• the two concepts are siblings and the father is

the root concept in the considered branch (ﬁgure

4(c)): their afﬁnity will be 0.5;

• the two concepts are siblings and the father is a

non-root concept in the considered branch (ﬁgure

4(d)): their afﬁnity will be 0.75;

• in any other case, the concepts’ afﬁnity will be

0.5.

The algorithm assigns the highest value to equiv-

alent concepts, or to concepts that are in a father-

son relationship. Instead, it penalizes two concepts

that are direct descendants of a root concept, as in

our ontology siblings concepts whose father is root

usually represent opposite concepts (e.g., Charged

vs FreeOfCharge, Guaranteed vs BestEffort). Con-

versely, siblings whose father is a non-root concept

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

540

are considered different but someway “close” con-

cepts (e.g., OnDemand vs Reservation, EnglishAuc-

tion vs DutchAuction), therefore they are given a

higher grade of afﬁnity.

4 CONCLUSIONS

Cloud computing has reached a good state of maturity

and is a very well accepted technology. Commercial

providers are trying to take advantage of the business

opportunities that this paradigm has brought. In the

future, when interoperability among clouds will be

fully achieved, there will be the need to rethink the

way by which the provision of virtualized resources

have to meet the applications’ demand. The market

of cloud resources will have to provide novel and ad-

vanced matchmaking processes that account for the

providers’ and the customers’ dynamic and heteroge-

neous business requirements, respectively in terms of

proﬁt and utility.

The work presented in this paper is a ﬁrst attempt

to deﬁning a cloud service discovery framework. In

particular, two ontologies have been developed to

characterize respectivelythe cloud resource’s features

and the application requirements, and a set of seman-

tic rules has been deﬁned to let customers’ requests

be mapped onto the cloud offers’ domain. Finally, a

matchmaking procedure has been devised to seman-

tically search the offers’ domain and provide the cus-

tomer with a list of most proﬁtable offers. A prototype

of the framework has just been implemented. In the

future we are planning to run intensive tests in order

to evaluate the viability of the proposed model.

ACKNOWLEDGEMENTS

The work described in this paper has been par-

tially supported by the MIUR-PRIN 2008 project

“Cloud@Home: a New Enhanced Computing

Paradigm”.

REFERENCES

Anderson, D. P. and Fedak, G. (2006). The computational

and storage potential of volunteer computing. In Pro-

ceedings of the Sixth IEEE International Symposium

on Cluster Computing and the Grid, CCGRID ’06,

pages 73–80, Washington, DC, USA. IEEE Computer

Society.

Aversa, R., Avvenuti, M., Cuomo, A., Di Martino, B., Di

Modica, G., Distefano, S., Puliaﬁto, A., Rak, M.,

Tomarchio, O., Vecchio, A., Venticinque, S., and Vil-

lano, U. (2010). The Cloud@Home Project: Towards

a New Enhanced Computing Paradigm. In Work-

shop on Cloud Computing: Project and Initiatives

(in conjunction with EUROPAR2010), Ischia (Italy).

Springer Verlag.

Badica, C., Ganzha, M., and Paprzycki, M. (2007). Imple-

menting rule-based automated price negotiation in an

agent system. Journal ofUniversal Computer Science,

13(2):244–266.

Buyya, R., Yeo, C. S., and Venugopal, S. (2008). Market-

oriented cloud computing: Vision, hype, and reality

for delivering it services as computing utilities. In

10th IEEE International Conference on High Perfor-

mance Computing and Communications (HPCC ’08),

pages 5 –13.

Distributed Management Task Force (2010).

The Open Virtualization Format.

http://www.dmtf.org/standards/ovf/.

Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet, S.,

Grosof, B., and Dean, M. (2004). SWRL: A seman-

tic web rule language combining OWL and RuleML.

http://www.w3.org/Submission/SWRL/.

Parameswaran, A. and Chaddha, A. (2009). Cloud Inter-

operability and Standardization. SETLabs Brieﬁngs,

7(7):19–26.

Reservoir Consortium (2011). The Reservoir Project.

http://www.reservoir-fp7.eu/.

The Cloud Computing Use Cases group (2011). Moving To

The Cloud. http://cloudusecases.org/.

The Cloud Security Alliance (2011). Security Guidance

for Critical Areas of Focus in Cloud Computing.

https://cloudsecurityalliance.org/.

The National Institute of Standards and Technology (2010).

Effectively and Securely Using the Cloud Comput-

ing Paradigm. http://csrc.nist.gov/groups/SNS/cloud-

computing/.

The Open Cloud Consortium (2011). The Open Cloud

Testbed. http://opencloudconsortium.org/.

The Open Grid Forum (2011). The Open Cloud Computing

Interface. http://occi-wg.org/.

The Storage Networking Industry Association

(2011). The Cloud Data Management Inter-

face. http://www.snia.org/tech

activities/ standard-

s/curr

standards/cdmi/.

W3C (2009). OWL 2 Web Ontology Language. W3C Rec-

ommendation.

ASEMANTICDISCOVERYFRAMEWORKTOSUPPORTSUPPLY-DEMANDMATCHMAKINGINCLOUD

SERVICEMARKETS

541