FLINS'08 - A linguistic approach for non-functional constraints in a semantic SOA environment
-
Upload
pierre-chatel -
Category
Technology
-
view
1.018 -
download
0
description
Transcript of FLINS'08 - A linguistic approach for non-functional constraints in a semantic SOA environment
A linguistic approach for non-functional constraints in a semantic SOA environment
Pierre ChâtelThales Land & Joint Systems, Université Pierre et Marie Curie - Paris 6, LIP6
Isis TruckLIASD, Université de Vincennes à Saint Denis - Paris 8
Jacques MalenfantUniversité Pierre et Marie Curie - Paris 6, CNRS, UMR 7606 LIP6
1
Research Topic
The Service Oriented Architecture (SOA) is divided between:
• Atomic feature producers, or (Web) services.
• Atomic feature consumers, or (Web) processes.
Semantic SOA:
• Usually provides: service offers ⊕ high level business concepts, extracted from domain ontologies, published in registries.
• We add: preferences between services non-functional properties, seen as “user semantics”.
Application domains: any domain where a dynamic coordination of services under quality constraints and with some guarantees is needed.
Non-functional constraint handling in Semantic Service Oriented Architectures.
2
Contents
1. Context
2. Preference Model
3. LCP-Net example
4. Related works
5. Conclusion
3
ContextSOA
Functional properties of Web services:
• Provided domain features.
• Ex. for a car service: move, carry persons or goods, protect from weather, a specific type of car.
Non-functional properties of Web services:
• Service features execution modalities that affect the provided or perceived Quality of Service (QoS).
• Ex. for a car service:
- Maximal speed.
- Tank capacity → traveling distance.
- Number of gears.
- Motor levels: temperature, oil, revolutions, ...
4
ContextMulti-Criteria Decision Making
The decision being made, in this application context, is the dynamic linking of an abstract service invocation in a Web process to one of its physical implementation (i.e a specific Web service), presumably the best-suited one.
Candidate services expose multiple non-functional properties, each one being a potentiel criterion for election of the best-suited service.
• Static filtering of services on individual criterion constraints → partial order.
• User preferences, between non-functional properties → total order.
5
ContextImpact on preference definition
In our SOA-driven context:
• Preferences must be easy to define since there are no preference modeling experts, nor many ressources to allocate for their elicitation.
➥ Some imprecision must be tolerated in preference models.
• Variables are limited in preference models (at most ~ 10 variables).
• Computation time for decision-making based on preferences is seen as relatively small compared to the subsequent networked service invocation.
It leads to the following sought-after properties of the preference formalism:
✓It must be graphical to ease definition and computation.
✓It must be qualitative as a mean to deal with imprecision → linguistic values integration.
6
ContextSemEUsE project
SemEUsE = “Sémantique pour bus de services”
• 3-year french ANR project, over €1M budget.
• 6 partners: Thales, FT, EBM, LIP6, INSA, INRIA, INT.
Implements “smart” web services orchestration...
• by static service filtering on functional and non-functional properties.
• by dynamic non-functional service selection.
Dedicated late-binding components implements selection by binding each service call in a running process to a single candidate service extracted from a set of otherwise functionally-equivalent services, using:
• Current QoS values of monitored services.
• Statically defined preferences over QoS properties of services.
7
ContextSemEUsE framework
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
S1 S3 S5
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
Non-Functional Service Filtering
S1 S3 S5
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
Non-Functional Service Filtering
S1 S3
S1 S3 S5
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
Non-Functional Service Filtering
Non-Functional Service Selection
Current QoSof S1 and S3
S1 S3
S1 S3 S5
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
Non-Functional Service Filtering
Non-Functional Service Selection
Current QoSof S1 and S3
S1 S3
S1 S3 S5
Statically definedPreferences
8
ContextSemEUsE framework
S1 S3 S5
S2 S4
Functional Service Filtering
Non-Functional Service Filtering
S3
Non-Functional Service Selection
Current QoSof S1 and S3
S1 S3
S1 S3 S5
Statically definedPreferences
8
Contents
1. Context
2. Preference model
3. LCP-Net example
4. Related works
5. Conclusion
9
Preference modelLCP-Nets
“Linguistic Conditional Preference-Networks”, an extension of CP-Nets [Boutilier et al., 1999].
Domain agnostic, but can be used for formal specification of preferences in our SOA context, in order to:
• Reveal relative importance of non-functional properties.
• Elicit preferred values for a specific QoS domain.
• Indicate tradeoffs between non-functional properties.
And is easy to understand, define, manipulate:
• Qualitative model: linguistic terms for QoS values (e.g. none, full for Security) and preference degrees (e.g. very_low, ... , very_high) [Zadeh, 1975; Herrera & Martínez, 2000].
• Graphical model: nodes, edges and preference tables.
10
Preference modelLCP-Net instance
... to efficient decision-making system at runtime:
• Utility tables mapped to fuzzy rule sets, as in fuzzy control.
• Inputs as crisp or fuzzy measured values from monitored services.
• Evaluation output as a crisp or linguistic (e.g. 2-tuple) utility value.
From static preferences...
QoS for surveillance camera services :S = SecurityB = BandwidthR = image Resolution
11
Preference modelLCP-Net instance
... to efficient decision-making system at runtime:
• Utility tables mapped to fuzzy rule sets, as in fuzzy control.
• Inputs as crisp or fuzzy measured values from monitored services.
• Evaluation output as a crisp or linguistic (e.g. 2-tuple) utility value.
&
From static preferences...
QoS for surveillance camera services :S = SecurityB = BandwidthR = image Resolution
11
Contents
1. Context
2. Preference Model
3. LCP-Net example
4. Related works
5. Conclusion
12
LCP-Net ExampleIn 5 steps
An example of a Security Camera preference evaluation, broke down into 5 key steps for selection of the best-suited service:
Step 1 - QoS values injection
Step 2 - Local utility values inference
Step 3 - Nodes weights computation
Step 4 - Global utility value computation
Step 5 - Service comparison and selection
13
Multiple QoS Values retrieved from monitoring layer can be of two kinds:
• Crisp QoS values → “Singleton” fuzzy subset.
• Fuzzy QoS value → “Adjusted” fuzzy subset.
LCP-Net ExampleStep 1 - QoS values injection
Bandwidth = 30 kb/s
Bandwidth = 0.30
Normalization Fuzzification
bandwidth0
1
1
LOW MEDIUM HIGH
0.5
Domain normalization
resolution
0
1
1024512
Retrieved Fuzzy Value
resolution
0
1
1
LOW HIGH
0.5
"Adjusted" Fuzzy Subset
14
Use of Generalized Modus Ponens [Zadeh, 1975] for inference of each node utility (i.e local utility). In this example for bandwidth:
• 3 fuzzy subsets = BL, BM, BH
• B’ = 0.3 is measured.
• local_utility(B’) = ?
LCP-Net ExampleStep 2 - Local utility values inference
bandwidth0
1
1
LOW MEDIUM HIGH
0.5
preference level
0
1
0.25 0.5 0.75
very low
1
low medium high very high
15
Use of Generalized Modus Ponens [Zadeh, 1975] for inference of each node utility (i.e local utility). In this example for bandwidth:
• 3 fuzzy subsets = BL, BM, BH
• B’ = 0.3 is measured.
• local_utility(B’) = ?
LCP-Net ExampleStep 2 - Local utility values inference
preference level
0
1
0.25 0.5 0.75 10.35
15
Use of Generalized Modus Ponens [Zadeh, 1975] for inference of each node utility (i.e local utility). In this example for bandwidth:
• 3 fuzzy subsets = BL, BM, BH
• B’ = 0.3 is measured.
• local_utility(B’) = ?
LCP-Net ExampleStep 2 - Local utility values inference
local_utility(B’) = 0.35 or (low, +0.10)
15
LCP-Net ExampleStep 3 - Nodes weights computation
Arcs in preference model give the relative importance of QoS properties.
Nodes weights computed to preserve implicit relative importance in global utility value computation:
• Weights based on node depth in graph.
• Lower depth in graph → Higher weight in preference model.
depth
weightdepth = 1depth = 2
depth = 2
weight ≈ 0.529
weight ≈ 0.235
weight ≈ 0.235
transform depths intonormalized weights in [0,1], summing to 1
16
LCP-Net ExampleStep 4 - Global utility value computation
Aggregation of local utilities to obtain global service utility.
Weighted average operator ∆, using previously computed weights:
• ∃ Web service S1 |local_utility(B’) = 0.35local_ utility(Sfull) = 1 local_ utility(B’, R’) = 0.20
• global_utility(S1) = ∆(0.529 x 0.35 , 0.235 x 1 , 0.235 x 0.20)) ≈ 0.47
global_utility(S1) = 0.47 or (medium, -0.03)
S1QoS snapshot at t = (B’, Sfull, R’)
17
LCP-Net ExampleStep 5 - Service comparison and selection
Automatic, using crisp global utility values.
Human-based, using 2-tuple global utility values (as shown below).
g_u(S1) = (medium, -0,03)
g_u(S2) = (low, -0,10)
g_u(S3) = (medium, -0,15)
g_u(S4) = (very-low, +0)
18
LCP-Net ExampleStep 5 - Service comparison and selection
Automatic, using crisp global utility values.
Human-based, using 2-tuple global utility values (as shown below).
g_u(S1) = (medium, -0,03)
g_u(S2) = (low, -0,10)
g_u(S3) = (medium, -0,15)
g_u(S4) = (very-low, +0)
18
Related works
UCP-Nets [Boutilier et al., 2001] are a directed graphical representation of utility functions that combines aspects of two existing preference models: generalized additive models and CP-Nets. They decompose a utility function into a number of crisp additive factors, whereas LCP-Nets use fuzzy terms.
TCP-Nets [Brafman et al., 2002] add variable importance tradeoffs into CP-Nets by introducing two new edge types: i-arcs and ci-arcs, incorporated in our LCP-Net formalism.
GAI-Networks [Gonzales & Perny, 2005] follow an other approach for graphical preference elicitation and preference-based optimization in the context of multi-attribute utility theory.
Recent works [Schröpfer et al., 2007] have proposed a system for specifying hard constraints, preferences and tradeoffs over NFPs as well as service level objectives (SLO), it relies on both TCP and UCP networks.
19
Conclusion
LCP-Nets build on previously established works from the decision-making and fuzzy-logic communities.
In the SOA context, they have a concrete application in the form of multicriteria decision making for Web service selection.
A fully-working LCP-Net definition and evaluation framework is currently being implemented:
• It is driven by the french SemEUsE project.
• It should be available, as soon as possible, under a free licensing scheme.
20
Thank you for your attention...Any questions ?
Pierre ChâtelThales Land & Joint Systems@ Thales Research & Technologies (TRT)RD 12891767 Palaiseau Cedex - France
+33 (0)1 69 41 55 65
21