4CaaSt Marketplace: An Advanced Business Environment for Trading Cloud Services

Andreas Menychtas1, Jürgen Vogel

2, Andrea Giessmann

2, Anna Gatzioura

1, Sergio Garcia Gomez

3,

Vrettos Moulos1, Frederic Junker

2, Mathias Müller

2, Dimosthenis Kyriazis

1, 4,

Katarina Stanoevska5, Theodora Varvarigou

1

1 National Technical University of Athens, Greece

2 SAP Research, Switzerland

3 Telefónica Investigación y Desarrollo, Spain

4 University of Piraeus, Greece 5 University of St. Gallen, Switzerland

ameny@mail.ntua.gr, juergen.vogel@sap.com, andrea.giessmann@sap.com, agatz@mail.ntua.gr, sergg@tid.es,

vrettos@mail.ntua.gr, f.junker@sap.com, mathias.mueller@unifr.ch, dimos@mail.ntua.gr

katarina.stanoevska@unisg.ch, dora@telecom.ntua.gr

Abstract. As Clouds mature and become ubiquitous, marketplace environments are developed

facilitating the provision of services in a manner that emphasizes on the modular composition of

individual services across different providers that crosscut the cloud service stack layers (i.e.

composition of XaaS) to fulfil customers’ requirements. Besides acting as intermediaries for the

search, selection and trading of services, such marketplaces should also support the complete

service lifecycle and the consolidation of offerings from different providers with varying and often

contradicting business goals. In this paper we present a one-stop cloud marketplace solution that

addresses the aforementioned challenges while enabling the simulation of different business cases

to optimize service offerings according to a wide and dynamic set of parameters. Moreover, the

proposed solution introduces advanced aggregated price models and integrates a new resolution

approach that incorporates business intelligence into the search and selection processes. We also

demonstrate the operation of the implemented approach and evaluate its effectiveness using a real-

world scenario, based on a taxi fleet management application.

Keywords: marketplace, cloud computing, cloud service, XaaS, business resolution, analytics,

simulation, optimization, price model

1 Introduction Following an increasing number of technical advancements in the area of cloud computing, the notion

of XaaS (Everything as a Service) [2], [40] is nowadays very common across the cloud providers to

characterise the trading and provisioning any type of ICT assets as cloud products. To this direction,

many different types of providers can be identified, that offer a variety of cloud-based services across

the cloud stack layers, according to the SPI model [39], with the most widely accepted ones referring to

Software (SaaS), Platform (PaaS) and Infrastructure (IaaS) as a Service. Various characteristics, such

as virtualization of hardware, rapid service provisioning, scalability, elasticity, accounting granularity

and cost allocation models enable Clouds to efficiently adapt resource provisioning to the dynamic

demands of Internet users.

In this new paradigm, users’ and providers’ requirements go beyond the aforementioned technical

characteristics, getting into the business space [4]. "The interesting question is whether and how

services will be traded in the future" [8]. In a world of multi-stakeholder information and services,

environments are required that will allow for the seamlessly integration of business and technical

aspects into the service provision process. To this direction, emerging marketplaces aim at enabling the

provision of “products” as potentially composite service offerings that may incorporate services from

different providers within and across the cloud service stack layers [5]. Marketplaces provide a focal

point for various stakeholders supporting the complete service lifecycle (planning, analysis and design,

development and testing, provisioning, deployment, discovery, composition, execution, and monitoring

[30]). What is more, marketplaces support advanced pricing and billing capabilities [28], by

considering and managing various and possibly diverse business terms and conditions (i.e. price,

revenue sharing, promotion). Even though the term “marketplace” is a business term, cloud

marketplace environments address several technical challenges besides business ones. Support for the

heterogeneity of services, has been highlighted as one of current Internet design principles that should

remain in the Future Internet architecture [18]. To this direction, marketplaces allow for products

offering consisting of potentially heterogeneous services from different providers. Furthermore, a

fundamental new design principle of the Future Internet architecture refers to information diffusion and

exchange leading to the so-called “all-win” situation [18]. As described in the corresponding report,

future internet should allow for “the exchange of information between layers and players principle,

which suggests that different stakeholders should be able to provide to others information on possible

choices and their preferences”. Information diffusion enabled through marketplaces refers not only to

aggregation, collection and assessment but also to decision making in a multi-stakeholder environment.

Marketplace mechanisms allow for such decision making through approaches that interpret high-level

business and technical requirements and provide selection proposals and recommendations for product

compositions. Moreover, marketplaces go beyond SLA-based selection of services [11] or discovery of

services based on performance prediction and analysis; marketplaces employ techniques for pricing

models and business resolution revenue sharing through analysis of existing dependencies between the

providers of the corresponding products.

Cloud marketplaces, as environments where all stakeholders who involved in the service lifecycle

participate to satisfy their business goals, are not very common, while the few existing approaches

(analysed in Chapter 2) lack of basic functionality, such as the support of composite offerings or the

automated resolution of the customers’ requirements. Therefore the need of forward-looking

marketplaces for cloud services and resources that follow the technical advancements of cloud

technologies is noticeable. These one-stop shops of cloud offerings will both improve the effectiveness

of Clouds as true business ecosystems and also leverage the wide adoption of cloud technologies.

In this paper we present a marketplace environment for the provision of cloud services through a

dynamic and fair ecosystem of all involved stakeholders. Providers utilize marketplace functionalities

to define new product offerings, business-related information and service level objectives, while users

may pose specific service requests and contract providers. Nevertheless the unique offerings of the

proposed marketplace are not limited to the aforementioned provider-user interaction and the

underlying product aggregation and composition, but are focused on the interplay between technical

and business aspects of service provisioning addressing the challenges related with pricing models in

distributed environments [10], [41]. The marketplace incorporates a pricing simulator for the offered

products, allowing providers to evaluate the pricing model accompanied with the product and linked

with its (technical and business) characteristics. According to the simulation process, the marketplace

proposes specific pricing models and implements them for each product in a dynamic way. The latter

allows for product customization given that service aggregation and deployment may be configured

based on the users requirements and current market context (i.e. dynamic offerings from providers).

Furthermore, the marketplace enables for automated revenue sharing across different providers based

on their contributions in the offered product, while delivering end users with an end-to-end solution for

selecting products based on technical and business criteria, which are in sequel considered by the

marketplace functions during the contracting and provisioning process. The proposed marketplace has

been developed in the framework of 4CaaSt EU-funded research project [1]. However, the algorithms

and functionalities have been developed following a service oriented architectural design that allows its

incorporation in any cloud environment since it can be invoked as a (third-party) service (see Chapter

5), while the data being exploited can be defined through the schema described in Section 6.1.

The rest of the paper is structured as follows. Chapter 2 presents the related work on electronic

marketplaces and the outcomes of a survey on the capabilities of existing electronic marketplace

environments. Chapter 3 highlights the role of the proposed solution in a cloud environment. The key

innovations of the proposed marketplace are presented in Chapter 4, while the architecture and

implementation details are presented in Chapters 5 and 6 respectively. Chapter 7 presents experimental

outcomes on a marketplace prototype and the evaluation outcomes from a group of experts. Finally

Chapter 8 concludes our work and highlights our future plans for its extension.

2 Related Work There are various approaches emphasizing on the importance of mediators in electronic markets [9],

[20]. Even from the older computational grid environments and the early cloud implementations,

marketplace frameworks had an important role, especially on the transition from a scientific to a more

business ecosystems [12], [24], [7]. Such markets aim at enabling service requests and the

corresponding offering in a structured manner, price negotiation, contract definition and customization

as well as accounting and billing [15], [23]. These environments are also enhanced with

recommendation mechanism for effective services selection [47] as well as SLA negotiation and QoS

management features to ensure that the resources are provisioned within the quality, time and budget

constraints posed by the customers [37], [45].

Table 1. Evaluation of existing marketplaces for electronic services

Marketplace

Functionality

Win

do

ws

Azu

re

Ma

rket

pla

ce1

Go

og

le A

pp

s

Ma

rket

pla

ce2

Ap

pE

xch

an

ge

on

Fo

rce.

com

3

Go

og

le P

lay

Sto

re4

Su

iteA

pp

.com

5

Zo

ho

6

1. Information phase

1.1 Product Definition + + + + + +

1.2 Product Search + + + + + +

1.3 User Bid for Missing Applications - + + - - +

1.4 Related Products + + + + + +

1.5 Recommendation - - + + - -

1.6 Advertisement - - + + - -

1.7 Community Rating & Comments + + + + + +

1.8 Social Analysis - - - + - -

2. Negotiation phase 2.1 Bid to Product - - + - - +

2.2 Product Resolution + + + - + -

2.3 Product Specification + + + + + +

2.4 Product Customizing - + + - - -

2.5 Composite Resolution - + + - - -

2.6 Real-time Resolution - - + - - -

2.7 Profile-based Resolution - - - + - -

2.8 Basket Management - + + + - -

3. Contracting phase

3.1 Contract Management - + + + - -

4. Settlement phase

4.1 Delivery Support + + + + + +

4.2 Payment Support + + + + + +

4.3 Rating & Charring - + - - - -

4.4 Settlement & Revenue Sharing - - - - - -

5. Analytics

5.1 Reporting on Products - + + + - -

5.2 Competitive Products Rankings - - + - - -

5.3 Business Model Simulation - - - - - -

Based on the above, electronic marketplaces support five main phases (i.e. information provision,

negotiation and price setting, contracting, analytics, and settlement) and accommodate the needs of

1 http://www.windowsazure.com/en-us/services accessed: 20. December 2013 2 http://www.google.com/enterprise/marketplace accessed: 20. December 2013 3 http://appexchange.salesforce.com accessed: 20. December 2013 4 http://play.google.com/store accessed: 20. December 2013 5 http://www.netsuite.com/portal/suiteapp/main.shtml accessed: 20. December 2013 6 http://www.zoho.com/creator/marketplace/marketplace.html accessed: 20. December 2013

three main roles (i.e. service providers, end users, and marketplace providers). What is of importance

refers to the service orientation of electronic marketplaces, being placeless and ubiquitous, as any

cloud-based service [44]. Table 1 summarizes an initial evaluation of the most sophisticated, existing

electronic marketplaces for cloud-based services. There has to be noted that the functionalities of each

phase (listed in the table) will also serve as features and evaluation criteria for the presented electronic

marketplace.

In regard to the first informational phase, the following comments can be made: all basic browsing

functionalities are supported by every marketplace, for example, those that allow users to search the

service catalogue for products fitting their needs. These are, for instance, the following features:

Product Definition (1.1), Product Search (1.2), and Related Products (1.4). In terms of advertisement

(1.6) however, classical banners displayed inside the marketplace interface to promote a specific

service are only implemented by AppExchange and even in this particular case, Service Providers can

only advertise on the marketplace page where their own product is described. Features from the second

phase of a typical marketplace transactions that support the negotiation between customers and

providers, are implemented in most of the marketplaces. However, this is not the case for the

marketplace of Microsoft.

Features related to contracting (feature 3.1) as well as the basic steps of the settlement phase (features

4.1 and 4.2) are the main actions needed in very simple cases like a classical web shop ordering

process. In regard to these basic needs, trading services instead of goods does not make much

difference. That is to say, first the customer chooses atomic service or a composition of services in an

instance of shopping basket (feature 2.5), then the detailed terms of the contract are reviewed (features

3.1) and finally the order can take place. From the three marketplaces that support these features, every

one of them can trigger the delivery of the product (feature 4.1) as well as insure a proper payment of

the services for the customer. Marketplace analytics like product report (feature 5.1) are available in

three of the compared platforms; they compute a kind of income report and hand the details out to the

Service Providers. In case of Google Apps, Google Play Store and AppExchange, these statistics are

mainly based on the number of instances sold. Meaning, the marketplaces keeps track of the

marketplace transactions. Further marketplace analytics like the competitive products ranking (5.2) are

only implemented by the Google Play Store, which establishes a ranking comparing similar apps and

displaying them to potential customers.

Advanced service and application directories, enabling structured registration of products, are

considered as another marketplace implementation concept – adopted by Windows Azure Marketplace,

SuiteApp.com and Zoho. While these directories cover the information phase of marketplaces they do

not offer functionalities required by the other phases (i.e. negotiation, contracting and settlement),

which are left to the service providers. Google Play Store supports all phases however there has to be

noted that the hosted and advertised services are not cloud-based services, since they are installed

locally, while also they cannot be aggregated and composed into new services. A similar solution is

provided by the Google Apps Marketplace that exploits various Google tools (e.g. Checkout, Analytics

or Product Ideas) to cover the different phases of a market transaction. The Google Apps Marketplace

itself puts emphasis on refined search functions for consumers and delegates other phases of the market

transaction to complementary Google products. Salesforce.com has developed AppExchange, which is

the most advanced marketplace compared to the previous ones, also covering cloud-based services. The

proposed 4CaaSt marketplace addresses these gaps, especially the price model simulation, dynamic

price definition, advanced selection and revenue sharing features, which is not offered by any cloud

enabled marketplace, by providing innovative solutions that are described in detail in Chapter 4.

3 The Marketplace in a Cloud Environment As discussed in the previous chapter, electronic marketplaces accommodate a wide set of features and

embrace novel characteristics in order to allow for effective trading of cloud based services and

resources. The proposed marketplace has been designed and implemented as part of 4CaaSt cloud

platform [21] to address the requirements and use cases for a) individuals, b) SMEs and c) enterprises,

however, by following service oriented design principles and by defining abstraction layers for the

communication with the underlying platform elements, the marketplace can be associated with any

modern cloud platform or provider.

Fig. 1. 4CaaSt Cloud Platform Lifecycle [21].

The 4CaaSt project encompasses the whole lifecycle of an application in a cloud environment, from its

development to the commercialization and deployment (Fig. 1). After the development of the software

components that comprise an application, 4CaaSt provides a description language called blueprint [13],

[36] that allows the developer to describe the dependencies or requirements that the application has in

order to be deployed on the cloud. The proposed marketplace extends the blueprint technical details

with business parameters (such as pricing models), following the product specification described in

section 6.1, to merchandize the application/service and create product offerings that will be traded and

contracted through the marketplace. The product description is an integral part of the contract to be

signed by the customer, and also references to the blueprint in order to provide to the platform the

complete set of information needed for the effective selection and configuration of cloud resources in

to deploy and provision the application, which in technical level is achieved by transforming the

blueprint and the agreed product offer to OVF++ [21], a 4CaaSt extension to OVF [14]. After the

deployment, the platform starts monitoring and registering the usage of resources to respectively

trigger elasticity actions and charge the customers.

To this direction, 4CaaSt marketplace, which represents one of the key innovations provided by the

project, is considered as the frontend that the PaaS provider offers to service providers to publish

market offerings and to customers to search and contract these offerings. Based on the analysis of the

electronic marketplaces in the previous chapter and the cloud platforms’ capabilities, the key roles for a

cloud marketplace, as well as the related stakeholders, have been identified. On the consumer side, we

can distinguish between a) end-consumers, who just consume a certain service, usually SaaS, b)

business customers, in particular SMEs, who take advantage of the cloud services available on the

marketplace, for example to deploy their own instances of applications in the cloud, and c) enterprises

that exploit the platform resources as a special case of cloud bursting. On the provider side, we can

distinguish between a) Infrastructure as a Service (IaaS) providers, usually enhanced with Network as a

Service (NaaS) capabilities, b) Platform as a Service (PaaS), and c) Software as a Service (SaaS)

providers [39]. Other important entities in this value network are the software providers (or vendors),

who offer the software to be deployed on the cloud resources (applications and middleware), as well as

the service aggregators with the role of both consumer and provider, combining offerings of different

types into new composite products that will be merchandised afterwards in the marketplace.

4 4CaaSt Marketplace Innovations Even though a cloud marketplace shares many characteristics with the generic electronic marketplaces,

it includes some unique features being part of a modern cloud environment, which were in fact the

motivation for our work. In the following sections we analyse how the 4CaaSt Marketplace addresses

these challenges and which are in fact the innovations introduced with the realization of these features.

It should be noted that our main effort on this marketplace, for which a prototype is already

implemented and integrated with the rest 4CaaSt platform, was focused on the aspects of dynamic

pricing models, price simulation and the effective resolution of customers’ requests. However, as a

cloud integrated marketplace, the typical processes such as contracting, payments, etc. are also

supported using or extending though off the shelf solutions.

4.1 Cloud Integrated Marketplace The proposed marketplace fosters the creation of dynamic business ecosystems in which multiple

service providers may find a fair environment to develop and provide new services [29]. The support of

flexible revenue models will help cloud providers to monetize the effort of creating and maintaining the

platform, while service providers can make business with a zero capital expenditure (CAPEX) entrance

barrier [27].

The marketplace supports the trading of all different types of services in a unified way; a “one stop

shop” for all type of service offerings: SaaS, PaaS, IaaS, NaaS or generally XaaS. A tight relationship

with the service engineering layer supports the specification of commercial offers for any type of

service, using the most appropriate revenue models for each service, simplifying the process of

building applications. The marketplace can also apply specific policies and constraints for deciding

which platforms and services will be used in the final service deployment, based on the business

requirements of both the service provider and the customer.

Fig. 2. Main Marketplace Phases and Processes

The main marketplace processes are separated in four different phases (Fig. 2) as already described in

[5]. In the first phase, so called information phase, the market players need to exchange information.

During the second phase, so called negotiation and price setting phase, after the consumer has chosen

certain services, resolution and price building takes place. The consumer is allowed to define specific

constraints for their request or to select from a set of customization options, predefined by the service

provider, for a particular product. The marketplace will identify any business dependencies and

propose a selection and combination of services and resources that satisfy the constraints that are

defined by the consumer. In the third phase (contracting), when the provider and the consumer have

agreed on a specific set of product and business terms, a legally-binding contract has to be defined

before the services are delivered. At the settlement phase, the services running in Cloud are

provisioned, monitored and accounted according to the signed contracts. Since the services may be the

result of a resolution and composition process, the marketplace revenue sharing mechanism simplifies

the accounting process allowing the service providers to foster the usage of their offer in the final

applications and services. The four main phases of the marketplace are also enhanced with the

marketplace analytics functionality. The marketplace analytics is a horizontal process that aggregates

information from various sources (operational, business, social, user feedback) in order to gain

knowledge for improving the business terms and conditions for the existing or new products and

business models.

4.2 Generic Handling of Price and Revenue Models Depending on his business model, a service provider may choose one or more price models for each of

the service offerings. In the general case, the price is a function that depends on one or more

parameters. For instance, a price may be the combination of a fixed subscription rate s plus a

transaction fee tf, say price p(x) = s + x tf, where x can be the number of service calls, the time elapsed

while interacting with the service or the quantity of resources consumed. A provider may also choose

to define several different price model alternatives for the same service in order to meet different

customer demands. Also, a price model may be adapted during the negotiation phase between service

provider and service consumer. A key functionality of our marketplace is that it allows the service

provider to define appropriate price models and supports him on this task, e.g., by preconfigured, best

practice price models or by simulation and analysis. The price model is formalized and can be

leveraged, e.g., to automatically select services based on the user’s pricing preferences or to calculate

payments to be made by service consumers based on their actual service consumption.

The proposed pricing framework, the implementation of which is previously described [26], also

envisions that several existing service offerings can be combined into new, composite ones, either by

one of the original service providers or by another one (who would then either be a mere reseller or

provide a value-added service). In the general case, each service may be based on other services

forming a service network. At the same time, each service is offered by a certain provider who may

then be the consumer of another provider. The marketplace processes allow service providers (and

consumers) to analyse this business network and calculate the overall price model for the consumer of

a service network. Vice versa, when distributing the generated income for a certain market transaction

from the final consumer to all involved providers according to the business network, the resulting

complex revenue sharing model is also managed by the marketplace.

4.3 Price Model Simulation A simulation tool is currently a core component of the 4CaaSt Marketplace, thus the aforementioned

aspects can be effectively evaluated by the service providers minimizing the risk of wrong estimations

on the cost and increasing the return of their investment on a new or customized product or price model

[16]. A provider may choose to define several different price model alternatives for the same service in

order to meet different customer demands. The price model has a large impact on the potential market

share, revenue, and profit of a service offering and choosing the right model is a vital albeit difficult

task for service providers. The simulation tool offers different visualization, simulation and

optimization options. For composite services that that require third-party services to operate, a

dependency graph is displayed complete with the price models for each service in the graph together

with the anticipated usage of a service, the expected revenues, expected costs of employing third-party

services and profit. One of the innovations introduced in this tool is that, as a component integrated in

the marketplace, the usage of a service can either be predicted on the basis of a mathematical usage

function (to be defined by the user) or on the basis of historic usage data observed by the marketplace

simplifying in that way the price model definition process and allowing for dynamic model adaptation

following the current market conditions and trends.

4.4 Service Search, Selection, and Resolution One of the most important features of the marketplace is the resolution of the customers’ requirements

to appropriate products or product compositions that will be contracted and provisioned [3]. The

requirements are typically associated with high level, application-specific aspects of the product and in

that sense, a great advancement of the marketplace will be the capability to analyse and translate

customer requirements to a set of technical and business parameters for services, technologies and

resources. During this resolution (both technical and business, as it will be explained in next chapter),

appropriate contract terms that include obligations and policies for the provisioning of a product on the

required Quality of Service (QoS) level, are identified and selected.

Part of this process is also the selection of appropriate price model(s) capable to support effectively the

business aspects of a product based on the customers QoS and/or business constraints. The resolution

and selection of products and price models is based on a dynamic set of parameters, taking into

consideration not only the customer’s request but also information such as the user profile (contextual

information related with a user), the market and infrastructure status and the experience about the

effectiveness of previous resolutions. In order to support this, a business resolution engine was

implemented following a pluggable architectural design, to allow developers, providers and

marketplace operators to produce advanced and sophisticated algorithms for the resolution of specific

types of requests or products. The dynamicity of the resolution process enables further optimization of

native and immigrant products and platform resources, in both technical and business level, and also

the development of new, personalized product offerings, product compositions, and price models which

latter can be handled smoothly by the marketplace and the underlying cloud platform(s).

5 Architecture The detailed architectural design of the 4CaaSt marketplace including the main components,

repositories and interfaces with the rest 4CaaSt Platform and the end-users is presented in Fig. 3. The

architectural design follows service oriented design principles and an independent data model for

information exchange (see section 6.1). The motivation for that was first of all the coupling of the

marketplace from a specific cloud platform so as to be compatible with any cloud environment and

provider. The marketplace uses an abstraction layer for the communication with the platform to realize

the deployment, provisioning, monitoring and accounting of the various services. This layer can be

extended and theoretically adapted to any cloud platform. In addition, the marketplace innovations

were considered of major importance for the proposed service oriented architectural design both in

terms of functionality and performance. Besides the typical marketplace functionality, our work

introduces the innovative aspects of dynamic pricing modes, price simulation and business resolution

of customers’ requests.

Initially, following the identification of the main processes of a cloud marketplace in Chapter 3, the

elements were designed to realize these processes: a) the Front End for the communication with the

end users providing all required information on the products and price specifications, b) Pricing and c)

Business Resolution for analysing the customer’s request, d) Contracting & Settlement for the effective

provisioning of the selected product(s) and finally e) Analytics for the optimization of the offered

products and price models.

Fig. 3. 4CaaSt Marketplace Architecture

On the top layer, the marketplace Front End accomplishes the communication with the end-users

including both Service Providers and Customers and consists of four main components: a) User &

Profile Management, b) Product Management, c) Requirements Definition & Product Customization

and d) Reporting. As all electronic marketplaces, 4CaaSt Marketplace includes an independent user &

profile management component for maintaining the user database and also to realize the authentication,

authorization and accounting features. In addition to its state-of-the-art capabilities, the user

management will communicate with the Product Management and the Analytics in order to encompass

the user experience and satisfaction of using a product in the product definition, which will be

exploited in the selection of future products, and also provide recommendations to the users to fine

grain their requirements increasing the QoS and/or lowering the cost. The Product Management

component is responsible for the definition of the business terms and conditions of a product based on

the technical offer described in the respective blueprint [13], [36]. Therefore the product definition in

the marketplace can be considered as a business extension to the technical description of the service

which includes its dependencies and platform requirements as specified in the blueprint.

The 4CaaSt Marketplace supports advanced business and price models and to this direction, the

product management incorporates into the product definition the complete price model for the offering,

which will be later consolidated with other product price models (if there are dependencies to other

services) into a consolidated product offer to be contracted. Customers access the marketplace through

the Requirements Definition & Product Customization components, posing the requirements and

constraints for their requests. Finally Reporting component presents to all stakeholders that are

involved in the product provisioning the billing and accounting details such as cost, violations and

penalties, in time intervals as agreed in the contract.

The Business Resolution subsystem is of major importance in a marketplace where any kind of cloud

assets (XaaS and XaaS compositions) can be traded. Initially the Offer Management Component

analyses the customer’s request and coordinates the offer building. This includes communication with

the Technical Resolution mechanism of the platform in order to acquire technically valid service (or

service compositions) solutions that realize the customers’ request. For one each of them, Price

Aggregator calculates the final cost which, along with the other business characteristics of the product

such as availability and rating, is used to create the best, for the given request, offer.

Contracting & Settlement elements carry out the respective processes as described in Chapter 3. It

should be noted that the marketplace does not use formal language to describe the contracts and the

contracting process is based on the blueprint and product specifications which already support complex

business and pricing models, including, among others, penalties and revenue sharing. Once the

customer agrees on an offer, the respective contracts are generated and a provisioning request is

forwarded to the platform to deploy and initialize the required services and also to configure the

management and monitoring mechanisms. During the service(s) provisioning these mechanisms

provide monitoring information and events to the Accounting & Billing component in order to calculate

the cost and proceed to the revenue sharing and payments.

The performance analysis of products and of their associated price models is elementary for any

business environment. The proposed marketplace addresses the analytics challenge introducing two

key components in the architecture, the Simulator and the Historical Analysis. On the one hand

Simulator is used offline to examine all price models that are applicable to a product offer and based on

the product target group develop applicable price models which are expected to maximize the profit.

On the other hand Historical Analysis will evaluate the monitoring, accounting and billing data of

previous product offers and make recommendations on the parameters of the product definition or the

price model that should be updated. In this process the customer experience and satisfaction of using a

product will be also taken into consideration.

6 Implementation In this chapter we describe the implementation details for the 4CaaSt Marketplace, focusing on its

unique features.

6.1 4CaaSt Product Specification One of the main objectives of the proposed marketplace is to be able to trade any kind of cloud-based

services following the notion of XaaS. In that sense, the product model that is used in all marketplace

processes should be carefully designed in order to cover the technical and business aspects of any XaaS

offering. The product model is depicted in Fig. 3. It is described as an XML Schema, in order to

facilitate the exchange of product instances between the different components of the marketplace.

Fig. 4. Product Schema

The product description includes the following information:

ProductName: The name of the product to be shown to the customer.

BlueprintId: The Id of the service on which the product is based.

ProductDescription: A customer friendly description of the product.

PublicationDate: Date of release of the product in the marketplace.

ValidityFrom: Date from which the product can be contracted in the marketplace.

ValidityUntil: Date until which the product can be contracted in the marketplace.

Version: Release version of the product.

Brand: Commercial Brand of the product/service provider.

ServiceProviderId: Id of the service provider in the marketplace.

License: Textual name of the (usually software) license that applies to the product.

Attribute: A set of configuration attributes, fixed in design/definition type that allows the customer

to customize the application or service. This attributes are specified with a name, unit, range of

values and step.

Price: Defines the cost of the product based on other technical or business parameters (price

model) and is described by the Unified Service Description Language (USDL).

Status: If the service is already active or not in the marketplace.

ProductType: Description of the type of product/service (SaaS, PaaS, IaaS).

Category: Application category (games, databases, etc.).

The product specification is highly related with the blueprint specification (using the BlueprintId

parameter for referring to a specific blueprint) however, the focus and objectives of each specification

is completely different. While the blueprints cover the technical aspects of the service offerings (e.g.

resource requirements, initialization and management rules, dependencies), the products define the

business characteristics which are used in the various marketplace processes. In other words, our

approach introduces another abstraction layer so as to decouple the business and the technical aspects

of an offering allowing on the one hand for effective selection of offerings through algorithms that

exploit the various business parameters (since blueprints guarantee technical compliance) and on the

other for deployment and provisioning of the services traded via the blueprints into different providers

minimizing any lock-in issues.

6.2 Price Models This section presents the 4CaaSt marketplace’s approach towards (1.) defining price models in a

machine-readable data format, and (2.) efficiently computing the cost the provider of a composite

service incurs by using third-party services. Beyond, section 6.3 presents the determination of an

optimal price model for a composite service under consideration of market conditions, such as demand

and supply. The price model of a product defines how much the consumer is charged, depending on

how much the product is used. As described in the previous section, the 4CaaSt Marketplace uses the

Unified Service Description Language (USDL) to store price models in machine-readable documents.

Thereby, the marketplace can automatically compute how much the consumer is charged, given how

much the product was used [16]. Our approach of employing a standardized language to describe price

models is partially analogous to existing approaches [10], yet represents the “time” property differently

to express monthly flat-rate payments. Also, it does not include a “user profile” to support user-specific

pricing and represents the “quality class” through SLAs with separate price models for each service

level. Caracas et al. [10] further describe software components to handle the pricing process, some of

which are equivalent to components of the 4CaaSt marketplace.

As mentioned, one of the main innovations of the 4CaaSt marketplace is the concept of composite

services, which rely on third-party services offered by different providers. One example composite

service, with its third-party services depicted in a product graph, is displayed in figure Fig. 5. The

4CaaSt marketplace uses machine-readable data on service functionalities to automatically select the

most appropriate third-party services for a composite service. Advantages of this automatic

combination of services from different vendors include reduced cost, more functionality and greater

flexibility in service choice. However, such automatic creation of composite services results in a very

large number of service combinations, each of which needs to be priced properly. To set the price

model of a composite service, the provider needs to consider an extended set of cost factors7: (1.)

development and operating cost of the composite service itself, and (2.) cost incurred by using third-

party services. In particular, the 4CaaSt marketplace’s ability to automatically create composite

services results in the latter of these cost factors to change over time, without intervention from the

provider of the composite service. To prevent pricing decisions from thereby becoming unreasonable

and to avoid manual work in handling revenue streams within a large number of different composite

services, the 4CaaSt Marketplace can automatically aggregate several machine-readable price models

into one cumulative price model. Thereby, the provider of a composite service can analyse which costs

incurred by using those third-party services, and can specify the price model for the composite service

accordingly. The 4CaaSt marketplace can automatically notify the provider of a composite service of

changed conditions, such as new third-party services being offered, and suggest an updated price

model.

This remainder of this section gives an overview of the definition and aggregation of price models [16].

The billing unit is the “unit per which the consumer is charged for using the service”. For instance, the

service provider (SP) can charge the service consumers (SC) of his/her service by month. The payment

assessment metric (PAM) defines the “basis by which the consumer gets charged for using a service”.

Currently, the 4CaaSt Marketplace supports the following PAMs:

Table 2. PAMs and their associated billing units

PAM Description: Consumer pays for: Billing Units

Subscription “time frame during which the product

can be used”

Day, Week, Month, Quarter,

Year

PayPerUseEvent “event of interaction with the service“ Invocation, Transaction

7 These cost factors determine the minimum price for the service offering to be profitable. Pricing based on supply

and demand is supported by the price simulation presented in section 6.3.

PayPerUseTime “time of actual interaction with the

service”

Millisecond, Second, Hour,

Day, Week

PayPerUseQuantity “quantity of resources consumed by

interacting with the service”

Kilobyte, Megabyte, Gigabyte

A price model component (PMC) is a “linear function which maps a number of consumed billing units

to a payment”, which is charged to the service consumer (SC). The PMC possesses a price, which

applies per billing unit. Further, the PMC possesses a PAM and a billing unit associated with the PAM,

as per Table 1. Also, a PMC only applies within the validity time frame, which is determined by the

two dates and { }. Usage of the service occurring outside this time frame does not

count into the consumed billing units which are subject to the PMC in question. A PMC also possesses

a discount rate between 0% and 100%, which the service provider can set. Finally, a price model is a

set of PMCs. The payment generated by a price model equals the sum of the payments generated by

each of its PMCs.

Beyond the simple definition of price models, the 4CaaSt Marketplace can automatically aggregate

several machine-readable price models into one cumulative price model. Thereby, the provider of a

composite service can analyse which costs he/she incurs by using those third-party services, and can

specify the price model for his/her composite service accordingly.

Price aggregation transforms a set of price models {P1, P2, ..., Pn} into a single price model P such that

P always generates the same payment as the sum of P1,...Pn, no matter how many billing units were

consumed at what point in time. As a trivial approach, the price models {P1, P2, ..., Pn} can be

aggregated by adding all of their PMCs to the (initially empty) resulting aggregate price model P (see

figure 4, upper plot). However, the goal of the price aggregation as employed by the 4CaaSt

Marketplace is to:

1. Minimize the number of PMCs in P in order to speed up the computational handling of price

models by the 4CaaSt Marketplace, e.g. during billing and composite service pricing, and

2. Avoid overlapping PMCs in P to computationally simplify billing and other processes8.

At the current stage, the price aggregation prioritizes the second goal over the first, resulting in the

possibility of increasing the number of PMCs in the output price model (see Fig. 5). However, the

number of PMCs will still increase by less than factor 2 [16]. Additionally, the 4CaaSt marketplace

also possesses a price aggregation algorithm that accepts the possibility of overlapping PMCs in return

for a guarantee that the number of PMCs will not increase.

8 Two PMCs c1 and c2 overlap when c2.tVFrom < c1.tVTo and c2.tVTo > c1.tVFrom or vice versa.

Fig. 5. Price aggregation algorithm demonstrated by means of one example.

6.3 Simulating and Analysing Price Models While the 4CaaSt Marketplace supports many different pricing options as described above and

therefore offers a high flexibility to service providers, defining a specific price model for a service

offering may also be quite challenging: On the one hand, the price model has a large impact on the

potential market share, revenue, and profit of a service offering and on the other hand the service

provider may not have sufficient experience from previous offerings or lack knowledge about the

targeted market segment.

To make reasonable decisions in defining price models, the 4CaaSt marketplace provides a simulation

and analytics tool that can be used either for exploring different pricing options upfront for a new

service offering or for optimizing the price model for an existing offering. The tool offers different

visualization, simulation and optimization options. For composite services that are constructed from

different other services, the product graph is displayed (see Fig. 6) completely with the price models

for each service in the graph. The novelty of the price model simulation tool is the incorporation of the

composite services concept into the traditional cost-profit calculations that analyse the interrelations

between price, sales, revenue, cost and profit.

The example product displayed in Fig. 6 is the Taxi manager, which allows a taxi company to

constantly keep track of its taxi fleet and optimize the allocation of taxis to customers as orders come

in. The taxi manager requires two third-party services: A location service allows for keeping track of

the geographical location of each taxi, and an SMS service is required for customer contact. These two

services, in turn, require further third-party services. As mentioned in the previous section, each of the

third-party services employed by the taxi manager has its own price model, according to which the

provider of the taxi manager needs to pay the provider of the third-party services.

The price simulation tool assists the provider of the taxi manager in determining a price model to

achieve a business goal, which can e.g. be maximizing profit or maximizing market share. Historical

data on usage of similar services is used to predict the usage of the taxi manager, depending on its price

model (price-usage function). Additionally, the provider determines mathematical functions that map

the consumption of the Taxi Manager to the consumption of each third-party service (usage functions).

For instance, each call by a taxi company to the Taxi Manager requires to get the location of each taxi

and to contact one customer by SMS, and therefore results in e.g. 10 calls to the location service and

one call to the SMS service. The usage function determining the consumption of the location service

would therefore return “10 x u”, where u is the number of calls made by the taxi company to the Taxi

Manager. In contrast, unlike the Taxi manager and the location service, the SMS service is billed based

on a monthly fee, independently from the number of calls made by the Taxi Manager, so that usage

function would always return “1”. Such functions do not need to be entered for third-party services

required indirectly, such as the “DB Service” in Fig. 6. The providers of the Location Service and SMS

Service have already used the price simulation tool to determine the price model for their services.

Based on these mathematical functions, the price simulation tool can determine the revenue and costs

depending on the Taxi Manager’s price model. Thereby, the price model is optimized to achieve a

given business goal, such as maximizing profit, maximizing market share, minimizing cost and others

[34]. As such optimization problems easily become intractable, the price simulation tool employs a

genetic algorithm to find a near-optimal price model in reasonable time [22]. A detailed example is

given in section 7.2.1.

Fig. 6. Example composite service

The price model simulator works by analysing the flow of money within the entire service value

network of a specific product (see product graph in Fig. 6). The monetary flow is analysed only within

a service network and external costs such as integration costs, marketing and promotion costs, taxes,

etc. are currently not considered. All products in a service value network that are composite 4CaaSt

products themselves may be inspected in detail. As a basic economic model, three monetary flows are

relevant:

1. The revenue model measures the ability of a company to translate the value it offers to its

customers into money and therefore generate incoming revenue streams [6]. Each product

generates one or more revenue streams as specified in its price model. The revenue of an

inspected product is in favour of its provider. It equals to the payment that is generated

according to the price model of the inspected product applied to the cumulated usage of all its

customers during a specific accounting period.

2. The costs structure measures all the costs a firm incurs in order to create, commercialize and

deliver value to its customers [6], [33]. All directly used products generate costs for their

value proposition usage of the inspected product. As mentioned in the introduction of this

section only the costs that arise in the product graph are considered. The costs for the provider

of an inspected product are the figured up costs that each of its directly used products

generate. The costs that a directly used product generates are the payments that its price model

specifies for the usage that the inspected product made to it during the accounting period.

3. The profit model is the difference between revenue model and cost structure [25]. Thus the

profit model is the revenue that is generated from the revenue model minus the costs that are

generated from the cost model applied to an inspected product for the usage during a specific

accounting period.

6.4 Product Search and Selection The requirements of a customer are usually associated with a set of high level, application-specific

parameters and features of a product offering. Additionally, the services which are commercialized

through the cloud marketplace, except from technical specifications and dependencies, are associated

with several business characteristics (e.g. price model, availability, security level, reliability,

Taxi

Manager

Location

Service

SMS

Service

DB Service

DB Service

community ratings, energy efficiency etc.) and the QoS levels that a service has to be provisioned

through. Therefore an important feature of a cloud marketplace and a great advancement of the 4CaaSt

Marketplace is the resolution of customers’ requirements into service offerings or compositions, able to

address the request, as well as the selection the most appropriate, among the list of possible products

(based on generic and also personalized criteria) to ensure customer satisfaction.

The steps of the resolution of the customer request can be seen in following sequence diagram, where

the box area highlights the core part of the resolution.

Fig. 7. Product Search and Selection Process

The product resolution in a marketplace refers to identifying services (and/or service compositions)

capable to address effectively the business aspects of the customer’s request. A customer’s request as

imposed through the Marketplace Front-end can be divided into a technical and a business part, a

process that is performed by the Offer Management Service as coordinator of the resolution process.

The Technical Resolution is resolved in the platform level following an approach based blueprints and

it is analysed in [13]. The Business Resolution refers to the set of the user business parameters of

interest with their threshold values, which together with the outcome of the Technical Resolution

(generates the list of technically valid solutions), form the input of the Business Resolution process.

The output of the Technical Resolution is the list of the product candidates for a specific request that

are described as abstract services, called Abstract Resolved Blueprints (ARB). Each ARB is described

as a full analysed graph including all underlying requirements, dependencies and references to

resources and/or to other services. The ARBs are used for the deployment and initialization of the

resources and services, including virtual machines, network links and installation of software etc., but

from the marketplace perspective, also affect the business characteristics and QoS of the final product

offer.

For building the final product offer, the ARB list is analysed and respective products (inlcuding their

business characteristics and their price models) are retrieved from the Marketplace Product Catalogue.

This list is filtered to ensure that the product candidates meet the request criteria and only the products

that may overcome these limitations are further taken into account and evaluated. In parallel, the Price

Aggregator is called and a complete price model is constructed for each abstract resolved service. A

selection algorithm is then applied in order to conclude to an optimal, or close to optimal, product offer

that will be finally contracted by the Contract Service and the respective services and resources are

deployed and instantiated.

The service selection problem is treated as a multi-attribute decision making problem [46], [43], [42].

Based on the analysis of the predicted usage, the characteristics and preferences of customers

(customer type, member type, favourite brand, open reservations etc.) as retrieved from their profile,

different importance factors for the parameters of interest are automatically generated and a product

rate is calculated for each product candidate. The most highly ranked product is the one that is going to

be selected and contracted. As the number of products in the cloud ecosystem and dependencies among

them increases, along with the diversity of customer business requirements there is a need for

mechanisms, like the proposed, handling these issues in an automatic and effective manner.

7 Evaluation and Experimentation A prototype of our work has already been implemented, deployed and configured on the cloud

infrastructure of Flexiscale [17] along with the rest 4CaaSt platform. Since, as we already mentioned in

Chapter 4, the focus of our work is on the flexibility of pricing models and the business resolution of

customers’ requests, the evaluation on the marketplace features had a similar scope. The methodology

that we followed for the evaluation had two different perspectives. On the one hand, we presented the

marketplace to a group of experts in this domain and directly acquired qualitative feedback on the

marketplace features and innovations. One the other hand, we applied an end-to-end scenario for a

service request and offer that highlights the innovative aspects and could be also applied to any kind of

cloud assets offerings.

7.1 Qualitative Evaluation by Experts In order evaluate the market phase seven qualitative, semi-structured expert interviews were

performed. The interviewed experts were characterized by having a good overview of the area under

investigation and came from both research and industry. They had the following positions/roles: (1.)

Senior Manager Business Development in an internationally networked outsourcing services provider.

(2.) Senior Researcher at a large software company, (3.) Software developer at an independent software

provider (4.) Lecturer at a University of Applied Sciences, (5.) Database Architect and Developer at

small consulting company (6.) Software developer at a multinational data networking and

telecommunications equipment company and (7.) Professional Services Consultant at a cloud service

provider. The answers given by the experts are presented in the sections below and categorized by the

innovations of the 4CaaSt marketplace.

7.1.1 Service Marketplace (SMP)

All experts believe that SMP will foster the emergence of innovative applications on the marketplace.

The main advantage of the SMP is that “there’s certainly something that is far more efficient [than

manual service composition] and can optimize service use of this to sort of composed together and

provide it [i.e. a composite service] as one service”. One expert mentioned that “for me as a software

developer you can focus on the feature on the application and your service and you don’t have to

consider any resource issues regarding the database”. Preconditions required for SMP include a

“uniform formal description” of price models, which is already realized by the 4CaaSt WP3 Price

Editor. The respective expert thinks that “it naturally becomes difficult to provide automatic support

even if you have a scheme […]; you need some knowledge about what this scheme actually means to

support it. You cannot do that on the formal basis only”. The great majority of the experts

independently named the variety of different services as the one limitation of the SMP in practice

(exemplary quote): “there’re so many different services out there and so many complexities involved

and sort of bringing those together is one service I think any user would probably appreciate that

sometimes some of the requirements will remain unresolved”.

7.1.2 Innovation: Price Aggregator (PA)

The experts consider the Price Aggregator useful “certainly for comparison purposes”, so transparency

is increased, “the providers would be accurate to be able to compare different things”, and “actually

then to sort of break that sort of composite cost” of third-party services. For the experts, the “biggest

importance is that you don’t have to think about the pricing strategies”. The feature is thought of “very

advantageous from that point of view for [composite service cost] to be normalized and presented and

in a competitive way”. PA is thought to increase the competitiveness of the service provider using it.

One requirement for PA to be feasible is the sufficient accuracy and standardization of price models.

Also, one expert was doubtful about how to handle different currencies which currently is out of the

scope of our research.

7.1.3 Price Model Design and Simulation (PMDS)

The PMDS is the most popular innovation among the experts. One expert mentioned that particularly

SMEs can profit from PMDS for two reasons: a) SMEs lack access to a sufficient market data and b)

large companies often follow the market shaping approach, i.e. they do not analyze the market

conditions and adapt their product to them, but rather use their size and influence to shape the market

conditions such that the product with their own preferred characteristics fits the market best.

7.2 Experimentation This scenario is based on a software company called SaaSSolutionS that develops a SaaS application

named TaxiManager for the management of Taxi fleets. It is an application that can be purchased and

delivered (instantiated) for a Taxi company that wants to subscribe to that service. SaaSSolutionS

requires buying or hiring the hardware and software to deploy and sell its service. However, as there

are many competing solutions, the business plan has a high level of uncertainty and they decide to use

4CaaSt PaaS services to deploy, provide, sell and bill their services. This will enable them to provide

the service in a very wide geographical region and to attract a high number of customers to achieve

economies of scale, and to be able to offer the service at a low price. If the solution succeeds in the

market, it will be easy to scale the application to the new requirements. On the other hand, they will not

have to worry about many issues as: systems management, customer management, billing,

network/telecom services, etc. Once SaaSSolutionS engineers have developed the application and

defined its PaaS and services requirements, the service provider business manager will be able to

define, through extensive simulations, in 4CaaSt Marketplace commercial offers, including the price

models of the TaxiManager usage, SLAs and other business constraints. A taxi fleet IT executive will

access 4CaaSt Marketplace in order to find TaxiManager as an appropriate offer, since it has been

chosen in the past by similar customers. He configures some application specific issues (e.g. number of

taxis, geographical area) and some business constraints (e.g. maximum price). In this moment, the

4CaaSt Marketplace will select the best platforms to be integrated in the solution (web server, database,

etc.) and infrastructures (virtual machines, network, etc.). Then, the marketplace will be able to

calculate the final price, handle the contract with the customer, and automatically invoke the cloud

platform to provision the service for the customer.

7.2.1 Using the simulator to define the price model

For the sake of simplicity, we assume that the TaxiManager price model only has a single price

component, that is, a monthly subscription fee. The task for the service provider is now to define the

monthly amount such that his profit is maximized. Typically, a higher price results in fewer customers,

respectively usages. It is assumed that during the next year the monthly priced version will be used by

the following linear price-usage function: u = (100-price) monthly subscriptions during the next year.

This function can be deduced for example by taking into consideration historic data on customer

behaviour or market surveys. As can be seen by the analysis within the price model simulator, such a

price usage function means that if the price is actually 0 (for free), 100 consumers will use the

application, representing the entire addressable market (see Fig. 8). On the other hand, if the price is set

to 100 € per month, not a single customer can be found. The price model simulator also supports more

complex, non-linear price usage functions that can either be defined mathematically or be derived via

interpolation from historical market data (collected via 4CaaSt).

Fig. 8: Price-Demand Function for TaxiManager

In the next step, the user can define an optimization goal (see Fig. 9), for instance, in order to calculate

the monthly subscription price that will maximize the TaxiManager provider’s profit, or to maximize

the market share in the addressable market. Here, we are interested in profit optimization.

Fig. 9: Optimization Goal

The optimization is then executed by means of a genetic algorithm. The result of the optimization is a

concrete monthly subscription fee of 50.91 € (see Fig. 10) that can be saved as price model for the

TaxiManager application. Alternatively, the user may explore different market parameters (other

pricing types, alternative consumed services, different price usage functions etc.) and compare the

results. The price model simulator also allows an in-detail analysis of the monetary flows, e.g., the

revenue model as depicted in Fig. 11. The “Revenue Analysis” breaks down the revenue generated by

each price model component (PMC) of the composite service for which the price model simulation was

conducted. Analogously, the “Cost Analysis” breaks down the cost generated by each of the third-party

services employed by the composite service. The “Profit Analysis” and “Break Even” allow to contrast

costs and revenues, as well as to determine a price model for which they balance out. Detailed analysis

of intermediate steps and values of the optimization algorithm can be found in [16]. In terms of

performance, the simulation tool as part of the overall marketplace framework, requires about 10

seconds for all types of models which is considered as acceptable, however additional optimizations are

foreseen in the future versions.

Fig. 10: Optimum Monthly Subscription Fee

Fig. 11: Revenue Analysis

7.2.2 Products and Price Models Definition

Similar simulations are performed for the alternative TaxiManager services and finally based on the

analysis of the results the respective products and price models are defined. The TaxiManager

application has a price model with two components: a monthly subscription fee (100€) to cover the

general usage of the application and a special pay per use fee to cover the communication costs via the

cell phone provider (0.1€ per SMS). The price model of the consumed services is defined analogous by

their respective service providers. Internally, 4CaaSt Marketplace stores price models in the USDL

format as discussed in Section 6.2.

Fig. 12. TaxiManager Price Model Definition

7.2.3 Resolution of Customers’ Request

We have described the case of a customer who has requested for a Taxi Application. Once he/she has

defined his/her requirements, in terms of functional and non-functional parameters, requests for search

and resolution of services, and the respective processes are triggered. The Offer Management,

communicating in sequel with the Technical Resolution Engine, the Price Aggregator and finally

Business Resolution Engine tries to find the best offer for the given request. We assume that the

Technical Resolution identifies two valid solutions, or Abstract Resolved Blueprints, the Resolved

TaxiManager and the Alt Resolved TaxiManager. Having them as input for the Business Resolution

Engine, the next step is to get a price model for each of them by calling the Price Aggregator.

Additionally a component analysis and product specification is performed for each Abstract Resolved

Blueprint by querying the product database of the Marketplace, through which the final values of the

business characteristics of the corresponding products are specified. In the case of the Taxi Application

Scenario, the Resolved Taxi Scenario Blueprint correspondents to a final product with availability 99%

and price 150€ per month (100€ for the subscription and 50€ for the SMS service based on an

estimation for 500SMS per month) while the Alt Resolved Taxi Scenario Blueprint refers to an

alternative final product with availability 95% and price 120€ per month (SMS service is free for 1500

messages).

The selection function of the Business Resolution Engine exploited the aforementioned information in

order to find the most applicable product for the user. The selection process is the kernel of that task.

The applied selection algorithm combines the price and the other business related information

(availability, security etc.) of the offerings when querying for the candidates that fulfil the user

constraints in an optimal way. Thus when the customer has requested a Taxi Application with

minimum availability 95% and maximum possible price 200€, the Alt Resolved TaxiManager is

selected. In the case that the customer is looking for a Taxi Application with minimum availability 99%

the Resolved TaxiManager is the applicable offer, while if the maximum possible price would have

been specified as 120€ both products would have been finally rejected. The final selection is also

affected by the estimated number of SMS per month, which changes the aggregated price for the

TaxiManager. For instance, if the estimated number of SMS per month is below 200, then the cost of

Resolved TaxiManager is below 120€, cheaper and with higher availability that Alt Resolved

TaxiManager. Even in this simple example becomes clear how small changes in the customer’s

requirements could change the final product selection (and potentially the SLAs, provisioning policies,

penalties etc.), highlighting the need to enhance the modern cloud marketplace environments with

features for selection and price aggregation of composite (and possibly cross-layer) XaaS offerings. It

should be noted that the business resolution feature follows a SOA design and implementation

approach and therefore could be provided in SaaS fashion to any business or cloud environment, as a

business intelligence or decision support tool.

Besides the use case based experimentation, we also setup an experiment using the 4CaaSt testbed on

Flexiscale infrastructure to evaluate the performance of the resolution engine prototype. In this

experiment, we applied the resolution processes on multiple product datasets, varying in size (1K, 10K,

100K and 1M records), which were stored in a single instance of MongoDB. The selection algorithm

that we implemented was a weighted min-max optimization model with the example parameters

presented in Table 3. Of course the set parameters, which can be used from the framework, either as

product characteristics or as constraints posed by the marketplace customers, could be practically

extended to any number. The most important parameter is the price that was not acquired from the

database, but was automatically generated from the price aggregator based on sample pricing models.

Table 3. Example parameters used for the evaluation of resolution engine

Name Type Range / Values

Availability Decimal 0-100

Rating Decimal 0-10

Software License Type String OS / CS

Quality Assurance Boolean True / False

Aggregated Price Decimal >=0

As already mentioned, in our experiment, we used a different number of records with dependencies in

the product graph so as to provide technically valid solutions. In addition, we tested our tool with both

single requests (Fig. 13) as well as with parallel (5 concurrent) requests (Fig. 14), while in each setup

we were using different contains from the customers a) unconstrained for no customer requirements, b)

low constrains for requirements that filtered the initial set of available products about 50% and c) high

constraints for requirements that filtered the initial set of available products about 20%.

Fig. 13. Response time for single requests

Fig. 14. Response time for 5 concurrent requests

The outcomes of this experimentation showed, as we expected, that the initial filtering process of the

resolution which uses the customers’ parameters to identify the valid, for the specific request, products,

considerably affects the total resolution time. In other words, when customers pose more requirements

the resolution process is faster. In addition, the number of concurrent requests increases significantly

the response time for large data sets (from 43s to 267s). The current implementation though, both for

the database and the respective services, includes only one instance for each element, however in the

next versions we plan to exploit the sharding and map/reduce features [35] of the Mongo database,

which we estimate that will considerably decrease the total time required for each resolution.

8 Conclusions & Outlook This paper presents a new cloud marketplace as a solution for increasing the transparency and

efficiency of the cloud environments. The proposed marketplace is considered as a one-stop solution

for trading cloud services, integrating smoothly with the cloud platform and addressing many business

and technical challenges across the overall service lifecycle, from the offline simulation, to the

effective selection of services and finally to the revenue sharing and analytics. A prototype of the

marketplace has already been implemented and also validated by a group of experts in this domain.

Exploiting the 4CaaSt solution, providers can draw upon an integrated offering of XaaS and support for

the full development lifecycle of their services and price models. In particular, they can rely on the

marketplace, based on its native support for composite price models and their offline simulation, and

for advanced definition of the products’ business characteristics. Potential customers of cloud services

can make use of the marketplace features for sophisticated service search, selection and resolution as

well as one-stop pricing and revenue sharing for compositions of services. In our future work, the

search and resolution mechanism will be further enhanced with social recommendations including

information for relationships among suppliers, customers and services, allowing, on the one hand, for

more effective and personalized use of all cloud assets and lowering the cost one the other. We also

foresee more advanced business and pricing models such as spot prices, which would considerably

strengthen the impact of the proposed marketplace. In addition, extensive testing with new application

scenarios and high number of users will take place, and based on the results it is expected to reinforce

the analytics services covering more parameters for the offered products and also support additional

optimization and statistical analysis algorithms and tools.

Acknowledgments. This work has been supported by the 4CaaSt Project and has been partly funded

by the European Commission’s IST priority of the 7th Framework Programme under contract number

258862. This paper expresses the opinions of the authors and not necessarily those of the European

Commission. The European Commission is not liable for any use that may be made of the information

contained in this paper.

9 References [1] 4CaaSt EU Project: http://www.4caast.eu

[2] A. Lenk, M. Klems, J. Nimis, S. Tai and T. Sandholm. 2009. What's inside the Cloud? An

architectural map of the Cloud landscape. In Proceedings of the 2009 ICSE Workshop on Software

Engineering Challenges of Cloud Computing (CLOUD '09). IEEE Computer Society, Washington,

DC, USA, 23-31.

[3] A. Menychtas, A. Gatzioura, T. Varvarigou, “A Business Resolution Engine for Cloud

Marketplaces”, 3rd IEEE International Conference on Cloud Computing (CloudCom 2011),

Athens, Greece, 29 November - 1 December 2011.

[4] A. Menychtas, G. Kousiouris, D. Kyriazis, T. Varvarigou, “Minimizing technical complexities in

emerging cloud computing platforms”, Proceedings (LNCS) of the Cloud Computing: Project and

Initiatives, Ischia, Italy, 31 August- 3 September 2010.

[5] A. Menychtas, S. Garcia Gomez, A. Giessmann, A. Gatzioura, K. Stanoevska, J. Vogel, and V.

Moulos, 2011. A marketplace framework for trading cloud-based services. In Proceedings of the

8th international conference on Economics of Grids, Clouds, Systems, and Services (GECON'11).

[6] A. Osterwalder, E. Osterwalder, S. B. Lagha, und Y. Pigneur, An Ontology for Developing e-

Business Models“, in Proceedings of IFIP DSIAge’2002, 2002, S. 3–7.

[7] Buyya R, Ranjan R, Calheiros RN. InterCloud: Utility-oriented federation of cloud computing

environments for scaling of application services. Proceedings of the 10th International Conference

on Algorithms and Architectures for Parallel Processing (ICA3PP 2010), Busan, South Korea.

Springer: Germany, 21–23 May 2010; 328–336.

[8] C. Legner, “Is there a Market for Web Services?, ” Service-Oriented Computing - ICSOC 2007

Workshops - Lecture Notes in Computer Science, E. Di Nitto and M. Ripeanu, eds., Vienna,

Austria: Springer Berlin / Heidelberg, 2007, pp. 29-42.

[9] C. Weinhardt, A. Anandasivam, B. Blau and J. Stößer, “Business Models in the Service World,”

IT Professional, vol. 11, no. 2, pp. 28-33, March/April 2009.

[10] Caracas, A., & Altmann, J. (2007, November). A pricing information service for grid computing.

In Proceedings of the 5th international workshop on Middleware for grid computing: held at the

ACM/IFIP/USENIX 8th International Middleware Conference (p. 4). ACM.

[11] D. Kyriazis, A. Menychtas and T. Varvarigou, “Grid Workflows with encompassed Business

Relationships: An approach establishing Quality of Service Guarantees” in book “Quantitative

Quality of Service for Grid Computing”, IGI Global Publishers, 2009.

[12] D. Neumann, J. Stoesser, A. Anandasivam, N. Borissov, SORMA-building an open grid market

for grid resource allocation, in: Proceedings of the 4th International Workshop on Grid Economics

and Business Models, Rennes, France, 2007.

[13] Dinh Khoa Nguyen, Francesco Lelli, Yehia Taher, Michael Parkin, Mike P. Papazoglou, and

Willem-Jan van den Heuvel. 2011. Blueprint template support for engineering cloud-based

services. In Proceedings of the 4th European conference on Towards a service-based

internet(ServiceWave'11).

[14] Distributed Management Task Force DMTF. Open virtualization format specification.

Specification DSP0243 v1.0.0d. Technical report, available online at:

https://www.coinor.org/OS/publications/optimizationServicesFramework2008.pdf

[15] E. Gillett, E. G. Brown, J. Staten and C. Lee, “Future View: The New Tech Ecosystems Of Cloud,

Cloud Services, And Cloud Computing,” Forrester, for Vendor Strategy Professionals, 28 August

2008.

[16] F. Junker, J. Vogel, K. Stanoevska, Aggregating Price Models for Composite Services in Cloud

Service Marketplaces, The 10th IEEE International Symposium on Parallel and Distributed

Processing with Applications, Leganés, Madrid, 10-13 July 2012.

[17] Flexiscale cloud computing platform: http://www.flexiscale.com

[18] Future Internet Architecture (FIArch) Group, “Future Internet Design Principles”, European

Commission, http://ec.europa.eu/information_society/activities/foi/docs/fiarchdesignprinciples-

v1.pdf, 2012.

[19] G. Kousiouris, D. Kyriazis, K. Konstanteli, S. Gogouvitis, G. Katsaros, T. Varvarigou: A Service-

Oriented Framework for GNU Octave-Based Performance Prediction. IEEE SCC 2010: 114-121.

[20] G.M. Giaglis, S. Klein, and R.M. O`Keefe, “The role of intermediaries in electronic marketplaces:

developing a contingency model,” Information Systems Journal, vol. 12, 2002, pp. 231-246.

[21] Garcia-Gomez, S., Jimenez-Ganan, M., Taher, Y., Momm, C., Junker, F., Biro, J., Menychtas, A.,

Andrikopoulos, V., Strauch, S. Challenges for the comprehensive management of Cloud Services

in a PaaS framework. Scalable Computing: Practice and Experience. Selected Papers from the

International Workshop on Clouds for Business and Business for Clouds. Vol 13, No 3, 2012.

[22] Gen, M., & Cheng, R. (2000). Genetic algorithms and engineering optimization (Vol. 7). John

Wiley & Sons.

[23] H. Li and J. Jeng, “CCMarketplace: a marketplace model for a hybrid cloud,” CASCON '10

Proceedings of the 2010 Conference of the Center for Advanced Studies on Collaborative

Research, 2010.

[24] J. Altmann, C. Courcoubetis, G. D. Stamoulis, M. Dramitinos, T. Rayna, M. Risch, C. Bannink,

“GridEcon - A Market Place for Computing Resources,”GECON 2008, Workshop on Grid

Economics and Business Models, Springer LNCS, Las Palmas, Spain, August 2008.

[25] J. Hamilton, „Service value networks: Value, performance and strategy for the services industry“,

Journal of Systems Science and Systems Engineering, Bd. 13, Nr. 4, S. 469–489, 2004.

[26] Junker, F., Vogel, J., & Stanoevska, K. (2012). Approaches to Aggregate Price Models to Enable

Composite Services on Electronic Marketplaces. Scalable Computing: Practice and Experience,

13(3).

[27] M. Armbrust, A. Fox, R. Griffith, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I.

Stoica, and M. Zaharia, “A View of Cloud Computing,” Communications of the ACM, vol. 53,

2010, pp. 50-58.

[28] M. Eurich, A. Giessmann, T. Mettler, and K. Stanoevska-Slabeva, “Revenue Streams of Cloud-

based Platforms: Current State and Future Directions,” Proceedings of the Seventeenth Americas

Conference on Information Systems (AMCIS), Detroit, Michigan: AISel, 2011, p. 10.

[29] M. Morris, M. Schindehutte, and J. Allen, “The entrepreneur’s business model: toward a unified

perspective,” Journal of Business Research, vol. 58(6), 2005, pp. 726-735.

[30] M. P. Papazoglou and W. Heuvel, “Business Process Development - Life Cycle Methodology,”

Communications of the ACM, vol. 50, 2007, pp. 79-86.

[31] M. Sarkar, B. Butler, and C. Steinfield, “Cybermediaries in Electronic Marketspace: Toward

Theory Building,” Journal of Business Research, vol. 41, 1998, p. 215–221.

[32] M.W. Johnson, C.M. Christensen, and H. Kagermann, “Reinventing your business model,”

Harvard Business Review, 2008, pp. 51-59.

[33] Mahdi M. Kashef, J. Altmann, "A Cost Model for Hybrid Clouds," GECON2011, 8th International

Workshop on Economics of Grids, Clouds, Systems, and Services, Springer LNCS, Paphos,

Cyprus, December 2011.

[34] Marler, R. T., & Arora, J. S. (2004). Survey of multi-objective optimization methods for

engineering. Structural and multidisciplinary optimization, 26(6), 369-395.

[35] MongoDB, http://www.mongodb.org/

[36] Nguyen D.K., Lelli F., Papazoglou M.P., van den Heuvel W.-J. Blueprinting Approach in Support

of Cloud Computing. Future Internet. 2012; 4(1):322-346.

[37] Oberle, K., Cherubini, D., & Cucinotta, T. (2013). End-to-End Service Quality for Cloud

Applications. In Economics of Grids, Clouds, Systems, and Services (pp. 228-243). Springer

International Publishing.

[38] P. F. Drucker, “The Discipline of Innovation,” Harvard Business Review, vol. August, 2002, pp.

95 - 103.

[39] P. Mell and T. Grance, NIST Definition of Cloud Computing, Version 15, 2009, available online

at: http://csrc.nist.gov/groups/SNS/cloud-computing

[40] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg and I. Br, Cloud computing and emerging it

platforms: Vision, hype, and reality for delivering computing as the 5th utility.

[41] Samimi, P., & Patel, A. (2011, March). Review of pricing models for grid & cloud computing. In

Computers & Informatics (ISCI), 2011 IEEE Symposium on (pp. 634-639). IEEE.

[42] See, T.K., Lewis, K. Multiattribute decision making using hypothetical equivalents. Proceedings of

DETC’02 ASME 2002 Design Engineering Technical Conferences and Computers and

Information in Engineering Conference, Montreal, Canada, 2002.

[43] ur Rehman, Z., Hussain, F.K., Hussain, O.K.. (2011). Towards Multi-criteria Cloud Service

Selection. Fifth International Conference on Innovative Mobile and Internet Services in Ubiquitous

Computing (IMIS), 44 – 48. Seoul, Korea 2011.

[44] Y. Bakos, “The Emerging Role of Electronic Marketplaces on the Internet,” Communications of

the ACM, vol. 41, 1998, pp. 35-42.

[45] Yaqub, E., Yahyapour, R., Wieder, P., & Lu, K. (2012). A protocol development framework for

SLA negotiations in cloud and service computing. In Economics of Grids, Clouds, Systems, and

Services (pp. 1-15). Springer Berlin Heidelberg.

[46] Yu, T., Lin, K.J. (2005). Service selection algorithms for Web services with end-to-end.

Information Systems and E-Business Management, 3(2), 103 – 126. Berlin Heidelberg: Springer

[47] Zhang, M., Ranjan, R., Nepal, S., Menzel, M., & Haller, A. (2012). A declarative recommender

system for cloud infrastructure services selection. In Economics of Grids, Clouds, Systems, and

Services (pp. 102-113). Springer Berlin Heidelberg.