LSDIS > Projects > METEOR-S > SWAPS

METEOR-S: Semantic Web Services and Processes

Applying Semantics in Annotation, Quality of Service, Discovery, Composition, Execution


Motivation for a Semantic Approach     WS-Agreement     WSDL-S Annotation     Implementation     Example     Use Case     Additional Resources    


SWAPS

A Semantic Reasoning Engine For WS-Agreements

This work is a component of the Meteor-S project which deals with all aspects of a Semantic Web Service and Process lifecycle.


Purpose

In a dynamic service oriented environment it is desirable for service consumers and providers to offer and obtain guarantees regarding their capabilities and requirements. WS-Agreement defines a language and protocol for establishing agreements between two parties. To date, there has been very little work done to advance the tools available for WS-Agreements. Existing tools are solely to facilitate the creation and monitoring of agreements. Some work has also been done in the area of agreement negotiation. The agreements are complex and expressive to the extent that the manual matching of these agreements would be expensive both in time and resources. It is essential to develop a method for matching agreements automatically. This work presents the framework and implementation of an innovative tool for the dynamic partnering of WS-Agreements. The approach utilizes Semantic Web technologies in combination with ARL rules to achieve rich and accurate matches. A key feature is the novel and flexible approach for achieving user personalized matches.


Contributions and Benefits

This project defines and provides reasoning methods for the components of an agreement which must be compatible for quality matches. We present a powerful approach which uses OWL ontologies to represent domain knowledge in conjunction with rules to achieve the most accurate and consumer personalized matches. The contributions of this work are:

  • Adding to the small body of work for WS-Agreement by defining a framework and implementation for the matching of agreements which eliminates tedious and error prone manual matching.
  • Developing a strategy for reasoning over the complex and multifaceted WS-Agreements.
  • Presenting a flexible approach for specifying and reasoning over user defined preferences which allows the matching to be modified and customized without changing code or possessing programming knowledge.



MOTIVATION FOR A SEMANTIC APPROACH

The current WS-Agreement specification is XML based and therefore lacks the ability to express any formal meaning. A matcher only considering the syntax of the agreements without an understanding of the semantics of the terms within the agreements is not able to correctly identify all matches. We illustrate the differences with the following example. Consider that a service consumer has the following requirement:

  • Availability is greater than 95%


and a provider is offering the assurances:

  • Mean Time to Recover equals 5 minutes
  • Mean Time between failures equals 15 hours

A syntactic matcher would perform a string comparison to determine if the provider can satisfy the consumerís request. The syntactic matcher would generally determine that these two services do not match on the grounds that the provider does not provide an assurance for availability. However, our semantic approach utilizes an ontology which provides a deeper understanding of the domain including the domain rules. For example, with respect to the above case:


Availability = Mean Time Between Failures/(Mean Time Between Failures + Mean Time To Recover)


Therefore the semantic approach reasons that the provider is actually offering the assurance:

Availability equals 99.4%.


Our matcher determines that this provider does in fact satisfy the requirements of the consumer. This example illustrates why incorporating semantics into matching yields much more accurate matches.


WS-AGREEMENT


SWAPS WS-Agreement Extensions     WS-Agreement Matching    

Web Service Agreement (WS-Agreement) Schema

Many protocols exist to express the capabilities and requirements of Web Services, the most widely accepted being WS-Policy. Using this specification a Web Service who is requesting a service from a provider Web Service may use assertions to advertise capabilities and specify objectives which must be satisfied. For example, the consumer may require that all response times be less than 5 seconds. However, in a real world environment these capabilities and requirements cannot be guaranteed under every circumstance. For instance, a service might only be able to process a job in less than 5 seconds if the number of requests at that moment is less than a thousand. WS-Policy does not offer the ability to express these types of conditions or business values such as importance, penalties, and rewards. WS-Agreement offers a richer language for stating the assurances and requirements of Web Services which is much more representative of the complicated nature of real world agreements as it, in addition to service level objectives, allows for the specification of conditions and business values.

WS-Agreements are written in XML and consist of alternative sets of guarantees denoted with the ExactlyOne and ALL tags. Due to the already complex nature of agreements, we save the WS-Agreements OneOrMore tag for future work and assume that all agreements are written as a disjunction of alternative sets of guarantees. The guarantees are expressed within the GuaranteeTerm tag and assert assurances or requirements on the quality associated with the service. Below is the Guarantee Term schema followed by Table 1 which describes the components of a guarantee term.


<wsag:GuaranteeTerm Obligated=>

<wsag:ServiceScope ServiceName=> </wsag:ServiceScope>*

<wsag:ServiceLevelObjective> Ö</wsag:ServiceLevelObjective>

<wsag:QualifyingCondition></wsag:QualifyingCondition>?

<wsag:BusinessValueList></wsag:BusinessValueList>

</wsag:GuaranteeTerm>

 

Table 1. GuaranteeTerm Components

WS-Agreement Tag

Purpose

Obligated

States the party responsible for the fulfillment of the guarantee. Value will be ServiceProvider or ServiceConsumer

ServiceScope

Describes to what service element specifically a service applies.

ServiceLevelObjective

(SLO)

An assertion over the terms of the agreement which represents the QoS aspect of the agreement. Usually defines bounds usually over QoS concepts such as response time, fault rate or cost.

QualifyingCondition

Optional condition which must exist in order for the SLO to be satisfied. Usually over external factors such as time of day.

BusinessValueList

Optional values which represent the strength of commitment by stating penalties, rewards and importance

 

The complete WS-Agreement Specification



SWAPS WS-Agreement Extensions

In order to achieve effective semantic matches, we extend the original WS-Agreement schema with several additional tags. The new tags allow for the incorporation of semantics into WS-Agreement and add additional structure for clarity during parsing and matching.

Adding Structure to SLO and Qualifying Conditions

The WS-Agreement specification was written with flexibility as one of the key goals and therefore lacks some structure in important areas such as the SLO and QualifyingCondition. The values within each of those tags can contain any possible expression. While this would be acceptable for an agreement which is intended to be read by a human user, additional structure must be added to the expressions in order to for a machine to automatically parse and reason over agreements. However, we added this structure while still preserving much of the flexibility specifically for domain specific predicates. For structure, we have added the expression, predicate, parameter, and value tags, as defined in the WSLA specification. In addition there are the optional tags for unit and percent. Percent is used when a service level objective uses a percentage. For example, 99% of responseTimes are less than 5 seconds.

Table 2 shows an example using the original schema as defined in the specification which is too ambiguous to parse and reason over. Our modified schema which adds structure is also shown in Table 2.


 

WS-Agreement Schema

SWAPS Schema

SLO

<ServiceLevelObjective> duration1+duration2 < 5 s </ServiceLevelObjective>

<ServiceLevelObjective>
<Expression>
<Predicate type="less">
<Parameter>duration1+duration2
< /Parameter> <OntConcept>qos:responseTime </OntConcept>
<Value>5</Value> <Unit>time:seconds</Unit> </Predicate></Expression> </ServiceLevelObjective>
Qualifying Condition <QualifyingCondition> day of week is a weekday </QualifyingCondition>

<QualifyingCondition>
<Expression> <Predicate type="equals"> <Parameter>dayOfWeek
</Parameter>
<OntConcept>time:dayOfWeek
</OntConcept>
<Value>time:weekday</Value>
</Predicate></Expression>
</QualifyingCondition>


 

 

 

 

 

 

 

 

 




Adding Semantics to the WS-Agreement


Agreements contain ambiguities which we clarify using an OntConcept annotation tag. In the original schema of the Terms

section of the WS-Agreement. Even though these variables have already been defined within the service description terms, it is unclear to what the summation of duration1 and duration2 actually refers. For example, it may refer to a QoS parameter responseTime or it may refer to a domain concept processOrderDuration. The addition of the OntConcept tag removes this ambiguity by linking this expression parameter directly to the concrete ontology concept. The value of OntConcept will be a concept from an ontology regardless of what variables are named and to what they refer. The agreement creators are required to include this tag to allow for semantic reasoning over the expression. This yields more effective matches than purely syntactic methods. The OntConcept tag clarifies the QoS or domain specific parameter to which the objective pertains. Figure 2 contains an example illustrating how the OntConcept tag remedies ambiguity. A syntactic matcher is not able to determine that (duration1+duration2) and processTime each refer to the response time of the service which is the concept responseTime in the QoS ontology. Adding OntConcept allows the matcher to recognize that although the concepts are syntactically different, they are semantically the same.




Figure 1. Illustrates the benefits of the ontConcept annotation.



WS-AGREEMENT MATCHING

In order for a provider to be considered a suitable partner match for a given consumer, its description must contain one alternative which may satisfy any of the consumer's alternatives as denoted by the "ExactlyOne" and "ALL" tags. An agreement A contains



A={Alt1, Alt2, ..., AltN}
Alt={G1, G2, ...GN} and
G={Scope, Obligated, SLO, QC, BV}

We define the following functions to facilitate the description:

"requirement(Alt, G)" returns true if G is a requirement of Alt
"capability(Alt, G)" returns true if G is an assurance of Alt
"scope(G)" returns the scope of G
"obligation(G)" returns the obligated party of G
"satisfies(Gj, Gi)" returns true if the SLO of Gj is equivalent to or stronger than the SLO of Gi

An alternative Alt1 is a suitable match for Alt2 if:

("Gi) such that Gi is a member of Alt1 and requirement(Alt1, Gi) and ($Gj) such that Gj is a member of Alt2 and capability(Alt2, Gj) and scope(Gi)
= scope(Gj) and obligation(Gi) = obligation(Gj) and satisfies(Gj, Gi)

 

Most users have preferences for conditions and business values and a tradeoff is decided. For instance, a user may choose an agreement with a less preferred condition but a higher penalty. Alternatively, a user with a high number of requests on the weekend would find a provider to be unsuitable if he has a condition which states that he is only able to satisfy a guarantee if it is a weekday. We consider the tradeoff between qualifying conditions and business values to be a matter of user preference and have designed a unique and flexible method for specifying these user preferences in order to yield the most suitable matches. Our approach is presented in detail in the next section.


WSDL-S Annotation

The ontConcept tag annotates the SLO and Qualifying Condition parameters which facilitates the understanding and matching of the guarantee terms of the agreement. The Agreement Service Description Terms (SDT) refer to the operations of the WSDL to which the Agreement pertains. These SDT are also used during the monitoring of the service and negotiation. Both the XML based WSDLs and WS-Agreements lack the ability to express semantic meaning. In order to achieve the most accurate monitoring and negotiation the WSDL files to which the SDTs refer are semantically annotated using WSDL-S. WSDL-S builds on current standards and allows multiple semantic representation languages to annotate services. This flexibility allows Web Services to be annotated with concepts from multiple ontologies from different sources. One of the most pressing challenges when mapping WSDL with ontologies is the heterogeneity between the XML Schema of the WSDL and the ontology, however, WSDL-S overcomes this challenge by providing support for rich mapping. Figure 2 shows these mappings between an Agreement and Web Service, Agreement and ontology, and Agreement and Web Service, in the context of the contract farming use case which is described in the use case section.



WS-Agreement negotiations and the runtime monitoring of WS-Agreement compliance is facilitated and enhanced by the use of semantically annotated Web Services since the ontologies provide a common understanding of the functional properties of Web Services. These semantic annotations enrich negotiations by linking heterogeneously expressed service elements to a common ontological concept. They enhance the monitoring of WS-Agreement compliance by disambiguating the terms used within the agreements and WSDL files and by providing additional domain knowledge which can be used when monitoring.


IMPLEMENTATION

Ontologies     Rules     Algorithm    



Architecture

The system consists of three phases: parsing, matching and searching, which can be seen in Figure 2. To reason about domain ontologies, we use Snobase, an ontology based management system that offers DQL-based Java API for querying OWL ontologies. IBM's ABLE engine is used by Snobase for inferencing and we use ABLE Rule Language (ARL) to write the rules. The ontologies are loaded into Snobase followed by each provider's WS-Agreement. We parse the agreements and load them into the system as instances of the WS-Agreement ontology. As each of these new agreement instances is created, the ABLE rule engine within Snobase executes rules as the criteria for each rule is met. The additional assertions made by the rules are used to greatly simplify the search phase by making the match decisions a priori. These rules provide additional knowledge about the domain and, as described in the Motivation for Semantics section, play a significant role in the discovery of the most accurate match results. We discuss the rules in further detail in the next section. When a consumer seeks a partner, the consumer agreement is parsed and entered into the system as another agreement instance. The search phase begins as the algorithm considers the agreement instances and the assertions previously set by the rules and returns a list, ranked by preference, of all of the provider agreements which accurately matched the consumer's agreement.




Figure 2.The control flow throughout SWAPS





Figure 3.SWAPS Architecture



ONTOLOGIES

In order to realistically model the domains we employ several ontologies.



WS-Agreement: We developed an OWL ontology to represent the WS-Agreement schema. This ontology contains the concepts from the schema such as Guarantee, Scope, and ServiceLevelObjective with relationships between them. In addition to the significant elements from the WS-Agreement, we have also included the common predicates from the WSLA specification. We allow the user to add additional predicates to this ontology to preserve flexibility. An instance of this ontology is created for each agreement that is introduced into the system where they can be queried and reasoned easily. HTML


Quality of Service (QoS): Most of the guarantees are asserted over quality of service (QoS) concepts; therefore the QoS ontology as described in defines such concepts as failureRate, latency, throughput, availability, and responseTime. Thanks to Dr. Michael Maximilien for providing the QoS Ontology described in his paper An Ontology for Web Services Ratings and Reputations.



RosettaNet:In addition to these ontologies a third OWL ontology represents domain specific knowledge. For our scenario in e-commerce and its implementation we are using the RosettaNet ontology which was developed by the LSDIS Lab and is also represented in OWL. Depending on the application, alternative or additional domain ontologies could be used. HTML


OWL Time: Finally, we use the OWL time ontology to represent temporal concepts such as endTime, interval, dayOfWeek, and seconds. These ontologies are used to provide a commonality of terms between agreement parties and to provide rich domain knowledge to the search engine so that it may achieve the best possible match results.





Rules

We enhance the efficiency and flexibility of our matches by defining several categories of rules. These rules are represented in ARL for ABLE inferencing. The rules assert new facts if the right conditions exist for executing the various rules. We use these rules to supplement domain knowledge, convert SLOs into a common comparable form, define the semantics of domain specific predicates, and specify user preferences. Using rules instead of writing Java code to perform all of the above allows us to separate the core implementation from the user so that he may customize the matcher to the domain and personal preferences without any programming ability. We define four categories of rules and show corresponding examples below.



1. Conversion of Heterogeneous SLOs



Often SLOs state the same objective but express it differently. We define a category of rules to address SLOs that have semantic similarity but are syntactically heterogeneous as in the example in Figure 4. In the example, the provider is expressing an assurance using the WSLA predicate "PercentageLessThanThreshold" and the consumer is expressing the same requirement more directly using the predicate "less". While a human reader can clearly see that the provider's SLO satisfactorily meets the consumer's requirements, the heterogeneity of the predicates prevents the direct comparison of the provider and consumer SLOs. We define the following ARL rule, where x is a user defined threshold, to convert the provider's SLO so that it expresses the objective more directly:



when: Agreement (A) and hasGuarantee (A,G) and hasSLO (G, SLO) and hasExpression(SLO, E) and hasPredicate(E, P) and hasType(P, "PercentageLessThanThreshold") and hasPercentage(E, percent) do: if (percent<=x) then assert hasType(P, "less") else assert hasType(P, "greater")




The above ARL rule looks for any expression which contains the predicate "PercentageLessThanThreshold" and if the percentage less than x it changes the predicate to "less" otherwise it changes it to "greater"

In many cases the value of x is dependent upon the parameter. For example, a user may require a high percentage for responseTime but may be more lenient about other parameters. This feature can be further customized by adding additional statements in the when segment which perform parameter checks.



Figure 4. Illustrates the Conversion of Heterogeneous SLOs

 

2. Semantics of Predicates Rules



The second category of rules allows a user to utilize any domain specific predicates within an SLO by defining how two SLOs with that predicate should be compared. A semantics rule should compare SLOs according to the predicate semantics and assert an isStronger or isEquivalent triple into Snobase. The following ARL rule defines the semantics of the predicate less.


when: Agreement (A1) and hasGuaranteeTerm(A1, G1) and hasSLObjective(G1, SLO1) and hasExpression (SLO1, E1) and hasPredicate(E1, P1) and hasType(P1, less) and hasParameter(E1, p1) and hasValue(E1, V1) and Agreement (A2) where A1 != A2 and hasGuaranteeTerm(A2,G2) and hasSLO(G2, SLO2) and hasExpression (SLO2, E2) and hasPredicate(E2, P2) and hasType(P2, less) and hasParameter(E2, p2) and p2 == p1 and hasValue(E2, V2)

do: if (V1<V2) assert [E1 isStronger E2]

else if (V1>V2) assert [E2 isStronger E2]

else assert [E1 isEquivalent E2]

 

The above rule compares the values of SLOs from different agreements with the same predicate and parameter and asserts isEquivalent if the values are the same otherwise it states which expression is stronger based on the semantics of the predicate less. This rule can also be further customized by incorporating parameters or checking units to determine whether to do a string or numeric comparison. The benefit of this approach is two-fold. First, it allows for domain predicate flexibility such that we do not restrict which predicates our matcher can compare but rather allow the user to introduce new predicates by defining the semantics with an ARL rule. Second, since rules are fired automatically as the agreements are being loaded into Snobase, the SLOs are compared much before the search process. This simplifies the search algorithm because to find a match for SLO1 we quickly query for all SLOs who have been asserted isStronger than or isEquivalent to SLO1. The semantics of predicate rules have the lowest priority so that the other rules may execute before the final evaluation is performed.

 

3. Domain Specific Rules



The domain rules provide the matcher with richer knowledge of the domain. The following example is based on the scenario from Section 2. Consider the following domain rule for Availability:



MTBF is the Mean Time Between Failures
MTTR is the Mean Time To Recover

Availability = MTBF/(MTBF + MTTR)

 

Consider a provider agreement with the following guarantees:

 

Guarantee1: SLO: qos:MTBF=150 time:minutes, Qualifying Condition: numRequests<1000, Penalty: 5 USD, Importance 8

Guarantee2: SLO: qos:MTTR<5 time:minutes, Qualifying Condition: numUsers<500, Penalty: 3 USD, Importance 4

 

The ARL rule for Availability creates a new guarantee term for any agreement which has SLOs regarding both MTBF and MTTR. The new guarantee has an SLO for the Availability. Any Qualifying Conditions will be compounded and a Penalty/Reward will be the higher of the two. If each has the business value importance, it will become the average of the two values. The following ARL rule accomplishes the above:

 

when: Agreement (A) and hasGuarantee (A, G1) and hasSLO (G1, SLO1) and hasQualifyingCondition(G1, QC1) and hasPenalty(G1, P1) and hasImportance(G1, I1) and hasExpression (SLO1, E1) and hasParameter(E1, qos:MTBF) and hasValue(E1, X) and hasGuarantee (A, G2) and hasSLO (G2, SLO2) and hasQualifyingCondition(G2, QC2) and hasPenalty(G2, P2) and hasImportance(G2, I2) and hasExpression (SLO2, E2) and hasParameter(E2, qos:MTTR) and hasValue(E2, Y) do: hasGuarantee (A,G3) and hasSLO(G3, SLO3) and hasExpression(SLO3, E3) and hasParameter(E3, qos:Availability) and hasVaule(E3, X+Y) and hasPenalty (G3, max(P1, P2)) and hasImportance(avg(I1,I2))

 

The rule will be fired once the provider agreement is loaded into Snobase and will add the following guarantee to the agreement:

Guarantee3: SLO: qos:Availability =96.8, Qualifying Condition: numUsers<500 AND numRequests<1000, Penalty: 5 USD, Importance: 6

 

 

4. User Preference Rules

 

The preference rules enable user assertions over subjective personal preferences. There is no standard of comparison for Qualifying Conditions and Business Values as they are a matter of user preference. For example, one service may be more active during the weekend in which case a provider with a condition stating that the objective may only be guaranteed if it is a weekday would not be suitable for that user. The matcher is unaware of the personal circumstances of each user until they are defined using rules. A rule may assert one of two possible assertions which will have an impact on matching: isPreferred or notSuitable. A user may write a rule to assert that a guarantee that has a condition that the day of the week must be a weekday is not suitable or a guarantee with a condition involving transactionRate is preferred over a guarantee with a condition involving the day of the week. These rules have the flexibility to be more specific or generic. The following ARL rule asserts that a weekday condition is not suitable for this user:

 

when: Agreement (A) and hasGuarantee (A, G1) and hasQualifyingCondition(G1, QC1) which hasExpression(QC1, E1) and hasParameter(E1, time:dayOfWeek) and hasValue(E1, time:weekday) do: assert Guarantee notSuitable G1

 

The above rule asserts that a guarantee is notSuitable if the parameter of the Qualifying Condition is the dayOfWeek and if the value is weekday. Conflicting rules are resolved by using optional priority and condition fields.

 

 

SEARCH ALGORITHM

The system uses a two fold approach to finding the result set of providers:

1. Matching: automatically performed by the semantics of predicates rules as agreement instances are created. These rules significantly simplify the matching

processbecause they compare the SLOs upon their entrance into Snobase. At this time assertions are made about which SLOs are stronger than or equivalent to other SLOs these assertions are queried by the search engine.

2. Second, searching is done to determine which providers had agreements which were best suited for the consumer's agreement. We now detail the search algorithm. The following functions are defined to facilitate the expression of the search algorithm:


"requirement(Alt, G)" returns true if G is a requirement of Alt
"capability(Alt, G)" returns true if G is an assurance of Alt
"scope(G)" returns the scope of G
"obligation(G)" returns the obligated party of G
"isStronger(Gj, Gi)" returns true if the SLO of Gj has an isStronger than the SLO of Gi
"isEquivalent(Gi, Gj)" returns true if the SLOs of the
guarantees have the assertion isEquivalent
"notSuitable(G)" returns true if G has an assertion notSuitable

As discussed in section 2.3, matching two agreements is reduced to finding two matching alternatives and finding matching alternatives is reduced to finding matching guarantees.

 

("Gi) such that Gi is a member of Alt1 and Alt1 is a member of A1 and requirement (Alt1, Gi) and ($(Gj) such that Gj is a member of Alt2 and Alt2 is a member of A2 and capability(Alt2, Gj) and scope(Gi)=scope(Gj) and obligation(Gi)=obligation(Gj) and (isStronger(Gj, Gi) or isEquivalent(Gi, Gj)) and notSuitable(Gj)=false



Classification Of Results

The search algorithm will yield a Vector of potential providers where each provider contains at least one alternative which can be fully satisfied and is also able to fulfill the requirements of the consumer. This set will not contain any providers which have conditions that would not be suitable for the consumer. As discussed earlier, each user will have a subjective personal preference regarding qualifying conditions and business values. If the method for stating preferences was utilized then there may be isPreferred assertions stated over some of the guarantees. We implement a preference score for each alternative which is incremented for each isPreferred statement asserted over one of the guarantees of the alternative. The agreements containing alternatives with the highest preference scores are displayed first.

 

EXAMPLE

In this section we present an example to illustrate our approach. Table 3 shows simplified set of guarantees for a consumer. The consumer is seeking the potential providers from the library of providers given in Table 4. The tags and structure of the agreements are removed for simplicity and clarity.

Instance Creation and Rule Execution

When the tool is started, each of the provider agreement documents in the library given in Table 4 are parsed and loaded into Snobase. An agreement instance is created for each provider alternative. Provider 3 will have two agreement instances associated with it because it has two alternatives. As each agreement instance is loaded, the rule engine executes the rules as the criteria for each is met. The user's system includes all of the ARL rules from the previous examples in addition to a similar rule to define the semantics of "greater". An additional domain rule exists for responseTime = processTime + transmitTime which follows the same procedure as the previous domain rule for Availability but sums the values. The following rule defines the semantics of the "true" and "false" predicates:

 

when any two guarantees from a different agreement instance have the same parameter and each predicate =true or each predicate=false

assert [SLO1 isEquivalent SLO2]

 

 

 

 

Table 3. Summary of Consumer Guarantees Library

 

Consumer1.wsag

G1

Scope: ProcessRequest, Obligated: ServiceConsumer SLOc1: qos:availableMemory greater 12 MB

G2

Scope: ProcessRequest, Obligated: ServiceProvider SLOc2: qos:failurePerWeek less 7

G3

Scope: ProcessRequest, Obligated: ServiceProvider SLOc3: qos:allowIncompleteInputs true

G4

Scope: ProcessRequest, Obligated: ServiceProvider SLOc4: 99% of qos:responseTime less 14 seconds




 

 






 

 

Table 4. Summary of Guarantees from Provider Library


 

Provider1.wsag

Provider2.wsag (Provider2a and Provider2b)

G1

Scope: ProcessRequest Obligated: ServiceProvider SLO1: qos:responseTime less 14 sec. QC: time:dayOfWeek equals weekday Penalty: 15 USD Scope: ProcessRequest Obligated: ServiceProvider SLO5: qos:transmitTime less 4 sec. QC:qos:maxNumUsers less 1000 Penalty: 1 USD

OR

Scope: ProcessRequest Obligated: ServiceProvider SLO9: qos:transmitTime less 4 sec. QC: qos:maxNumUsers less 1000 Penalty: 1 USD

G2

Scope: ProcessRequest
Obligated: ServiceProvider
Penalty: 10 USD
Scope: ProcessRequest Obligated: ServiceProvider SLO6: qos:processTime less 5 sec. QC: qos:numRequests less 500 Penalty: 1 USD Scope: ProcessRequest Obligated: ServiceProvider SLO10: qos:processTime less 5 sec. QC: qos:numRequests less 500 Penalty: 1 USD

G3

Scope: ProcessRequest Obligated: ServiceProvider SLO3: qos:incompleteInputs true Scope: ProcessRequest Obligated: ServiceProvider SLO7: qos:failurePerWeek less 16 Penalty: 2 USD Scope: ProcessRequest Obligated: ServiceProvider SLO11:qos:failurePerWeek less 7 Penalty: 2 USD
G4 Scope: ProcessRequest Obligated: ServiceConsumer SLO4:qos:availableMemory greater 12MB Scope: ProcessRequest Obligated: ServiceProvider SLO8: qos:incompleteInputs false Scope: ProcessRequest Obligated: ServiceProvider SLO12: qos:incompleteInputs true

 










 

 

 

 

 

 

 

 

 

Rules

Table 5 Contains a complete list of the rules fired and the assertions created.




Table 5. SWAPS Matching

 

Guarantee

Fact/Rule

Assertion

1

Consumer G4

PercentageLessThanThreshold Conversion Rule

qos:responseTime < 14 seconds

2

Provider1 G1

Semantics of "less"

SLO1 isEquivalent SLOc4

3

Provider1 G1

User Preference Rule weekday notSuitable

Provider1ís G4 notSuitable

4

Provider1 G2

Semantics of "less"

SLO2 isEquivalent SLOc2

5

Provider1 G3

Semantics of "true"

SLO3 isEquivalent SLOc3

6

Provider1 G4

Semantics of "greater"

SLOc1 isStronger SLO4

7

Provider2a G1 and G2

Domain rule for "qos:ResponseTime"

Provider2a-G5-SLO13: qos:responseTime less 9 secs., Qualifying Condition:numRequests<1000 AND

numUsers<500Penalty: 1 USD

8

Provider2a G5

Semantics of "less"

SLO13 isStronger SLOc4

9

Provider2a G3

Semantics of "less"

SLOc2 isStronger SLO7

10

Provider2b G1 and G2

Domain rule for qos:ResponseTime

Provider2b-G5-SLO14: qos:responseTime less 9 secs., Qualifying Condition:numRequests<1000 AND

numUsers<500Penalty: 1 USD

11

Provider2b G5

Semantics of "less"

SLO14 isStronger SLOc4

12

Provider2b G3

Semantics of "less"

SLO11 isEquivalent SLOc2

13

Provider2b G4

Semantics of "true"

SLO12 isEquivalent SLOc3

 





Example Search

The consumer is matched against each alternative of each provider. By querying for isStronger and isEquivalent assertions for the Provider's SLOs, the algorithm determines that Provider1 is able to satisfy the consumer's needs and the consumer can also satisfy the requirement expressed in G1. However, Provider1 is dismissed as a potential match because one of the guarantees was asserted as notSuitable as highlighted in number 3 of Table 5. Provider2's first alternative is considered and the algorithm will determine that not all of the consumer's guarantees are satisfied as the provider does not have an isStronger or isEquivalent assertion for each of them and as one of the SLOs is weaker than the consumer SLO as highlighted in number 9 from Table 5. The algorithm moves on to the next alternative of Provider 2 and determines that it is a match because all of the consumer's guarantees are satisfied and none of the relevant provider guarantees have been asserted as notSuitable. The algorithm returns Provider 2 as the only match.

Post Search Considerations

There was only one potential match in the simplified example above. However, if there had been more compatible providers in the library, the algorithm would continue with additional steps. There are several issues of preference in the example above. If Provider1 had been a suitable match the responseTime is guaranteed to be less than 14 seconds with a very high penalty of 15 USD. Provider 2 offers a much faster responseTime of 9 seconds but a much lower penalty of 1 USD. Some users may desire efficiency while others may wish to merely satisfy the objective while sacrificing some efficiency for the potential of a high penalty payoff. Since this is a personal user preference, the user may define a rule which states that a guarantee isPreferred if the penalty is over some threshold. The user may also wish to state that if the penalties are the same then faster speeds are preferred. During the matching process, the preference score for each alternative is incremented each time a satisfactory guarantee has the isPreferred assertion. When multiple providers are able to satisfy the basic needs of a consumer, the results are ranked by highest preference scores so that the user may consider the most preferred providers first. This example showed the reasoning process while illustrating the flexibility provided by the user defined rules.

USE CASE

This section does not attempt to show another technical example but rather describes how WS-Agreements and our tool can be applied to remedy a challenging real world situation. The next sections will describe the problem, how WS-Agreements can be applied, and how the WS-Agreement matching tool can solve this problem.

 

Agriculture in India

Agricultural trade in India is problematic for both Farmers and Merchants and there is a lack of effective use of IT to facilitate trade.

 

Problems:

-Farmers spend time and resources growing goods and sending them to the markets without guarantee that they will be sold.

-The farmer pays for the transportation of the goods and the wastages that occur when the goods spoil during transport. -Merchants have no assurances on the quality or availability of the goods that they seek to purchase.

Dr. Sanjay Chaudhary has addressed these problems with papers describing his work on Agricultural Information System to improve the effectiveness of decision-making in the agriculture domain. A Web Services based business process management system was developed to aid the marketing of agricultural produce. Each party involved is represented as a Web Service. If each party is a Web Service, then the process of matching farmer to merchant can be reduced to one of Web Service composition and policy matching.

 

 

Contract Farming

Contract farming is one remedy currently being practiced to solve the dilemma.

 

Contract Farming:a system for the production and supply of agricultural products under forward contracts between producers/suppliers and buyers.

 

-The cultivator makes a commitment 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.

-Using faming contracts, growers and buyers can agree to terms and conditions for the sale and purchase of goods. -The buyer can make agreements to supply selected goods which sometimes also include land preparation and technical advice. -Conditions are frequently stated regarding the price and quality of goods and penalties in the form of discounts are offered for flaws or lack of quality.

 

Benefits of Contract Farming:

-The situation for farmers is improved as they no longer must send goods to markets without a guarantee of acquisition.

-The farmer's price risk is reduced because the contracts specify the prices in advance. -The buyers obtain more consistent quality and more reliable production than if purchases were made on the open market.   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.

 

Just as Web Services can represent the farmers and merchants, the WS-Agreement is well suited to represent the complex contracts drawn between the two.

Farming Contracts as WS-Agreements

The WS-Agreement is perhaps the best suited standard for representing farming contracts. The protocol is functional for representing the guarantees which always include some objective and often contain conditions which must exist in order for the objective to be fulfilled. For example, a merchant may guarantee a price under the condition that the goods are of a certain quality. Business values such as penalties are often seen in contracts in the form of discounts. For example, a farmer may guarantee that the moisture percentage is than 10% and may offer a discount for every bushel that contradicts that assurance. In this use case, a merchant is considered to be a service consumer and his guarantees and requirements can be proficiently represented using WS-Agreement. The available merchants are the service providers. Table 6 contains an example of farming contracts as WS-Agreements. It depicts the merchant as the consumer seeking the most suitable farmer, however, this tool can also be used by a farmer to find the ideal merchant.

 

 

Table 6. Farming Contracts represented with WS-Agreement

Merchant

Farmer 1

Farmer 2

Guarantee1: SLO1: Moisture is less inclusive 12%

Guarantee2: SLO2: splits is less inclusive 20%

Guarantee3: SLO3: test weight is greater than 54 lbs

Guarantee4: SLO4: price lessEqual 10 cents per bushel

Guarantee1: SLO1: Moisture is less 10% Penalty: discount $10 each

Guarantee2: SLO2: splits is less inclusive 20% Penalty: splits of 5% or more, discount $1 each

Guarantee3: SLO3: test weight is greater than 60 lbs

Guarantee4: SLO4: price greaterEqual 8

Guarantee1: SLO1: Moisture is less inclusive 12%

Penalty: discount $15 each

Guarantee2: SLO2: splits is less inclusive 20% Penalty: splits of 3% or more, discount $5 each

Guarantee3: SLO3: test weight is greater than 58 lbs

Guarantee4: SLO4: price greaterEqual 7






 

 

 

 

 

 






WS-Agreement Matching for the Agriculture Domain

An ontology representing the Agriculture domain can provide the matcher with a complete understanding of the domain and the user can supplement this knowledge with rules specific to the domain. The user can also write any relevant conversion rules for measurements. For example, the user may write a rule to convert from ounces to grams or from bushels to pounds. For predicates, this user may which to use the basic predicates already defined within the system or can also add domain specific predicates. The simple example in Table 6 uses predefined predicates. In this domain, price is compared differently than moisture or splits because, with the latter, both parties specify that the number must be less than some value because while moisture may vary per bushel it must always be less than some value. Price, however, is a fixed price per bushel. Therefore, when comparing price, expressions with different predicates may still be compatible. For example, the merchant is willing to pay five cents or less but the farmer is asking 4 cents or greater per bushel. Since a parameter such as price will be reasoned over differently than a parameter like moisture, a separate rule must be defined to define the procedure for comparing price. The user will surely have personal preferences and may define these as rules. In Table 6, Farmer 1 clearly offers better quality goods while Farmer 2 offers much higher penalties. The merchant may specify the tradeoff as an ARL rule which states that high penalties are preferred. This causes Farmer 2 to be presented as a higher match than Farmer 1. This tool can effectively narrow down the hundreds of farmers into a group which contains only those farmers offering what the merchant requires. The merchant can specify additional preferences and aspects which are notSuitable to further narrow down the search. Finally the merchant is presented with one or more farmers, in order of preference, from which to choose. This feature greatly reduces the search effort for both farmers and merchants. It can ensure that each farmer and merchant gets the best possible deal tailored to their individual needs and preferences.

 








Additional Resources