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


S1 S3 S5

S2 S4

8


S1 S3 S5

S2 S4

Functional Service Filtering

8


S1 S3 S5

S2 S4


S1 S3 S5

8


S1 S3 S5

S2 S4


Non-Functional Service Filtering

S1 S3 S5

8


S1 S3 S5

S2 S4



S1 S3

S1 S3 S5

8


S1 S3 S5

S2 S4



Non-Functional Service Selection

Current QoSof S1 and S3

S1 S3

S1 S3 S5

8


S1 S3 S5

S2 S4





S1 S3

S1 S3 S5

Statically definedPreferences

8


S1 S3 S5

S2 S4



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






preference level

0

1

0.25 0.5 0.75 10.35

15






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

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

[email protected]

+33 (0)1 69 41 55 65

21

mailto:[email protected]

mailto:[email protected]

flins'08 - a linguistic approach for non-functional constraints in a semantic soa environment

Technology