1. A linguistic approach for non-functional constraints
in a semantic SOA environment
Pierre Châtel
Thales Land & Joint Systems, Université Pierre et Marie Curie - Paris 6, LIP6
Isis Truck
LIASD, Université de Vincennes à Saint Denis - Paris 8
Jacques Malenfant
Université Pierre et Marie Curie - Paris 6, CNRS, UMR 7606 LIP6
1

2. Research Topic
Non-functional constraint handling in Semantic Service Oriented
Architectures.
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.
2

3. Contents
1. Context
2. Preference Model
3. LCP-Net example
4. Related works
5. Conclusion
3

4. Context
SOA
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

5. Context
Multi-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

6. Context
Impact 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

7. Context
SemEUsE 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

8. Context
SemEUsE framework
8

9. Context
SemEUsE framework
S1 S3 S5
S2 S4
8

10. Context
SemEUsE framework
S1 S3 S5
S2 S4
8

11. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
8

12. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
S1 S3 S5
8

13. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
S1 S3 S5
Non-Functional Service Filtering
8

14. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
S1 S3 S5
Non-Functional Service Filtering
S1 S3
8

15. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
S1 S3 S5
Non-Functional Service Filtering
S1 S3
Non-Functional Service Selection
Current QoS
of S1 and S3
8

16. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
S1 S3 S5
Non-Functional Service Filtering
S1 S3
Non-Functional Service Selection
Current QoS
of S1 and S3
Statically defined
Preferences
8

17. Context
SemEUsE framework
Functional Service Filtering
S1 S3 S5
S2 S4
S1 S3 S5
Non-Functional Service Filtering
S1 S3
Non-Functional Service Selection
S3
Current QoS
of S1 and S3
Statically defined
Preferences
8

18. Contents
1. Context
2. Preference model
3. LCP-Net example
4. Related works
5. Conclusion
9

19. Preference model
LCP-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

20. Preference model
LCP-Net instance
From static preferences...
QoS for surveillance camera services :
S = Security
B = Bandwidth
R = image Resolution
... 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.
11

21. Preference model
LCP-Net instance
From static preferences...
QoS for surveillance camera services :
&
S = Security
B = Bandwidth
R = image Resolution
... 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.
11

22. Contents
1. Context
2. Preference Model
3. LCP-Net example
4. Related works
5. Conclusion
12

23. LCP-Net Example
In 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

24. LCP-Net Example
Step 1 - QoS values injection
Multiple QoS Values retrieved from monitoring layer can be of two kinds:
• Crisp QoS values → “Singleton” fuzzy subset.
1 LOW MEDIUM HIGH
Bandwidth Bandwidth
= 30 kb/s = 0.30
Normalization Fuzzification
• Fuzzy QoS value → “Adjusted” fuzzy subset. 0 0.5 1
bandwidth
1 Retrieved Fuzzy Value 1 LOW quot;Adjustedquot; Fuzzy Subset HIGH
Domain normalization
0
512 1024 0
0.5 1
resolution
resolution
14

25. LCP-Net Example
Step 2 - Local utility values inference
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’) = ?
high
very low low medium very high
1 LOW MEDIUM HIGH
1
0.75
0 0.5 1 0 0.25 1
0.5
bandwidth
preference level
15

26. LCP-Net Example
Step 2 - Local utility values inference
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’) = ?
1
0.75
0.35
0 0.25 1
0.5
preference level
15

27. LCP-Net Example
Step 2 - Local utility values inference
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’) = ?
local_utility(B’) = 0.35 or (low, +0.10)
15

28. LCP-Net Example
Step 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.
weight weight
≈ 0.235 ≈ 0.529
depth = 2 depth = 1 weight
transform depths into
normalized weights in
[0,1], summing to 1
weight
depth = 2 depth ≈ 0.235
16

29. LCP-Net Example
Step 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.35
local_ utility(Sfull) = 1 S1
local_ utility(B’, R’) = 0.20 QoS snapshot at t = (B’, Sfull, R’)
• 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)
17

30. LCP-Net Example
Step 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(S3) = (medium, -0,15)
g_u(S2) = (low, -0,10) g_u(S4) = (very-low, +0)
18

31. LCP-Net Example
Step 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(S3) = (medium, -0,15)
g_u(S2) = (low, -0,10) g_u(S4) = (very-low, +0)
18

32. 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 tradeos over NFPs as well as service level
objectives (SLO), it relies on both TCP and UCP networks.
19

33. 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

34. Thank you for your attention...
Any questions ?
Pierre Châtel
Thales Land Joint Systems
@ Thales Research Technologies (TRT)
RD 128
91767 Palaiseau Cedex - France
pierre.chatel@thalesgroup.com
+33 (0)1 69 41 55 65
21