WS-Agreement Based Semantic Partner Selection A component of the Meteor-S project

1. WS-Agreement Based Semantic Partner SelectionA component of the Meteor-S project Nicole Oldham, LSDIS Lab, University of Georgia SWAPS Project Page

2. Outline WS-Agreement Project Objective Related Work Solution Reasoning Semantic Modeling Rules Searching Algorithm Architecture Example Use Case

3. Name Context Agreement Terms Service Terms Guarantee Terms WS-Agreement Structure • Objective: to define a language and protocol for:- -Establishing agreement between two parties • -Advertising the capabilities and requirements of • service consumers and providers • -Creating agreements based on creation offers • -Monitoring the agreement compliance at runtime <wsag:GuaranteeTerm Obligated=”wsag:ServiceRoleType”> <wsag:ServiceScope ServiceName=”xsd:NCName”> xsd:any </wsag:ServiceScope> <wsag:QualifyingCondition>...</wsag:QualifyingCondition> <wsag:ServiceLevelObjective>…</wsag:ServiceLevelObjective> <wsag:BusinessValueList>…</wsag:BusinessValueList> </wsag:GuaranteeTerm>

4. WS-Agreement • Allows users to specify requirements and capabilities in the following domains/categories: • Scopes: describes to what service element specifically a service applies. A performance guarantee might only apply to one operation of a Web service at a particular end point • computeJob1, validateCreditCard • Service Level Objectives: expresses the condition that must be met to satisfy the guarantee. • responseTime < 2 seconds • Qualifying conditions: express a precondition under which a guarantee holds. • numRequests < 100 • Business Values: expresses importance, confidence, penalty, and reward. • Penalty 5 USD

5. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Searching Algorithm Architecture Example Use Case

6. What is the objective? • Goal: to be able to reason dynamically over scope, objectives, conditions, and business values to find the best possible match. • What is the challenge? - heterogeneous service level objectives different ways to say the same thing For Example: 98% of responses < 2s responseTime < 2s - objectives can only be met under certain conditions. How to determine which conditions are more suitable for consumer? ie: txRate VS weekday - tradeoffs exist for different consumers Consumer may prefer certain business values over other factors. ie: provider1 rt < 10 s and penalty 15 USD provider2 rt < 5s and penalty 1 USD *consumer may prefer slower with higher penalty - matching should be symmetric such that both consumer and provider’s requirements are met. Why is this an important problem to solve?

7. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Rules Searching Algorithm Architecture Use Case

8. Related Work • [Uszok et al., 2004] Policy and Contract Management for Semantic Web Services, AAAI Spring Symposium on Semantic Web Services, 2004 • KAoS services and tools allow for specification and management of policies. • KPO – KAoS uses ontology concepts to build policies • Is restricted by the functionality of OWL • Does not consider rules and numeric expressions (later work uses role-value maps for rules) • [Wohlstadter et al., 2004] GlueQoS: Middleware to Sweeten Quality-of-Service Policy Interactions, (ICSE 2004) • Extends the grammar of WS-Policy to support qualifying conditions • Not Semantic!

9. Related Work • WSLA: Compatibility Analysis, Heiko Ludwig and Asit Dan • What they do: • Parse WSLAs into syntax trees and match algorithm compares node by node • Handle heterogeneous SLOs with weakening functions Table shows how to decide which has the looser condition - Consult a lookup table to determine how to compare SLOs • What they don’t do: • Consider Actions (the WSLA equivalent of qualifying conditions) • Utilize semantics to achieve better matches. • Use rules to capture user preferences and domain knowledge < < > RECONSTRUCT RT 5 PLTT 95% RT 2 RT 2

10. Related Work • Kunal Verma, Rama Akkiraju, Richard Goodwin, Semantic Matching of Web Service Policies, Second International Workshop on Semantic and Dynamic Web Processes (SDWP 2005) • Semantic policy matching • Use a combination of OWL and SWRL based rules to capture domain concepts and rules • Use of semantics and rules enables the discovery of matches that a syntactic matcher probably wouldn’t discover. • Example: Provider: BusinessLevel of requestor must be Enterprise Requestor has a Dun & Bradstreet rating of A3. Rule: If a company has Dun &Bradstreet rating A3 then it is enterprise level when: Policy (P) and hasAlternative (P, ALT) and hasAssertion (ALT, A) and DunAndBradStreetRating(A, “A3”) do: Assertion (A1) and BusinessLevel (A1, “Enterprise”) and hasAssertion (ALT, A1) • What they don’t do: • Reason over qualifying conditions or business values • Allow the user to specify tradeoffs and preferences

11. Contributions of this work • Present a framework for semantically matching agreements. • This framework considers scopes, objectives, qualifying conditions and business values as factors during matching. • A flexible matching algorithm which allows users to specify preferences and tradeoffs through the use of rules

12. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Searching Algorithm Architecture Example Use Case

13. How I solved the problem A Semantic Approach • Represented domains with ontologies • WS-Agreement: individual agreements are instances of the WS-Agreement ontology • Domain Ontology • Temporal Concepts: time.owl (DAML time) • Concepts: seconds, dayOfWeek, ends • Quality of Service: Dr. Michael Maximilien’s QoS ontology (IBM). • Concepts: responseTime, failurePerDay • Designed a flexible matching algorithm which eliminates needless matching with the use of ontological queries • Provided abstraction from the code such that the user may specify tradeoffs, preferences, and semantics by modifying one file of ARL rules.

14. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Searching Algorithm Architecture Example Use Case

15. WS-Agreement Ontology hasGuaranteeTerm GuaranteeTerm hasBusinessValue hasScope hasObjective hasCondition Scope BusinessValue ServiceLevelObjectivev Qualifying Condition hasReward Reward Predicate Predicate hasPenalty hasImportance Penalty Parameter Parameter Unit Importance Value ValueExpression Unit Value ValueUnit ValueExpression OWL ontology Assessment Interval Assessment Interval ValueUnit TimeInterval Count Count TimeInterval

16. Sample Agreement <wsag:GuaranteeTerm wsag:Name="TransferTimeJob1"> <wsag:Obligated>ServiceProvider</wsag:Obligated> <wsag:ServiceScope> <wsag:ServiceName>ComputeJob1</wsag:ServiceName> </wsag:ServiceScope> <wsag:ServiceLevelObjective> <wsag:predicate type="less"> <wsag:parameter>qos:ResponseTime</wsag:parameter> <wsag:value>5</wsag:value> <wsag:unit>time:seconds</wsag:unit> </wsag:predicate> </wsag:ServiceLevelObjective> <wsag:BusinessValueList> <wsag:Penalty> <wsag:AssessmentInterval> <wsag:Count>1</wsag:Count> </wsag:AssessmentInterval> <wsag:ValueExpression>5</wsag:ValueExpression> <wsag:ValueUnit>USD</wsag:ValueUnit> </wsag:Penalty> </wsag:BusinessValueList> </wsag:GuaranteeTerm>

17. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Searching Algorithm Architecture Example Use Case

18. Reasoning • Match Criteria • Each consumer requirement must be satisfied. • Each provider requirement must be satisfied. • Scope: each guarantee term has a service scope for which that guarantee applies. ie: computeJob1, validateCredit • The value of this parameter is a concept from the domain ont. • Scope is not an optional parameter. • SLO: must be compatible, the provider SLO must meet or exceed the need expressed in the consumer SLO • ie: responseTime < 4s • Heterogenity of SLOs will be dealt with by conversions using ARL rules and ontologies. • SLO parameter will be a variable from the WS-Agreement or a concept from one of the ontologies (probably QoS) • Qualifying Condition: One provider’s qualifying condition may be more suitable for the consumer than another’s. • User will define rules which specify preferences • Business Values • I assume user will always prefer a higher penalty amount to a lower amount but the differences in agreements will never be this simple. • User will define rules which specify tradeoff preferences

19. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Searching Algorithm Architecture Example Use Case

20. Categories of Rules 1. Conversions for Heterogeneous SLOs ie: PercentageLessThanThreshold, etc. When there exists an SLO such that the predicate equals PercentLessThanThreshold Do if (percentage >= UserDefinedThreshold) predicate = less else predicate = greater 2. Semantics of Predicates When there exists an agreement which has an SLO such that predicate is less and a second agreement which also has an SLO with the predicate less AND the parameters of the two SLOs are the same Do if (value2 > value1) assert: slo1 isStronger slo2 else if (value1 > value2) assert: slo2 isStronger slo1 else assert: slo1 isEquivalent slo2

21. Categories of Rules 3. User preferences or tradeoffs When a guaranteeX exists whose qualifying condition parameter is txRate and another guaranteeY with the same objective has a qualifying condition parameter dayOfWeek Do guaranteeX isPreferedOver guaranteeY An assertion using the verb “notSuitable” would allow the user to state which conditions will never be appropriate • Domain Specific User Defined Rules ex: totalPrice = unitPrice + tax + freight + specialHandling totalTime = executionTime + networkTime availablility = totalTimeAvailable in last Q seconds/ Q seconds reliability = # of successful deliveries / total # of invokations When an agreement exists which has an SLO with parameter executionTime and an SLO with parameter networkTime Do Create a new guarantee for that agreement with an SLO that has parameter totalTime = the sum of the values of the two SLOs with a qualifying condition that is the compound of the two guarantees. • Unit Conversions seconds -> ms bytes -> mB

22. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Searching Algorithm Architecture Example Use Case

23. The Control Flow Parsing 1. As agreements are parsed they are entered into SnoBase as instances of the WSAG ontology. SNOBASE As these new predicates are entered, if the conditions in the ARL rules become present those rules will be fired at this time The process of searching for a match occurs as soon as a consumer is seeking a partner. The searching algorithm will query the predicates in SNOBASE to find the best match Searching 2.

24. Searching Algorithm Narrows set Eliminates Needless Matching providerSet = set of all potential providers For each Consumer Guarantee, get Scope cScope { providerSet = all providers who have a guarantee with the same scope as cScope and were in the prev. set } if providerSet is empty there are no suitable providers else { For each provider p from providerSet { For each consumer guarantee term Gc { if the obligatedParty of Gc is ServiceProvider { satisfied = false; for each provider guarantee Gp { if the scopes are the same if the obligated parties are the same if the slos are compatible satisfied = true; } if (satisfied == false) // if you went through all of a provider guarantees and satisfied is still false for this consumer need this provider is removed from the set, move to next provider. } } // check that a consumer can satisfy each provider’s needs. For each provider guarantee Gp if (Gp.obligatedParty == ServiceConsumer) satisfied = false for each consumer guarantee if (Gc.obligatedParty == ServiceConsumer) if checkScopes() if checkSLOs() satisfied = true; if (satified = false) // if you went through all of a consumer’s guarantees and could not satisfy the provider need, remove provider remove provider from set, move to next provider.

25. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Matching Algorithm Architecture Example Use Case

26. OWL.arl Architecture Ontologies are loaded into SNOBASE 1 Ontologies Domain Knowledge and Rules OntologyManager Provider Library SnoBase 2 3 After the agreements are parsed the ontology manager creates instances in SNOBASE WsagSelection WsagParser 4 WsagMatcher 5 Match policies with the help of domain knowledge stored in SNOBASE Consumer Agreement

27. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Matching Algorithm Architecture Example Use Case

28. Example: Service Properties in a Web Service Environment Provider1 • Objective1a: executionTime < 3s • Condition: day equals weekday • Objective 2a: networkTime < 2s • Condition: numRequests < 1000 • Objective3a: endTime before 03-01-2005 • RequirementA: availableMemory > 100 MB Consumer Requirement1: responseTime < 8s Requirement2: endTime before 03-03-2005 Challenges/Notes: 1. Heterogeneous SLOs for Objective1 2. Provider1 and Provider2 conditions which is more suitable for the consumer, txRate or weekday and numRequests? 3. Provider2 is slower but offers a higher penalty – does consumer have a preference? 4. Provider1 also has a requirement – matching must be symmetric. Provider2 Objective1b: 99% of responseTime < 7s Condition: txRate < 1000 Penalty: 5USD Objective2b: endTime before 01-01-2005 Penalty: 50 USD *Since approach is semantic responseTime, endTime, day, availableMemory are all concepts from the ontologies. We have a common understanding.

29. The Matching Process endTime before 03-01-2005 executionTime < 3s day equals weekday Provider1 endTime before 03-03-2005 availableMemory > 100 MB responseTime < 8s Consumer networkTime < 2s numRequests < 1000 endTime before 01-01-2005 50 USD 99% of responseTimes < 7s txRate < 1000 5 USD Provider2 Rule: responseTime = executionTime + networkTime with compound condition

30. The Matching Process endTime before 03-01-2005 responseTime < 5s day equals weekday AND numRequests < 1000 Provider1 endTime before 03-03-2005 availableMemory > 100 MB responseTime < 8s Consumer endTime before 01-01-2005 50 USD 99% of responseTimes < 7s txRate < 1000 5 USD Provider2 Weakening Rule: PercentageLessThanThreshold if percent >= X predicate = less else predicate = greater

31. The Matching Process endTime before 03-01-2005 responseTime < 5s day equals weekday AND numRequests < 1000 Provider1 endTime before 03-03-2005 availableMemory > 100 MB responseTime < 8s Consumer endTime before 01-01-2005 50 USD responseTime < 7s txRate < 1000 5 USD Provider2 User Preference Rule: if (GTa exists where condition parameter == txRate AND value > 1500) AND (GTb exists where condition parameter == weekday) GTa preferredOver GTb

32. The Matching Process isStronger endTime before 03-01-2005 responseTime < 5s day equals weekday AND numRequests < 1000 Provider1 endTime before 03-03-2005 availableMemory > 100 MB responseTime < 8s Consumer endTime before 01-01-2005 50 USD responseTime < 7s txRate < 1000 5 USD Provider2 isStronger Semantics of Predicate Rules: if (slo1 and slo2 have the predicates less) if (slo1Value < slo2Value) slo1 isStronger slo2 else if (slo1Value > slo2Value) slo2 isStronger slo1 else slo1 isEquivalent slo2

33. The Matching Process isStronger endTime before 03-01-2005 responseTime < 5s day equals weekday AND numRequests < 1000 Provider1 endTime before 03-03-2005 availableMemory > 100 MB responseTime < 8s Consumer endTime before 01-01-2005 50 USD responseTime < 7s txRate < 1000 5 USD Provider2 isStronger Semantics of Predicate Rules: if (slo1 and slo2 have the predicates before) if (slo1Value.compareTo(slo2Value) < 0) slo1 isStronger slo2 else if (slo1Value.compareTo(slo2Value)>0) slo2 isStronger slo1 else slo1 isEquivalent slo2

34. The Matching Process endTime before 03-01-2005 responseTime < 5s day equals weekday AND numRequests < 1000 Provider1 endTime before 03-03-2005 availableMemory > 100 MB responseTime < 8s Consumer endTime before 01-01-2005 50 USD responseTime < 7s txRate < 1000 5 USD Provider2 Searching: first narrow down provider set by querying for consumer scopes for each provider p for each consumer Guarantee Term if consumer’s obligated party is ServiceProvider for each provider Guarantee Term checkScopes() checkObligations() checkSLOs (only have to query for isStronger or isEquivalent if (!satisfied) remove provider p for each provider Guarantee Term if provider’s obligated party is ServiceConsumer for each consumer guarantee term checkScopes() checkObligations() checkSLOs (only have to query for isStronger or isEquivalent if (!satisfied) remove provider p

35. Outline WS-Agreement Project Objective Related Work Solution Semantic Modeling Reasoning Rules Matching Algorithm Architecture Example Use Case

36. Use Case: The value of agreements in farming Contract farming is defined as a system for the production and supply of agricultural or horticultural products under forward contracts between producers/suppliers and buyers. The essence of such an arrangement is the commitment of the cultivator to provide an agricultural commodity of a certain type, at a time and a price, and in the quantity required by a known and committed buyer 1. Market provision: The grower and buyer agree to terms and conditions for the future sale and purchase of a crop or livestock product; 2. Resource provision: In conjunction with the marketing arrangements the buyer agrees to supply selected inputs, including on occasions land preparation and technical advice; 3. Management specifications: The grower agrees to follow recommended production methods, inputs regimes, and cultivation and harvesting specifications.

37. Categories of Agreement • Crop Delivery Arrangements • Pricing Arrangements • Cultivation Practices • Quality and Quantity of Goods • Payment Procedures • Insurance Arrangements

38. Advantages for farmers • Buyer will normally undertake to purchase all produce grown, within specified quality and quantity parameters. • Farmers’ price risk is often reduced as many contracts specify prices in advance • Inputs and production services are often supplied by the sponsor • This is usually done on credit through advances from the sponsor • Contract farming often introduces new technology and also enables farmers to learn new skills • Contract farming can open up new markets which would otherwise be unavailable to small farmers

39. Advantages for Buyers • Production is more reliable than open-market purchases and the sponsoring company faces less risk by not being responsible for production • More consistent quality can be obtained than if purchases were made on the open market

40. Sample Contracts • Objective1: Moisture is less inclusive 14% • Penalty: discount $x each • Objective2: splits is less inclusive 20% • Penalty: splits of 5% or more, discount $y each • Objective3: test weight is greater than inclusive 54 lbs • Objective4: oil content varies between x% and y% • Conditions: variety of seed selected • planting date is between x and y dates • contaminating pollination by non-high oil corn variety Farmer Contract • Objective1: guarantees compensation of grower to be • (deliveryLocationPrice – discountPenalties) * netBushels • Condition: market conditions may make deliveryLocationPrice higher or lower. • Objective2: establishes delivery date. • Objective3: draws a sample oil content from each load. Buyer Contract

41. Why Agreements? • Agreements, in the form of a written contract or a verbal understanding, usually cover the responsibilities and obligations of each party, the manner in which the agreement can be enforced and the remedies to be taken if the contract breaks down. • When efficiently organized and managed, contract farming reduces risk and uncertainty for both parties as compared to buying and selling crops on the open market.

42. Status and Expected Completion Implementation Status: • Ontologies • ARL Rules • Domain Rules • Semantics of Predicates • Weakening Rules, PLTT • Parser • OntologyManager • 60% of matcher To Do: • Matcher to consider Qualifying Conditions • Matcher to consider Business Values • ARL rules to represent user preferences • User Interface • (maybe) A module which will convert SWRL to ARL Expected Completion: Coding: September 21st Testing: September 28th Paper: October 28th