In this work, we present a novel approach for matching the nonfunctional properties of Web Services represented using WS-policy. To date, most policy matching has been done using syntactic approaches, where pairs of policies are compared for structural and syntactic similarity to determine compatibility. In our approach, we enhance the policies of a Web Service with semantics by creating the policy assertions based on terms from ontologies. The use of semantic terms enables richer representations of the intent of a policy and allows matching of policies with compatible intent, but dissimilar syntax. Also, in cases where policies are defined at multiple levels/domains (such as security, privacy, trust, transactional etc.), we handle inter-domain policy interactions by processing the rules represented in the semantic domain models. This helps identify any inconsistencies in policies during specification as well matching. This approach of using semantic concepts and rules during policy matching leads to better Web Service matches that may not have been possible with syntax based matchers, or prior semantic based methods.
Web Services Policy Framework (WS-Policy) is a general purpose framework for describing capabilities and requirements of Web Service entities. While Web Services Description Language (WSDL) is meant to represent the functional aspects of a Web Service, WS-Policy is used to represent its non-functional attributes. To determine if a Web Service is suitable for a particular use, both the functional and non-functional capabilities and requirements of a Web Service have to be matched with those of a request. Specifically, in matching the non-functional properties, the policy requirements of the entity invoking the Web Service must be compatible with the policies of the entity providing the Web service. In their current specification, both WSDL and WS-Policy are capable of representing the syntactic aspects of the functional and non-functional properties respectively but lack semantics. For example, using WSDL one can describe the interfaces of a service and details on how to invoke it but not what a service actually does. Similarly, using WS-Policy one can describe the policies that a service requires or provides but not the context in which these policies operate. This lack of semantics hampers the effectiveness of computing the compatibility between the policies.
Realizing this need for semantics, the semantic web community [Berners-Lee et al., 1999] is proposing to formalize the representation of meaning (semantics) of content with the help of model theory based RDF [RDF, 1999] and description logics based OWL [OWL, 2002]. In addition, academic projects like OWL-S [OWL-S, 2002], METEOR-S [METEOR-S, 2002] and WSMO [WSMO, 2004] have proposed approaches to semantically represent Web services. Using OWL, OWL-S provides a vocabulary to represent the semantics of both the functional and nonfunctional aspects of Web Services. However, much of semantic matching work, to date, has been focused on the matching of functional properties of Web Services; namely inputs, outputs, preconditions and effects [Paolucci et al] [Mc.Ilraith et al].
In this paper, we present a novel approach to represent and match the nonfunctional attributes of Web Services. There are two distinct aspects to our approach. First, we use a combination of OWL and SWRL [SWRL 2004] based rules to capture domain concepts and rules and present a mechanism to enhance policies represented using WS-Policy with semantics. Second, we present an approach to validate such semantically described policies specified across multiple domains (such as security, privacy, trust, transactional, business) during specification and then prescribe an algorithm for policy matching.
The rest of the paper is organized as follows. In Section 2, we present a motivating example to make a case for semantics in representing the non-functional properties of Web Services. Section 3 presents how policies represented using WS-Policy can be matched today using syntactic matching approach. In Section 4, we describe how WS-Policy can be extended to incorporate semantics. In Section 5 we present our semantic policy matching algorithm. Section 6 provides a comparison of this work with other projects in this area. Our conclusions and future work is outlined in section 7.
The current WS-Policy specification relies on XML based vocabularies like WS-Security and WS-Trust to make assertions in those domains. In principle, two parties can make assertions in any number of domains, as long as they have an agreed upon vocabulary. However, if the matching is unaware of the semantics of the assertions, it will be somewhat restricted. In order to illustrate our viewpoint, let us consider the following example. Say that a service provider would like to specify policies at three domains for a specific service. They are:
• Business domain: BusinessLevel of requestor must be Enterprise In the above assertions, if we were to use syntactic matching, the matcher would have no additional knowledge about the domain and it would only perform string matching on the attributes of the assertions. This would lead to false negatives, even though the assertions are equivalent. For example, in the above example a syntactic matcher would not know what relation, if any, the enterprise level status of a company holds to a Dun & Bradstreet rating of a company. Also, the syntax matcher would not know how to match the expected response time of the request service with the information on execution time and network response time given by the service providers' service. Say that now we create a domain ontology to capture the following semantic information:
• If a company has Dun &Bradstreet rating A3 then it is enterprise level • Kerberos 5.1 can accept Kerberos 4.0 tokens.
• Total Processing time = Service execution time + network response time
• Response time is Equivalent to Total processing time When this additional domain information along with semantic reasoning is applied, the relationships between seemingly unrelated policies become apparent thereby making it possible to match them correctly. For example, based on a domain rule which states that 'TotalProcessingTime = NetworkTime + executionTime', and with the inference that a response time is equivalent to total time, the matcher can now match the transaction domains of the two policies. Similarly, applying the rule that Dun and Bradstreet (D&B rating) A3 means that the company is enterprise level business domains can now be matched. Also, the compatibility of security tokens is an additional piece of information that a syntax based matcher did not have in a syntax based matcher. This example illustrates how domain knowledge captured as semantic models can improve the quality of matches.
In this section, we briefly describe the WS-Policy specification and provide an overview of how policy matching can be done today in the absence of semantics.
WS-Policy provides a grammar for representing the non-functional attributes of entities in a Web services based XML environment [WS-Policy]. A policy is defined as a collection of alternatives and an alternative is defined as a collection of assertions. An assertion is used to represent a requirement, capability or a behavior of a Web service. An assertion can have arbitrary number of child assertions and attributes. A WS-Policy can be represented in XML using the following tags: The "Policy" tag is used to start and end a policy. The "ExactlyOne" tag is used to contain a set of alternatives and the "All" tag contains all the assertions in an alternative. Each assertion belongs to some vocabulary and can have any number of attributes or child assertions.
Once a client or a service finds another service with the desired functionality, it must evaluate whether it is compatible by matching the policies. WS-Policy describes a policy normal form which is a disjunction of alternatives and conjunction of all assertions in an alternative. In this paper, we always use the normal form for policy matching.
A policy P is defined as a finite set of alternatives. It can also be expressed as a disjunction of all its alternatives
An alternative Alt is defined as a finite set of assertions. It can also be expressed as a conjunction of all its assertions. Alt = {A1, A2 … AN} = A1 ^ A2^ …. AN Matching two policies is reduced to finding two equivalent alternatives.
( ( Alt i ) S.T. Alt i P1 and ( ∃ Alt j ) S.T. Alt j ∃ ∈ ∈ P2 and Alt i ⇔ Alt j ) (P1 ⇔ P2) ……………Rule 1 ⇒ Finding equivalent alternatives can be defined in the following manner. Two alternatives are equivalent, if for each assertion in both alternatives, there exists an equivalent assertion.
(( ∀ A i ) S.T. A i Є Alt1 and ( A j ) S.T. A j Є Alt2 and A i ∃ ⇔ A j ) and ((
..Rule 2 In the current policy framework, equivalent assertions can be computed using syntactical matching of the assertions. In the end, from the application of the above two rules 1 and 2, a working policy must be created from the equivalent alternatives. In some cases, the intersection of policies may also be useful to find common properties and creating a limited working policy. When we apply this approach to match the pair of policies described in section 2, we note that the business domain and transaction domain cannot be matched based on syntax alone. In the next section we show how we extend WS-Policy to capture semantic annotations and how policy matching can be achieved using this newly available semantic information.
Policies must be augmented with semantic information in order to enable semantic matching. Below we describe how we use domain ontologies for creating policy assertions with semantics. As mentioned in section 3, assertions are used to represent a requirement or a behavior of Web services in any number of domains. The type of the assertion is specified by using the QName [XML-Namespaces, 1999] specified in a domain specific vocabulary. A sample assertion is shown in Figure 1.
<wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT </wsse:TokenType> </wsse:SecurityToken>
This assertion is a security assertion, which is specified by the "wsse", which is the URI part of the name of the root element of the assertion. In the WS-Policy specification, this URI is mapped to the URI of the OASIS site hosting the XML schema description of WS-Security. The local part of the name of root element "SecurityToken" specifies that it is a security token assertion. It has a child assertion which states that the token type of the security token should be Kerberosv5TGT.
For adding semantics to WS-Policy, we recommend using OWL ontologies instead of XML schema based vocabularies like WS-Security. Consider an OWL ontology, which semantically describes all the elements of WS-Security using the more expressive description logics constructs available in OWL ontologies. The fact that OWL ontology concepts can be referenced through URIs allows us to use concepts from the ontologies directly in the policy assertions. In Figure 2, the URI part of QName "semsecurity:SecurityToken", is mapped to an URI hosting a security ontology in OWL, which has semantic descriptions of SecurityToken, Kerberosv5TGT and TokenType.
In addition to creating assertions from domain ontologies, we propose adding three optional attributes to each assertion for explicating the semantics of the assertion. They are: 1. assertionType: This attribute is used to specify whether an assertion is a requirement or a capability. The current specification states an assertion could be either a requirement or a capability of a Web service. As a result during matchmaking, all assertions have to be matched and are considered as both a capability and requirement. This makes the matching cumbersome. Explicitly categorizing an assertion as either a requirement or a capability resolves this ambiguity and makes the matching simpler and cleaner. The assertions in Figure 2 are requirements. The default value of assertionType is requirement.
This attribute is used to specify whether an assertion is a numeric or a non-numeric assertion. The value owl:object specifies that the assertion is belongs to an OWL ontology and OWL based operators can be used to reason about it. The value xsd:type specifies that it a literal, where type can be any data type (xsd:string, xsd:float, xsd:int, etc.) supported by XML schema. . We use this attribute to decide whether to use numeric/string based comparisons or description logics based reasoning for matching the particular assertion. By default, an assertion is xsd:string, and string matching is used . The assertions in Figure 2 are non numeric.
This attribute is used to represent the relationship between the assertion name and value. For example the child assertion in Figure 1 states that "TokenType = Kerberosv5TGT". WS-Policy assumes an "equals-to" relationship. While the "equals-to" is the default value we allow "greater than", "less than", "greater than or equal to", "less than or equal to" for number numeric assertions and "subclassof", "superclassof", "instanceof" for non numeric assertions.
<semsecurity:SecurityToken assertionType="sempolicy:Requirement" valueType="owl:object" comparisonOperator="sempolicy:EQ"> <semsecurity:TokenType assertionType="sempolicy:Requirement" valueType="owl:object" comparisonOperator="sempolicy:EQ"> semsecurity:Kerberosv5TGT </semsecurity:TokenType > </semsecurity:SecurityToken > Figure 2: Assertion using ontologies
In this section, we will describe how semantic matching can help match the policies of the request and advertisement shown in section 2 with the help of domain ontologies and rules.
To reason about domain ontologies, we use a semantic network based ontology management system known as SNoBASE [Lee et al., 2003] that offers DQL-based [DQL, 2003] Java API for querying ontologies represented in OWL. SNOBASE uses IBM's ABLE [Bigus et al 2002] engine for inferencing. We have created an OWL ontology for WS-Policy. This allows to represent individual policies as OWL instances. We implemented a module to add SWRL rules to SNoBASE. Consider the following rules, and their SWRL and ABLE representations.
If there exists a policy P, which has an alternative ALT, which has an Assertion A, which states that "DunAndBradStreetRating = A3", then create a new Assertion A1 which states "BusinessLevel=Enterprise" and belongs to Alternative Alt. This rule can be represented in SWRL abstract syntax as: Policy (P) and hasAlternative(P, ALT) and hasAssertion (ALT, A) and DunAndBradStreetRating(A, "A3") => Assertion (A1) and BusinessLevel (A1, "Enterprise") and hasAssertion (ALT, A1)
The ARL "when-do" for the above SWRL rule is given below: when: Policy (P) and hasAlternative (P, ALT) and hasAssertion (ALT, A)
In order to explain the satisfiability of one assertion by another we define the following functions.
"val" returns the value of an assertion or an attribute "type" returns the type of an assertion or an attribute "children" returns all the children of an assertion "attributes" returns all attributes of an assertion A capability assertion satisfies a requirement assertion if its value satisfies the requirement assertion's value and if all the attributes of the requirement assertions are satisfied by its attributes. In addition, all the child assertions of the capability assertion, must satisfy the child assertions of the requirement assertions.
[val (A2) satisfies val (A1) and
( ∀ attr i ) S.T. attr i attributes(A1) and ( attr j ) S.T. attr j ∈ ∃ ∈ attributes (A2) and type(attr i ) = type (attr j ) and val (attr j ) satifisfies val (attr i ) ) and (( child i ) S.T. child i children(A1) and ( ∀ ∈ ∃ child j ) S.T. child j ∈ children (A2) and child i satisfies child j ) ] ⇒ (A2 satisfies A1)
Following operators are used to check value or attribute satisfiability 1. For XML type based assertions: equals, =, <, >, <=, >= 2. For OWL based assertions: sameClassAs, sameInstanceAs, subClassOf, instanceOf, superClassOf, subsumes
We use the same example introduced in section 2. Below, we categorize the policies of the provider into requirements and capabilities.
Provider Requirements:
• Business domain: BusinessLevel of requestor must be Enterprise There has also been some work in policies using Semantic Web technologies. [Uszok et al., 2004] have developed the KAOS system for representing policies using OWL. Their approach is similar to ours, but we use SWRL rules, instead of value-maps used by them. [Kagal et al., 2004a] use a rule based engine for handling trust and privacy of Web services. In another paper [Kagal et al., 2004b] the authors have discussed the interaction of OWL ontologies and SWRL rules as an open problem. The approach discussed in this paper allows us to combine OWL ontologies and SWRL rules, by representing only those aspects of which are beyond the expressivity of description logics to OWL. [Li and Horrocks, 2004] provides an approach for matching non-functional attributes, but their framework is restricted as they rely solely on subsumption for the matching and their expressivity is limited by description logics. While our approach also takes care of hierarchical relationships (the basis for subsumption), it is more flexible we can use either subsumption based reasoning as well as domain rules for matching. In addition, we support relationships (inter and intra domain) using rules which cannot be representing using description logics alone. [Parsia et al., 2005] have developed an OWL ontology for representing WS-Policy. However, they have not considered adding SWRL rules to the assertions, which is a key contribution of this approach.
In this paper, we have proposed an approach for matching non-functional requirements of Web services based on creating rich domain models using ontologies and rules. The research contributions of this paper are providing a extensible domain crossing approach for semantic policy matchmaking as well as providing an approach for implementing horn logic based rules to be used in conjunction with OWL based ontologies. Our implementation acts as a proof of concept and shows the usefulness of such an approach.
and DunAndBradStreetRating(A, "A3") do:
Assertion (A1) and BusinessLevel (A1, "Enterprise") and hasAssertion (ALT, A1) If there exists a policy P, which has an alternative ALT, which has an Assertion A1, which states that "ExecutionTime = X" and an Assertion A2, which states that "NeworkTime = Y", then create a new Assertion A3 which states that TotalProcessingTime = X + Y. This rule can be represented in SWRL syntax as: Policy (P) and hasAlternative (P, ALT) and hasAssertion (ALT, A1) and hasAssertion (ALT, A2) and ExecutionTime(A1, X) and NetworkTime (A2, Y) => Assertion (A3) and TotalProcessingTime (A3, X + Y) and hasAssertion (Alt,A3) This rule can be written in ARL as:
when: Policy (P) and hasAlternative (P, ALT) and hasAssertion (ALT, A1) and hasAssertion (ALT, A2) and ExecutionTime(A1, X) and NetworkTime (A2, Y) do:
Assertion (A3) and TotalProcessingTime (A3, X + Y) and hasAssertion (Alt, A3) Rules are used in ABLE using a RETE [Forgy, 1982] network and new facts are added to the policies if the right conditions exist for firing the particular rules. A key challenge was to model these rules over OWL facts. However, the ABLE based implementation of SNOBASE, which also models OWL facts as rules, allowed us to write these in Able Rules Language. Similar rules can be written to invalidate alternatives, if the inter-domain assertions do not make sense or contradict each other. For example, if a security algorithm assertion and compression algorithm assertion are in the same alternative, and they cannot co-exist, then the alternative can be invalidated, by having a rule to do so.
In this section, we will explain our matching algorithm. As discussed in section 3.2, matching two policies is reduced to finding two equivalent alternatives. However, based on requirements and capabilities, we present a different definition for equivalent alternatives. Equivalent alternatives can be defined as alternatives whose capabilities satisfy each others requirements. In order to write the definition, we define functions "req" and "cap", which represents requirement and capability assertions of an alternative respectively.
(( ∀ A i ) S.T. A i req (Alt1) and ( ∃ A j ) S.T. A j ∈ ∈ cap (Alt2) and A i satisfies A j ) and (( ∀ A i ) S.T. A i ∈ req (Alt2) and ( A j ) S.T. A j ∃ ∈ cap(Alt1) and A i satisfies
⇒ ⇔
Similarly, we categorize the policies of requester in section 2 as follows:
Requestor Requirements:
• The following rule is fired when the above assertions are added to the policy object.
DunAndBradStreetSize(P, A3) => businessLevel(P) = Enterprise Hence, a new assertion is generated • BusinessLevel is Enterprise
Our matchmaking framework can now match the policies of the requestor and the provider with the help of the new facts that have been added to both the policies.
Checking all requirments of policy 1:
1. BusinessLevel (P1 , Enterprise) is satisfied by assertion BusinessLevel (P1 , Enterprise) as Enterprise = = Enterprise 2. SecurityToken (P1, Kerberos 5.1) is satisfied by assertion SecurityToken (P2, Kerberos 5.0) as Kerberos 5.0 is substituteable for Kerberos 5.1 and keysize ( 1024 >= 512) 3. EncryptionAlgorithm (P1, EncryptionAlgorithm) is satisfied by assertion EncryptionAlgorithm (P1, RSA) as RSA subClassOf EncryptionAlgorithm Therefore, all requirements of policy 1 are satisfied by policy 2. Checking all requirements of policy 2: 1. ProcessingTime (P2 , <=, 100ms) is satisfied by assertion ProcessingTime (P1 , <=, 90ms) as 90ms <= 100ms Therefore, all requirements of policy 2 are satisfied by policy 1. Since all requirements of both policies are satisfied by each other, the matcher declares these policies as being equivalent.
Much of the previous work on policy matching has been based on syntactical models. Wohlstadter et al [Wohlstadter et al., 2004] extend the grammar of WS-Policy to add qualifying conditions and numerical predicates, but is still based on syntactical domain models. Having XML based models limits the expressivity of the assertions and also limits the matching to syntactical matching. Our work addresses these limitations by using OWL based domain ontologies along with SWRL like rules. This allows our matcher to use rich domain knowledge for better matching. [Mukhi and Plebani, 2004] discuss issues in WS-Policy based frameworks. One of