Reputation-Enhanced Web Services Discovery with QoS

Transcription

1 Reputation-Enhanced Web Services Discovery with QoS by Ziqiang Xu A thesis submitted to the School of Computing in conformity with the requirements for the degree of Master of Science Queen s University Kingston, Ontario, Canada August, 2006 Copyright Ziqiang Xu, 2006

2 Abstract With an increasing number of Web services providing similar functionalities, more emphasis is being placed on how to find the service that best fits the consumer s requirements. In order to find services that best meet their QoS requirements, the service consumers and/or discovery agents need to know both the QoS information for the services and the reliability of this information. The problem, however is that the current UDDI registries do not provide a method for service providers to publish the QoS information of their services, and the advertised QoS information of Web services is not always trustworthy. We propose a simple model of reputation-enhanced Web services discovery with QoS. Advertised QoS information is expressed in XML style format and is stored using tmodels in a UDDI registry. Services that meet a customer s functionality and QoS requirements are ranked using the service reputation scores which are maintained by a reputation management system. A service matching, ranking and selection algorithm is presented and evaluated. ii

3 Acknowledgments I would like to extend my sincerest thanks to my supervisor, Patrick Martin, for providing me with this opportunity. I would like to thank him for all his excellent guidance, precious advice and endless support over the years during my graduate study and research at Queen s University. I would also like to thank Wendy Powley for her excellent support and wonderful advice. I would like to acknowledge my lab mates, fellow students and friends who have provided endless inspiration during my stay at Queen s University. I would like to extend my gratitude to the School of Computing at Queen s University for their support. Finally, I would like to express my sincerest appreciation and love to my family and my wife, Katie, for all their help and support during these past few years. iii

4 Table of Contents Abstract Acknowledgements Table of Contents List of Tables List of Figures Glossary of Acronyms ii iii iv vii viii xi Chapter 1 Introduction Motivation Problem Research Statement Thesis Organization 8 Chapter 2 Background and Related Work Web Services Discovery Discovery: Registry, Index and P2P Approaches Manual versus Autonomous Discovery The UDDI Registry The Semantic Web and Ontology QoS and Web Services Discovery Storage of QoS Information in the UDDI Registry Researches on Web Services Discovery with QoS Web Services Reputation System Reputation-enhanced Web Services Discovery with QoS 22 iv

5 Chapter 3 Reputation-Enhanced Service Discovery with QoS UDDI Registry and QoS Information Publishing QoS Information Updating QoS Information Discovery Agent Reputation Manager Reputation Collection Storage of Service Ratings Computation of Reputation Score Dynamic Service Discovery Service Matching, Ranking and Selection Algorithm Service Matching, Ranking and Selection Service Matching, Ranking and Selection Algorithm 41 Chapter 4 Evaluation Evaluation of the Service Discovery Model Experimental Environment Test Scenarios Evaluation of the Matching, Ranking and Selection Algorithm Experimental Environment Generation of Service Ratings and Execution of Discovery Requests Selection of Inclusion Factor λ Simulation 1: QoS and Reputation Requirements Help Find Best Services 55 v

6 4.2.5 Simulation 2: Unstable Vs. Consistent QoS Performance Simulation 3: Selection of Services with Unstable QoS Performance Simulation 4: Effect of Inclusion Factor on Service Selection Summary of the Evaluations 73 Chapter 5 Conclusions and Future Work Thesis Contributions Conclusions Future Work 77 References 79 Appendix A: Service Matching, Ranking and Selection Algorithm 85 Appendix B: WSDL document of Web service XWeb Validation 90 vi

7 List of Tables Table 3.1 Example Ratings for a Service 34 Table 4.1 Summary of QoS and reputation information of Services 56 Table 4.2 Service QoS information 56 Table 4.3 Service price information 56 Table 4.4 Service reputation information 56 Table 4.5 Summary of QoS and reputation requirements of consumers 57 Table 4.6 Price and QoS information of services 60 Table 4.7 Summary of QoS and reputation requirements of consumers 62 Table 4.8 Summary of QoS information of service 65 Table 4.9 Summary of QoS and reputation requirements of consumer 67 Table 4.10 Summary of QoS information of service 68 Table 4.11 Summary of QoS and reputation requirements of consumer 68 vii

8 List of Figures Figure 1.1 Current Web services publish-find-bind model 2 Figure 1.2 Sample SOAP request message sent to XWeb Validation 2 Figure 1.3 Sample SOAP response message from XWeb Validation 3 Figure 2.1 UDDI core data structures 12 Figure 2.2 QoS Information on BindingTemplates 17 Figure 2.3 The tmodel with the QoS Information 18 Figure 3.1 Model of Reputation-enhanced Web Services Discovery with QoS 24 Figure 3.2 The tmodel with the QoS information 26 Figure 3.3 Service discovery request 28 Figure 3.4 Service discovery request with QoS and reputation requirements using SOAP 31 Figure 3.5 Service discovery response using SOAP 32 Figure 3.6 Steps of Service Publish Process 36 Figure 3.7 Steps of Service QoS Information Update Process 36 Figure 3.8: Steps of Service Discovery Process 37 Figure 3.9: Flow chart of the service matching, ranking and selection algorithm 42 Figure 3.10 High level part of the service matching, ranking and selection algorithm 42 Figure 3.11 Service QoS matching algorithm 43 Figure 3.12 Service QoS ranking algorithm 44 Figure 3.13 Service QoS and reputation ranking algorithm 45 Figure 3.14 Service selection algorithm 46 viii

9 Figure 4.1 Experiment of the service discovery model 49 Figure 4.2: Experimental environment for evaluation the matching, ranking and selection algorithm 52 Figure 4.3: Effect of λ on the reputation score 55 Figure 4.4 Service selection result of simulation 1 59 Figure 4.5 Rating and reputation of service 1 in each group (Simulation 2) 60 Figure 4.6 Rating and reputation of service 2 in each group (Simulation 2) 61 Figure 4.7 Rating and reputation of service 3 in each group (Simulation 2) 61 Figure 4.8 Rating and reputation of service 4 in each group (Simulation 2) 61 Figure 4.9 Service selection for customer 1 (Experiment 1, Simulation 2) 63 Figure 4.10 Service selection for customer 2 (Experiment 1, Simulation 2) 63 Figure 4.11 Service selection for customer 3 (Experiment 1, Simulation 2) 64 Figure 4.12 Service selection for customer 4 (Experiment 1, Simulation 2) 64 Figure 4.13 Rating and reputation of service 1 (Simulation 3) 65 Figure 4.14 Rating and reputation of service 2 (Simulation 3) 66 Figure 4.15 Rating and reputation of service 3 (Simulation 3) 66 Figure 4.16 Rating and reputation of service 4 (Simulation 3) 66 Figure 4.17 Service selection for the customer (Simulation 3) 67 Figure 4.18 Rating and reputation of service 1 (Experiment 1, Simulation 4) 69 Figure 4.19 Rating and reputation of service 2 (Experiment 1, Simulation 4) 70 Figure 4.20 Rating and reputation of service 3 (Experiment 1, Simulation 4) 70 Figure 4.21 Rating and reputation of service 4 (Experiment 1, Simulation 4) 70 Figure 4.22 Rating and reputation of service 1 (Experiment 2, Simulation 4) 71 ix

10 Figure 4.23 Rating and reputation of service 2 (Experiment 2, Simulation 4) 71 Figure 4.24 Rating and reputation of service 3 (Experiment 2, Simulation 4) 71 Figure 4.25 Rating and reputation of service 4 (Experiment 2, Simulation 4) 72 Figure 4.26 Service selection for the customer (Experiment 1, Simulation 4) 73 Figure 4.27 Service selection for the customer (Experiment 2, Simulation 4) 73 x

11 Glossary of Acronyms API DAML DARPA HTTP OWL QoS P2P SOAP UDDI UBR WSAF WSDL WSLA XML Application Programming Interface DARPA Agent Markup Language Defense Advanced Research Projects Agency HyperText Transfer Protocol Ontology Web Language Quality of Service Peer-to-Peer Simple Object Access Protocol Universal Description, Discovery, and Integration UDDI Business Registry Web Services Agent Framework Web Service Description Language Web Services Level Agreements Extensible Markup Language xi

12 Chapter 1 Introduction What are Web services and why do we need them? Web services are application components that communicate using open protocols such as HyperText Transfer Protocol (HTTP), Extensible Markup Language (XML) and Simple Object Access Protocol (SOAP). They are designed to support interoperable machine-to-machine interaction over a network [40]. Many companies provide Web services to customers. For example, Google Web APIs service [12] allows software developers to query billions of web pages directly from their own computer programs. A developer can use his or her favorite programming language, such as Java, Perl or Visual Studio.Net to develop applications that access the Google Web services. The current Web services architecture encompasses three roles: Web service provider, Web service consumer and Universal Description, Discovery and Integration (UDDI) registry [33], as shown in Figure 1.1. The Web service provider publishes a description of the service in the UDDI registry, as well as details of how to use the service. UDDI registries use Web Services Description Language (WSDL) [8], an XMLbased language, to describe a Web service, the location of the service and operations (or methods) the service exposes. The Web service consumer uses the UDDI to discover appropriate services that meet its requirements using the information provided by the services, chooses one service, and invokes the service. The Web service publishing, 1

13 discovery and binding process is generally done by consumers at design time, or through a discovery agent [24]. Figure 1.1 Current Web services publish-find-bind model [33] We give an example here to illustrate how a Web service is used. XWeb Validation [43] is a simple Web service that validates addresses for client applications. The WSDL document of the service, which can be found in Appendix B, shows only one operation is provided by this service: Validate with a string validate in as input and a string validate out as output. Figure 1.2 shows a sample SOAP request message sent to the service. The to be validated in the request is @mycompany.com. <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <Validate Request xmlns="urn:ws-xwebservicescom:xweb validation: validation:v2:messages"> < > @mycompany.com</ > </Validate Request> </soap:body> </soap:envelope> Figure 1.2 Sample SOAP request message sent to XWeb Validation [43] 2

14 Figure 1.3 shows a sample SOAP message from the service. The status of the is VALID. <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <Validate Response xmlns="urn:ws-xwebservicescom:xweb validation: validation:v2:messages"> <Status>VALID</Status> </Validate Response> </soap:body> </soap:envelope> Figure 1.3 Sample SOAP response message from XWeb Validation [43] The current UDDI registries only support Web services discovery based on the functional aspects of services [33]. However, customers are interested in not only the functionalities of Web services, but also their quality of service (QoS), which is a set of non-functional attributes (for example, response time and availability) that may have impact on the quality of the service provided by Web services [19][33][39]. If there are multiple Web services providing the same functionality in UDDI registries, the QoS requirement can be used as a finer search constraint. We propose a model of reputationenhanced Web services discovery with QoS to help consumers find the services that best meet their requirements. The following sections discuss the motivation, the problem and the goal of the research. 1.1 Motivation With an increasing number of Web services providing similar functionalities, more emphasis is being placed on how to find the service that best fits the consumer s 3

15 requirements. These are functional requirements, that is, what the service can do, and non-functional requirements, such as the price and quality of service guaranteed by a service. For example, a financial company is looking for a Web service to obtain real time stock quotes for its business management system. The target service must guarantee a service availability of more than 98% (QoS requirement), and the cost of each transaction should be no more than CAN $0.01 (price requirement). By manually searching the major UDDI Business Registries (UBRs), such as those provided by IBM, Microsoft and SAP, the company finds that there exist 20 Web services that provide real time stock quotes. After contacting the service providers, it is found that only 10 services satisfy the price requirement, and all of these 10 services claim that their service availability is above 98%. Which service should be chosen? Assuming that the QoS claims made by these service providers are trustworthy, the choice is simple, either the service with the lowest price, or the service providing the highest availability. The problem, however, is that the advertised QoS information of a Web service is not always trustworthy. A service provider may publish inaccurate QoS information to attract more customers, or the published QoS information may be out of date. Allowing current customers to rate the QoS they receive from a Web service, and making these ratings public, can provide new customers with valuable information on how to rank services. Service QoS reputation can be considered as an aggregation of service ratings for a service from consumers over a specific period of time. This provides a general and overall estimate of the reliability of a service provider. With service reputation taken into consideration, the probability of finding the best service for a customer can be increased. 4

16 1.2 Problem As mentioned previously, service customers manually search UBRs to find Web services that satisfy their functional requirements. If some suitable services are found, the customer must contact the service providers to obtain the QoS information, since this information is not provided in the UBRs. The customer manually selects from these services the one that best matches both the functionality and the QoS requirements. To achieve the goal of dynamic Web services discovery, which enables consumers to discover services satisfying their requirements automatically at run time [24], this process must be automated. There are two major problems in dynamic Web services discovery with QoS. The first involves the specification of QoS information. How should the QoS information be expressed and/or stored? A standard format must be agreed upon and used in order for the information to be exchanged and interpreted. The second problem is one of matching the customer s requirements with that of the provider. For example, if a customer is looking for services that matches its QoS requirements of 2ms response time, 400Kbps throughput and 99.9% availability, how can services be found whose QoS advertisement satisfies these requirements? Major efforts in this area include Web Services Level Agreements (WSLA) [15][16][17] by IBM, Web Services Policy Framework (WS-Policy) [5] by BEA, IBM and SAP, and the DARPA Agent Markup Language (DAML) Program [9]. These efforts have considerable industrial support. Most of these efforts represent a complex framework focusing not only on QoS specifications, but on a more complete set of aspects relating to Web services. Modeling and management of service level agreements 5

17 (WSLA), service invocation policy (WS-policy specifications) and semantic annotation (DAML-S specifications) are supported by these efforts [13]. Instead of using a complex framework, some researchers propose other simpler models and approaches [22][26][38] for dynamic Web services discovery. However, all of these efforts struggle with the same challenges related to QoS publishing and modeling, and/or QoS matching. In the current Web Services architecture, the UDDI registry stores descriptions about Web services in a common XML format and functions like a "yellow pages" for Web Services. However, the UDDI registry does not include QoS information. This information can be added to the UDDI, but the challenge of how to express and match the provider s QoS advertisements and the consumer s QoS requirements remains. Additionally, how can reputation be expressed and used to facilitate service selection? 1.3 Research Statement The goal of this research is to investigate how dynamic Web service discovery can be realized to satisfy a customer s QoS requirements using a new model that can be accommodated within the basic Web service protocols. We propose a simple model of reputation-enhanced Web services discovery with QoS. The motivation is to create a simple model at the level of standards such as WSDL and UDDI as opposed to a more complex model based on high-level WSLA or WS-Policy specifications. The current UDDI registries support only keyword-based search [32][42] to find Web services that satisfy a customer s functional requirements. This process is typically 6

18 done at design time and choosing a Web service is static and does not change during run time. Our interests lie not in the matching of functional requirements, but instead, in QoS and reputation-based matching during dynamic service discovery process at run time. We propose a Web services discovery model that contains a discovery agent and a reputation management system. Based on the customer s functional, QoS and reputation requirements, the discovery agent contacts the UDDI registry to discover Web services that match the given requirements. The agent then ranks the suggested services according to their advertised QoS information and/or reputation scores, which are maintained by a separate service reputation management system. The reputation management system is responsible for collecting and processing ratings of services from consumers, then updating the reputation score of the related service. We assume that the ratings are all trustworthy. We use technical models (tmodels) [36], a current feature in UDDI registries, to store advertised QoS information of services. A tmodel consists of a key, a name, an optional description and a Uniform Resource Locator (URL) which points to a place where details about the actual concept represented by the tmodel can be found. When a business publishes a Web service, it creates and registers a tmodel within a UDDI registry. The QoS information of the Web service is represented in the tmodel, which is referenced in a binding template [35] that represents the Web service deployment. We develop a service matching, ranking and selection algorithm that finds services that match a consumer s requirements, ranks the matches using their QoS information and reputation scores and selects services based on the consumer s preference in the service discovery request. 7

19 1.4 Thesis Organization The remainder of the dissertation is organized as follows. Chapter 2 outlines the related research conducted in the area of Web services discovery, service QoS and reputation. Chapter 3 describes the proposed reputation-enhanced Web service discovery with QoS. Chapter 4 presents evaluations of our service discovery model and matching, ranking and selection algorithm. It describes the simulations and then discusses a set of experiments. The thesis is summarized and future work is discussed in Chapter 5. 8

20 Chapter 2 Background and Related Work This section discusses work related to Web services discovery, and QoS and reputation-based discovery. We give a brief introduction to Web service discovery in Section 2.1 and the UDDI registry in Section 2.2. We present some previous work in the area of Semantic Web and ontology in Section 2.3. Section 2.4 describes QoS of Web services and related research on Web services discovery with QoS, while addressing how our work looks to further the progress towards service QoS publishing and modeling. Section 2.5 looks at work in the field of Web services reputation. Finally, Section 2.6 examines the issue of reputation-enhanced Web services discovery with QoS. 2.1 Web Services Discovery Web services discovery is "the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria" [40]. The goal is to find appropriate Web services that match a set of user requirements. A discovery service, which could be performed by either a consumer agent or a provider agent, is needed to facilitate the discovery process. There are three leading approaches [40] on how a discovery service should be designed: a registry, an index, or a peer-to-peer (P2P) system. Their differences are discussed in the following section. 9

21 2.1.1 Discovery: Registry, Index and P2P Approaches A registry is an authoritative, centrally controlled repository of services information. Service providers must publish the information of their services before they are available to consumers. The registry owner decides who has the authority to publish and update services information. A company is not able to publish or update the information of services provided by another company. The registry owner decides what information can be published in the registry. UDDI is an example of this approach. Centralized registries are appropriate in static or controlled environments where information does not change frequently. An index is a collection of published information by the service providers. It is not authoritative and the information is not centrally controlled. Anyone or any company can create their own index, which collects information of services exposed on the web usually using web spiders. The information in an index could be out of date but can be verified before use. Google is an example of the index approach [40]. P2P computing provides a de-centralized alternative that allows Web services to discover each other dynamically. Each Web service is a node in a network of peers. At discovery time, a Web service queries its neighbors in search of a suitable Web service. If any one of its neighboring peers matches its requirements, it replies and the query is ended. Otherwise, the query is propagated through the network until a suitable Web service is found or certain termination criteria are reached. P2P architecture is more reliable than registry approach since it does not need a centralized registry, but introduces more performance costs since most of time a node acts as a relayer of information. 10

22 2.1.2 Manual versus Autonomous Discovery Depending on who is actually performing the discovery, service discovery could be manual or autonomous. Manual discovery is typically done at design time and involves a human service consumer that uses a discovery service to find services that match its requirements. Autonomous discovery involves a discovery agent to perform this task at design time or run time. One situation in which autonomous discovery is needed is when a service consumer needs to switch to another service because the current service is either no longer available or cannot satisfy its requirements anymore. 2.2 The UDDI Registry The Universal Description, Discovery, and Integration, or UDDI, standard is the most dominating among the Web services discovery mechanisms discussed above [11]. A UDDI registry is a directory for storing information about Web services. A service provider makes its services available to public users by publishing information about the service in a UDDI registry. Individuals and businesses can then locate the services by searching public and private registries. For example, airlines can publish their fare services to a UDDI registry. Travel agencies then use the UDDI registry to locate Web services provided by different airlines, and to communicate with the service that best meets their requirements. The information about Web services in a UDDI registry includes a description of the business and organizations that provide the services, a description of a service s business function, and a description of the technical interfaces to access and manage those services [35]. A UDDI registry consists of instances of four core data structures 11

23 including the businessentity, the businessservice, the bindingtemplate and the tmodel. The four core structures and their relationships are shown in Figure 2.1. This information comprises everything a user needs to know to use a particular Web service. The businessservice is a description of a service s business function, businessentity describes the information about the organization that published the service, bindingtemplate describes the service s technical details, including a reference to the service s programmatic interface or API, and tmodel defines various other attributes or metadata such as taxonomy and digital signatures [37]. Figure 2.1: UDDI core data structures [35] 2.3 The Semantic Web and Ontology The current World Wide Web represents information using natural languages. The information is intended for human readers but not machines. The Semantic Web is an extension of the current Web in which information is given well-defined meaning, 12

24 enabling computers and people to work in better cooperation [2]. It is a mesh of information that can be automatically processed and understood by machines. The Semantic Web was devised by Tim Berners-Lee who invented the WWW, HTTP and HTML. The Resource Description Framework (RDF) [20] is a basic semantic markup language for representing information about resources on the Web. It is used in situations where the information needs to be processed by applications rather than humans. RDF Schema (RDF-S) [6] is a language for describing RDF vocabulary. It is used to describe the properties and classes of RDF resources. The Web Ontology Language (OWL) is used to publish and share sets of terms called ontologies, supporting advanced Web search, software agents and knowledge management [27]. It provides more vocabulary for describing properties and classes of RDF resources than RDF-S. OWL-S, the Web Ontology Language for Services [30], is an OWL based Web service ontology. It provides a language to describe the properties and capabilities of Web services. OWL-S can be used to automate Web service discovery, execution, composition and interoperation. WSDL is a XML document used to describe Web services [8]. It describes the location of a Web service and the operations the service provides. It defines a protocol and encoding independent way to describe interactions with Web services. One shortcoming of the current technologies of Web services, such as WSDL, SOAP and UDDI, is that they describe only the syntax but not semantics of services. By taking advantage of the strengths of both OWL-S and WSDL, Web service providers can describe their services in an unambiguous form that can be understood by computers [21]. 13

25 Ontology is defined as a specification of a conceptualization [14]. It uses a formal language, such as OWL, to describe the concepts and relationships in a domain. The main reason to use ontologies in computing is that they facilitate interoperability and machine reasoning [10]. A common ontology for Web services is the DAML-S ontology [7], which aims to facilitate automatic Web service discovery, invocation and composition. It describes properties and capabilities of Web services but does not provide details about how to represent QoS descriptions. A DAML-QoS ontology [45] is proposed as a complement for the DAML-S ontology. It describes QoS property constraints and presents a matchmaking algorithm for QoS property constraints. Zhou et al. [46] propose a QoS measurement framework based on the DAML-QoS ontology to check the service provider s compliance with the advertised QoS at run time. Papaioannou et al. [31] develop a QoS ontology that aims to formally describe arbitrary QoS parameters and support QoS-aware Web service provision. Maximilien and Singh [24] propose a QoS ontology for their framework for dynamic Web services selection. A QoS upper ontology that describes the basic characteristics of all qualities and a QoS middle ontology that specifies domain-independent quality concepts are presented in the paper. 2.4 QoS and Web Services Discovery Quality of Service, or QoS, is a combination of several qualities or properties of a service [29]. It is a set of non-functional attributes that may influence the quality of the service provided by a Web service [39]. Some examples of the QoS attributes are given below: 14

26 Availability is the probability that system is up and can respond to consumer requests. Generally it is slightly parallel to reliability and slightly opposite to capability. Capacity is the limit of concurrent requests a service can handle. When the number of concurrent requests exceeds the capacity of a service, its availability and reliability decrease. Reliability is the ability of a service to perform its required functions under stated conditions for a specific period of time. Performance is the measure of the speed to complete a service request. It is measured by latency (the delay between the arrival and completion of a service request), throughput (the number of requests completed over a period of time) and response time (the delay from the request to getting a response from the service). Cost is the measure of the cost of requesting a service. It may be charged per the number of service requests, or could be a flat rate charged for a period of time. The QoS requirements for Web services are more important for both service providers and consumers since the number of Web services providing similar functionalities is increasing. Current Web service technologies such as WSDL and UDDI, which are for publishing and discovering Web services, consider only customer functionality requirements and support design time, or static service discovery. Nonfunctional requirements, such as QoS, are not supported by current UDDI registries [24] Storage of QoS Information in the UDDI Registry 15

27 As a current feature in the UDDI registry, the tmodel is used to describe the technical information for services. A tmodel consists of a key, a name, an optional description and a Uniform Resource Locator (URL) which points to a place where details about the actual concept represented by the tmodel can be found [36]. tmodels play two roles in the current UDDI registries. The primary role of a tmodel is to represent a technical specification that is used to describe the Web services. The other role of a tmodel is to register categorizations, which provides an extensible mechanism for adding property information to a UDDI registry. Blum [3] [4] proposes that the categorization tmodels in UDDI registries can be used to provide QoS information on bindingtemplates. In the proposal, a tmodel for quality of service information for the binding template that represents a Web service deployment is generated to represent quality of service information. Each QoS metric, such as average response time or average throughput, is represented by a keyedreference [36], that is a general-purpose structure for a namevalue pair, on the generated tmodel. Blum gives an example of the bindingtemplate reference to the tmodel with the QoS attribute categories, and an example of the QoS Information tmodel, which contains a categorybag [36], which is a list of name-value pairs specifying QoS metrics. The two examples are shown in Figures 2.2 and 2.3 respectively. The example used in Figure 2.2 is one of a Stock Quote service. A tmodel with tmodelkey "uddi:mycompany.com:stockquoteservice:primarybinding:qosinformation" containing the QoS attribute categories is referenced in the bindingtemplate. In order to retrieve more detailed management information, the location of a WSDL description is stored in a keyed reference with tmodelkey "uddi:mycompany.com:stockquoteservice 16

28 :PrimaryBinding:QoSDetail", which is not shown in the figure. Figure 2.3 shows the tmodel that is referenced in the bindingtemplate in Figure 2.2. This tmodel contains a categorybag that specifies three QoS metrics of Average ResponseTime, Average Throughput and Average Reliability. The tmodelkey in each keyedreference is used as a namespace which provides a uniform naming scheme. <businessservice servicekey="uddi:mycompany.com:stockquoteservice" businesskey="uddi:mycompany.com:business> <name>stock Quote Service</name> <bindingtemplates> <bindingtemplate bindingkey="uddi:mycompany.com:stockquoteservice:primarybinding" servicekey="uddi:mycompany.com:stockquoteservice"> <accesspoint URLType="http"> </accesspoint> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey="uddi:mycompany.com:stockquoteservice:primary Binding:QoSInformation"> <description xml:lang="en"> This is the reference to the tmodel that will have all of the QOS related categories attached. </description> </tmodelinstanceinfo> <tmodelinstanceinfo tmodelkey="uddi:mycompany.com:stockquoteservice:primary Binding:QoSDetail"> <description xml:lang="en"> This points to the tmodel that has the reference to the web service endpoint that allows detailed retrieval of information </description> </tmodelinstanceinfo> </tmodelinstancedetails> </bindingtemplate> </bindingtemplates> </businessservice Figure 2.2: QoS Information on BindingTemplates [3] 17

29 <tmodel tmodelkey="mycompany.com:stockquoteservice: PrimaryBinding:QoSInformation"" > <name>qos Information for Stock Quote Service</name> <overviewdoc> <overviewurl> describing schema of QoS attributes> <overviewurl> <overviewdoc> <categorybag> <keyedreference tmodelkey="uddi:uddi.org:qos:responsetime" keyname="average ResponseTime" keyvalue="fast" /> <keyedreference tmodelkey="uddi:uddi.org:qos:throughput" keyname="average Throughput" keyvalue=">10mbps" /> <keyedreference tmodelkey="uddi:uddi.org:qos:reliability" keyname="average Reliability" keyvalue="99.9%" /> </categorybag> </tmodel> Figure 2.3: The tmodel with the QoS Information [3] Research on Web Services Discovery with QoS Many researchers work on how to take QoS information for Web services into account in the service discovery process to find services that best meet a customer s requirements. Ran [33] proposes a model in which the traditional service discovery model is extended with a new role called a Certifier, in addition to the existing three roles of Service Provider, Service Consumer and UDDI Registry. The Certifier verifies the advertised QoS of a Web service before its registration. The consumer can also verify the advertised QoS with the Certifier before binding to a Web service. This system can prevent service providers from publishing invalid QoS claims during the registration phase, and help consumers to verify the QoS claims to assure satisfactory transactions 18

30 with the service providers. Although this model incorporates QoS into the UDDI, it does not provide a matching and ranking algorithm, nor does it integrate consumer feedback into service discovery process. Gouscos et al. [13] propose a simple approach to dynamic Web services discovery that models Web service management attributes such as QoS and price. They discuss how this simple model can be accommodated and exploited within basic specification standards such as WSDL. The key Web service quality and price attributes are identified and categorized into two groups, static and dynamic. The Price, Promised Service Response Time (SRT) and Promised Probability of Failure (PoF) are considered as static in nature and could be accommodated in the UDDI registry. The actual QoS values that are the actual SRT and PoF are subject to dynamic updates and could be stored either in the UDDI registry or in the WSDL document, or could be inferred at run time through a proposed information broker. The advantage of this model is its low complexity and potential for straightforward implementation over existing standards such as WSLA and WS-Policy specifications. Maximilien and Singh [24] propose an agent framework and ontology for dynamic Web services selection. Service quality can be determined collaboratively by participating service consumers and agents via the agent framework. Service consumers and providers are represented and service-based software applications are dynamically configured by agents. QoS data about different services are collected from agents, aggregated, and then shared by agents. This agent-based framework is implemented in the Web Services Agent Framework (WSAF). A QoS ontology, which captures and defines the most generic quality concepts, is proposed in their paper. 19

31 Zhou et al. [45] propose a DAML-QoS ontology as a complement for the DAML- S ontology to provide a better QoS metrics model. QoS requirements and various constraints can be specified explicitly and precisely using this novel ontology. Although these works address some form of service discovery with QoS, none considers feedback from consumers. The result of service discovery and selection is based solely on advertised QoS, which may be invalid (in the one case though, advertised QoS is verified by the Certifier in the model proposed by Ran). 2.5 Web Services Reputation System QoS reputation can be considered as an aggregation of ratings for a service from consumers for a specific period of time. It is a general and overall estimate of how reliably a provider services its consumers. Compared to trust, which is the willingness to depend on something or somebody in a given situation with a feeling of relative security [28], reputation are public scores based on public information while trust are private scores based on both private and public information. Even if service consumers can obtain QoS advertisements from service providers in a service registry, one cannot be assured that the services found in the discovery process actually perform as advertised. However, with a reputation system, ratings of services can be collected and processed, and reputation scores of services updated. Services found to match a consumer s requirements can be ranked according to their reputation scores. This improves the possibility that the services that best meet user needs are selected, and ensures that the selected services are reliable. 20

32 Majithia et al. [18] propose a framework for reputation-based semantic service discovery. Ratings of services in different contexts, which either refer to particular application domains, or particular types of users, are collected from service consumers by a reputation management system. A coefficient (weight) is attached to each particular context. The weight of each context reflects its importance to a particular set of users. A damping function is used to model the reduction in the reputation score over time. This function, however, only considers the time at which a reputation score is computed, and ignores the time at which a service rating is made. This can result in a problem. For example, consider two services, X and Y. Service X provides an increasing quality of service over time, while the quality of service Y decreases. Assume the ratings for service X are (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12), and for service Y are (12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1), where each number represents the rating for one month and a higher number is a better rating. Obviously service X should obtain a higher reputation score because its performance is improving, while the performance of service Y is declining. However, with the damping function used by Majithia et al., service X and Y obtain the same reputation score. Wishart et al. [41] present SuperstringRep, a new protocol for service reputation. This protocol uses service reputation scores that reflect the overall quality of service in order to rank the services found in the discovery process. An aging factor for the reputation score is applied to each of the ratings for a service, thus newer ratings are more significant than older ones. The value of the factor is examined in the paper and small aging factors are found to be more responsive to changes in service activity while large 21

33 factors achieve relatively stable reputation scores. The value of the aging factor should depend on the demands of the service consumers and the reputation management system. Maximilien and Singh [23] propose a model of service reputation and endorsement. The reputation of a service is the aggregation of the ratings of the service by service consumers based on historic transaction records. New services that have no historical data can be endorsed by trustworthy service providers or consumers even before their reputation is established. No details are provided as to how the reputation score of a service is computed based on the consumers ratings and endorsements. Maximilien and Singh [25] also propose a multi-agent approach of service selection based on user preferences and policies. A matching algorithm is presented to match consumer policies to advertised provider service policies. Although reputation for the QoS is mentioned in the algorithm, no details regarding how the reputation affects the service selection process are provided. 2.6 Reputation-enhanced Web Services Discovery with QoS Although the approaches discussed previously pursue one or more aspects of Web services discovery with QoS, none of them address the issues of where and how the advertised QoS information is stored, and how it would be updated. If service discovery agents need to contact service providers to obtain the latest QoS information each time a discovery query is processed, then an extra burden is placed on service providers. If a discovery agent chooses to keep a local copy of QoS information for the service 22

34 providers, the agent must periodically contact the service providers to update its local QoS repository. In this case, it is unclear how the agent knows when the QoS information should be updated. In our proposed model, QoS information is stored in the UDDI registry and is updated by providers whenever there are changes. Service discovery agents can obtain the latest advertised QoS information directly from the UDDI registry without creating additional workload for service providers. When experiencing a lower QoS performance from a service than it expects, a consumer may send a service discovery request to the discovery agent to find if there are other services available that meet its requirements. Another critical issue that we examine is how the reputation of services affects the matching process. Previous approaches either do not consider QoS reputation or they do not provide details of how QoS reputation is specified in a customer s requirement nor how the reputation of services is used in the matching process. Our approach allows consumers to specify requirements on both QoS (including price) and reputation. A detailed service matching, ranking and selection algorithm is proposed that takes service reputation into account in the ranking process. 23

35 Chapter 3 Reputation-Enhanced Service Discovery with QoS The traditional Web services publish and discovery model has three roles: service provider, service consumer and UDDI registry. The UDDI registry is enhanced with QoS information, and two new roles, discovery agent and reputation manger, are added in our model as shown in Figure 1. The white boxes represent the existing roles in the current Web services architecture, as shown in Figure 1.1. The shaded boxes/circles represent the new roles in our model. The UDDI registry stores QoS information of services by using tmodels. The discovery agent acts as a broker between a service consumer, a UDDI registry and a reputation manager to discover the Web services that satisfy the consumer s functional, QoS and reputation requirements. The reputation manager UDDI Registry QoS QoS info. Reputation Manager Ratings Reputation Scores Discovery Request/Result Discovery Agent Service Info. Rating DB Service Consumer Request/Response Service Provider Figure 3.1: Model of Reputation-enhanced Web Services Discovery with QoS 24

36 collects and processes service ratings from consumers, and provides service reputation scores when requested by the discovery agent. 3.1 UDDI Registry and QoS Information The tmodel, a current feature of the UDDI registry, is used to store advertised QoS information of Web services. When a provider publishes a service in a UDDI registry, a tmodel is created to represent the QoS information of the service. It is then registered with the UDDI registry and related to the service deployment. When the provider need update the QoS information of the service, it retrieves the registered tmodel from the UDDI registry, updates its content and saves it with the same tmodel key Publishing QoS Information We discussed how to use the categorization tmodels in UDDI registries to represent QoS information in Chapter 2. W e apply the same technique in our service discovery model. When a business publishes a Web service, it creates and registers a tmodel within a UDDI registry. The QoS information of the Web service is represented in the tmodel, which is referenced in the binding template that represents the Web service deployment. Each QoS metric is represented by a keyedreference in the generated tmodel. The name of a QoS attribute is specified by the keyname, and its value is specified by the keyvalue. The units of QoS attributes are not represented in the tmodel. We assume default units are used for the values of QoS attributes in the tmodel. For example, the default unit used for price is CAN$ per transaction, for response time is second, for availability is percentage, and for throughput is transaction per second. 25

37 For example a company publishes its Stock Quote service in a UDDI registry with the following QoS information: Service price: CAN $0.01 per transaction Average response time: 0.05 second Availability: 99.99% Throughput: 500 transaction/second <tmodel tmodelkey="somecompany.com:stockquoteservice: PrimaryBinding:QoSInformation"" > <name>qos Information for Stock Quote Service</name> <overviewdoc> <overviewurl> describing schema of QoS attributes> <overviewurl> <overviewdoc> <categorybag> <keyedreference tmodelkey="uddi:uddi.org:qos:price" keyname="price Per Transaction" keyvalue=" 0.01" /> <keyedreference tmodelkey="uddi:uddi.org:qos:responsetime" keyname="average ResponseTime" keyvalue="0.05" /> <keyedreference tmodelkey="uddi: uddi.org:qos:availability" keyname="availability" keyvalue="99.99" /> <keyedreference tmodelkey="uddi:uddi.org:qos:throughput" keyname=" Throughput" keyvalue="500" /> </categorybag> </tmodel> Figure 3.2: The tmodel with the QoS information The company creates and registers a tmodel that contains the QoS information for this service before it publishes the service with the UDDI registry. An Application 26

38 Programming Interface (API) to the UDDI registry, such as UDDI4J [34], may be used to facilitate the service publishing process. Figure 3.2 shows an example of this tmodel. With QoS information of Web services stored in tmodels in a UDDI registry, service consumers can find the services that match their QoS requirements by querying the UDDI registry. The details of this process are discussed in the following sections Updating QoS Information It is the right and responsibility of Web services providers to update the QoS information in the UDDI registry. Only a service provider that publishes a service and its QoS information in a UDDI registry has the right to modify and update the QoS information. A service provider should also update the QoS information of the services it publishes frequently to ensure that the QoS information is accurate and up to date. An API to the UDDI registry, such as UDDI4J mentioned previously, may be used to facilitate the process of updating QoS information. A service publisher searches the UDDI registry to find the tmodel that contains QoS information for the service it published before, updates the QoS information in the tmodel, and then saves the tmodel with the same tmodelkey assigned previously for the tmodel to update the QoS information of the service. 3.2 Discovery Agent A discovery agent receives requests from service consumers, finds the services that match their requirements and then returns the matches to the consumers. Functional, QoS, and reputation requirements can be specified in the discovery request. The detail of 27

39 how to specify functional, QoS and reputation requirements in the request, and how to find services that match the requirements are discussed in this section. <?xml version="1.0" encoding="utf-8"?> <envelope xmlns=" <body> <find_service generic="1.0" xmlns="urn:uddi-org:api"> <functionalrequirement> Keywords in service name and description </functionalrequirement> <qualityrequirement weight=qos Weight> <dominantqos>dominant QoS</dominantQoS> <QoS attribute 1>Value</QoS attribute 1> <QoS attribute 2>Value</QoS attribute 2> <QoS attribute 3>Value</QoS attribute 3> <QoS attribute n>value</ QoS attribute n> </qualityrequirement> <reputationrequirement weight=reputation Weight> <reputation>reputation Score</reputation> </reputationrequirement> <maxnumberservice>value</maxnumberservice> </find_service> </body> </envelope> Figure 3.3: Service discovery request Figure 3.3 shows the SOAP message for a discovery request in the general form. The strings in bold are replaced by corresponding values of an actual discovery request. Customers need not manually generate the SOAP messages for discovery requests. Developers can specify QoS and reputation requirements in a Java program that automatically generates required SOAP messages sent to the discovery agent. As Figure 3.3 shows, customers can specify the following in the discovery request: The maximum number of services to be returned by the discovery agent Functional requirements: keywords in service name and description 28