See

discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/276088811

A semantic framework to support resource

discovery in future cloud markets

ARTICLE in INTERNATIONAL JOURNAL OF COMPUTATIONAL SCIENCE AND ENGINEERING · JANUARY 2015

DOI: 10.1504/IJCSE.2015.067054

DOWNLOADS VIEWS

5 7

2 AUTHORS:

Giuseppe Di Modica Orazio Tomarchio

University of Catania University of Catania
54 PUBLICATIONS 282 CITATIONS 90 PUBLICATIONS 689 CITATIONS

SEE PROFILE SEE PROFILE

Available from: Orazio Tomarchio

Retrieved on: 01 July 2015
Int. J. Computational Science and Engineering, Vol. 10, Nos. 1/2, 2015 1

A semantic framework to support resource

discovery in future cloud markets

Giuseppe Di Modica* and Orazio Tomarchio

Department of Electrical, Electronic and Computer Engineering,
University of Catania,
V.le Andrea Doria 6, 95125 Catania, Italy
Email: Giuseppe.DiModica@dieei.unict.it
Email: Orazio.Tomarchio@dieei.unict.it
*Corresponding author

Abstract: The market of cloud resources is currently dominated by proprietary solutions

for what concerns resource delivering, pricing models and service level agreements. In the future
cloud markets, when cloud standards will get mature and full interoperability among cloud
systems will be a reality, the competition challenge among providers will be played on the
capability of supplying high and differentiated QoS levels. In this new scenario advanced and
flexible mechanisms to support the matchmaking between what providers offer and what
customers demand must be devised. Along with an analysis of the current cloud offering in
terms of pricing model, SLA negotiation capabilities, service performance levels and cloud
application requirements, this work proposes the definition of a semantic model to support the
supply-demand matchmaking process in future cloud markets. Leveraging on a semantic
description of the cloud resources’ features, customers will be able to discover cloud offers that
best suit their own business needs. Tests conducted on an implementation prototype proved the
viability of the approach.

Keywords: cloud market; cloud ontology; cloud price model; semantic discovery.

Reference to this paper should be made as follows: Di Modica, G. and Tomarchio, O. (2015)
‘A semantic framework to support resource discovery in future cloud markets’, Int. J.
Computational Science and Engineering, Vol. 10, Nos. 1/2, pp.1–14.

Biographical notes: Giuseppe Di Modica received his degree in Computer Engineering in 2000
from the University of Catania (Italy). In 2005, he received his PhD in Computer Science and
Telecommunication Engineering from the University of Catania. The PhD thesis discussed was
entitled ‘A user-centric analysis of the interworking between heterogeneous wireless systems’.
His research interests include mobile agents, ad-hoc networks and wireless networking, mobile
P2P computing, Grid, Cloud and service oriented architectures, and semantic technologies. He is
currently a Research Assistant at the Engineering Faculty of the University of Catania (Italy).

Orazio Tomarchio received his degree in Computer Engineering from the University of Catania
(Italy) in 1995. In 1999, he received his PhD in Computer Science from the University of
Palermo. His scientific activity has focused on studying distributed systems, particularly with
regard to programming and management techniques. His main research interests include
mobile agents, network and QoS management techniques, mobile P2P computing, middleware
for MANETs, Grid and service oriented architectures, cloud computing, security, semantic
technologies. He is currently an Assistant Professor at the Engineering Faculty of the University
of Catania (Italy).

1 Introduction ‘pay-per-use’ business model allows consumers to pay only

for what they actually use, without any initial investment.
Cloud computing has emerged as a popular computing
Despite the cloud technology has been widely adopted in
paradigm that aims at providing remote access to
commercial contexts, time is not mature for open and
on-demand computing capabilities, based on an easy
competitive cloud markets.
pay-per-use business model (Buyya et al., 2008). The real
The main technological reason behind this fact is the
success of the cloud is mostly due to the considerable
lack of interoperability among existing cloud systems
business opportunities that it produces for both consumers
(Parameswaran and Chaddha, 2009). In a desirable
and providers. On the one hand, providers see in the cloud
scenario, the user would like be able to build up its own
model a way to maximise the use of their computing assets
application independently of the specific cloud system that
and minimise the maintenance cost; on the other hand, the
the application will run onto, define the application

Copyright © 2015 Inderscience Enterprises Ltd.

2 G. Di Modica and O. Tomarchio

requirements (both functional and non-functional) in a cloud offers that best meet the request’s requirements. A
standardised way, search for the cloud provider that best first prototype of the semantic discovery framework has
meets the requirements, negotiate for the service provision, been implemented. Experimental results show that the usage
deploy the application, monitor the application performance, of semantic technologies for the characterisation or
moving the application to another cloud in the case that the resources’ business feature enhance the performance of
service provision did not meet the expected performance. supply-demand matchmaking in open cloud markets.
Several issues need to be addressed in order realise such The remainder of the paper is organised as
scenario. The research community is focused on several follows. Section 2 discusses the related work. Section 3
cloud managements aspects: provisioning, metering provides an analysis of the current pricing models and
and billing, privacy, security, identity management, quality negotiation schemes adopted by main business players.
of service (QoS), service level agreements (SLA). Some Section 4 discusses business requirements of some classes
works propose real specifications and promote their of ‘cloudifiable’ applications. In Section 5 the semantic
adoption as standards by the cloud community. It is discovery framework is presented. Section 6 shows the
the case of the open virtualisation format (OVF) results obtained from experimental tests. We conclude the
by DMTF (http://www.dmtf.org/standards/ovf/), the open work in Section 7.
cloud computing interface (OCCI) specifications (The Open
Grid Forum, http://occi-wg.org/), cloud data management
interface (CDMI) (The Storage Networking Industry 2 Related work
Association, http://www.snia.org/techactivities/standards/
Several standard organisations are working hard to
currstandards/cdmi/) by Storage Networking Industry
propose specifications that will enable future
Association. Others advice best practices that should be
scenarios of interoperable cloud services (DMTF,
adopted when dealing with specific cloud management
http://www.dmtf.org/standards/ovf/; The Open Grid Forum,
issues, such as the use cases identified by National Institute
http://occi-wg.org/; The Storage Networking Industry
of Standards and Technology (NIST, http://csrc.nist.gov/
Association, http://www.snia.org/techactivities/standards/
groups/SNS/cloud-computing/) and by the Cloud
currstandards/cdmi/; NIST, http://csrc.nist.gov/groups/SNS/
Computing Use Cases Group (http://cloudusecases.org/),
cloud-computing/; The Open Cloud Consortium, http://
and the work made by the Open Cloud Consortium (OCC)
opencloudconsortium.org/). An exhaustive review of the
(http://opencloudconsortium.org/) to support interoperability
research efforts dealing with interoperability issues in cloud
of clouds.
computing systems was produced in the context of
Even though big cloud players do not really care about
Cloud4SOA project. In the same context, interoperability
interoperability (they just impose proprietary interfaces to
among cloud systems is analysed at different semantic
lock-in customers), we are confident that in a near future
levels (Loutas et al., 2010), with the purpose of identifying
most of the above listed initiatives will accomplish their
the minimum set of requirements to cater for in the
task. Interoperable scenarios will be a reality, and the
definition of a cloud semantic interoperability framework.
providers’ competition for acquiring new customers will be
Many from the scientific community are proposing to
played on the ground of the overall QoS that they are able to
support the process that will lead to interoperability with
offer. This will yield a diversification of the service
tools borrowed from the semantics. There are several
offerings in terms of (to cite a few) adopted security models,
attempts to design ontologies for the definition of
performance monitoring tools, SLA templates, resource
cloud-related concepts and relationships. Still, there is no
negotiation protocols and pricing models.
proposal that has reached a broad acceptance from the
In this paper we focus on the last two of the just cited
community, nor all features of the cloud domain have been
aspects. Specifically, we address the need to support
fully covered so far.
customers in the choice of the price models and negotiation
Some works (Rimal et al., 2009; Youseff et al., 2008)
protocols that best suite their applications need. We
have tried to define taxonomies for cloud-based systems.
advocate that an offering diversification will yield benefits
They mostly identify and classify cloud delivery models,
to cloud providers too, who will be able to define new
services and resources; some also deals with requirements
strategies to reach customers according to specific business
like fault tolerance and security. One of the most complete
targets. In order to build an effective matchmaking process
cloud taxonomy in maintained and continuously updated by
between supply and demand, a structured model to describe
OpenCrowd (2010): in this project, existing cloud providers
resources’ business features and applications’ requirements
and cloud-related software are classified according to a
is needed. To this purpose, we propose two ontologies to
specific scheme.
describe the resources offered by cloud providers on the one
Speaking of initiatives working on the definition of
hand, and the application requirements expressed by
specification for the cloud computing, both standardisation
customers on the other one. Final aim is to devise a new
bodies and commercial players have been proposing their
resource publish/discovery mechanism including pricing
own taxonomies. The NIST (http://csrc.nist.gov/
models, negotiation capabilities and service performance
groups/SNS/cloud-computing/) has proposed a cloud
levels as filter options. A semantic matchmaking algorithm
taxonomy standard. Its definition of cloud computing
will also support the discovery process to search for those
architecture includes basically concepts such as essential
 A semantic framework to support resource discovery in future cloud markets
characteristics, roles, service models and deployment
models. IBM (Kopp et al., 2011) has provided a draft
document describing a reference architecture for cloud
systems. It recalls the NIST and open cloud computing
interface (OCCI) standards, integrating some new elements.
IBM architecture inherits mainly NIST actors taxonomy,
and also addresses the problem of defining quality of
services and SLA. In the aim of defining an open and
standardised cloud interface for the unification of cloud
APIs, the unified cloud interface (UCI) project (Cloud
Computing Interoperability Forum, 2010) has proposed and
released an RDF-OWL cloud data model, mostly covering
the characterisation of resources in the cloud domain.
To the best of our knowledge, the mOSAIC ontology
(Moscato et al., 2011) is the one that covers the highest
number of aspects of the cloud context. It inherits most of
the elements defined in other proposals (OCCI, NIST,
IBM), and deals with aspects such as deployment models,
service models, resources, services, actors, consumers,
functional and non-functional properties, languages, APIs.
The ontology was developed in OWL and is used for
semantic retrieval and composition of cloud services in the
mOSAIC project.
The model we propose in this paper addresses aspects of
cloud interoperability not covered by any of the works cited
above. The proposed perspective is that of a global market
of cloud resources, where there is the need of characterising
what is offered and demanded by actors in terms of business
profit and utility respectively (Di Modica and Tomarchio,
2012). The proposed ontology, therefore, covers a new
portion of the cloud’s domain of knowledge; still, it can be
integrated to existing ontologies/taxonomies to also cover
functional aspects of the cloud.
In addition to the ontology model, this work contributes
to define a semantic discovery framework for cloud service
offers. The framework’s aim is to favour a process of
matchmaking between customers’ business requirements
and providers’ business objectives. Other works in the
literature address this issue adopting approaches that are
slightly different than ours. In Amato et al. (2012), authors
investigate on the lack of negotiation interfaces and
mechanisms by current cloud providers for dynamic
provisioning. They propose a tool for SLA-based dynamic
provisioning of cloud resources, that offers the customer
negotiation and brokering facilities.
In the context of environmental management,
Badica et al. (2012) proposes an agent-based system
exploiting negotiation to dynamically select service
providers and compose processing services. Oldham et al.
(2006) propose a framework to match SLAs described in
OWL. Dobson and Sànchez-Maciàn (2006) and Ardagna et
al. (2006) use semantics as well to implement a framework
for QoS/SLA-based web service selection. In Maurer et al.
(2012), authors present an approach that tries to fill the gap
between offer and demand by guiding the customers in
adapting their requirements to service features advertised in
public SLA templates.
3
The framework we propose does not provide a real
brokering/negotiation service. Brokering services gather
specific customers constraints and objectives, and are in
charge of seeking the specific services (sometimes by
negotiating with the customer as well) which are able to
accomplish them. Our service gathers the customers
business requirements/needs (not just the functional) and
suggests them the kind of service offers that mostly
fit their business objective. To the best of our knowledge
none of the works analysed so far covers all the numerous
aspects characterising the cloud business in the same way
our work does. We opted for using semantic techniques
because of the clear and acknowledged benefits they bring
when facing discovery issues: semantics overperforms
keyword-based techniques for what concerns the customer’s
expectation. On the other end semantic approaches
introduce a computational load that may sometimes impair
performance. Tests we conducted on our prototype, though,
produced encouraging results in terms of overall system
responsiveness.
3 Analysis of current cloud offerings
In this section some of the commercial offerings advertised
by three of the main cloud service providers will be
analysed under the perspective of the adopted price models,
the SLA negotiation support and the offered service
performance level. There are many other business-related
aspects that deserve attention in the characterisation of a
business-oriented perspective of the cloud. Among others
we can cite security, monitoring tools, technical support
service. Such aspects will be furtherer investigated and
taken into account in our future work.
3.1 Price models
The main cloud paradigm’s claimed strength is that
resources (computing, storage, and network) can be
accessed on an on-demand basis, and customers can be
charged according to the actual usage time. In particular, the
CPU is usually charged by the hour, the data storage service
is charged per GB/month, the data transfer service over the
network is charged per GB. Providers also propose their
customers an alternative pricing model based on resource
reservation, which on the cloud provider’s end provides an
instant economic benefit (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 itself is intensively used. Despite the name, this
particular pricing model does not assume that resources are
dedicated to the customer making the reservation. The
customer, within a fixed frame time, only reserves the right
to pay resources less than the standard on-demand price.
Other cloud providers, instead of selling raw resources,
offers cloud-based services in the form of developing and
execution platforms (PaaS) and applications (SaaS). Some
decide to charge the customer according to the usage that
4 G. Di Modica and O. Tomarchio
the provided service makes of the underlying raw resources.
Others (mostly providing business oriented services)
adopt a model that is more suited to those business
applications that, once deployed, involve the interaction of
many end users. The customer 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. The model is mainly adopted to let
the customers try the proposed service for a medium-long
period (from 30 days to a year); at the end of the trial period
the customer will eventually decide to continue using the
service for charge (some refers to this model as the
‘freemium’ model). The model is currently offered by the
big commercial players to gain new customers on the
market, but maybe, in the future, the managers of open
cloud infrastructure (such as those based on volunteered
resources) might want to adopt the model too.
In the forthcoming cloud economy generation other
pricing models might result more attractive for both
providers and customers. In the process of optimising the
usage of internal resources, providers might want to
encourage customers to access their resources during
specific periods of underutilisation (at night, or during the
weekends), and thus would be willing to charge customers
according to ad-hoc, time-oriented models. Again, in the
same way like mobile phone operators do, providers might
even offer their customers pre-paid packages of resources to
be consumed as they like.
In the following, the price models currently offered by
main commercial providers are discussed.
3.1.1 On-demand
All main commercial providers of cloud infrastructures
and services ‘comply’ with the on-demand approach, and
offer to charge customers for the actual period of
time that the resource has been utilised. Amazon
(http://aws.amazon.com/ec2) proposes the so called
on-demand instances, that let users pay for compute
capacity by the hour, with no long-term commitments.
Instances are differently priced according to the
capacity of the requested resource, from less powerful
(micro instance) to more powerful (cluster GPU instance).
Microsoft Azure’s resources (http://www.microsoft.com/
windowsazure) are charged according to the pay-as-you-go
model, which is the commercial name for the on-demand
pricing model. Rackspace (http://www.rackspace.com) as
well lets user pay for what they use. Both Microsoft and
Rackspace also differentiate (and accordingly charge) on the
capacity of instances that can be requested.
3.1.2 Resource reservation
Amazon gives the customer the option to make a low,
one-time payment for each instance they want to reserve,
and in turn they receive a significant discount on the hourly
usage charge for that instance. The instance is reserved for
the customer, whether they decide to use it (in which case
they are charged) or not (they are not charged). The
reservation time goes from one to three years. Same
proposal comes from Microsoft’s Windows Azure under the
name of subscription offer, with the difference that the
minimum subscription (read it reservation) time is six
months. Rackspace does not offer reserved resources, but
rather proposes a Managed Service Level offering, that
provides (at the price of an extra monthly fee and an higher
cost per instance/hour) an additional level of support on
instances, which includes monitoring, operating system
and application infrastructure layer support, and technical
guidance.
3.1.3 End-user-based
For its platform and application services Salesforce.com
(http://www.salesforce.com) adopts the end-user-based
model. The customer deploying their application on the
Salesforce’s cloud is charged by month and by the number
of end users that will have to use the application.
Google charges the customers of its app engine platform
(http://code.google.com/appengine) according to the amount
of resources that their applications make use of (mostly an
on-demand model). An interesting offered feature is that
customers can control their billing by setting for each
application the maximum daily resource budget that the
application itself is allowed to use. Also, Google has
recently launched a new, enhanced, business-oriented
platform (app engine for business) for which it has been
announced that the end-user-based model will apply.
3.1.4 Free-of-charge
To attract new customers, Amazon has introduced a free
usage model called free tier, providing a limited access to
low-capacity resources for a one year time. The Azure’s
free-of-charge proposal is known as free trial introductory
special; it delivers almost as the same service level as
Amazon’s. It seems that Rackspace does not adopt any
try-before-buy strategy. Finally, the very basic service
offered by Google’s App Engine is free of charge:
customers will have to pay only if their applications overuse
a fixed amount of resources (overcome the so called
‘freethreshold’).
3.2 SLA negotiation
Research in cloud computing is pushing toward scenarios
where providers will be able to set-up and offer virtualised
resources, customers will be able to search for, select,
configure and run virtualised resources, and eventually
brokers will have to mediate between the providers’ and
the customers’ business requirements in order to fill the
supply-demand gap. Such a dynamic environment calls for
advanced mechanisms to support the negotiation and the
management of SLAs.
In the literature several proposals for the negotiation and
management of SLA have appeared in the context of GRID
and SOA, but many also address the same issues in the
 A semantic framework to support resource discovery in future cloud markets
cloud computing context too. Actually most of them
provides limited or no support for dynamic SLAs
negotiation, which we believe to be a strict requirement for
the future cloud markets. As for the negotiation protocol,
the OGF’s WS-agreement negotiation (The Open Grid
Forum, 2011) is the most notable standardisation effort. The
proposal is an extension of the former (yet recommendation)
WS-agreement, and is still in progress. It just supports the
one-to-one negotiation scheme and the very simple
offer/counter-offer dynamics. Although some extensions
have been provided (Di Modica et al., 2009), the basic
approach is not efficient and flexible enough for complex
application areas. Auction-based alternatives (Fujiwara
et al., 2010; Zaman and Grosu, 2010; Lin et al., 2010) were
also suggested as more appropriate for highly dynamic
contexts. One of the objectives of the SLA@SOI
European FP7 project (The SLA@SOI Consortium,
http://sla-at-soi.eu/publications/) was to provide negotiation
mechanisms for exchanging offers and counter offers
between customers and providers in a SOA context. The
implemented framework (SLAM) gives support for both
one-to-one and one-to-many negotiations, allows for
multiple rounds of negotiation, and can be adopted in agent
marketplace as well as broker-based architectures. The
Vienna service level agreement framework (VieSLAF)
architecture for cloud service management (Brandic et al.,
2009) introduces the concept of meta-negotiations to allow
two parties to reach an SLA on what specific negotiation
protocols, security standards, and documents to use before
starting the actual negotiation. In Sim (2010), the author
presents the design of a complex cloud negotiation
mechanism to support negotiation activities in cloud
markets. The work discusses about negotiation models,
protocols and strategies in a market of cloud resources
where broker agents tries to maximise the utilities of
providers and customers.
The market of cloud resources is today dominated by
very big commercial providers that impose their charging
models, price quotes and resource availability level, without
any chance of negotiation. As for the resource cost aspect,
for instance, customers can acquire a resource just at the
price that it is advertised at, with no chance for them to
negotiate on the price. Neither providers propose auction-
based sales that let customers compete with each others for
acquiring the resources. Only recently some providers have
introduced some limited negotiation capabilities, as the
Amazon’s spot instances model. This model enables the
customer to bid for unused Amazon capacity. Instances are
charged the Spot Price, which is set by Amazon and
fluctuates periodically depending on the supply of and
demand for Spot Instance capacity. We can say this is the
first attempt to import a very basic form of negotiation
(whose object is just the resource price) into the market of
the virtualised resources. According to this model, on the
one hand the provider gives the user the possibility to
acquire resources at a lower price than the standard; on the
other one, whenever the resources’ demand increases, the
provider reserves the right to pre-empt those resources and
5
give them to better bidders. This very primitive form of
negotiation gives the providers the chance to adopt
more flexible (and economically advantageous) resource
scheduling’s schemes. From the customer’s perspective,
money can be saved at the risk of an increased probability
of resource unavailability. We argue that, similarly to what
happens in some market of goods, the providers should be
given the possibility to tune their selling strategies
according to the resources’ demand and supply levels. This
would bring benefits to providers and to customers as well.
The latter will have the chance to search for resources
according to the associated negotiation scheme that best suit
their own business strategies and needs. Resource price is
just one of the possible term on which negotiations might
take place. There may be several quality parameters that the
customers may want (and the providers may be willing) to
negotiate on. Resource availability, resource reliability,
data security might be terms of negotiations between the
providers and the requestors of the resources. This work
though puts forward the idea that the resource price will
play a crucial role, with respect to that of other parameters,
in the future cloud economy.
3.3 Service performance levels
The performance features that cloud providers advertise are
usually vague, sometimes focused on virtual machines
computation speed, ignoring other aspects such as the
storage and network services performance. The only
parameter which is quantitatively expressed and granted by
all the commercial providers is the availability of resources,
measured as the percentage of time in a one year period that
a resource is up and reachable. All providers guarantee a
very high level of resource 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 delivered services.
The competition among the providers is played on both
on the price at which the resources are sold and the
capability of sustaining the promised, guaranteed service
levels. Some providers further differentiate their service
offer. Besides provisioning what we call a standard basic
service level, which is the core activity of their business,
some of them also offer a premium service level, which
provides more guarantees than the basic and adds extra
services. Amazon’s dedicated instance service offers EC2
instances launched within virtual private cloud that run
hardware dedicated to a single customer. Customers have
the same guarantees as those provided with the basic level
instances, with the advantage of having them running on
dedicated hardware. Note that on this service level, both the
on-demand and the resource reservation pricing models can
be applied. Google’s app engine for business provides the
same ease of use and flexibility of basic App Engine, but
with more power and guarantees to support business-critical
applications. SalesForce’s Force.com platform is proposed
in two different flavours (the enterprise edition and the
unlimited edition) to accommodate at best the needs of their
6 G. Di Modica and O. Tomarchio
customers. Basically, the unlimited edition provides, in
addition to what the enterprise offers, customisation and full
support service.
Those discussed here are the service level models that
are currently being offered in today’s cloud infrastructures.
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 fine-grained customer
requirements, providers might want to propose customisable
plans of service levels, that will enable customers to build
their own desired service level provisioning. The guaranteed
category could encompass more than just the basic and
premium models. Besides the guarantee-based, new models
providing no guarantees on the provided service may appear
as well (best effort service level). In a not so far future,
non-profit communities (universities, public administration
offices) might also be tempted to share their unused
resources in a cloud fashion (Aversa et al., 2011), and most
likely would decide to opt for a best effort service level. In
such scenarios, users will be able to access each other’s
computing resources and open communities’ resources,
possibly at no charge, being conscious that they are going to
receive a service providing low or no assurance on the
resource availability, and a very low support for the
operational management.
4 Application requirements
Every application needing some computing power could
technically run on a cloud. Still security is a big concern that
prevents service providers from unconditionally deploying
their applications on the cloud. The Cloud Computing Use
Cases Group (http://cloudusecases.org/) has recently
published a work where the key factors affecting the
decision of moving an application to the cloud are analysed.
Several considerations need to be made before making that
important decision. Generally speaking, before making the
move a cost/benefit analysis must be carefully done. The
decision concerns both whether to move onto the cloud or
not, and to select the cloud offer that fits. In the following,
we tries to make such analysis from the point of view of the
application that has to be deployed.
One should verify, according to the company’s
business objectives to be accomplished and to how much
mission-critical the application is, whether the application to
be deployed requires a guaranteed service level or a best
effort is enough. If the former is to be chosen, again,
depending on 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
fits must be made according to the application’s profile,
i.e., the application’s specific usage pattern: if such pattern
is ‘dense’ (resources are continuously used within a
timeframe), reserved-based solutions are to be preferred;
otherwise, the on-demand pricing model will result more
convenient.
Finally, the budget availability is the most compelling
among the requirements. All the choices must be made
checking that the budget they require is compatible with the
company’s investment capability. For example, a service
level might fit a given application’s profile, but might not be
affordable for the company; on the contrary, a more
affordable service level would make the company
save money, but might not fit the strict application’s
requirements. In most cases a compromise has to be
searched for.
There follows a list of some of the categories of
applications that are currently being deployed on the cloud.
For each category, considerations are expressed regarding
the service level plans and the pricing models that may
apply.
4.1 Web applications
Cloud-hosted web infrastructure and software offer cost
savings in terms of maintenance costs and rapid
deployment. Depending on how critical the being deployed
service is, further considerations must be made to choose
the service level and the pricing model that best fits. Web
applications have a very intensive usage pattern. The
application should serve users’ requests anytime from
anywhere in the world (24/7). Depending on the level of
criticality exposed by the application, its provider may opt
for a premium service level (highly critical) or for a basic
service level (low critical). To make an example, it would
be the case to opt for a premium service level for a web
appliance advertising discounts on commercial products
(temporary degradation of the service might turn into
heavy losses), while for a weather forecast website a basic
service level would be enough (no relevant consequences
in case of service failing). The best effort level should
instead be discarded, as service discontinuity might very
negatively affect the usage pattern. As for the pricing,
the reservation-based model is to be preferred to the
on-demand. If we make a break-even analysis, we would in
fact discover that for continuous usage patterns and
long-lived appliances (like the web applications’) the
reservation-based is more profitable.
4.2 Business applications
Moving applications like CRM, ERP, human resources and
financial solutions onto the cloud have demonstrated to limit
up-front investment and costly integration required for
in-house deployments. However, data security has limited a
wider deployment of business applications on public clouds.
The criticality of service and the need for high data
availability in this specific context is such that premium
solutions should be preferred. The business applications
have a discontinuous usage pattern (mostly accessed
during the business hours), but nonetheless the application
should be always up and running (24/7 pattern). Again,
reservation-based is an advantageous option from the cost
point of view, but the end-users-based option has to be
evaluated as well. Depending on the number of users that
 A semantic framework to support resource discovery in future cloud markets
are going to make use of the application, the latter of the
two options might result more profitable.
4.3 High performance computing applications
Several high-performance-computing-based applications
can benefit from the cloud paradigm. In most cases, those
applications occasionally require a huge amount of
computational resources to complete in a very short period
of time. It is the case of rendering processes (e.g., to create
film special effects), drug development in a pharmaceutical
company, financial modelling at a bank, testing a new
feature of an on-line game at a software house. The
application pattern is such that very powerful resources are
accessed in a limited period of time, so the on-demand
approach seems to be a cost-effective solution. Once again,
one has to evaluate
a how often the cloud resources have to be accessed
in a given time frame, just to check whether a
reservation-based option would be better
b how mission critical is the application to run,
in order to choose the appropriate service level: highly
mission-critical applications would surely require a
premium service level, for other applications even
the best effort could be enough (think about a
university sharing its data centre’s resources for testing
scientific-purpose applications).
5 Supply-demand matchmaking
The previous analysis of current cloud offering has shown
that the provider and the customer perspectives are quite
different. The former seeks to maximise the profit and the
utilisation level of their IT asset. The latter needs to make
fine-tuned searches on the market in order to discover the
service fitting their specific business needs. We have then
designed a service discovery framework that exploits
semantic mechanisms to favour the matchmaking of the
providers’ offer and the customers’ demand. Two ontologies
have been developed. The first ontology semantically
describes the features of the resources being offered by
cloud providers, the second describes the application’s
business requirements expressed by customers. As each
Figure 1 Mapping and matching
7
ontology contains semantic concepts belonging to two
different domains, we have devised a mapping process, that
makes use of a rule system based on SWRL, able to
transform application requirements into ‘semantically’
equivalent resource features, i.e., features that best represent
the application 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 resource s) on which a semantic procedure will try to
make the match.
Figure 1 depicts the two semantic domains, along
with the mapping and matchmaking processes. In the figure,
the filled circles represent, respectively, real requests
issued by customers (within the application requirements’
domain) and real offers advertised by service providers
(resource features’ domain). Through the mapping process
the application requirement AR4 is transformed into its
‘equivalent’ resource feature offer RF6 (empty circle) in the
offers domain. Such resource feature does not necessarily
coincide with a real offer, rather, it represents the ideal offer
that would perfectly match the considered application
requirement. In the next step, the matchmaking procedure
explores the resource features’ domain in order to search
for concrete offers that show a semantic affinity to RF6
(those covered by the grey area in the figure). The final
outcome of the entire process will be a list of concrete
offers, sorted by the semantic affinity degree, that may
satisfy the business needs represented by AR4.
In the following subsections we provide an overview of
the two ontologies, respectively describing the application
requirements and the resource features domains, and give
some details on how the mapping and the matchmaking
processes work.
5.1 Ontology design
We have designed two simple and extensible OWL-based
(W3C, 2012) ontologies that may be of help to semantically
characterise the resources offered by cloud providers and
the requirements expressed by customers. This is a very first
attempt to define the base for a more comprehensive and
complete ontology framework, but we believe it is sufficient
to give the reader a rough picture of the idea being proposed
in this work.
8 G. Di Modica and O. Tomarchio

5.1.1 Resource features’ ontology cloud providers, as earlier discussed at the beginning of the
section. As depicted in the figure, the charged class is
In its current state the resource features’ ontology focuses
linked to the NegotiationModel class by means of the
on the concepts that, according to us, best represent the
hasNegotiationModel property. This link models the
cloud resources from the providers’ business perspective
negotiability of the price of any non-free offer. The service
and that have been analysed in Section 3: the pricing model,
provider is allowed to select the negotiation model that
the service performance level and the negotiation model.
accommodate at best its vending strategy’s objective. In
Figure 2 depicts a comprehensive view of the developed
particular, as explained in Section 3.2, there are two big
ontology. Ellipses represent ontology classes. A solid arrow
categories of negotiation models: the OneToOne, which
models an is-a relationship between two classes, while
models private negotiation models between a customer and
arrows with dashed lines are object properties defined
a provider, and the OneToMany, representing all the public
among classes. Basically, a cloud offer is the main concept
negotiation schemes in which many customers compete to
of the ontology. An offer regards the provisioning of a cloud
acquire the resource offered by one provider.
service, that can be in the form of IaaS, PaaS of SaaS.
As regards the service performance level class, it is
Among the features that an offer can exhibit, we have
subclassed by the best effort and guaranteed classes as it
depicted the pricing model that will be used to charge the
results from the analysis shown in Section 3.3. The former
customer, and the service performance level associated to
represents the category of services for whose performance
the provisioning of the service that the offer refers to.
no guarantee is provided; the latter represents the services
The pricing model is partitioned into two disjoint
for which a basic guarantee is offered, those for which a
concepts (classes): free of charge and charged. Free of
premium level guarantee is provided, and those allowing for
charge represents the category of services offered for free
a customisation of the performance level to be delivered.
(see ‘try-before-buy’ strategies). Charged embraces all
The object property, linking the customised class to the
pricing models that charge the customer for the
OneToOne class, models the possibility for the provider to
service usage. In this tentative ontology, charged is
select the preferred negotiation scheme to be used when
further subclassed by the on-demand, reservation and
contracting with the customer for the QoS to be delivered.
end-user-based concepts. The three sub-concepts represents
the pricing categories currently adopted by commercial

Figure 2 Resource features ontology

 A semantic framework to support resource discovery in future cloud markets
5.1.2 Application requirements’ ontology
From the analysis carried out in Section 4, an ontology
defining the application requirements has been developed
(depicted in Figure 3). A dashed arrow originating from a
concept and pointing to a box represents a concept’s data
property, whose range of values is indicated within the box
itself. Basically, a customer 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 (charged and free concepts). In the first
case, the customer may want to also specify the amount of
the budget at his disposal. At this stage, two qualitative
values are allowed (‘high’ and ‘low’) but a more detailed
specification 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 publicly
negotiable (canNegotiate property).
In the case of computing resources, the customer is
given the possibility to specify whether he has a plan for
utilising the resource (UtilisationPlan concept), and a
timeline for that plan (hasDuration data property). A
resource ConsumptionPlan, indicating how ‘dense’ will be
the consumption of the resource for the duration of the plan,
may also be specified (by means of the hasDensity
property). Finally, customer may want to specify the
MissionCriticality of the application/service that is going to
Figure 3 Application requirements ontology
9
be deployed in the cloud. These parameters aim to model
what in Section 4 we earlier referred to as application
requirements.
5.2 Mapping
The mapping process is a simple procedure that applies a
list of mapping rules. Rules have been defined using the
Semantic Web Rule Language (SWRL) (Horrocks et al.,
2004). SWRL was chosen since it is a W3C specification
and it copes well with OWL-based ontologies. The
objective of each rule is to transform a specific application
requirement into the ideal, best matching resource feature.
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 matchmaking process, of which details
are provided in the next section.
The definition of the rules follows a heuristic approach.
Considerations stemming from the analysis conducted in
Sections 3 and 4 drove the design of the rules. So, for
instance, an application requiring to run in the long term and
consuming loads of computation resources, is best served by
offers advertising reservation-based price models in the case
that budget is a constraint. Or again, highly performing
resources must be suggested to applications with real-time
constraints in the case that budget is not a problem.
10 G. Di Modica and O. Tomarchio
From the technological point of view, a group of chained
semantic rules drive the mapping from individuals of the
Application requirements’ ontology to individuals of the
Resource features’ ontology. A rule engine takes a request
in input, applies the sequence of rules and, according on the
rules that match, incrementally builds up the ideal offer. For
the sake of brevity, we report only a significant subset of
rules:
1 request : Request(?request) ∧ offer : Offer(?offer)
→ hasMatchedOffer(?request, ?offer)
2 hasMatchedOffer(?request, ?offer) ∧
request : Computing(?request) ∧
offer : provides(?offer, ?service)
→ offer : IaaS(?service)
3 hasMatchedOffer(?request, ?offer) ∧
request : Platform(?request) ∧
offer : provides(?offer, ?service)
→ offer : PaaS(?service)
4 hasMatchedOffer(?request, ?offer) ∧
request : Software(?request) ∧
offer : provides(?offer, ?service)
→ offer : SaaS(?service)
5 hasMatchedOffer(?request, ?offer) ∧
request : hasPrice(?request, ?price) ∧
request : Free(?price) ∧
offer : hasPriceModel(?offer, ?priceModel) ∧
offer : hasPerformanceLevel(?offer, ?performance)
→ offer : FreeOfCharge(?priceModel) ∧
offer : BestEffort(?performance)
6 hasMatchedOffer(?request, ?offer) ∧
request : hasPrice(?request, ?price) ∧
request : canNegotiate(?price, ?negotiation) ∧
request : Public(?negotiation) ∧
offer : hasPriceModel(?offer, ?priceMod) ∧
offer : NegotiationModel(?negModel)
→ offer : hasNegotiationModel(?priceMod,
?negModel) ∧
offer : OneToMany(?negModel).
Rule 1 just states that, given a generic request in the
application requirements’ domain, a corresponding ideal
offer exists in the resource features’ domain. Rules 2
through 4 handle the different type of cloud services that
can be requested. The rules are very intuitive, and states that
a request for computing resource is mapped onto an offer of
the type IaaS, a request for a Platform resource is mapped
onto a PaaS offer, and a request for a Software resource
maps to an offer of the type SaaS. Rule 5 states that a
request asking resources for free will be mapped onto offers
advertised as free of charge for which the guaranteed level
of performance is best effort. Rule 6 maps a request for a
generic cloud service, for whose price the customer is
willing to negotiate in a public auction. This request is
mapped onto offers advertising negotiation of the
OneToMany type.
5.3 Matchmaking
After the mapping process has elaborated the ideal offer, the
matchmaking process will start exploring the domain of the
real offers in order to find those ones whose features best
meet the initial application requirements. In particular, for
each offer advertised in the market, the matchmaking
process will evaluate the semantic affinity between that
offer and the ideal one. The semantic affinity will reveal
how close a real offer is to the customer expectations.
Ontologies have been designed in such a way to let
customers and providers specify requests and offers at
shallower or deeper level of details. If a customer request is
made up of individuals created from concepts whose depth
in the ontology trees is low (i.e., closer to root concepts),
then it expresses very general requirements that will likely
match a large number of offers. Instead, in the case of a very
detailed request (represented, e.g., by leave concepts in the
ontology trees) a reduced set of offers will match.
The semantic affinity will be a value in the range [0, 1],
1 being the highest achievable affinity. This will allow us to
present the customer with a list of concrete offers (sorted by
the affinity criteria) that will ease the task of selecting the
best offer. The function that calculates the semantic affinity
is the following:
A = Serva ∗ Wserv + Pricea ∗ W price + Perf a ∗ W perf
+ Neg a ∗ Wneg
The overall affinity between the ideal offer and a real offer
is obtained by summing up four components which,
respectively, represent the sub-affinities evaluated on
each offer’s feature: service, price model, performance level
and negotiation model. So, for instance, the addendum
Pricea ∗ Wprice represents the sub-affinity evaluated on the
price feature. In particular, Pricea is the outcome of the
semantic comparison between the price concepts exposed
by the two individuals (the offers), while Wprice is a weight
factor that can be employed to privilege the price criteria in
the evaluation of the overall affinity. Each parameter has an
associated weight factor. We plan to use this factor to give
the customer the power to tune the affinity algorithm
according to customisable priority criteria. For the tests
discussed in the next Section, all weights are equally
assigned 0.25.
We now provide some details on the semantic
comparison of concepts. Let Oj(Servo−j, Priceo−j, Perfo−j,
Nego−j) be a generic offer, where Servo−j, Priceo−j, Perfo−j,
Nego−j represent the semantic concepts characterising the
offer. In order to evaluate the overall semantic affinity of
two offers Oideal (the ideal offer that is the outcome of the
mapping process) and Oreal (a real offer in the market place),
couples of homologous concepts (i.e., referring to the same
feature) must be compared. So, Servo−ideal will be compared
to Servo−real, Priceo−ideal will be compared to Priceo−real, and
so on. In general, the concept Co−ideal must be compared to
its homologous Co−real. Let us now focus on that branch of
the ontology tree to which the generic concept/feature C
 A semantic framework to support resource discovery in future cloud markets
refers to. Four different cases are relevant to our evaluation.
Let us analyse all the possible cases:
• the two concepts are semantically equivalent [Figure
4(a)]: they are assigned 1
• Co−ideal is the father of Co−real [Figure 4(b)]: their affinity
will be 1 as well
• the two concepts are siblings and the father is the root
concept in the considered branch [Figure 4(c)]: their
affinity will be 0.5
• the two concepts are siblings and the father is a non-
root concept in the considered branch [Figure 4(d)]:
their affinity will be 0.75
• Co−ideal is not expressed: the affinity will be 0
• in any other case, the concepts’ affinity will be 0.5.
The algorithm assigns the highest value to equivalent
concepts, or to concepts that are in a father-son
relationship. Instead, it penalises two concepts that are
direct descendants of a root concept, as in our ontology
siblings concepts whose father is root represent opposite
Figure 4 Concepts comparison
(a)
(c)
11
concepts (e.g., Charged vs FreeOfCharge, Guaranteed vs
BestEffort). Conversely, siblings whose father is a non-root
concept are considered different but someway ‘close’
concepts (e.g., OnDemand vs Reservation, EnglishAuction
vs DutchAuction), therefore they are given a higher grade of
affinity.
6 Implementation and test
A prototype of the framework was implemented and tested.
For the design of the ontologies and of the semantic rules
the Protégé editor tool was used. The core of the framework
consists of an ontology mapper, a matchmaker supported
by a semantic reasoner powered with the Pellet library
(Sirin et al., 2007), and a repository of advertised cloud
offers. The overall framework was implemented as a web
application. Customers are then provided with a front-end
tool to build and submit cloud requests, while at this stage
the repository of cloud offers was populated by hand. In the
future we plan to implement a tool that will help providers
to build their offers and upload them to the repository.
(b)
(d)
12 G. Di Modica and O. Tomarchio

For the test purpose, we generated a complete set of offers
spanning the whole semantic domain of resources’ features:
it resulted in a repository containing around 30,000 offers.
Afterwards, several different requests were generated, each
of them asking for a specific cloud service. For each
submitted request, the framework replied with a list of
fitting offers. All tests were conducted on off-the-shelf
desktop PC equipped with an Intel Core i5 processor and
4GB of RAM: despite the computing capacity demanded by
the semantic reasoning procedures and the large number of
offers populating the repository, the average response time
for a query was observed to be less than one minute.
In the following we describe two sample requests and
analyse the corresponding results provided by the discovery
procedure. In the first request the customer asks for a
service of type Platform, for whose price he is willing to
negotiate in the context of a public auction:
R1(Type : Platform, PriceModel : Charged,
NegotiationModel : Public)
After submission, the mapping process was run. From the
overall list of available SWRL rules, the following applied
to R1:
• request : Request(?request) ∧ offer : Offer(?offer)
→ hasMatchedOffer(?request, ?offer)
• hasMatchedOffer(?request, ?offer) ∧
request : Platform(?request) ∧
offer : provides(?offer, ?service)
→ offer : PaaS(?service)
• hasMatchedOffer(?request, ?offer) ∧
request : Platform(?request) ∧ request :
hasPrice(?request, ?price) ∧ request : Charged(?price)
∧ offer : hasPriceModel(?offer, ?priceModel) ∧ offer :
hasP erformanceLevel(?offer, ?performance) →
offer : EndUserBased(?priceModel) ∧ offer :
Guaranteed(?performance)
• hasMatchedOffer(?request, ?offer) ∧
request : hasPrice(?request, ?price) ∧
request : canNegotiate(?price, ?negotiation) ∧
request : Public(?negotiation) ∧
offer : hasPriceModel(?offer, ?priceMod) ∧
offer : NegotiationModel(?negModel)
→ offer : hasNegotiationModel(?priceMod,
?negModel) ∧
offer : OneToMany(?negModel)
First rule does nothing but create the ideal individual offer
in the resource feature domain. Second rule maps the
‘Platform requirement into the ‘PaaS’ feature, Third rule
transforms the ‘Charged’ requirement into the
‘EndUserBased’ feature for what concern the price model,
and the ‘Guaranteed’ feature for what concerns the support
level. The last rule maps the customer’s willingness to
negotiate for the price (‘canNegotiate’) to the ‘OneToMany’
negotiation feature.
The mapping process, then, transformed R1 into the
following ideal offer:
O1ideal ( Service : PaaS , PriceModel : EndUserBased ,
ServicePerf ormanceLevel : Guaranteed ,
NegotiationModel : OneToMany )
For that offer, the matchmaking process produced the
results depicted in Table 1. As the list is very long many
results have been omitted. On top of the list the perfectly
matching concrete offers appear. Offers with an affinity
value of 0.875 have a partial matching, as those offers do
not provide any kind of negotiation. Offers at the bottom
have a very poor match because of differences in both the
service type and the service performance level.
Here is the second request that we tested:
R 2(Type : Computing ,
UtilisationPlan − > hasDuration : long ,
ConsumptionPlan − > hasDensity : high)

Table 1 List of matching offers for request R1

Offer # Service PriceModel SPL NegModel Affinity

39 PaaS EndUserBased Basic ContractNet 1.0
49 PaaS EndUserBased Premium EnglishAuction 1.0
48 PaaS EndUserBased Premium DutchAuction 1.0
... ... ... ... ... ...
36 PaaS EndUserBased Customised n.a. 0.875
35 PaaS EndUserBased Basic n.a. 0.875
... ... ... ... ... ...
3 SaaS FreeOfCharge BestE_ort n.a. 0.5
1 IaaS FreeOfCharge BestE_ort n.a. 0.5
 A semantic framework to support resource discovery in future cloud markets
Table 2 List of matching offers for request R2
Offer # Service PriceModel
10 IaaS Reservation
... ... ...
33 IaaS Reservation
32 IaaS Reservation
... ... ...
12 IaaS OnDemand
... ... ...
After submission, the mapping process transformed R2 into
the following ideal offer:
O 2ideal ( Service : IaaS , PriceModel : Reservation,
ServicePerformanceLevel : Premium,
NegotiationModel : no)
For that offer, the matchmaking process produced the
results depicted in Table 2. As expected, offers proposing
the reservation-based price model have the best matching; in
fact, they perfectly fit the application requirements
concerning the utilisation plan and the resource
consumption plan. Offers proposing auctions are lightly
penalised. Offers advertising a basic performance level get
penalised more.
7 Conclusions
Commercial cloud providers are trying to take advantage of
the business opportunities that the cloud computing
paradigm has brought. Today a very few big players
dominate the market. They lock-in their customers by
imposing proprietary solutions. In fact, for customers, the
process of migration from a cloud provider to another cloud
provider is still painful. In a near future, when
interoperability among clouds will be technically achieved,
there will be the need to rethink the way the provision of
virtualised resources has to meet the applications’ demand.
The market of cloud resources will have then to provide
novel and advanced matchmaking processes that account for
the providers’ and the customers’ dynamic and
heterogeneous business requirements, respectively in terms
of profit and utility. The work presented here, in the aim of
supporting the design of future supply-demand
matchmaking processes, is a first attempt of defining a
semantic model to describe cloud resources’ business-
related features. Specifically, we have focused on features
like the pricing models, the negotiation protocols and the
service performance levels. In the future we are going to
enrich the described semantic model, and integrate it to
existing and widely accepted ontologies that describe the
cloud domain from other perspectives, so as to integrate
other filtering criteria to the discovery process.
13
SPL NegModel Affinity
Premium n.a. 1.0
... ... ...
Premium DutchAuction 0.9375
Premium ContractNet 0.9375
... ... ...
Basic ContractNet 0.8125
... ... ...
References
Amato, A., Liccardo, L., Rak, M. and Venticinque, S. (2012)
‘SLA negotiation and brokering for sky computing’,
in CLOSER 2012 – Proceedings of the 2nd International
Conference on Cloud Computing and Services Science,
pp.611–620.
Ardagna, D., Giunta, G., Ingraffia, N., Mirandola, R. and
Pernici, B. (2006) ‘QoS-driven web services selection in
autonomic grid environments’, in Robert Meersman and
Zahir Tari (Eds.): On the Move to Meaningful Internet
Systems, pp.1273–1289, CoopIS, DOA, GADA, and
ODBASE, Vol. 4276 of Lecture Notes in Computer Science,
Springer, Berlin Heidelberg.
Aversa, R., Avvenuti, M., Cuomo, A., Di Martino, B.,
Di Modica, G., Distefano, S., Puliafito, A., Rak, M.,
Tomarchio, O., Vecchio, A., Venticinque, S. and Villano, U.
(2011) ‘The Cloud@Home project: towards a new enhanced
computing paradigm’, in Euro-Par 2010 Parallel Processing
Workshops, Springer Verlag, Vol. 6586 of Lecture Notes in
Computer Science, pp.555–562.
Badica, C., Ilie, S., Kamermans, M., Pavlin, G., Penders, A. and
Scafes, M. (2012) ‘Multi-agent systems, ontologies
and negotiation for dynamic service composition in
multi-organizational environmental management’, in Software
Agents, Agent Systems and Their Applications, IOS Press,
Vol. 32 of NATO Science for Peace and Security Series – D:
Information and Communication Security, pp.286–306.
Brandic, I., Music, D., Leitner, P. and Dustdar,S. (2009)
‘VieSLAF framework: enabling adaptive and versatile
SLA-management’, in Proceedings of the 6th International
Workshop on Grid Economics and Business Models, GECON
‘09, Springer-Verlag, Berlin, Heidelberg, pp.60–73.
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 High Performance
Computing and Communications, HPCC ’08, 10th IEEE
International Conference on, September, pp.5–13.
Cloud Computing Interoperability Forum (2010) UCI Cloud OWL
Ontology [online] http://code.google.com/p/unifiedcloud/
(accessed 17 December 2012).
Di Modica, G. and Tomarchio, O. (2012) ‘A semantic discovery
framework to support supply-demand matchmaking in cloud
service markets’, in CLOSER 2012 – Proceedings of the 2nd
International Conference on Cloud Computing and Services
Science, Porto, Portugal, April, pp.533–541.
Di Modica, G., Tomarchio, O. and Vita, L. (2009) ‘Dynamic SLAs
management in service oriented environments’, Journal of
Systems and Software, May, Vol. 82, No. 5, pp.759–771.
14 G. Di Modica and O. Tomarchio
Distributed Management Task Force (DMTF), The Open
Virtualization Format [online]
http://www.dmtf.org/standards/ovf/ (accessed 17 December
2012).
Dobson, G. and Sànchez-Maciàn, A. (2006) ‘Towards unified
QoS/SLA ontologies’, in Proceedings – SCW 2006: IEEE
Services Computing Workshops, pp.169–174.
Fujiwara, I., Aida, K. and Ono, I. (2010) ‘Applying double-sided
combinational auctions to resource allocation in cloud
computing’, in Proceedings – 2010 10th Annual International
Symposium on Applications and the Internet, SAIN 2010,
pp.7–14.
Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet, S., Grosof, B.
and Dean, M. (2004) ‘SWRL: a semantic web rule language
combining OWL and RuleML’ [online]
http://www.w3.org/Submission/SWRL/ (accessed 17
December 2012).
Kopp, P., Dieckmann, R., Breiter, G., Pappe, S., Kreger, H.,
Arsanjani, A., Behrendt, M. and Glasner, B. (2011)
‘Introduction and architecture overview’, IBM Cloud
Computing Reference Architecture 2.0.
Lin, W-Y., Lin, G-Y. and Wei, H-Y. (2010) ‘Dynamic auction
mechanism for cloud resource allocation’, in Proceedings of
the 2010 10th IEEE/ACM International Conference on
Cluster, Cloud and Grid Computing, CCGRID ‘10, IEEE
Computer Society, Washington, DC, USA, pp.591–592.
Loutas, N., Peristeras, V., Bouras, T., Kamateri, E., Zeginis, D.
and Tarabanis, K. (2010) ‘Towards a reference architecture
for semantically interoperable clouds’, in IEEE Int. Conf. on
Cloud Computing Technology and Science (CloudCOM
2010), pp.143–150.
Maurer, M., Emeakaroha, V.C., Brandic, I. and Altmann, J. (2012)
‘Cost-benefit analysis of an SLA mapping approach
for defining standardized cloud computing goods’, Future
Generation Computer Systems, Vol. 28, No. 1, pp.39–47.
Moscato, F., Aversa, R., Di Martino, B., Fortis, T. and Munteanu,
V. (2011) ‘An analysis of mOSAIC ontology for
cloud resources annotation’, in Computer Science and
Information Systems (FedCSIS), 2011 Federated Conference
on, September, pp.973–980.
Oldham, N., Verma, K., Sheth, A. and Hakimpour, F. (2006)
‘Semantic WS-agreement partner selection’, Proceedings
of the 15th International Conference on World Wide Web,
pp.697–706.
OpenCrowd (2010) The OpenCrowd Cloud Taxonomy
[online] http://cloudtaxonomy.opencrowd.com/
(accessed 17 December 2012).
Parameswaran, A.V. and Chaddha, A. (2009) ‘Cloud
interoperability and standardization’, SETLabs Briefings,
Vol. 7, No. 7, pp.19–26.
Rimal, B.P., Choi, E. and Lumb, I. (2009) ‘A taxonomy and
survey of cloud computing systems’, in INC, IMS and IDC,
NCM ’09, Fifth International Joint Conference on, August,
pp.44–51.
Sim, K. (2010) ‘Towards complex negotiation for cloud economy’,
in Advances in Grid and Pervasive Computing, Springer
Berlin/Heidelberg, Vol. 6104 of Lecture Notes in Computer
Science, pp.395–406.
Sirin, E., Parsia, B., Grau, B.C., Kalyanpur, A. and Katz, Y. (2007)
‘Pellet: a practical OWL-DL reasoner’, Web Semantics,
Vol. 5, No. 2, pp.51–53.
The Cloud Computing Use Cases Group, Moving to the Cloud
[online] http://cloudusecases.org/ (accessed 17 December
2012).
The National Institute of Standards and Technology (NIST),
Effectively and Securely Using the Cloud Computing
Paradigm [online]
http://csrc.nist.gov/groups/SNS/cloud-computing/ (accessed
17 December 2012).
The Open Cloud Consortium (OCC), The Open Cloud Testbed
[online] http://opencloudconsortium.org/ (accessed 17
December 2012).
The Open Grid Forum (2011) WS-Agreement Negotiation
Specification [online]
http://forge.gridforum.org/sf/go/projects.graap-wg/.
The Open Grid Forum, The Open Cloud Computing Interface
[online] http://occi-wg.org/ (accessed 17 December 2012).
The SLA@SOI Consortium, SLA@SOI Negotiation Platform
[online] http://sla-at-soi.eu/publications/ (accessed 17
December 2012).
The Storage Networking Industry Association, The Cloud
Data Management Interface [online] http://www.snia.org/tech
activities/standards/currstandards/cdmi/.
W3C (2012) OWL 2 Web Ontology Language (W3C
Recommendation) [online] http://www.w3.org/TR/owl-
overview/ (accessed 17 December 2012).
Youseff, L., Butrico, M. and Da Silva, D. (2008) ‘Toward a
unified ontology of cloud computing’, in Grid Computing
Environments Workshop, GCE ‘08, November, pp.1–10.
Zaman, S. and Grosu, D. (2010) ‘Combinatorial auction-based
allocation of virtual machine instances in clouds’,
in Proceedings of the 2010 IEEE Second International
Conference on Cloud Computing Technology and Science,
CLOUDCOM ‘10, IEEE Computer Society, Washington, DC,
USA, pp.127–134.