Enhancing Web Service Selection by QoS-Based Ontology and WS-Policy Sodki CHAARI
Youakim BADR
Frédérique BIENNIER
LIESP, INSA-Lyon 20, Avenue Albert Einstein F-69621 Villeurbanne, FRANCE
LIESP, INSA-Lyon 20, Avenue Albert Einstein F-69621 Villeurbanne, FRANCE
LIESP, INSA-Lyon 20, Avenue Albert Einstein F-69621 Villeurbanne, FRANCE
[email protected]
[email protected]
[email protected]
ABSTRACT
fundamental characteristics of modern business requirements.
The Service Oriented Architecture enables the development of flexible large scale-applications in open environments by dynamically combining Web services. Nevertheless, current techniques fail to address the problem of selecting adequate services to meet service consumer needs. Service selection must take into account non-functional parameters especially the Quality of Service (QoS). In this work we propose a Web service selection approach based on QoS attributes. We extend the WS-Policy to represent QoS policies. We apply ontological concepts to WS-policy in order to enable semantic matching. Publishing QoS policies is also examined in this work. We propose to extend the UDDI register to handle QoS-based policies.
However, existing web service standards and techniques do not conform to the approach of SOAs In fact, these techniques rely on syntactic descriptions of service interfaces to find and publish web services with disregard to non-functional service parameters. Previous research demonstrate how this situation generates two major problems: (i) The syntactic discovery efforts return results with low precision and recall ratios [8] and (ii) no means are provided in order to select among multiple services those which can perform the same function [12, 21]. Many efforts tend to combine semantic web and service technologies to solve the first above-stated problem [13]. For this reason, web service descriptions are enhanced with annotations of ontological concepts. In addition, algorithms have been developed to deal with semantic matching to improve web services discovery. In response to the second problem, some research works attempt to consider non-functional properties in particular QoS properties [3, 4] which encompass any characteristics significant to consumers [10, 16]. These include performance, reliability, integrity, accessibility, availability, interoperability, security and so on. QoS properties have substantial impacts on users' expectations of services and can be used as a discriminating factor among web services providing equivalent functionalities. Consequently, descriptions of web services should be reinforced by the annotations of QoS attributes.
Categories and Subject Descriptors H.3.3 [Information Systems] Information Search and RetrievalSearch process; H.3.5 [Information Storage and Retrieval]: Online Information Services – Web-based services.
General Terms Algorithms, Management
Keywords Web service, Policy, QoS, WS-Policy, Ontology
1. INTRODUCTION Web services offer a suitable technical foundation for making business processes accessible within and across organization boundaries. Web services provide technology-independent interfaces and standards allowing for the encapsulation and componentization of software and applications [9, 14].
We attempt in this present work to enhance web service discovery and selection with a particular focus on QoS attributes. As managing QoS raises the need for a structured representation of QoS attributes, we consider treating them as policies of web services. For the purpose of representation we adopt the WS-Policy framework [1].
The Service Oriented Architecture (SOA) promises to enable the design of business applications from independently developed and deployed services. The major advantage of SOA is that it enables services to be dynamically selected and composed. By such SOA guarantees flexibility and adaptability which are
Nevertheless, WS-Policy presents some deficiencies. It only allows for a syntactic description of service properties. This lack of semantics hampers the effectiveness of specifying and matching the compatibility between the QoS policies. To remedy this restriction, we propose to extend QoS policies with additional semantic information using ontologies. The inclusion of semantics allows a greater precision in the description of QoS policy assertions. Different syntactic assertions could be considered compatible with respect to a common ontology and guarantee a broad range of possibilities for service discovery and selection.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’08, March 16-20, 2008, Fortaleza, Ceará, Brazil. Copyright 2008 ACM 978-1-59593-753-7/08/0003…$5.00.
The rest of the paper is organized as follows. Section 2 focuses on the extending of WS-Policy by introducing the QoS
2426
integration of semantics in policies hinges on the use of ontological concepts within policy assertions [7].
ontology, the WS-Policy ontology and the QoS matching process. Section 3 presents mechanisms for publishing QoS policies and how to use them to discover adequate services.
3. EXTENDING WS-POLICY FOR QoS PRESENTING AND MATCHING
2. MOTIVATION WS-Policy framework [1] provides a grammar for representing non-functional attributes of entities in a web services-based XML environment. A policy is defined as a collection of alternatives which is, itself, defined as a collection of assertions. An assertion is used to represent a requirement, capability or a behavior of a Web service. An assertion includes an arbitrary number of child assertions and attributes. They are based on a domain of vocabulary. A service consumer and/or service provider can define assertions in WS-Policy of any domain by using specifications describing the vocabulary. The matching process of policies, if unaware of the domain knowledge, will only be reduced to a syntactical matching of strings of characters. We demonstrate the usefulness of syntactical matching in the example illustrated in Figure 1. Consider that a service consumer presents a requirement on a QoS attribute related to the “Response Time” capability as shown in Figure 1(a) and a service provider guarantees a "Response Time" presented as two separate indicators: the "Execution Time" and the "Network Time", as shown in Figure 1(b):
We propose to use semantically-enriched policies to represent QoS attributes and reasoning among alternatives, assertions and expressions. Extended policies not only guarantee the interoperability between policies of service consumers and providers but also the discovery and selection of web services with respect to non-functional properties. These policies offer multiple service usage contexts as result of combinations of alternatives and assertions. Throughout this paper we propose a framework to deal with semantically-annotated policies for Web services selection and discovery. Firstly, we propose a generic ontology to describe QoS attributes. We then adopt standard web technologies such as WS-Policy and UDDI registry to extend their technical specifications with semantics. We redesign the WS-Policy with an ontological representation of concepts and relations. Additional concepts are introduced as well to enhance the matching process of policies. The integration of QoS ontology and WS-Policy ontology allow an advanced reasoning. Thus we introduce a preliminary matching algorithm of QoS-based Policy to find equivalent assertions and alternatives which are usually expressed independently by service consumers and providers. The framework of our contribution also deals with the publishing and selection of QoSbased Policies. We enrich the UDDI registry with entries to handle attributes of QoS and their appropriate policies. In addition, a complete mechanism of discovery is illustrated in order to build a matrix of selection of QoS attributes. In the real context of the Web the number of Web services available, QoS attributes and policies is significant. The selection matrix helps to apply data-mining algorithms and find relevant services.
(a) Consumer requirement in Web Service Response Time
3.1 QoS-based Ontology In order to achieve semantic enrichment, we introduce a QoS ontology to define domain-independent and domain-specific QoS concepts. To facilitate reusability and extensibility the QoS-based ontology is designed from the onset to be modular and structured as a set of layers of interconnected smaller ontologies. Ontologies in higher layers are specialized and built upon those from lower layers. The QoS-based ontologies fall into three layers as shown in Figure 2:
(b) Provider capability in Web Service Response Time Figure 1. Matching problem of WS-Policy assertions A typical syntactic matcher would perform a string comparison to determine if the service provider can satisfy the request of the service consumer. The matcher generally concludes that these two services do not altogether match according to their QoS attributes despite the fact that the assertions are equivalent. By such, a potential partnership between service consumers and providers can be rejected during the policy matching phase of compatible policies. Integrating semantics into the WS-Policy framework achieves expressive policy specifications, policy reasoning and matching. Such has recently been advocated in several works [6, 17] in order to deal with some limitations of current policy handling systems. Semantic-enriched policies also facilitate service negotiation, improve policy monitoring [2] and enable more accurate interaction than syntactic approaches [18]. The
Figure 2. Three layers of QoS ontology The Bottom Layer includes an Upper Ontology that defines generic concepts relevant to QoS. In addition, this layer contains Unit Ontology for metric measure units and unit conversion rules. For instance, we can mention the Time Ontology which represents units of time and how to convert between them. Finally, the Operator Ontology denotes operations to compare attributes and metrics.
2427
The Middle Layer includes a Domain-Independent Ontology that defines general QoS attributes, their metrics, relationships and dependencies between them.
- The second type is "ont," indicating that a semantic reasoning can be used when matching this assertion. When defining assertion, the policy manager, based on its domain knowledge, can assess if reasoning using transformation rules can be applied to the assertions. For example, an administrator defines two policy assertions concerning the "Execution Time" and "Network Time." But, he or she knows that the sum of these two QoS attribute values can produce another QoS attribute: the "Response Time" attribute. The administrator indicates that semantic reasoning can be applied by setting attribute of the MatchingType to the "ont" value in the assertion definition.
The Upper Layer contains a Domain-Specific Ontology corresponding to a particular domain of interest. This ontology contains, for example, some particular QoS attributes, related to a domain as well as their corresponding metrics other than those defined in the Middle Layer.
3.2 Extending WS-Policy Specifications WS-Policy was written with some flexibility in such a way that assertions are domain dependent. Hence, according to the domain, the form and specification of the assertion contents can be defined. In order to address the QoS-based policy, we suggest extending WS-Policy specifications with a super set of elements to enable an automatic parsing and reasoning over policies. For this reason, we propose using an ontology-based model to specify these elements as illustrated in Figure 3. We introduce concepts as well as relationships among them to represent QoS policies. Below, we describe the various elements which constitute the extended policy: •
Policy: represents the root WS-Policy element and indicates a policy expression, which is an XML representation of a policy;
•
Name, Id: identify a given policy within the WS-Policy.;
•
PolicyCategory: each policy belongs to a specific policy category corresponding to a particular QoS attribute;
•
PolicyReference: enables assertion reusing across policies. Then, the content of a policy may be included into another policy;
•
Service: describes details of the service implementation for which the policy has been specified. A capability policy includes this element to specify details of the service type to which the policy is applied;
•
PolicyOperators: the ExactlyOne and All elements are WS-Policy policy operators. The ExactlyOne operator is a collection of policy alternatives and the All operator groups policy assertions into alternatives. Policy operators may be recursively nested;
• ServiceOperation: an assertion is related to a particular Web service operation. In some cases the assertion may be applied to a particular attribute in the service operation; • Expression: guarantees an easy parsing and facilitates automatic comprehension and handling of assertions.. This element contains sub-elements: the Parameter subelement represents the QoS attribute that will expressed by the assertion, such as the Response Time; the Value subelement related to the supported assertions; the Unit subelement corresponding to a measure unit of metrics related to the QoS attribute; and the Operator sub-element used in the assertion expression to represent relationship between QoS attributes and values. It can be a basic operator such as "greater" and "equal" or an OWL-based operator such as the "subclass" operator. • FlexibilityMode: indicates the flexibility level of any given assertion. This attribute value can be either negotiable (N) or non negotiable (NN). This attribute indicates if assertion can be negotiated in order to modify values.
The QoS policy assertion is composed of the following attributes: • AssertiontType: indicates whether the assertion is a capability or a requirement. This Type enhances the match-making process. In fact, in normal cases the matching process considers all assertions as capabilities and requirements and takes one-to-one matching. This complicates matching and makes the process time consuming. The AssertionType seeks to facilitate the matching process;
Figure 3. WS-Policy ontology The example illustrated in Figure 4 defines a QoS policy based on the extended WS-Policy. This example addresses the Response Time attribute. Lines (02-05) show name-spaces: wspes, qosid, qoso, qosu which correspond respectively to the name-space URIs of the web service extended policy, the Domain-Independent Ontology, the Unit and Operator Ontologies. The line (08) indicates the name of the Response Time assertion, (RTAssertion), a non-negotiable assertion. Its expression is defined between lines (11) and (18) which indicate that the Response Time must be less than 5 seconds.
• MatchingType: indicates the type of reasoning that can be used regarding the assertion. There are two types: - The first type is "xml", denoting any data type supported by the XML schema such as string and float. In this case our reasoning about this assertion compatibility must take into account the manipulation of such data.
2428
After applying the above rule, the Response Time of the service provider, is equal to 5000 milliseconds. In reference to the Unit Ontology, it can be determined that 5000 milliseconds is equal to 5 seconds and consequently the two policies are compatible. We introduce the algorithm used to mach two QoS policies as detailed in Figure 5. The algorithm contains three principal functions: • AltMatch: compares the compatibility of two alternatives. Two sub-functions, AsserCap and AserReq, retrieve capability assertions and requirement assertions from alternatives (lines 01-04). • AsserMatch: matches the compatibility of assertions belonging to two different assertion sets. It returns a true value when all assertions of the first set satisfy all assertions of the second set (lines 05-15). • Sat: verifies whether two particular assertions are compatible. It first checks the compatibility of the two QoS categories (line 16). Then it performs a semantic reasoning and uses transformation rules to modify assertions (line 18 and 19). Next it compares units and makes conversions in the presence of two different units (line 20). Finally, it compares the two assertion values (line 21) and returns true value when the two assertions are compatible.
Figure 4. A QoS-based policy example
3.3 QoS-Based Policy Matching Once a service consumer finds a service fitting functional properties, he or she must verify the compatibility of nonfunctional properties.. QoS policy matching must address this issue. Two QoS policies match each other when at least two compatible alternatives can be found. The compatibility of two alternatives can be defined as the capability of one alternative to match the requirements of another alternative. In other words, assuming two alternatives A and B, A is compatible with B ( ) if and only if Capability Assertions (CA) of alternative A match ( ) the Requirement Assertions (RA) of the alternative B and the Requirement Assertions of alternative A match the Capability Assertions of alternative B. By such, CAset and RAset can be respectively defined as the set of capability and requirement assertions of an alternative. The compatibility between two alternatives is defined as follows:
, ,
. .
A capability assertion satisfies a requirement assertion if its value satisfies the requirement assertion's value. When verifying compatibility of the two assertions we must take into account the MatchPolicy value in order to decide what kind of comparison will be made (i.e. a syntactic comparison when its value is "xml" or a semantic comparison based on transformation rules when its value is "ont").
Figure 5: Matching algorithm
4. A GENERAL FRAMEWORK FOR PUBLISHING AND SELECTION We introduce a framework for dealing with the publishing and discovery of Web services using QoS-based Policies. We enrich the UDDI registry with entries to handle attributes of QoS and their appropriate policies. The following sub-sections detail the framework.
Rules and domain knowledge are used to reason about assertions. Considering the example presented in Figure 1 in which the domain knowledge supported by ontologies and based on well-defined transformation rules can help compute Response Time. We can use transformation rules as presented in [18] which have the following form:
4.1 Publishing the QoS policy In order to be used in service selection mechanisms, service QoS-based policies must be published. For this reason, each QoS policy description is attached to the registration entry of its appropriate Web service. We use UDDI [19] as a registration repository and adopt the mechanism introduced in the WSPolicyAttachment specification [20] to attach policy expressions
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 "ResponseTime = X + Y".
2429
to UDDI. The tModel field is used to register policies. Each tModel will be referenced in the business service entry of the Web service. A tModel is defined as a tuple:
policies. We illustrate the advantages of this approach through a simple scenario of Web service substitution whereby we need to replace a Web service (WS1) with an equivalent in respect to the functional and non-functional properties. The selection involves three entities: the service composition engine, the PolicyMatcher and the UDDI registry. For simplicity, our approach only focuses on non-functional properties such as QoS attributes. The substitution process will be carried out in two phases. The first phase includes 4 steps as illustrated in Figure 7:
tModel=< P-ID, P-URL, S-ID, C > where P-ID corresponds to the policy identifier, P-URL points to the policy XML file. S-ID represents the Web service identifier and finally, C refers to the policy category represented by the tModel. The policy category designs the QoS attribute presented by the policy.
1. The service composition engine sends an initial request to the UDDI registry containing the identifier of WS1 (S-ID).
As illustrated in Figure 6, the tModelKey attribute (line 1) in the tModel tag represents a unique identifier generated by UDDI to refer to the tModel. This identifier also represents the QoS policy identifier (P-ID) presented by the tModel. The first keyedReference (lines 7-10) represents the URL of XML file corresponding to the QoS policy. The second keyedReference (line 12-15) corresponds to the service identifier on which QoS will be attached. The third keyedReference represents category of the QoS policy (lines 17-19). Its value acts like an index which refers to the QoS policy attribute helping in UDDI parsing and tModel clustering.
2. The composition engine receives as an answer the list of policies which are attached to the WS1 ({Pi}). 3. The service composition engine seeks services which match all registered QoS policies. For this reason, the engine searches for all P-Groups having the same categories of QoS policies related to WS1(Pj). 4. The P-Group will return the complete list of Web service candidates after have completed the matching process among QoS policies by using the QoS PolicyMatching engine as specified in Paragraph 3.3. The P-Group, having all policies stored in tM files, can help to easily parse the Web service policies and select compatible policies.
Figure 7: Exchanging messages between different entities In the second phase, after having retrieved the set of services responding to QoS constraints, the service composition engine builds the Selection Matrix, SM = (SMi,j,1≤ i ≤ n, 1≤ j ≤ m), in which each row, SMi corresponds to a particular service while each column corresponds to a QoS attribute. Cell values can either be 1 if there is a match and 0 in the opposite case.
Figure 6. Registered QoS-based policy in tModel Each service can have one or more QoS policies corresponding to general QoS attributes (availability, security, etc.). In order to improve policy management, we cluster all QoS policies sharing the same category into different groups called Policy Groups (PGroup) defined as follows: P-Group=
S1 S2 Sm
Whereby C refers to the policy category which gathers all policies in the P-Group and {tModeli} is the set of all tModels of policies belonging to the category C.
Att1 1 0
Att2 1 1
Att3 0 1
1
1
0
QoS Attributes …
Attn 1 0 0
Figure 8: Example of the selection matrix When there are one or more services which respond entirely to all QoS attributes, the service composition engine (SCE) will choose one among them by using additional parameters. In the opposite case, the SCE chooses the services having a minimum number of zeros. The SCE can either negotiate with the service provider to change the QoS attribute or combine two or more services to meet service consumer’s need. The selection matrix has the potential to become large in dimension. Data mining techniques can be used to enhance the QoS matching.
P-Group can be treated by the UDDI registry in the same way as a Web service. New QoS policy categories can be added dynamically through tModels and easily managed. Adding a new category means creating a new QoS policy attribute and its related P-Group in the registry.
4.2 Selecting Web Services Using QoS-Based Policy
5. RELATED WORK
Web services selection using QoS attributes, WS-Policies and Ontologies enhances the discovery of adequate services. The UDDI registry improves, in its turn, the selection of compatible
Empowering web service technologies with QoS constraints has been discussed in several previous works especially in the case of using QoS attributes in the service selection process to find
2430
services that best respond to consumer needs. Ran [15] extends the three basic elements in the web service architecture (i.e. service provider, service consumer and UDDI register) with the addition of a fourth element called the certifier. In one hand, the certifier verifies the compliance of the QoS of provided web services before publishing them. On the other hand, the certifier enables the Web service consumer to verify the QoS claims in order to assure satisfaction when interacting with service providers. However, this work does not address the presentation of QoS attributes. Whereas this framework publishes QoS into the UDDI, there are no actual descriptions of the contents of this extension apart from its structure. Moreover, matching mechanisms are not developed. Garcia and Toledo [5] present a simple approach to select Web services based on QoS policy. Information regarding QoS is attached to the UDDI register but the authors do not demonstrate how the attachment is taken nor do they present mechanisms for handling and extracting this information from the UDDI. In their work, a broker is used to enable service selection. However, broker functionalities are not well detailed especially in regards to extracting QoS information from the registry. In their work, Maximilien and Singh [11] present an agent framework enriched with ontology for a dynamic Web service selection. Agents collect different QoS information from services which will be shared among all agents. The ontology captures and defines the most generic QoS concepts. In addition, QoS attributes are represented as policies. Nevertheless, these policies are very complex and require sophisticated matching facilities. Lastly, this work fails to address publishing mechanisms and used standard policy language to guarantee interoperability.
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
6. CONCLUSION Web service selection should be supported by suitable mechanisms and approaches. Non-functional parameters must be taken into account in such selection process. Indeed, syntactic selection can eliminate potential Web service candidates. In this work we have presented QoS-based policies for Web service selection. We extend the WS-policy standard with some ontological concepts to represent QoS attributes. QoS-based policies are then published in UDDI registry through tModels. Our selection process is based on QoS policy matching in with domain knowledge and transforming rules are used to enhance selection results. In future works we consider three potential contributions. Firstly, we will test our approach with a large set of QoS attributes. Secondly, we will integrate negotiation facilities in our selection process, and finally, we will enrich the selection matrix with data mining techniques in order to improve the selection of appropriate Web services.
[13]
[14]
[15] [16]
[17]
7. REFERENCES [1]
[2]
[3]
S. Bajaj, D. Box, and D. Chappell, "Web Services Policy Framework (WS-Policy) published on line at: http://www128.ibm.com/developerworks/library/specification/wspolfram/," 2006. L. Baresi, S. Guinea, and P. Plebani, "WS-Policy for service monitoring," in International Workshop on Technologies for E-Services, 2006, pp. 72-83. J. Cardoso, A. Sheth, J. Miller, J. Arnold, and K. Kochut, "Quality of service for workflows and web service processes," Web Semantics: Science, Services and Agents on the World Wide Web, vol. 1, pp. 281-308, 2004.
[18]
[19] [20] [21]
2431
M. Conti, M. Kumar, S. K. Das, and B. A. Shirazi, "Quality of service issues in Internet web services," IEEE Transactions on Computers, vol. 51, pp. 593-594., 2002. D. Z. G. Garcia, M. B. F. d. Toledo, and "Semanticsenriched QoS policies for web service interactions," in the 12th ACM Brazilian symposium on Multimedia and the web, 2006. L. Kagal, T. Berners-Lee, D. Connolly, and D. Weitzner, "Self-describing delegation networks for the Web," in Seventh IEEE International Workshop on Policies for Distributed Systems and Networks, 2006, pp. 205-214. L. Kagal, T. Finin, and A. Joshi, "A policy language for a pervasive computing environment," in the 4th IEEE International Workshop on Policies for Distributed Systems and Networks, 2003, pp. 63-74. K. Kritikos and D. Plexousakis, "Semantic QoS Metric Matching " in European Conference on Web Services (ECOWS'06), 2006, pp. 265-274. F. Leymann and K. Güntzel, "The Business Grid: Providing Transactional Business Processes via Grid Services," in Service-Oriented Computing - ICSOC 2003, 2003, pp. 256-270. H. Ludwig, "Web Services QoS: External SLAs and Internal Policies Or: How do we deliver what we promise?," in the First Web Services Quality Workshop, Rome, Italy, 2003, pp. 115-120. E. M. Maximilien and M. P. Singh, "A Framework and Ontology for Dynamic Web Services Selection," IEEE Internet Computing, vol. 8, pp. 84 - 93 2004. E. M. Maximilien and M. P. Singh, "Toward Autonomic Web Services Trust and Selection," in International Conference On Service Oriented Computing 2004, pp. 212-221 B. Medjahed and A. Bouguettaya, "A Dynamic Foundational Architecture for Semantic Web Services," Distributed and Parallel Databases, vol. 17, pp. 179–206. M. P. Papazoglou, "Service oriented computing: concepts, characteristics and directions," in the 4th IEEE International Conference on Web Information Systems Engineering, , Italy, 2003, pp. 3-12. S. Ran, "A Model for Web Services Discovery with QoS," ACM SIGecom Exchanges, vol. 4, pp. 1-10, 2003. E. M. M. a. M. P. Singh, "A framework and ontology for dynamic Web services selection," IEEE Internet Computing, vol. 8, pp. 84-93, 2004, 2004. A. Uszok, J. M. Bradshaw, R. Jeffers, A. Tate, and J. Dalton, "Applying KAoS Services to Ensure Policy Compliance for Semantic Web Services Workflow Composition and Enactment," in International Semantic Web Conference, 2004, pp. 425-440. K. Verma, R. Akkiraju, and R. Goodwin, "Semantic Matching of Web Service Policies," in Second International Workshop on Semantic and Dynamic Web Processes (SDWP 2005), 2005. W3C, " Universal Description, Discovery, and Integration (UDDI), available at http://www.uddi.org," 2002. W3C, " Web Services Policy Attachment, available at http://www.w3.org/Submission/WS-PolicyAttachment". L. Zeng, B. Benatallah, A. H. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang, "QoS aware Middleware for Web Services composition," IEEE Transactions on software engineering, vol. 30, pp. 311-327, 2004.
