Post on 17-Jul-2015
transcript
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]
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 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
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 QoSand 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.
• ProgrammingEnvironmentconcept 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-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
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
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
hasParameterDataValue
ServiceType
hasParameter
ServiceTypehasParameter
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
hasParameterDataValue
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
Storage Latency UptimeDatabase 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 requirementApplication
NameProgramming
LanguageProcessing Resources
Storage Latency UptimeDatabase Services
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 - -