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

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

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

DnS Pattern

Offering Ontology Overview

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)

Application Ontology Overview

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)

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.

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.

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

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

Algorithm (functional parameters) Nominal value

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

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

Algorithm (non-functional parameters - Scoring)

Scoring function

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

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

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

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.

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.

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.

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 1.6.0 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