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

WS-Agreement Based Semantic Partner Selection

A component of the Meteor-S project

Nicole Oldham, LSDIS Lab, University of Georgia

SWAPS Project Page

http://lsdis.cs.uga.edu/projects/meteor-s/

http://lsdis.cs.uga.edu/~oldham

http://lsdis.cs.uga.edu/

http://www.uga.edu/

http://lsdis.cs.uga.edu/projects/meteor-s/swaps

http://lsdis.cs.uga.edu/projects/meteor-s/swaps

OutlineWS-AgreementProject ObjectiveRelated WorkSolution

ReasoningSemantic ModelingRulesSearching AlgorithmArchitecture

ExampleUse Case

WS-Agreement Structure

Agreement

Terms

Service Terms

Guarantee Terms

Context

Name

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

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

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


Semantic ModelingReasoningRules

Searching AlgorithmArchitecture

ExampleUse Case

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?

Outline

WS-AgreementProject ObjectiveRelated WorkSolution

Semantic ModelingRulesSearching AlgorithmArchitecture

Use Case

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!

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

Fuction Predicate Slo1 Slo2 Comparison Results

RT < RT<x1 RT<x2 X1<X2 RT1>RT2

RT 5

<

PLTT 95%

>

RT 2

<

RT 2

RECONSTRUCT

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

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


Semantic ModelingReasoningRulesSearching AlgorithmArchitecture

ExampleUse Case

How I solved the problemA 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.



ExampleUse Case

WS-Agreement Ontology

GuaranteeTerm

ScopeServiceLevelObjectivev

OWL ontology

Predicate

Parameter

hasScope

hasObjective

Unit

Value

hasCondition

Qualifying Condition

Predicate

ParameterUnit

Value

BusinessValue

Penalty

Reward

hasReward

hasPenalty

hasGuaranteeTerm

Importance

hasImportance

hasBusinessValue

Assessment IntervalValueExpression

ValueUnit

TimeInterval Count

Assessment Interval

ValueExpression

ValueUnit

TimeInterval

Count

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

Sample Agreement



ExampleUse Case

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



ExampleUse Case

Categories of Rules1. Conversions for Heterogeneous SLOs ie: PercentageLessThanThreshold,

etc.

When there exists an SLO such that the predicate equals PercentLessThanThresholdDo 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

Categories of Rules3. 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

DoguaranteeX isPreferedOver guaranteeY

An assertion using the verb “notSuitable” would allow the user to state which conditions will never be appropriate

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

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

5. Unit Conversions seconds -> ms bytes -> mB



ExampleUse Case

The Control Flow

Parsing

As agreements are parsed they are entered intoSnoBase as instances of the WSAG ontology.

SNOBASE

As these new predicates are entered, if theconditions in the ARL rules become present those rules will be fired at this time

1.

Searching2.

The process of searching for a match occurs as soon as a consumer is seekinga partner.The searching algorithm will query the predicates in SNOBASE to find the bestmatch

Searching Algorithm

providerSet = set of all potential providersFor 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 providerselse { 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.

Narrows setEliminatesNeedlessMatching


Semantic ModelingReasoningRulesMatching AlgorithmArchitecture

ExampleUse Case

Architecture

Provider Library

WsagSelection

Consumer Agreement

WsagParser

OntologyManager

Ontologies

SnoBase

OWL.arl

WsagMatcher

1

23

4

5Match policies with the help of domain knowledge stored in SNOBASE

Ontologies are loaded into SNOBASE

After the agreements are parsed the ontology manager creates instances in SNOBASE

Domain Knowledge and Rules



ExampleUse Case

Example: Service Properties in a Web Service Environment

Requirement1: responseTime < 8s

Requirement2: endTime before 03-03-2005

ConsumerObjective1a: executionTime < 3s

Condition: day equals weekday

Objective 2a: networkTime < 2s Condition: numRequests < 1000

Objective3a: endTime before 03-01-2005

RequirementA: availableMemory > 100 MB

Provider1

Objective1b: 99% of responseTime < 7s Condition: txRate < 1000 Penalty: 5USD

Objective2b: endTime before 01-01-2005

Penalty: 50 USD

Provider2

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.

*Since approach is semantic responseTime, endTime, day, availableMemory are all concepts from the ontologies. We have a common understanding.

The Matching Process

Consumer

endTime before 03-03-2005

responseTime < 8sProvider1


availableMemory > 100 MB

networkTime < 2s numRequests < 1000

Rule: responseTime = executionTime + networkTime with compound condition

executionTime < 3s day equals weekday

Provider2

endTime before 01-01-2005 50 USD

99% of responseTimes < 7s txRate < 1000 5 USD


Consumer





Weakening Rule: PercentageLessThanThreshold if percent >= X predicate = less else predicate = greater

responseTime < 5s day equals weekday AND numRequests < 1000

Provider2


99% of responseTimes < 7s txRate < 1000 5 USD


Consumer





User Preference Rule: if (GTa exists where condition parameter == txRate

AND value > 1500) AND (GTb exists where condition parameter == weekday) GTa preferredOver GTb


Provider2


responseTime < 7s txRate < 1000 5 USD


Consumer





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


Provider2



isStronger

isStronger


Consumer





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


Provider2



isStronger

isStronger


Consumer





Searching: first narrow down provider set by querying for consumer scopesfor 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


Provider2





ExampleUse Case

Use Case: The value of agreements in farmingContract 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 conditionsfor the future sale and purchase of a crop or livestock product;

2. Resource provision: In conjunction with the marketing arrangements thebuyer agrees to supply selected inputs, including on occasions landpreparation and technical advice;

3. Management specifications: The grower agrees to follow recommendedproduction methods, inputs regimes, and cultivation and harvesting

specifications.

Categories of Agreement

• Crop Delivery Arrangements• Pricing Arrangements• Cultivation Practices• Quality and Quantity of Goods• Payment Procedures• Insurance Arrangements

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 wouldotherwise be unavailable to small farmers

Advantages for Buyers• Production is more reliable than open-market purchases

and the sponsoring company faces less risk by not beingresponsible for production

• More consistent quality can be obtained than if purchases were made on the open market

Sample ContractsObjective1: 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

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.

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 21stTesting: September 28thPaper: October 28th

Documents

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