 |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
METEOR-S: Semantic Web Services and ProcessesApplying Semantics in Annotation, Quality of Service, Discovery, Composition, ExecutionMotivation for a Semantic Approach WS-Agreement WSDL-S Annotation Implementation Example Use Case Additional Resources SWAPS A Semantic Reasoning Engine
For WS-Agreements 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:
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:
and a provider is offering the assurances:
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. 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
The complete WS-Agreement
Specification
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.
Adding Semantics to the WS-Agreement Agreements contain ambiguities which we clarify using
an OntConcept annotation tag. In the original schema of the Terms 
Figure 1. Illustrates the benefits of the ontConcept annotation. 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 We define the following functions to facilitate the
description: 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) 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.
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. 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 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. 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: 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)) 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. 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 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. | ||||||||||||||||||||||||
