Flexible Matching and Ranking of Web Service Advertisements Navid Ahmadi
Walter Binder
Faculty of Informatics University of Lugano, Switzerland
Faculty of Informatics University of Lugano, Switzerland
[email protected]
[email protected]
ABSTRACT
1. INTRODUCTION
With the growing number of service advertisements in service marketplaces, there is a need for matchmakers which select and rank functionally similar services based on nonfunctional properties, such as QoS and reputation parameters. Current matchmakers only support predefined service description languages and predefined third-party repositories of service description documents, which both are hardcoded inside their internal structure, forcing providers to publish their services using a specific service publishing component. Therefore, current matchmakers are not able to look for existing services which are published using different service publishers. In this paper, we propose a flexible matchmaker for service discovery, selection, and ranking, taking both functional and non-functional properties of the services into account. The matchmaker provides an expressive language for the clients to define service requests, specifying involved repositories, non-functional properties and a utility function for ranking Web services. The proposed matchmaker enables clients to search inside existing UDDI and third-party repositories and match already published services, while supporting different service description languages as well as emerging languages. Independency from the service description language and the type of the third-party repository is preserved as long as very basic constraints are satisfied.
Web services are basic building blocks for creating serviceoriented software [13]. Web service repositories store Web service advertisements and allow one to search inside them. UDDI [16] is an industrial initiative for service description and discovery. It has an extensible architecture, called tModels [15], for specifying service type definitions, but it provides limited search facilities, allowing only a keywordbased search of businesses, services, and tModels based on names and identifiers. Searching inside service description documents registered in the registry is not supported by UDDI. Therefore, semantic Web service matching methods have been developed to resolve UDDI keyword-based search shortcomings using subsumption reasoning based on ontologies [5, 12]. With the dramatic increase in the number of Web services, the number of functionally similar Web services is increasing as well. Therefore, there is a need to select the most suitable service from the matching service list. To address this problem, service discovery methods based on non-functional properties have been developed to exploit non-functional parameters such as quality of service (Qos) and reputation with the aim of narrowing down the service selection. WSDL [2] is the de-facto standard for service description based on functional properties, but it does not describe non-functional properties of Web services, e.g. QoS properties. A number of other service description languages for describing QoS and Service Level Agreements (SLAs), e.g., WS-Agreement [1] and WSLA [17], as well as reputation mechanisms are proposed by different organizations and researchers. A more advanced technique for service selection is to rank the matching services based on some criteria. The criterion for ranking the Web services can be a semantic-based measure [6], or non-functional properties [18], e.g., QoS and reputation. Existing matchmakers are restricted by the following constraints:
Categories and Subject Descriptors H.4 [Information Systems Applications]: Miscellaneous
General Terms Algorithms, Languages
Keywords Web Services, Flexible Matchmaking, Service Discovery, Service Selection, Service Ranking
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, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MW4SOC ’07, November 26, 2007 Newport Beach, CA, USA Copyright 2007 ACM 978-1-59593-928-9/07/11 ...$5.00.
• Current matchmakers only support their own service description language which is hard-coded inside their internal structure. Usually, the properties of the supported description language are mapped into UDDI’s tModel structure [8, 11, 18]. • Third-party repositories (e.g., reputation repositories) are directly bound to the matchmaker. Users of the matchmaker can not specify external third-party repositories.
• Ranking criteria are hard-coded inside the matchmaker. Client
All these limitations force the service providers to publish their services with the following constraints:
1- Service Request
• Services should be described only using the supported service description languages.
10- Ranked Service List
• Services should be published only via the provided service publishing interface. Only the services that are published by the provided publisher will be searchable.
Ranker
According to these constraints, matchmakers lose their ability to search inside current service repositories and match already published services. In this paper, we present a flexible matchmaker for service discovery, selection and ranking, as a middleware for clients, which addresses the mentioned problems. Our design goals include: • Flexible service selection based on client requirements using a sufficiently expressive formalism to define custom service requests.
9- Ranking
8-Integrated Description Description Selector and Integrator (DSI)
7- Extracting properties
6- Service Descriptions Service Retriever
5.b-Related Documents
5.a-Related
4.b-Service ID
• Compatibility with existing service description languages and third-party repository infrastructures. • Openness to emerging service description languages and external third-party repositories.
Matchmaker
Disk Party Third Disk Repositories
Documents 3-Matched 2-Functional Services 4.a-Service ID Properties
UDDI UDDI UDDI Registries Registries Registries
Disk Disk Providers
• Integration of functional and non-functional aspects of the services for service selection and ranking. • Flexible service ranking based on a custom utility function (ranking formula) specified by the client in the service request.
Figure 1: Architecture of the Matchmaker
Our approach is to avoid hard-coding particular matchmaking constraints, particular third-party repositories, and a particular ranking algorithm. We provide a language which lets the client define the semantics of matching by defining the repositories for service lookup, the nonfunctional properties for service selection, and a utility function for service ranking. The client will provide a XPath expression for each type of service specification as well as the interface for interoperating with UDDI and third-party repositories. Finally, the services will be ranked based on a utility function computed by the values of the corresponding service properties provided by the client. The rest of this paper is organized as follows: In Section 2 our architecture is presented. Section 3 describes the service request structure. Section 4 explains the matchmaking process. In Section 5 related work is presented. Finally, Section 6 concludes the paper
1. Client sends a service request to the matchmaker. A service request is expressed in a XML-based language which includes information about repositories, service lookup in UDDI and third-party repositories, property extraction, and ranking.
2.
6. The service retriever passes all the corresponding service description documents of each service to the DSI.
ARCHITECTURE
The proposed matchmaker has three main parts that we will discuss in this section: service retriever, description selector and integrator (DSI), and ranker. The matchmaker is itself a Web service. It offers two interfaces: one returns all the ranked services immediately, while the other one works incrementally and returns the next best result each time the client asks. The architecture of the matchmaker is shown in Figure 1. Below, the matchmaking steps are explained:
2. The service retriever looks for the services in the UDDI repositories using service lookup information. 3. The UDDI returns a list of matching services and their keys. 4. The service retriever looks for service description documents in the third-party repositories as well as service providers using the service key of the matching services. 5. Third-parties and providers return corresponding service description documents for each matching service.
7. The DSI generates a XSLT file with embedded XPath queries that for each service extracts requested properties from the related service description documents and integrates them in one description document. 8. The DSI sends the generated service description document to the ranker.
9. The ranker collects generated service description documents of all matching services and ranks services according to the provided utility function in the service request. 10. The ranker sends the ranked list of services back to the client, completely or incrementally. The service retriever interacts with UDDI and third party repositories. It looks for the matching services inside UDDI repositories using UDDI’s find service service. For each declared UDDI repository in the service request a respective message for interacting with the find service service is included by the client. For matching the functional properties, the matchmaker may also support any semantic matching based on any semantic Web service language such as OWLS [10]. Then, for each matching service in the service list returned by UDDI, the service retriever returns all the respective service description documents which are referred to inside UDDI and in the third-party repositories. Finally, the service retriever sends all retrieved documents of each matching service to the DSI. DSI takes all the documents related to each matching service from the service retriever as input, selects properties defined in the service request using XPath expressions, and finally integrates them in a unique XML-based service description document using XSLT. The internal structure of the DSI is explained in Section 4. The ranker receives the integrated service description document generated by the DSI and extracts values of the variables. The matching score for every service is computed using a utility function defined by the client in the service request. Finally, services are sorted based on their matching score. The description document generated by DSI and the rank score of the services are returned to the client. For the incremental retrieval of the matching services, the results are stored in a list and every time the client invokes the matchmaker using the same service request ID, the next best matching service is returned to the client.
2.1 Service Publication Issues In order to retrieve service description documents from the third-party repositories, the service keys should be shared among the UDDI and third-party repositories, which restricts the matchmaker to a specific service publishing component, but if any published service uses a globally unique service key, there will be no need to a specific service publisher anymore. We suppose that a service publishing component such as the one depicted in Figure 2 is used to make sure that a published service has a unique service key among all the repositories. Initially, the service publisher receives a service advertisement and respective repository information from the service provider. Service advertisement would be published in the UDDI repository using the service publishing API of UDDI. UDDI returns the published service key to service publisher. The service publisher then uses repository information received from service provider to contact third-party repositories and make them aware of the newly published service. The service key of the new service will be passed to these third-parties, as a key for later information retrieval by matchmaker. Third-party repositories that need to be aware of the published services immediately after the publication of the ser-
Service Provider
1-Service Advertisement, Repository Information
Service Publisher
4-Register with Service ID
3-Service ID 2- Register Service
Disk Third Disk Party Repositories
UDDI Registry
Figure 2: Service Publisher vice, will be notified by the service publishing component. However, there may be some third-party repositories which do not need to be aware of services at publication time, but rather they create entries for new services upon first information arrival about those services. The contact information of these repositories will not be passed to service publisher.
2.2 Deployment Strategies We consider three methods for deploying the matchmaking middleware: 1. The middleware is on the client side: in this case every client has its own instance of the matchmaker which makes the client responsible for defining UDDI and third party repositories to search for services and retrieve description documents. 2. The middleware is on the UDDI server side: In this case the middleware will be set up by the UDDI server maintainers. This enables the UDDI server to be bound to some specific third party repositories which are in collaboration with the UDDI server. Hence, the third-party repositories will be transparent to the client. 3. The middleware is on an external server: In this case the middleware will be set up by external organizations which maintain the external server, with the aim of binding both UDDI and third parties to specific repositories according to the organization’s goals. Hence, both of the UDDI and third-party repositories will be transparent to the client.
3. SERVICE REQUEST The structure of the service request is depicted in Figure 3. A service request has four major parts: Repositories, XPath Extractors, Selectors, and Utility Function. The repositories part of the service request consists two different types of repositories: UDDI repositories and thirdparty repositories. Each repository has a binding address
Service Request Repositories UDDI Repositories UDDI Repository Binding Address UDDI Find_Service Message
Third-Party Repositories Third Party Repository Binding Address Service Description Look-up Message
XPath Extractors XPath Extractor XML Namespace XPath Expression
Selectors Selector Selector Name Assigned Variable Namespace List Selection Condition Default Value
Utility Function
Figure 3: Structure of service request
and a service lookup message. The lookup message for UDDI repositories is called find service message, which is embedded inside the service request by the client. Upon receiving a service request, the matchmaker connects to UDDI repositories and sends them the find service message. After the matchmaker has received a list of matching services and their keys from UDDI, it connects to each third-party repository and sends the respective description lookup message and asks for the related documents of each service using its service key. Our assumption is that service keys are unique among determined repositories in the service request. XPath extractors are used to refer to parts of the service description documents where the requested properties are expected to appear. Each XPath extractor has two parts: a XML namespace and a XPath expression. We use XML namespaces to distinguish different service descriptions types, as service description documents are usually allowed to contain multiple types of service descriptions. For instance, in the WS-Agreement [1] specification, using any
service term, such as WSDL, job specification, or data service specification, is allowed. For each XML namespace, there can be at most one XPath extractor in the service request. XPath extractors are responsible to extract defined variables in selectors according to the corresponding namespace structure. For example, an XPath expression such as //wsag:Variable[@name=$name]/location/ means that in a WS-Agreement document with the wsag namespace, Variable elements represent non-functional properties and they have a child element called location which is again an XPath expression locating the place where the domainspecific value of that non-functional property exists. Moreover, dereferences, i.e., any XPath expression that locates another XPath expression that needs to be retrieved, are easy to handle by adding a simple syntactic symbol (e.g., parentheses) around the XPath expression. Our goal is to preserve the flexibility and openness aspects of the matchmaking by means of highly customizable service requests that are able to support future description languages. Therefore, we do not restrict the matchmaker to the predefined XPath extractors. Since writing XPath extractors for different types of documents can be complex, we provide extractors for well-known service description types (e.g., WSDL, WS-Agreement, WSLA) and have published them on the Web so that clients can retrieve and embed them inside the service requests. Selectors are used to define those properties described in service descriptions which will be used for service ranking. Every selector has five attributes: property name, variable name, namespace list, selection condition, default value. The property name will replace $name inside the XPath extractor to refer to the respective property inside a namespace. The variable name will be used by XSLT as the new name of the variable inside an integrated document which will be passed to the ranker. The namespace list determines which namespaces have to be looked for to extract defined properties from service descriptions. The selection condition is an optional parameter which is embedded inside XPath expressions to filter the matching service list. If a selector retrieves a value for a property, but the retrieved value does not satisfy the condition, the corresponding service will be dropped from the list. The default value is an optional parameter which (if provided) will be used in case that a property is not available for a service. If the default value is not provided, and there is no such property inside a document, the service will be dropped from the list. The selector’s structure is inspired by SQL queries. For example, {“availability”, A, {wsaq,wsla}, node() >= 0.8,0.95} can be considered as select availability as A from wsaq,wsla where availability >= 0.8. In this example, “availability” is the property that should be searched inside service description documents, A is the corresponding variable that will be filled by the retrieved value and will be used for service ranking, {wsaq,wsla} is the list of XML namespaces that defined property will be looked for using corresponding XPath extractors of those namespaces, node() >= 0.8 is the selection condition which will be added to the XPath extractor, and 0.95 is the default value which will be used in case that requested property will not be found in those defined namespaces. Finally, the ranking part allows clients to define their own customized utility function for evaluating the services
based on the variables defined in the selectors part. Ranking will be done based on maximizing or minimizing the utility function. As an example, let’s suppose a client wants to rank the services based on two non-functional properties, namely: Availability and Cost. Since increasing the availability and decreasing the cost of a service increase the ranking score of the service, a utility function such as Score=Availability/Cost could be appropriate to rank the services. The utility function inside the service request can be expressed using a mathematical markup language such as MathML.
4.
MATCHMAKING PROCESS
The matchmaking process is demonstrated in Figure 4. In this figure, DIS is illustrated as three different components: XPath Generator, XSLT Generator and Selection and Integration. Upon receiving a service request from the client, the service retriever searches inside UDDI repositories (based on functional properties declared in the UDDI’s find service message) and then retrieves description documents of each matching service from third-party repositories. Meanwhile, the XPath generator generates XPath expressions using the selectors and XPath extractors from the service request. Then, the XSLT generator, which is the main part of DSI, generates a transformation document to extract requested properties using generated XPath expressions from description documents, and then stores them in a single description document. Since there may exist multiple description documents for a matching service, the XSLT generator needs to know description documents’ types and corresponding XML namespaces, to be able to complete the transformation generation. The selection and integration part applies the generated transformation document to the description documents and generates one integrated description document. In this document, each element is equal to a variable name defined in each selector and its value is the corresponding property value which satisfies the selection condition, or the default value provided by the selector. Finally, the ranker receives this integrated description document and computes the ranking of the service based on the provided utility function in the service request. The proposed architecture for the matchmaker is open to new service description languages, with one constraint: the matchmaker can retrieve properties from any description language as long as the description language is a XMLbased language and the property is addressable using XPath expressions. In addition, the dereferencing feature enables the matchmaker to run the embedded XPath expressions inside the service description documents which point to the requested variables. An example of using such dereferences is WS-Agreement service description language, as is shown in Section 3.
5.
RELATED WORK
Quality of service has been previously exploited to enhance the service selection. Ran [14] extends the traditional service discovery model by adding a Certifier component. The Certifier is responsible for verification of the advertised QoS, where the QoS information of the Web services is stored inside UDDI. Maximilien and Singh [9] propose an agent framework coupled with a QoS ontology for dynamic Web service selection. With their approach, participants
Client Service Request
XPath Generator
XPath Selectors
Service Retriever
Description Documents' Information
Description Documents
XSLT Generator
XSLT Document
Selection and Integration
Integrated Description Document Sorted Service List Ranker
Figure 4: Matchmaking Process
collaborate to determine service quality and trustworthiness of each other. Reputation mechanisms are also used as a measure for narrowing down the service selection. Majithia et al. [7] propose a framework to facilitate reputation-based discovery and matchmaking of services using semantic web technologies. They support different contexts for different users and applications, each using a weight to show the importance of the context. Jurca et al. [3] propose a reputation manager based on incentives for the clients to report honestly. None of the aforementioned approaches use ranking methods to rank the matching services. However, there is some work focusing on service ranking. Lamperter et al. [4] present service configurations and associated preferences which are modeled in a formal way by attaching price information to property values. Here the assumption is that the values of the service properties are already provided. Lu [6] proposes a semantic Web service discovery and ranking based on a provided service description language. The ranking is based on functional properties, where the more semantically similar service gains a higher ranking score. No non-functional properties and no other service description languages have been taken into account. Ziqiang et al. [18] propose a Web service ranking method based on reputation and QoS properties, But two problems exist: first, QoS properties are embedded inside tModels of the UDDI. They have not been presented as external service descriptions. Sec-
ond, the reputation manager, as a third party repository, is bound to the matchmaker. The user has no access to change or define another reputation manager. All these works use a specific service description language, either the language is a standard language (e.g., OWL-S) or the authors have proposed a new language. As we discussed in the introduction, none of these methods work with existing published services, while our proposed framework is able to cope with different service description languages, and third-party repositories as well as look for already published services.
6.
CONCLUSIONS AND FUTURE WORK
We propose a flexible matchmaker for service discovery, selection, and ranking, as a middleware, with the following properties: • Flexible service selection based on client’s requirements using an expressive formalism to define custom service requests. • Compatibility with existing service description languages as well as openness to emerging service description languages. • Flexible interoperation with existing third-party repositories. • Integration of functional and non-functional aspects of the services for service selection and ranking. • Flexible service ranking using a utility function provided by the client. Regarding future work, we aim at dynamic negotiation for the best SLA with providers, i.e., knowing the client preferences, the matchmaker could be put in charge of negotiating with the providers of matching services to choose the best SLA for the client. This way, ranking would not be only based on static information taken from repositories, but also involve dynamic interaction with service providers. For example, the matchmaker could use a branch-and-bound algorithm, in order to always negotiate with the provider that might offer the best possible solution, until the best possible solution has been agreed on by the corresponding provider.
7.
REFERENCES
[1] A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig, T. Nakata, J. Pruyne, J. Rofrano, S. Tuecke, and M. Xu. Web services agreement specification (WS-Agreement), March 14, 2007. [2] R. Chinnici, J.-J. Moreau, A. Ryman, and S. Weerawarana. Web services description language (WSDL) version 2.0, 2007. [3] R. Jurca, B. Faltings, and W. Binder. Reliable QoS monitoring based on client feedback. In WWW ’07: Proceedings of the 16th international conference on World Wide Web, pages 1003–1012, New York, NY, USA, 2007. ACM Press. [4] S. Lamparter, A. Ankolekar, R. Studer, and S. Grimm. Preference-based selection of highly configurable web services. In WWW ’07: Proceedings of the 16th international conference on World Wide Web, pages 1013–1022, New York, NY, USA, 2007. ACM Press.
[5] L. Li and I. Horrocks. A software framework for matchmaking based on semantic web technology. In WWW ’03: Proceedings of the 12th international conference on World Wide Web, pages 331–339, New York, NY, USA, 2003. ACM Press. [6] H. Lu. Semantic web services discovery and ranking. In WI ’05: Proceedings of the 2005 IEEE/WIC/ACM International Conference on Web Intelligence, pages 157–160, Washington, DC, USA, 2005. IEEE Computer Society. [7] S. Majithia, A. S. Ali, O. F. Rana, and D. W. Walker. Reputation-based semantic service discovery. In WETICE ’04: Proceedings of the 13th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’04), pages 297–302, Washington, DC, USA, 2004. IEEE Computer Society. [8] D. Martin, M. Paolucci, S. McIlraith, M. Burstein, D. McDermott, D. McGuinness, B. Parsia, T. Payne, M. Sabou, M. Solanki, N. Srinivasan, and K. Sycara. Bringing semantics to web services: The owl-s approach, 2004. [9] E. M. Maximilien and M. P. Singh. A framework and ontology for dynamic web services selection. IEEE Internet Computing, 8(5):84–93, 2004. [10] OWL-S. Owl-s: Semantic markup for web services, 2004. [11] M. Paolucci, T. Kawamura, T. R. Payne, and K. P. Sycara. Importing the semantic web in uddi. In CAiSE ’02/ WES ’02: Revised Papers from the International Workshop on Web Services, E-Business, and the Semantic Web, pages 225–236, London, UK, 2002. Springer-Verlag. [12] M. Paolucci, T. Kawamura, T. R. Payne, and K. P. Sycara. Semantic matching of web services capabilities. In ISWC ’02: Proceedings of the First International Semantic Web Conference on The Semantic Web, pages 333–347, London, UK, 2002. Springer-Verlag. [13] M. P. Papazoglou and D. Georgakopoulos. Introduction: Service-oriented computing. Communications of the ACM, 46(10):24–28, Oct. 2003. [14] S. Ran. A model for web services discovery with qos. SIGecom Exch., 4(1):1–10, 2003. [15] tModel. Uddi version 2.03 data structure reference., 2002. [16] UDDI. The universal description, discovery and integration protocol. version 3.0.2, 2004. [17] WSLA. Web service level agreement language specification, 2003. [18] Z. Xu, P. Martin, W. Powley, and F. Zulkernine. Reputation-enhanced qos-based web services discovery. icws, 0:249–256, 2007.
