Translating User Preferences into Fuzzy Rules for

the Automatic Selection of Services

Ioana Sora, Doru Todinca, Catalin AvramDepartment of Computers

Politehnica University of Timisoara, Romania

Problem Domain Background: Service Oriented Computing

• Service-oriented systems are created by linking software services provided by different service providers.

Service Requestor

Service Requestor

Service Provider

Service Provider

Service Provider

S2

S1

S2

S1

ServiceRegistry

Publish Service DescriptionsFind Service (S1)

Find Service (S2) bind

bind

Problems:Service DescriptionService DiscoveryService SelectionService Composition

Our Research Problem and Approach

Service DescriptionService DiscoveryService Selection

NEEDS: Description and matchmaking at levels:

EXISTING: Standards and technologies:

Functional

Semantic

User Preferences, QoS Parameters

Functional

Semantic

User Preferences, QoS Parameters

Novel fuzzy logic based approach for:• Service description: fuzzyfying QoS domain ontology

• Service selection(ranking): by fuzzy inference with

a set of automatically generated rules

WSDL, UDDI, WSDL-S, OWL-S

Our Fuzzyfying QoS Domain Ontology• an explicit semiformal specification of how to describe and classify values of

non-functional (QoS) properties in the context of a certain functionality

Functional property

Non-Functional Property1

Domain

Direction

FuzzyTerms

Non-Functional Property2

TravelScheduler

Availability

ResponseTime

0 100

unreliable low medium high

0 infinity

fast medium slow

Basic Ontology Concepts Example

Service Descriptions

• QoS descriptions are added to all published service descriptions• QoS descriptions are interpreted with help from the the domain ontology• QoS parameters in a service description are values that can be crisp or fuzzy

TravelScheduler

Availability

ResponseTime

0 100

unreliable low medium high

0 infinity

fast medium high

Ontology Example

Service1: DeLuxeTours

TravelScheduler

Availability=95

ResponseTime=56

Service2: BudgetTravel

TravelScheduler

Availability=medium

ResponseTime=74

Service Description Examples

Service Registry Implementation – Service QoS Descriptions in XML

<service id="S0001" name="Happy Camper"functionality="TravelScheduler"><prop name="Availability" fuzzy="High" /><prop name="ResponseTime" crisp="500" /><prop name="PublReputation" fuzzy="Medium" /></service>

<service id="S0002" name="De Luxe Tours"functionality="TravelScheduler"><prop name="Availability" crisp="90.7" /><prop name="ResponseTime" crisp="100" /><prop name="Cost" crisp="10" /></service>

<service id="S0003" name="LocalWeather"functionality="WeatherForecast"><prop name="Availability" crisp="80.8" /><prop name="ResponseTime" crisp="200" /><prop name="PublReputation" fuzzy="good" /></service>

Client Requirements

• The Client requirement has to specify both functional and non-functional requirements.

• The functional requirements are non-negotiable.

• The non-functional requirement can be:

– non-negotiable (exact value or sharp interval)

– negotiable (around a value or around an interval)

– best-possible

Automatic selection /ranking

Individual Client Requirements/ QoS PreferencesExample: Find a TravelScheduler service with

Availability at least about medium, Cost at most about 50, ResponseTime about 70

Automatic Fuzzy Rules Generator

Set of Fuzzy Rulesthe linguistic variable in conclusion is the selection decision,

with terms ranging from strong accept to strong reject

Fuzzy Inference EngineService Registry

Selected (ranked) services

Each service description becomes a fact for an inference process

Generation strategyA

Generation strategyB

Rules generation - Strategy A

The client request is translated in fuzzy terms from the domain ontology to specify the requested values.

Example Client Requirement : Find a TravelScheduler service with: Availability at least about medium and ResponseTime about 70

For example, in the DomainOntology, the value 70 for ResponseTime falls into the term medium for response time:

If Availability=medium and ResponseTime=medium then SelectionDecision= StrongAccept

For Availability (requested as at least about) better values lead to the same decision:If Availability=high and ResponseTime=medium then SelectionDecision= StrongAccept

For the less good matches, the strenght of the conclusion will be diminished proportionally with the distance from the ideal situation.

If Availability=Low and ResponseTime=medium then SelectionDecision= WeakAcceptIf Availability=Low and ResponseTime=slow then SelectionDecision= WeakRejectIf Availability=Unreliable and ResponseTime=medium then SelectionDecision=WeakRejectIf Availability=Unreliable and ResponseTime=slow then SelectionDecision=StrongReject… etc.

Rules generation - Strategy B

A new MatchingNeighborhood ontology is generated, describing for each property the meaning of matching exactly the target, or being near or far away from the target.

Example Client Requirement : Find a TravelScheduler service with: Availability at least about medium and ResponseTime about 70The new lingvistic variables in premises are MatchingAvailability and MatchingResponseTimeFor each MatchingProperty, the terms Exactly, NearLeft, FarLeft, VeryFarLeft, NearRight,

FarRight, VeryFarRight are automatically generated, having trapezoidal shapes automatically generated considering a percentually distance from the center in Exactly and pondered with the limits of the terms in the domain ontology

If Availability=Exactly and ResponseTime=Exactly then SelectionDecision= StrongAccept

For the less good values, the strenght of the conclusion will be diminished proportionally with the distance from the ideal situation.

If Availability=NearLeft and ResponseTime=Exactly then SelectionDecision= WeakAcceptIf Availability=NearLeft and Response-Time=NearRight then SelectionDecision= WeakReject

Rule generation parameters

• Variable parameters for rule generation: – Number of terms in conclusions (how many degrees of acceptance are

there defined between very strong accept and very strong reject)

– Number of generated neighborhoods (how many categories there are to describe an inexact match for a property, from near to very far).

– Proportionality relationship (linear or not) between the cumulated distance from the ideal match and the degree of weakening the conclusion

– Relative importance of properties that can be differently taken into account when computing the cumulated distance

Experiments• We studied the influence of the rule generation strategy over the

overall quality of the ranking result. • We define following metrics in order to appreciate the quality of a

ranking strategy:– Ranking hierarchy of solutions: is it the same hierarchy as the ideal one or

some inversions appear ?– The average ranking step (the distance between candidates ranked on

consecutive positions): we want clear hierarchies– The range covered by the ranking scores: we want that the scores don’t

crowd only in the selectable or only in the unselectable area– The number of distinct ranks: we want to differentiate as much as possible

between all candidates, and not repeatedly rank several candidates on similar scores

• Experiments performed: – 26 candidates to be ranked on 5 properties– Strategies A and B– Number of terms in conclusion: between 2 and 8– Number of generated neighborhoods: up to 2 neighbors on each side

ResultsMinimum & Maximum ranking scores

00.20.40.60.8

1

B(2) B(3) B(4) B(5) B(6) B(7) B(8) A(4)

Strategies used for ranking

Number of distinct ranks

05

1015202530

B(2) B(3) B(4) B(5) B(6) B(7) B(8) A(4)

Distinct values Maximum possible distinct values

Average ranking step

0

0.01

0.02

0.03

0.04

B(2) B(3) B(4) B(5) B(6) B(7) B(8) A(4)

Cummulated ranking inversions

Rankings compared to this one

0

5

10

15

B(2) B(3) B(4) B(5) B(6) B(7) B(8) A(4)

Conclusions

• We start by enriching service descriptions with specification of QoS properties, based on our Fuzzyfying QoS Domain Ontology

• The novelty of our approach: using fuzzy inference for ranking/selecting services, but based on sets of on-line automatically generated fuzzy rules for each set of individual preferences

• Advantages of our approach:– Deals with imprecise/incomplete matching of requirements

– Selection through fuzzy inference instead of FMCDM:

• Selection criteria can be made much more flexible

• The proposed automatic online generation of the rules for the inference process is the key factor that enables the practical use of this approach