WS-Agreement Based Semantic
Partner Selection
A component of the Meteor-S project
Nicole Oldham, LSDIS Lab, University of
Georgia
SWAPS Project Page
Outline
WS-Agreement
Project Objective
Related Work
Solution
Reasoning
Semantic Modeling
Rules
Searching Algorithm
Architecture
Example
Use Case
WS-Agreement Structure
Agreement
Name
Context
Terms
Service Terms
Guarantee Terms
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>
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
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Searching Algorithm
Architecture
Example
Use 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-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Rules
Searching Algorithm
Architecture
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
<
Fuction
Predicate
Slo1
Slo2
Comparison
RT
Results
RT
<
RT<x1
RT<x2
X1<X2
RT1>RT2
>
5
PLTT
RT
<
RECONSTRUCT
95%
2
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
RT
2
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
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Searching Algorithm
Architecture
Example
Use Case
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.
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Searching Algorithm
Architecture
Example
Use Case
WS-Agreement Ontology
hasGuaranteeTerm
GuaranteeTerm
hasBusinessValue
hasScope
hasObjective
hasCondition
Scope
BusinessValue
ServiceLevelObjectivev
Qualifying Condition
hasReward
Reward
Predicate
Predicate
hasPenalty
hasImportance
Penalty
Parameter
Parameter
Unit
Value
Unit
Importance
ValueExpression
Value
ValueUnit
ValueExpression
OWL ontology
Assessment Interval
Assessment Interval
ValueUnit
TimeInterval
Count
Count
TimeInterval
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>
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Searching Algorithm
Architecture
Example
Use 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
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Searching Algorithm
Architecture
Example
Use Case
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
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
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
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.
5.
Unit Conversions
seconds -> ms
bytes -> mB
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Searching Algorithm
Architecture
Example
Use Case
The Control Flow
1. Parsing
As agreements are parsed they are entered into
SnoBase as instances of the WSAG ontology.
SNOBASE
2. Searching
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 Algorithm
providerSet = set of all potential providers
Narrows set
For each Consumer Guarantee, get Scope cScope {
Eliminates
providerSet = all providers who have a guarantee with the same scope as cScope and were in the prev. set
Needless
}
Matching
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.
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Matching Algorithm
Architecture
Example
Use Case
Architecture
1
Ontologies
Ontologies are
loaded into
SNOBASE
Domain
Knowledge and
Rules
OntologyManager
Provider Library
2
SnoBase
3 After the agreements are
parsed the ontology manager
creates instances in
SNOBASE
WsagSelection
OWL.arl
WsagParser
4
WsagMatcher
Consumer Agreement
5
Match policies with the help of
domain knowledge stored in
SNOBASE
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Matching Algorithm
Architecture
Example
Use Case
Example: Service Properties in a Web Service
Provider1
Environment
Consumer
Requirement1: responseTime < 8s
Requirement2: endTime before 03-03-2005
Objective1a: executionTime < 3s
Condition: day equals weekday
Objective 2a: networkTime < 2s
Condition: numRequests < 1000
Objective3a: endTime before 03-01-2005
RequirementA: availableMemory > 100 MB
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?
Provider2
Objective1b: 99% of responseTime < 7s
Condition: txRate < 1000
Penalty: 5USD
Objective2b: endTime before 01-01-2005
Penalty: 50 USD
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
endTime before 03-01-2005
endTime before 03-03-2005
executionTime < 3s
day equals weekday
Provider1
responseTime < 8s
Consumer
availableMemory > 100
MB
networkTime < 2s
numRequests < 1000
99% of responseTimes < 7s
txRate < 1000
5 USD
Rule: responseTime = executionTime + networkTime
with compound condition
endTime before 01-01-2005
50 USD
Provider2
The Matching Process
endTime before 03-01-2005
endTime before 03-03-2005
responseTime < 8s
responseTime < 5s
day equals weekday AND
numRequests < 1000
Provider1
availableMemory > 100
MB
Consumer
99% of responseTimes < 7s
txRate < 1000
5 USD
Weakening Rule: PercentageLessThanThreshold
if percent >= X
predicate = less
else
predicate = greater
endTime before 01-01-2005
50 USD
Provider2
The Matching Process
endTime before 03-01-2005
endTime before 03-03-2005
responseTime < 8s
responseTime < 5s
day equals weekday AND
numRequests < 1000
Provider1
availableMemory > 100
MB
Consumer
responseTime < 7s
txRate < 1000
5 USD
endTime before 01-01-2005
50 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
The Matching Process
isStronger
endTime before 03-01-2005
endTime before 03-03-2005
responseTime < 8s
responseTime < 5s
day equals weekday AND
numRequests < 1000
Provider1
availableMemory > 100
MB
Consumer
isStronger
responseTime < 7s
txRate < 1000
5 USD
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
endTime before 01-01-2005
50 USD
Provider2
The Matching Process
isStronger
endTime before 03-01-2005
endTime before 03-03-2005
responseTime < 8s
responseTime < 5s
day equals weekday AND
numRequests < 1000
Provider1
availableMemory > 100
MB
Consumer
isStronger
responseTime < 7s
txRate < 1000
5 USD
endTime before 01-01-2005
50 USD
Provider2
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
The Matching Process
endTime before 03-01-2005
endTime before 03-03-2005
responseTime < 8s
responseTime < 5s
day equals weekday AND
numRequests < 1000
Provider1
availableMemory > 100
MB
Consumer
responseTime < 7s
txRate < 1000
5 USD
Searching:
endTime before 01-01-2005
50 USD
Provider2
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
Outline
WS-Agreement
Project Objective
Related Work
Solution
Semantic Modeling
Reasoning
Rules
Matching Algorithm
Architecture
Example
Use Case
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.
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 would
otherwise 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 being
responsible for production
• More consistent quality can be obtained than if purchases
were made on the open market
Sample Contracts
Objective1: Moisture is less inclusive 14%
Penalty:
discount $x each
Farmer Contract
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
Buyer 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.
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 21st
Testing: September 28th
Paper: October 28th