paasport semantic model and matchmaking/recommendation algorithm

Semantic Model and Matchmaking/Recommendation Algorithm

Plenary Meeting

Istanbul, 5-6 February 2015

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

Introduction

DnS Pattern

Core PaaSport Pattern

Offering Pattern

Application Pattern

SLA Pattern

extension

extension

extension

extension

dul:Situation 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

dul:Situation dul:Descriptiondul:satisfies

dul:Conceptdul:classifies

dul:isSettingFor

entities

dul:defines

dul:Parameter

dul:hasParameter

dul:parametrizes

rdfs:subClassOf

property assertion

rdfs:subPropertyOf

DnS Pattern

Offering Ontology Overview

GroundOffering

dul:satisfies[allValuesFrom]

rdfs:subClassOf

property restriction

rdfs:subPropertyOf

Offering

Service

ProgrammingEnvironment

Certificates

Resource

Location

requires[allValuesFrom]

QoS

QoSParameter

MinCPULoad

Latency

MaxMemoryLoad

ResponseTime

Uptime

Maxdul:parametrizes

[allValuesFrom]

dul:hasDataValue[allValuesFrom]

xsd:double

Millisecond

measuredIn[allValuesFrom]




MaxCPULoad

MinMemoryLoad

dul:hasParameter[allValuesFrom]

Rating

PaaSProcingPolicy


Offering Ontology Explanation

Every Offering has an Offering Description (GroundOffering)

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)

Every Offering Description consists of (offers) some PaaSConcepts, such as Programming Environment, Services, Resources, QoS etc

Each Concept has some Parameters e.g. the QoShas parameter Latency

Application Ontology Overview

ApplicationRequirement

dul:satisfies[allValuesFrom]

rdfs:subClassOf


rdfs:subPropertyOf

Application

Service


Certificates

Resource

Location


QoS

QoSParameter

MinCPULoad

Latency

MaxMemoryLoad

ResponseTime

Uptime

Maxdul:parametrizes

[allValuesFrom]

dul:hasDataValue[allValuesFrom]

xsd:double

Millisecond

measuredIn[allValuesFrom]




MaxCPULoad

MinMemoryLoad

dul:hasParameter[allValuesFrom]

Application Ontology Explanation

Every Application has a Description(satisfies some ApplicationRequirement)

Each parameter either has a value (without measurement unit) or parameterizes one Quality Value, that consists of a measurement unit and a data value

Every Application Requirement requires some PaaS Concepts, such as Programming Environment, QoS etc

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.

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 QoSand pricing from the PaaSConcept.

SLA Ontology Explanation

SLAAgreement SLATemplate

rdfs:subClassOf


rdfs:subPropertyOf

ServiceConsumer PaaSProvider

includesProvider[allValuesFrom]

includesClient[allValuesFrom]

DUL:Defines[allValuesFrom]

PaaSPricingPolicyQoS

EndDate[allValuesFrom]

StartDate[allValuesFrom]

Xsd:dateTime DUL:Satisfies

PaaSGroundedOfferingApplication

includesApplication[allValuesFrom]

includesOffering[allValuesFrom]

DUL:Defines[allValuesFrom]

PaaSConcept

Service

PaaSProcingPolicy


QoS

Certificates

Resource

Location

Rating

ProgrammingFramework

ProgrammingLanguage

Database

Server

NoSQLDatabase

SQLDatabase

Concept Hierarchy

• PaaSConcepts are divined into eight subclasses.

• ProgrammingEnvironmentconcept is further subdivided into programming framework and programming language

• Service subdivided into Database and Server.

PaaSParameter

rdfs:subClassOf


rdfs:subPropertyOf

ServiceParameter

PaaSProcingPolicyParameter

ProgrammingParameter

QoSParameter

CertificatesParameter

ResourceParameter

RatingParameter

InformationalParameter

Matchmaking Parameter

LocationParameter

FunctionalParameter

NonFunctionalParameter

PaaS Parameters• 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.

Concepts

Functional Parameters

Non-Functional Parameters

•Coefficients

•Difference Functions

•Functional?

Factor K

Matchmaking and Ranking algorithm

Application Requirement Instance

GUI

Sort Results

Rank Non-Functional

Retrieve parameter values Score parameter values

Check Functional

For each concept, offering and parameter

Run SPARQL query Keep offering or not

Initialization

GetOfferings Input

PaaSOffering profiles

Offerings

Offerings

Offerings + Score

Algorithm (functional parameters)

SELECT ?concept WHERE {

<offering.ID> DUL:satisfies ?groundDescription .

?groundDescription paas:offers ?concept .

?concept rdf:type <concept.type> .

{

?concept DUL:hasParameter ?par .

}

UNION

{

?concept paas:hasCompatibilityWith+ ?concept1 .

?concept1 DUL:hasParameter ?par .

}

?par rdf:type <par.type> .

?par DUL:hasParameterDataValue ?Value .

<par.qualityValue> rdf:type paas:NominalValue .

?par DUL:parametrizes <par.qualityValue> .

FILTER(?Value = <par.value> )

}

Nominal value

Algorithm (non-functional parameters)

Retrieving parameter Values

Finding max/min per parameter

SELECT ( xsd:double(?Factor)*?Value as ?Offering-Value ) ?concept WHERE {

<offering.ID> DUL:satisfies/paas:offers ?concept .

VALUES ?concept { <concept-list> }

?concept rdf:type <concept.type> .

?concept DUL:hasParameter ?par .

?par rdf:type <par.type> .

?par DUL:hasParameterDataValue ?Value .

{ ?par DUL:parametrizes ?qualityValue .

?qualityValue uomvocab:measuredIn <par.qualityValue.MeasureUnit> .

BIND (1 AS ?Factor1) BIND (1 AS ?Factor2) }

UNION

…

{ ?par DUL:parametrizes ?qualityValue .

?qualityValue uomvocab:measuredIn ?Units .

<par.qualityValue.MeasureUnit> rdf:type ?AppParamMeasureUnitType .

?Units rdf:type ?AppParamMeasureUnitType.

<par.qualityValue.MeasureUnit> rdf:type uomvocab:SimpleDerivedUnit .

?Units rdf:type uomvocab:SimpleDerivedUnit .

<par.qualityValue.MeasureUnit> uomvocab:derivesFrom ?BasicUnit .

?Units uomvocab:derivesFrom ?BasicUnit .

<par.qualityValue.MeasureUnit> uomvocab:modifierPrefix ?prefix1 .

?Units uomvocab:modifierPrefix ?prefix2 .

?prefix1 uomvocab:factor ?Factor1 .

?prefix2 uomvocab:factor ?Factor2 . }

BIND (?Factor2/?Factor1 AS ?Factor)

}

Retrieving non-functional

parameter values

Units need to be converted to be comparable

No unit conversion is needed. Quality Values are identical.

Unit conversion is needed.Both Quality Values are NOT base units.

E.g. 512 MB, 1 GB

Algorithm (non-functional parameters - Scoring)

Scoring functionFunction Score-offering(?offering-value, ?app-value, ?parametrizes_type, ?min, ?prevmax, ?max, ?coefficient, ?differenceFunction, ?K) : ?Score:float

?Op = find-operator(?parametrizes_type) If ?max == unbounded Then ?maxdif = unbounded Else ?maxdif = difference(?op, ?max, ?min) ?prevmaxdif = difference(?op, ?prevmax, ?min) If ?offering-value == unbounded

Then ?y = 1 Else If !check-op(?op, ?offering-value, ?app-value)

Then ?y = 0 Else If ?op == “==”

Then ?y = 1 Else

If ?maxdif == unbounded Then ?a = abs( difference(?op, ?offering-value, ?min)) * (1-1/?prevmaxdif) / ?prevmaxdif Else ?a = abs( difference(?op, ?offering-value, ?min)) / ?maxdif

If ?Op == “<=” Then ?x = 1 – ?a Switch ?differenceFunction

Case flat: ?y = 0

Case sublinear: If ?x == 1 Then ?y = 1 Else ?y = -ln(1 - ?x)/?K

Case linear: ?y = ?x

Case superlinear: ?y = 1-exp(-?K * ?x)

Case spike: If ?x == 0 Then ?y = 0 Else ?y = 1

?Score = ?coefficient * ?y Return (?Score)

Final score for the parameter

𝑃𝑎𝑟𝑆𝑐𝑜𝑟𝑒𝑝𝑎𝑟 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 =

1, 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 = ∞0, 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 < 𝐴𝑝𝑝𝑅𝑒𝑞𝑃𝑎𝑟𝑉𝑎𝑙

𝑤𝑝𝑎𝑟𝑓𝑑𝑓𝑝𝑎𝑟 𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 , 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒

If the offering is unbounded

If the offering is worse than the application

Normal case

coefficient Difference function

Difference Functions

Flat : 𝑓𝑓𝑙(𝑥) = 0

Linear : 𝑓𝑙𝑖𝑛(𝑥) = 𝑥

Super-linear : 𝑓𝑠𝑢𝑝 𝑥 = 1 − 𝑒−𝑘𝑥

Sub-linear : 𝑓𝑠𝑢𝑏 𝑥 = 𝑓𝑠𝑢𝑝−1 𝑥 =

=−ln (1−𝑥)

𝑘

Spike - Step: 𝑓𝑠𝑝(𝑥) = 0, 𝑥 = 01, 𝑥 > 0

Calculation of x

𝑎 =

𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 − 𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙) 1 −1

𝑀𝑎𝑥𝐷𝑖𝑓𝑓

𝑀𝑎𝑥𝐷𝑖𝑓𝑓, 𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 = ∞

𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 − 𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙

𝑀𝑎𝑥𝐷𝑖𝑓𝑓, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒

If an offering has unbounded as maximum value

Different x according to parameter type:

𝑀𝑎𝑥𝐷𝑖𝑓𝑓 = 𝑃𝑟𝑒𝑣𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 − 𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙, 𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 = ∞

𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 − 𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒

𝑥 = 𝑎, 𝑝𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟. 𝑡𝑦𝑝𝑒 = 𝑀𝑖𝑛 𝑀𝑎𝑥𝑀𝑖𝑛

1 − 𝑎, 𝑝𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟. 𝑡𝑦𝑝𝑒 = 𝑀𝑎𝑥 𝑀𝑖𝑛𝑀𝑎𝑥

If an offering has unbounded as maximum value

e.g. storage capacity, more is better

e.g. latency, less is better

Java_1.4.0

Example

Application ExampleIn 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.

offering1MySQL_1GB

MySQL_5GB

offers

Capacity

ServiceNameoffers

hasParameter

hasParameter

Capacity

ServiceName

hasParameter

hasParameter

Java_1.6.0

offers

LanguageNamehasParameter

LanguageVersion

hasParameter

hasParameterDataValue

ServiceType

hasParameter

ServiceTypehasParameter








java

1.6.0

1

SQLDatabase

SQLDatabase

MySQL

5

MySQL

parametrizes

MaxMinGB

parametrizes MaxMinGB

MySQL Capacity:Max=10GBMin=1GB

MySQL_1GB, Score=0.0

MySQL_5GB, Score= (5-1)/(10-1)=4/9= 0.44

score=0.44

score=0.0score=0.44

offering2MySQL_10GB

MongoDB_15GB

offers

Capacity

ServiceNameoffers

hasParameter

hasParameter

Capacity

ServiceName

hasParameter

hasParameter

Java_1.4.0

offers

LanguageNamehasParameter

LanguageVersion

hasParameter


ServiceType

hasParameter

ServiceTypehasParameter








java

1.4.0

10

SQLDatabase

NoSQLDatabase

MySQL

15

MongoDB

parametrizes

MaxMinGB

parametrizes MaxMinGB

Example

Application ExampleIn 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.

MySQL_15GB, Score=1

MongoDB_15GB

Java_1.4.0

MySQL Capacity:Max=10GBMin=1GB

score=1score=1

Java (~700 lines of code)

Structures

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

Offering Instances

PaaS Offering Name

Programming Language

Processing Resources

Storage Latency Uptime Database Services

OpenShift java 1.6.01 core, 1 GB

Ram1 GB disc 200 99.5

mySQL/ postgreSQL/

mongoDB (unbounded

storage)

cloudBees java 1.6.0

1 core, 128 MB Ram or 2

cores, 256 MB Ram

- 100 99.5mySql (1GB or

40GB)

googleAppEngine

java 1.6.0

2 cores, 256 MB Ram or

4 cores, 512MB Ram

- 100 99.5 -

Implementation examplesApplication Instances with only functional requirement

Application Name

Programming Language

Processing Resources

Storage Latency UptimeDatabase Services

DummyApp0java (without

version)- - 150 - -

DummyApp1 java 1.6.0 - - - -mongoDB(without Storage)

Application Instances with only non-functional requirementApplication

NameProgramming

LanguageProcessing Resources


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 requirementApplication

NameProgramming

LanguageProcessing Resources


DummyApp6 -0.3 giga

(sublinear)- - -

mongoDB(without Storage)Offering Instance

OpenShift cloudBees googleAppEngine

Ap

pli

cati

on

In

stan

ce

DummyApp0 -DummyApp1 - -DummyApp2 1 0 0.44DummyApp3 0 0.99 0.99DummyApp4 1 0 0.11DummyApp5 0.66 0.67 0.69DummyApp6 1 - -

paasport semantic model and matchmaking/recommendation algorithm

Software

qos parameters

matchmaking parameters

nonfunctional parameters

nonfunctional parameters

pricing policy parameters

set dul

qos etceach concept

certain dul