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
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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
search
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