PaaS semantic model and algorithm

Semantic Model and Matchmaking/Recommendation

AlgorithmPlenary 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 PaaS Concepts, such as Programming Environment, Services, Resources, QoS etc

Each Concept has some Parameters e.g. the QoS has 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 QoS and 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.

• ProgrammingEnvironment concept 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-FunctionalRetrieve parameter values Score parameter values

Check FunctionalFor each concept, offering and parameter

Run SPARQL query Keep offering or not

InitializationGetOfferings Input

PaaS Offering 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 ,𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙<𝐴𝑝𝑝𝑅𝑒𝑞𝑃𝑎𝑟𝑉𝑎𝑙𝑤𝑝𝑎𝑟 𝑓 𝑑𝑓 𝑝𝑎𝑟

(𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 ) , h𝑜𝑡 𝑒𝑟𝑤𝑖𝑠𝑒

If the offering is unbounded

If the offering is worse than the application

Normal case

coefficient

Difference function

Difference Functions

Flat :

Linear :

Super-linear :

Sub-linear :

=

Spike - Step:

Calculation of x

𝑎={¿ (𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙¿(1− 1𝑀𝑎𝑥𝐷𝑖𝑓𝑓 )

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

¿ 𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙𝑀𝑎𝑥𝐷𝑖𝑓𝑓

, h𝑜𝑡 𝑒𝑟𝑤𝑖𝑠𝑒

If an offering has unbounded as maximum value

Different x according to parameter type:

𝑀𝑎𝑥𝐷𝑖𝑓𝑓={𝑃𝑟𝑒𝑣𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 ,𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙=∞𝑀𝑎𝑥𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙−𝑀𝑖𝑛𝑂𝑓𝑓𝑃𝑎𝑟𝑉𝑎𝑙 , h𝑜𝑡 𝑒𝑟𝑤𝑖𝑠𝑒

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

If an offering has unbounded as maximum value

e.g. storage capacity, more is bettere.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








T͚java V͚

T͚1.6.0 V͚

1

T͚SQLDatabase V͚

T͚SQLDatabase V͚

T͚MySQL V͚

5

T͚MySQL V͚

parametrizesMaxMinGB

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








T͚java V͚

T͚1.4.0 V͚

10

T͚SQLDatabase V͚

T͚NoSQLDatabase V͚

T͚MySQL V͚

15

T͚MongoDB V͚

parametrizesMaxMinGB

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 InstancesPaaS

Offering Name

Programming Language

Processing Resources

Storage Latency Uptime Database Services

OpenShift java 1.6.01 core, 1 GB Ram

1 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


Processing

Resources

Storage

Latency

Uptime Database Services

DummyApp0

java (without version) - - 150 - -

DummyApp1 java 1.6.0 - - - -

mongoDB

(without Storage)

Application Instances with only non-functional requirement

Application Name


Processing

Resources

Storage

Latency UptimeDatabas

e 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


Processing

Resources

Storage

Latency

Uptime Database Services

DummyApp6 -

0.3 giga (sublinear

)- - -

mongoDB

(without Storage)

Offering InstanceOpenShi

ft cloudBeesgoogleAppEngi

ne

Application

Instance

DummyApp0 -

DummyApp1 - -

DummyApp2 1 0 0.44

DummyApp3 0 0.99 0.99

DummyApp4 1 0 0.11

DummyApp5 0.66 0.67 0.69

DummyApp6 1 - -

Date post:	27-Jul-2015
Category:	Technology
Upload:	nick-bassiliades
View:	158 times
Download:	3 times

PaaS semantic model and algorithm

Technology