PaaS semantic model and algorithm
-
Upload
nick-bassiliades -
Category
Technology
-
view
160 -
download
3
Transcript of 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]
requires[allValuesFrom]
requires[allValuesFrom]
requires[allValuesFrom]
MaxCPULoad
MinMemoryLoad
dul:hasParameter[allValuesFrom]
Rating
PaaSProcingPolicy
requires[allValuesFrom]
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
property restriction
rdfs:subPropertyOf
Application
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]
requires[allValuesFrom]
requires[allValuesFrom]
requires[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
property restriction
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
ProgrammingEnvironment
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
property restriction
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
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
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
hasParameterDataValue
ServiceType
hasParameter
ServiceTypehasParameter
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
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
Programming Language
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
Programming Language
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
Programming Language
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 - -