Architectting the Recommendation Layer of a Platform-as-a-Service

e-Marketplace

Fatemeh AhmadiZeleti, Islam Hassan, Sonya Abbas, Adegboyega Ojo and Lukasz Porwol

Insight Centre for Data Analytics, National University of Ireland, Lower Dangan, Galway, Ireland

Keywords: Recommender Systems, Semantic Recommender, PaaS Recommendation Layer, Cloud e-Marketplace.

Abstract: This paper addresses the problem of how to architect aspects of an Electronic Marketplace (e-Marketplace)

to enable Software SMEs (Small and Medium Scale Enterprises) Engineers to easily discover the most

appropriate Platform-as-a-Service (PaaS) offerings available in a marketplace. While there are existing

architectural models for e-Marketplaces, these models largely ignore the semantic aspects of the

descriptions of offerings in the marketplace. In addition, they provide little support for recommendations

and decision making for consumers in the marketplace. These shortcomings make the reuse of existing e-

Marketplace architectures inadequate for some categories of services such as PaaS services which are

characterised by relatively complex technical specifications. We address this problem by integrating a

Semantic Recommendation Layer into a PaaS e-Marketplace architecture. Requirements for this layer were

obtained from a series of interviews with Software SME engineers and PaaS providers within the context of

a Three-year EU Project. We describe the major components of the Layer and the underpinning

recommendation and decision model. Results from this work should contribute to domain-specific

architecture for e-Marketplaces.

1 INTRODUCTION

Architectures for Cloud e-Marketplace are receiving

growing attention from researchers, demonstrated by

scholarly works such as (Kamateri et al. 2013).

However, published e-marketplace architectures in

literature are far from maturity. Most of the

implementations of these e-Marketplaces

architectures are below level 4 of the Technology

Readiness (TRL 4 – technology validated in the lab).

Asides this limitation, these models largely

ignore the semantic aspects of the descriptions of

offerings in the marketplace. In addition, they

provide little support for recommendations and

decision making for consumers in the marketplace.

These shortcomings make the reuse of existing e-

Marketplace architectures inadequate for categories

of services such as PaaS services which are

characterized by relatively complex technical

specifications. A notable earlier attempt at

addressing this problem is presented in (Kamateri et

al. 2013) as part of the Cloud4SOA project.

However, the architecture was only intended to

support a demonstrator – typically, TRL 4.

This research carried out as part of a follow-up

project designed to address the some of the

limitations of the Cloud4SOA project aims to

develop the Semantic Recommendation Layer for a

viable PaaS e-Marketplaces in collaboration with

Cloud SMEs in Europe. The Recommendation Layer

is also expected to support the decision making of

the Consumer Engineers in selecting the most

appropriate offering satisfying their needs from the

list of recommendations. We describe the major

components of the Layer and the underpinning

recommendation and decision model.

The rest of the paper is structured as follows:

Section 2 describes some background to existing

Cloud e-Marketplaces. In Section 3, we address the

research question and describe our approach to the

research. The details of the architectural framework

for the PaaS e-Marketplace Recommender Layer is

presented in Section 4. We end with concluding

remarks in Section 5.

336

AhmadiZeleti, F., Hassan, I., Abbas, S., Ojo, A. and Porwol, L.

Architectting the Recommendation Layer of a Platform-as-a-Service e-Marketplace.

DOI: 10.5220/0006007603360341

In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 1: ICSOFT-EA, pages 336-341

ISBN: 978-989-758-194-6

2 BACKGROUND

In this section, we summarize recommender systems

of three broker-based Cloud architectures derived

from related EU projects that aim to address Cloud

interoperability mainly in the PaaS layer as well as

open and proprietary offerings targeting PaaS

interoperability.

2.1 Cloud4SOA

Cloud4SOA is a completed FP7 project that focused

on resolving the interoperability and portability

issues that exist in current Clouds infrastructures and

on introducing a user-centric approach for

applications which are built upon and deployed

using Cloud resources. The project architecture

consists of five layers, three horizontal and two

vertical, outlined below. The three horizontal layers

include Front-End Layer, Repository Layer, and

Harmonized API. The two vertical layers include

Semantic Layer and Governance Layer. Cloud4SOA

PaaS Recommendation is an individual component

of the SOA Layer. In Cloud4SOA, the PaaS

Recommendation component offers suggestions for

the best matches of PaaS offerings. The degree of

relation between a PaaS offering and an application

is computed based on the similarity of their semantic

profiles. Moreover, this module offers a rating

mechanism that enables the user rating and the

system automatic rating (based on SLA violations)

of PaaS offerings (Kamateri et al. 2013).

2.2 MODACloud

MODAClouds is an EU FP7 project aiming to

provide the followings: Decision Support System; an

Integrated Development Environment; a run-time

environment for the high-level design, early

prototyping, semi-automatic code generation, and;

automatic deployment of applications on Multi-

Clouds with guaranteed Quality of Service (QoS). In

particular, MODAClouds uses a Model-Driven

Engineering approach for Clouds for semi-automatic

code deployment using decision support systems on

multiple Cloud providers hiding the proprietary

technology stack (Almeida et al. 2014).

MODAClouds Architecture consists of two

distinct software levels: the MODAClouds IDE and

the Runtime platform. The Runtime platform

includes Monitoring Platform, the Self-Adaptation

Reasoner, the Models@runtime engine, the

Execution Platform and the Filling the Gap

component. MODAClouds IDE includes Decision

Support System, MODACloudML Functional

Modelling Environment, QoS modelling and

analysis tool, Data Mapping Component,

MODACloudML Deployment and Provisioning

Component, and Filling the Gap Design-Time

Manager (Almeida et al. 2014).

The Data Mapping Component allows the user to

decide upon the best cloud-specific data

representation formats and tools that fulfil the

application requirements. A cloud developer must

consider the possibility of migrating and replicating

data on different data storages possibly located in

different clouds. This component offers different

kinds of Cloud data storage services. As clouds offer

different kinds of storage services, a first issue to

address is to select the type of service to exploit

according to the characteristics of data to be stored

the way they are going to be used. A second

important concern is about the way data have to be

mapped on the data schema offered by the selected

storage service. Finally, a cloud developer must

consider the possibility of migrating and replicating

data on different data storages possibly located in

different clouds (Almeida et al. 2014).

2.3 4CaaSt

4CaaSt is a FP7 EU project that aims at introducing

a broker-based architecture which decouples the

development and specification of applications from

their actual deployment, leaving the underlying

complexity of infrastructure and platforms out of

users’ concerns (Garcia-Gomez & Jimenez-Ganan

2012). 4CaaSt introduces the concept of the

blueprint, a technical description of an application or

a service that decouples the various dependencies it

has along the Cloud layers. For PaaS deployments,

using 4CaaSt blueprints, application providers can

choose from different platform layers and services to

run their applications, including different

infrastructure, middleware, and applications

components/services. Once the selection is done,

4CaaSt generates automatically the deployment

designs and automatically provision the necessary

resources required for the deployment. In addition,

4CaaSt offers resource provisioning by considering

based on the deployment designs the required

resources needed for the deployment for instance the

QoS levels, scalability requirements, the

configuration of virtual machines (Gómez 2013)

(Momm 2013).

The recommendation is performed in

Marketplace section which includes a number of

sub-components. The marketplace allows any of its

Architectting the Recommendation Layer of a Platform-as-a-Service e-Marketplace

337

stakeholders to search and check the constituting

components of a particular service and product

before he purchases it. Ideally, it should support as

many different search methods as possible. 4CaaSt

uses the following types (Gómez 2013) (Momm

2013): Free text search, Search by formal

specification, Search by browsing, History based

search, and User profile based search. The

marketplace gets a list of the most relevant products

for a customer and it allows service consumer or any

stakeholder to compare two or more products in

terms of capabilities, price model or conditions. The

marketplace enables the selection of the most

appropriate product among those offered (Slabeva &

Hoyer 2013) (Momm 2013).

2.4 Comparing Cloud E-Marketplaces

A simple comparison between open source related

projects shows that Cloud4SOA, ModaClouds, and

4CaaSt are the projects that implement

recommendation layer either in one module or

combination of modules for their offerings.

Other Cloud e-Marketplace or brokers without

recommender system are listed in Table 1.

Table 1: Analysis of recommender systems for cloud

marketplaces.

3 RESEARCH QUESTION AND

APPROACH

3.1 Research Question

The research question addressed in our work

includes: What kind of architectural framework and

decision model is required to recommend the best

PaaS Offerings to DevOps?

To answer the above problem, we carried out an

extensive review of the literature and designed

questionnaires for eliciting requirements from SME

Clouds service provider and the SME engineers for

the recommendation layer (and other layers) of the

PaaS e-Marketplace architecture.

3.2 PaaSport Project Contexts

The research was carried out as part of the PaaSport

project which aims to create a marketplace where on

the one hand, different PaaS providers can advertise

their cloud offerings and, on the other hand,

developers can benefit from a PaaS abstraction layer

in order to avoid the vendor lock-in problem.

Moreover, PaaSport project focuses on resolving the

data and application portability issues that exist in the

Cloud PaaS market through a flexible and efficient

deployment and migration approach. The vision of the

PaaSport project is to enable Cloud vendors to roll out

semantically interoperable PaaS offerings while

benefiting European Software SMEs by allowing

them to deploy or migrate business applications on

the best-matching Cloud PaaS offerings.

3.3 The PaaSport Architectural

Framework

PaaSport Marketplace constitutes a thin, non-

intrusive broker that mediates between PaaS

offerings and PaaS users. It relies on open standards

and introduces a scalable, reusable, modular,

extendable and transferable approach for facilitating

the deployment and execution of resource-intensive

business services on top of semantically-enhanced

Cloud PaaS offerings. PaaSport Marketplace

comprises of five layers (Figure 1). The major

layers of the architecture are explained below:

 The PaaSport Semantic Models: this layer serves

as the conceptual and modelling pillars of the

marketplace infrastructure, for the annotation of

the registered PaaS offerings and the deployed

applications profiles;

 The PaaS Offering Recommendation Layer: this

layer implements the core functionalities offered

by the PaaSport Marketplace Infrastructure, such

as PaaS offering discovery, recommendation and

rating;

 The Monitoring and SLA Enforcement Layer:

this layer realizes the monitoring of the deployed

business applications and the corresponding

Service Level agreement;

 The Persistency, Execution and Coordination

Layer: this layer puts in place the technical

infrastructure, e.g. repositories, on top of which

the PaaSport marketplace is built. It also includes

the PaaSport Unified PaaS API that is a common

API exploited in order to uniformly interact with

the heterogeneous PaaS offerings and, in

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

338

addition, it realizes the lifecycle management of

the deployed applications;

 The Adaptive Front-ends: this layer support

seamless interaction between the users and the

PaaSport functionalities, through a set of

configurable utilities that are adapted to the

user’s context.

Figure 1: PaaSport high-level architecture.

4 RECOMMENDATION LAYER

Recommendation layer offers a toolbox that

software SMEs can use through their personalized

front-end in order to find the PaaS offering that best

matches the requirements of the application that they

want to deploy in the cloud. The offering

recommendation is based on the degree of similarity

between the applications deployment profiles and

the available PaaS characteristics, which is

computed based on the similarity of their semantic

descriptions. Recommendation Layer has been

developed as part of the PaaSport Cloud-broker

Architecture specification.

4.1 Core Components

This section presents the eight core components of

the Recommendation Layer of PaaSport Reference

Architecture, shown in Figure 2.

Figure 2: Recommendation layer of the PaaSport

Reference Architecture.

 PaaS Offering Search: PaaS offering Search

component receives software SMEs application

requirements and sends the requirement to the

Semantic Query Handling component.

 Semantic PaaS Offering Discovery: The PaaS

Offering Discovery component capitalizes on the

search mechanisms offered by the Distributed

Repository Layer and employs lightweight

semantic models and techniques in order to find

among the available PaaS offerings these which

meet best the user’s requirements. It also

negotiates with those PaaS Offerings to get SLA

agreements.

 Application to PaaS Offering Matchmaking:

Application to PaaS offering Matchmaking

implements the semantic matchmaking between

the semantic profile of an application and those

of the available PaaS offerings. The

matchmaking criteria will be flexible and

configurable thus allowing the Software SMEs

Engineer to decide in a range between exact

(full) match and partial matches.

 PaaS Offering Shortlist: PaaS offering shortlists

provides to Software SMEs Engineers

suggestions of PaaS offerings related to/suitable

for the application that they want to deploy. The

degree of relation between an application and the

available PaaS offerings is computed based on

the similarity of their semantic profiles.

 PaaS Offering Selection: PaaS offering selection

utilizes lightweight semantic models and multiple

parameters in order to support Software SMEs

Engineers to make their final decision and selection

with regards to the most suitable PaaS offering

recommended by the PaaS Offering Shortlist

Component, by simply prioritizing and adjusting

the multi-parametric characteristics of the service

deployment and configuration requirements.

 SLA Matchmaking: The SLA Matchmaking

Component allows the SLA matchmaking based on

the application requirements and the multi-

parametric characteristics of the service deployment

and configuration requirements of the provider.

 PaaS Offering Rating: PaaS offering rating

facilitates the rating of a particular PaaS offering

by a Software SMEs Engineer. Each engineer

can leave a comment and rate a particular PaaS,

thus offering to express their satisfaction or

dissatisfaction with regards to quality, usability,

reliability and user-friendliness of the offering.

 Semantic Query Handling: Semantic (SPARQL)

query handling component is the core component

of the layer as it controls all the interaction

between all the other components.

Cloud Marketplace

Catalogue

DevOps Engineer

personalised space

PaaS provider

personalised space

PaaS model

SLA model

Application

model

PaaS offering

selection

PaaS offering

shortlist

PaaS offering

rating

Semantic Query handling

Semantic PaaS

offering discovery

Application to PaaS

offering matchmaking

Semantic

models

Adaptive Front-ends

PaaS Offering Recommendation Layer

User profiles

PaaS offering

profiles

Application

profiles

Search and Discovery

Interfaces

Tunnelling and

Virtual Execution

PaaSport Unified

PaaS API

Persistency, Execution and Coordination Layer

Monitoring and

SLA

Enforcement

Layer

Orchestration

Deployed

application

monitoring

PaaSport

Adapter

PaaSport

Adapter

SLA

Matchmaking

SLA

Enforcement

Interoperability

Libraries

Architectting the Recommendation Layer of a Platform-as-a-Service e-Marketplace

339

 It triggers the Semantic PaaS offering

discovery component to get all the offers

according to the user preferences comes from

the user profile.

 It sends the offers along with the application

requirements to the Application to PaaS

Offering Matchmaking component where the

matchmaking happens based on the matching

algorithm and returns list of the matched

offers to the semantic query handling.

 It sends a list of the matched offers to the

PaaS Offering Shortlist component where the

offering scoring algorithm score the offers

and returns the matched offers combined with

scores.

 It sends the scored matched offers combined

with the PaaS offering search component

where a response will be generated to the

SearchPaaSOfferingWidget.

4.2 Interaction between the

Components

Figure 3 shows the interactions between the different

components of Recommendation Layer. It also shows

the flow of the implementation where the semantic

query handling component plays a critical role in

managing other components as detailed in the

previous section. An essential component in

architecture to start with is the PaaS offering search, it

is one of the interfaces, which receives software

SMEs application requirements with or without the

user preference that might has valuable information to

be used for providing a personalized semantic

discovery. PaaS offering search component sends

these query handler component continue with the rest

of the process through interacting with the semantic

PaaS offering discovery, Discovery component

receives the semantic query from semantic query

handling. It applies two different search methods in

order to find among the available PaaS offerings

these, which meet best the user’s requirements.

Figure 3: Interaction among components of the

Recommendation Layer.

The PaaS Offering Discovery component search

is based on the semantic profile of the application

and also on manually inserted searching criteria. It is

responsible for getting SLA offers through

matchmaking with the PaaS Offerings that meet the

user’s requirements. It interacts with the repository

layer, SLA matchmaking component and semantic

query-handling component in order to achieve the

required functionality.

The PaaS offering matchmaking implements the

semantic matchmaking between the application

requirements and those of the available PaaS

offerings. The matchmaking criteria will be flexible

and configurable thus allowing the Software SMEs

Engineer to decide in a range between exact (full)

match and partial matches. It is invoked by the

semantic query handling component and based on

the matchmaking algorithm.

Then, Shortlisting component provides

suggestions of PaaS offerings regarding the

application that the Software SMEs Engineers want

to deploy. It receives the results of the matchmaking

component through semantic query handling

component. It is evoked by the semantic query

handling component and it’s mainly based on the

offering scoring algorithm. The output of this

component is a list of scored matched offers, which

is sent back to semantic query handling component.

Finally, the selection component implements the

multi-criteria decision-making algorithm, AHP over

a list of PaaS offering results obtained from the PaaS

Offering Shortlist component. The selection criteria

are: 1) Quality of Service, 2) Quality of Support, 3)

Maintenance Activity, 4) SLA Reliability and 5)

Value For Money. The Software SMEs Engineer are

allowed to specify their preferences for these criteria

as a basis for PaaS Offering Shortlist component

through semantic query handling component.

4.3 Elaborating the Decision Model

We frame the ranking of the matching offerings as a

Multi-Criteria Decision (MCD) problem.

There are three different methods for Multi-

Criteria Decision Making (Kousalya et al. 2012):

 Weighted Sum Method: common approach

especially for single dimensional problems,

 Preference Ranking Organization Method for

Enrichment Evaluation: uses pair-wise

comparison of alternatives, and

 Analytical Hierarchy Process (AHP):

decomposes complex problem into a hierarchy

where the goal is on the top and criterions are at

levels and sub-levels of it.

ICSOFT-EA 2016 - 11th International Conference on Software Engineering and Applications

340

Despite the existence of aforementioned

methods, we employed AHP for developing the

Selection Component of the project as it is fairly

simple to apply, and one of the most popular

approaches used for multi-criteria decision-making.

AHP sorts and recommends list of PaaS Offerings

based on the following:

 Preferences/priorities (1, the lowest priority, 5,

the highest priority) given by the Software SMEs

Engineers on the following five selection criteria:

 Quality of Service,

 Quality of Support,

 Maintenance Activity,

 SLA Reliability and

 Value for Money

 Overall score of each PaaS offering. The rating

mechanisms are used to give an average rating to

each PaaS Offerings. The average rating per

Offering is stored in the Rating Repository and

automatic update takes place every time a new

rating is submitted.

In order to compare PaaS Offerings, a scale of

numbers is required to indicate how dominant one

element is over another element with respect to the

set of criteria (Coyle 2004) (Adamcsek 2008)

(Kousalya et al. 2012).

5 CONCLUSIONS

In this paper, we have developed an architectural

framework to enable semantic recommendation and

support decision-making of end-users in the PaaS e-

Marketplace. We believe that our framework can be

easily reused in another e-Marketplace architectural

context. Our future work includes large-scale

validation of the architecture with members of the

SME Associations that is a member of the PaaSport

project consortium.

ACKNOWLEDGEMENTS

The work was supported by the EC FP7 Project

PaaSport Project, Grant No. 605193.

REFERENCES

Adamcsek, E., 2008. The Analytic Hierarchy Process and

its Generalizations. Eotvos Lorand University.

Almeida, M. et al., 2014. MODAClouds architecture,

Coyle, G., 2004. The Analytic Hierarchy Process (AHP).

Principal Strategy. Open Access Material., (1980),

pp.1–11.

Dogac, A. et al., AN ELECTRONIC MARKETPLACE

ARCHITECTURE.

Garcia-Gomez, S. & Jimenez-Ganan, M., 2012.

Challenges for the comprehensive management of

Cloud Services in a PaaS framework. Scalable

Computing: Practice and Experience, 13(3), pp.201–

213. Available at: https://scpe.org/index.php/scpe/art

icle/view/793.

Gómez, S.G., 2013. Building the PaaS Cloud of the

Future: Integration of Results,

Kamateri, E. et al., 2013. Cloud4SOA : A Semantic-

Interoperability PaaS Solution for Multi-cloud

Platform Management and Portability. In The

European Conference on Service-Oriented and Cloud

Computing. pp. 64–78.

Kousalya, P. et al., 2012. Analytical Hierarchy Process

approach – An application of engineering education.

Mathematica Aeterna, 2(10), pp.861–878.

Momm, C., 2013. Analysis of the State of the Art and

Definition of Requirements,

Slabeva, K.S. & Hoyer, V., 2013. 4CaaSt - Building the

PaaS Cloud of the Future. University of St.Gallen.

Available at: https://www.alexandria.unisg.ch/Projekte

/64171 [Accessed January 21, 2016].

Architectting the Recommendation Layer of a Platform-as-a-Service e-Marketplace

341