1. Semantic Model and Matchmaking/Recommendation Algorithm
Plenary Meeting
Istanbul, 5-6 February 2015

2. Introduction
A PaaSport-oriented core model defined as the extension of the Descriptions and Situations (DnS) pattern
DnS is part of DOLCE+DnS Ultralite ontology
Three contextualized extensions of the core pattern have been defined for modelling
Offerings
Applications
SLAs

3. DnS Pattern dul:Situation dul:Description dul:Concept dul:Parameter
A relational context that includes a set of entities, e.g. observations, events, values, data, etc.
The entities are interpreted in terms of a dul:Description
dul:Description
A descriptive context that defines a set dul:Concepts in order to create a view on a dul:Situation, e.g. what an entity actually refers to
dul:Concept
Classifies an entity, specifying the way it should be interpreted
dul:Parameter
A dul:Concept can have a dul:Parameter (or more) that constrains the attributes that a classified entity can have in a certain dul:Situation

4. DnS Pattern

5. Offering Ontology Overview

6. Offering Ontology Explanation
Each parameter either has a value (without measurement unit, e.g. name) or parameterizes one Quality Value, that consists of a measurement unit and a data value (e.g. Latency-> 10msec)
Each Concept has some Parameters e.g. the QoS has parameter Latency
Every Offering Description consists of (offers) some PaaS Concepts, such as Programming Environment, Services, Resources, QoS etc
Every Offering has an Offering Description (GroundOffering)

7. Application Ontology Overview

8. Application Ontology Explanation
Each parameter either has a value (without measurement unit) or parameterizes one Quality Value, that consists of a measurement unit and a data value
Each Concept has some Parameters e.g. the QoS has parameter Latency.
Some Parameters are functional, whereas some other are non-functional. For example the name of a database is functional. For nonfunctional parameters the user through the GUI can state if it will be considered as functional or not.
E.g. Latency less than 10ms is absolutely needed.
Every Application Requirement requires some PaaS Concepts, such as Programming Environment, QoS etc
Every Application has a Description
(satisfies some ApplicationRequirement)

9. SLA Ontology Explanation
SLA is an agreement between 2 parties, the service consumer and a specific PaaS Offering Provider.
The level of service is defined in terms of performance and reliability.
SLA has a period of validity (properties StartDate, EndDate)
The performance described by QoS parameters and the pricing by pricing policy parameters which are the same with QoS and pricing from the PaaSConcept.

10. Concept Hierarchy PaaSConcepts are divined into eight subclasses.
ProgrammingEnvironment concept is further subdivided into programming framework and programming language
Service subdivided into Database and Server.

11. Parameters are divided into two subclasses: InformationalParameters, MatchmakingParameters.
Only MatchmakingParameters are visible when the application’s developer creates the profile of the application.
So the matchmaking algorithm uses only the matchmaking parameters.
Matchmaking parameters are subdivided into functional and non-functional parameters.
Functional parameters can only be used as functional requirements by the GUI.
Non-functional parameters can be used both as nonfunctional requirements and as functional ones by the GUI.
PaaS Parameters

12. Matchmaking and Ranking algorithm
GUI
Initialization
GetOfferings
Input
Check Functional
For each concept, offering and parameter
Run SPARQL query
Keep offering or not
Rank Non-Functional
Retrieve parameter values
Score parameter values
Sort Results
Application Requirement Instance
Offerings
Concepts
Functional Parameters
Non-Functional Parameters
Coefficients
Difference Functions
Functional?
Factor K
PaaS Offering profiles
Offerings
Offerings + Score

13. Algorithm (functional parameters)
Nominal value

14. Algorithm (non-functional parameters)
Retrieving parameter Values
Finding max/min per parameter

15. Retrieving non-functional parameter values
No unit conversion is needed.
Quality Values are identical.
Units need to be converted to be comparable
Unit conversion is needed.
Both Quality Values are NOT base units.
E.g. 512 MB, 1 GB

16. Algorithm (non-functional parameters - Scoring)

17. Scoring function

18. Final score for the parameter
If the offering is unbounded
𝑃𝑎𝑟𝑆𝑐𝑜𝑟𝑒 𝑝𝑎𝑟 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 = 1, 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙=∞ 0, 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙<𝐴𝑝𝑝𝑅𝑒𝑞𝑃𝑎𝑟𝑉𝑎𝑙 𝑤 𝑝𝑎𝑟 𝑓 𝑑𝑓 𝑝𝑎𝑟 𝑥 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 , 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
If the offering is worse than the application
coefficient
Difference function
Normal case

19. Difference Functions Flat : 𝑓 𝑓𝑙 (𝑥)=0 Linear : 𝑓 𝑙𝑖𝑛 (𝑥)=𝑥
Super-linear : 𝑓 𝑠𝑢𝑝 𝑥 =1− 𝑒 −𝑘𝑥
Sub-linear : 𝑓 𝑠𝑢𝑏 𝑥 = 𝑓 𝑠𝑢𝑝 −1 𝑥 =
=− ln (1−𝑥) 𝑘
Spike - Step: 𝑓 𝑠𝑝 (𝑥)= 0, 𝑥=0 1, 𝑥>0

20. Calculation of x If an offering has unbounded as maximum value
𝑎= & 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙) 1− 1 𝑀𝑎𝑥𝐷𝑖𝑓𝑓 𝑀𝑎𝑥𝐷𝑖𝑓𝑓 , 𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙=∞ & 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 𝑀𝑎𝑥𝐷𝑖𝑓𝑓 , 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
If an offering has unbounded as maximum value
If an offering has unbounded as maximum value
𝑀𝑎𝑥𝐷𝑖𝑓𝑓= 𝑃𝑟𝑒𝑣𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙, 𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙=∞ 𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
Different x according to parameter type:
e.g. storage capacity, more is better
𝑥= 𝑎, 𝑝𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟.𝑡𝑦𝑝𝑒= 𝑀𝑖𝑛  𝑀𝑎𝑥𝑀𝑖𝑛 1−𝑎, 𝑝𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟.𝑡𝑦𝑝𝑒= 𝑀𝑎𝑥  𝑀𝑖𝑛𝑀𝑎𝑥
e.g. latency, less is better

21. Example MySQL Capacity: Max=10GB Min=1GB Java_1.4.0
MySQL_1GB, Score=0.0
score=0.0
score=0.44
score=0.44
MySQL_5GB, Score= (5-1)/(10-1)=4/9= 0.44
Application Example
In this case the user only needs a MySQL database. If an offering indeed has a MySQL database, then we would like to give it a higher score if the storage is larger than 1GB.

22. Example MySQL Capacity: Max=10GB Min=1GB Java_1.4.0
MySQL_15GB, Score=1
score=1
score=1
MongoDB_15GB
Application Example
In this case the user only needs a MySQL database. If an offering indeed has a MySQL database, then we would like to give it a higher score if the storage is larger than 1GB.

23. Implementation Java (~700 lines of code) Structures Jena Framework
ApplicationInstance (supposed to come from GUI)
Concept
Parameter
Jena Framework
The only third-party framework we use is Apache Jena for parsing ontologies, processing data and executing SPARQL queries.

24. Implementation examples
Application Instances with only functional requirement
Application Name
Programming Language
Processing Resources
Storage
Latency
Uptime
Database Services
DummyApp0
java (without version) -
150
DummyApp1
java
mongoDB (without Storage)
Offering Instances
PaaS Offering Name
Programming Language
Processing Resources
Storage
Latency
Uptime
Database Services
OpenShift
java 1.6.0
1 core, 1 GB Ram
1 GB disc
200
99.5
mySQL/ postgreSQL/ mongoDB (unbounded storage)
cloudBees
1 core, 128 MB Ram or 2 cores, 256 MB Ram -
100
mySql (1GB or 40GB)
googleAppEngine
2 cores, 256 MB Ram or 4 cores, 512MB Ram
Application Instances with only non-functional requirement
Application Name
Programming Language
Processing Resources
Storage
Latency
Uptime
Database Services
DummyApp2 -
0.3 giga (linear)
DummyApp3
120 (superlinear)
DummyApp4
0.3 giga (sublinear)
DummyApp5
0.125 giga (sublinear)
120 (sublinear)
98 (sublinear)
Application Instances with functional and non-functional requirement
Application Name
Programming Language
Processing Resources
Storage
Latency
Uptime
Database Services
DummyApp6 -
0.3 giga (sublinear)
mongoDB (without Storage)
Offering Instance
OpenShift
cloudBees
googleAppEngine
Application Instance
DummyApp0 -
DummyApp1
DummyApp2 1
0.44
DummyApp3
0.99
DummyApp4
0.11
DummyApp5
0.66
0.67
0.69
DummyApp6