1. Translating User Preferences into Fuzzy Rules for the Automatic Selection of Services Ioana Sora, Doru Todinca, Catalin Avram Department of Computers Politehnica University of Timisoara, Romania

2. 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 Service Registry Publish Service Descriptions Find Service (S1) Find Service (S2) bind Problems: Service Description Service Discovery Service Selection Service Composition

3. Our Research Problem and Approach Service Description Service Discovery Service 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

4. 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 lowmediumhigh 0 infinity fast mediumslow Basic Ontology Concepts Example

5. 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 lowmediumhigh 0 infinity fast mediumhigh Ontology Example Service1: DeLuxeTours TravelScheduler Availability=95 ResponseTime=56 Service2: BudgetTravel TravelScheduler Availability=medium ResponseTime=74 Service Description Examples

6. Service Registry Implementation – Service QoS Descriptions in XML <service id="S0001" name="Happy Camper" functionality="TravelScheduler"> <service id="S0002" name="De Luxe Tours" functionality="TravelScheduler"> <service id="S0003" name="LocalWeather" functionality="WeatherForecast">

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

8. Automatic selection /ranking Individual Client Requirements/ QoS Preferences Example: 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 Rules the linguistic variable in conclusion is the selection decision, with terms ranging from strong accept to strong reject Fuzzy Inference Engine Service Registry Selected (ranked) services Each service description becomes a fact for an inference process Generation strategyA Generation strategyB

9. 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= WeakAccept If Availability=Low and ResponseTime=slow then SelectionDecision= WeakReject If Availability=Unreliable and ResponseTime=medium then SelectionDecision=WeakReject If Availability=Unreliable and ResponseTime=slow then SelectionDecision=StrongReject … etc.

10. 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 70 The new lingvistic variables in premises are MatchingAvailability and MatchingResponseTime For 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= WeakAccept If Availability=NearLeft and Response-Time=NearRight then SelectionDecision= WeakReject

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

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

13. Results

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