Trust Management for Service-Oriented Environments

ETrust E Management for Service-Oriented Environments “This page left intentionally blank.” Zaki Malik • Athman Bou...

Author: Zaki Malik | Athman Bouguettaya

21 downloads 830 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

ETrust E Management for Service-Oriented Environments

“This page left intentionally blank.”

Zaki Malik • Athman Bouguettaya

Trust Management for Service-Oriented Environments

Zaki Malik Department of Computer Science Wayne State University 456 State Hall 5143 Cass Avenue Detroit, MI 48202 USA [email protected]

Athman Bouguettaya CSIRO ICT Center Australian National University Computer Sci. & Information Tech. Bldg. North Road Canberra, ACT 2601 Australia [email protected]

ISBN 978-1-4419-0309-9 e-ISBN 978-1-4419-0310-5 DOI 10.1007/978-1-4419-0310-5 Springer New York Dordrecht Heidelberg London Library of Congress Control Number: 2009934434 © Springer Science+Business Media, LLC 2009 All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights.

Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

To all my family and friends. Zaki Malik


To my parents. Athman Bouguettaya


Foreword

Web services and service oriented environments are key enablers for the migration of entertainment, business, sociability, science and health-care from the physical world to the virtual world. The result of this on-going migration is a new “place” very much different from the physical world, one where interconnected services interact with human users, sensors and embedded devices. Yet for this vision to become reality, trust needs to be addressed as members of the global e-society regularly today deal with the question whether they can trust other, unknown parties. Trust is a vital component of internet-based interactions and service-oriented environment, but all too often it is assumed to be an implicit property that exists in the background rather than being an explicit property that is well-defined and quantifiable. While providing trust is challenging in existing computing systems, providing trust in service oriented environments is much more complex due to the dynamic and adaptable nature of these environment which are often large scale and across domains. To date the problem of trust for service oriented environments has been largely unexplored. This book represents the first comprehensive coverage of the principles, methods and systems for trust management and evaluation in service oriented environments. The book provides the key relevant foundations by looking at regulations and common practices, which that are the traditional solutions for establishing trust, and then discussing departures from these conventional solutions. The central part of the book is devoted to reputation-based approaches to trust. Reputation techniques are the most widely used techniques for assessing whether parties in a distributed open system can be trusted. The book provides a well organized systematic treatment of reputation, by organizing the presentation according a notion of reputation life cycle. Based on this notion, the book discusses all aspects related to reputation management from the creation of reputation information to reputation assessment. The book also provides a comprehensive coverage of the robustness of the various reputation techniques and an assessment of their performance. Techniques and systems are described in detail and illustrated with extensive examples. This book is an invaluable reference for researchers in academia and industry who are interested in getting acquainted with the foundations of trust for service ix

x

Foreword

based environments and in exploring open research directions in this important area. Practitioners will find in the book information on recent trends about technology and tools for reputation which will help them in understanding the potential practical applications of this technology. West Lafayette, IN. USA May 2009

Elisa Bertino

Preface

Service Computing holds the promise of transitioning the field of IT to levels of efficiencies and globalization never reached before. The ideal space of operation is without any doubt the Web, where data, documents, and tools/applications are expected to be uniformly represented and managed through the prism of services. The objective is to be able to leverage the vast array of data and applications in the most cost effective way while providing more opportunities for leveraging previous investments. The standardization efforts have played a key role leading to the early adoption of services as the paradigm of choice for IT investments. However, much remains to be done in terms of providing a robust and efficient infrastructure to manage the whole life-cycle of services. Unfortunately, this is mainly due to “over-standardization” efforts. The last few years have seen too many standards, in many cases competing; springing up from various standards bodies to deal with specific and sometimes narrow requirements of service management, organization, and use. This unfortunate situation has created confusion in the targeted markets and stifled innovation in what could be considered as a potentially revolutionizing field. Additionally, this state of affairs had the effect of hampering the wide and speedy deployment of service-oriented solutions. Service computing is undoubtedly the latest emerging paradigm in the computing “food chain”. Computing has gone through several key stages since the first modern computer was designed. Each computing period was governed by a paradigm. For instance, when meaning was added to the data paradigm, the information paradigm was born. When reasoning was added to information, this led to the transition to the knowledge paradigm. The argument is that we are now transitioning to a new paradigm, called “service”, that is result of adding action to “knowledge”. This in effect means that services can be thought of knowledge that is acted upon. It is noteworthy pointing out that each paradigm was supported by a management system that was usually the result of intense research efforts. Our argument is that the time has come to build a foundation for next-generation service management systems using Web services as the technology that embodies that the service paradigm. We propose laying the foundation of the Web Service Management System (WSMS). We identify four core components in a generic WSMS: service composition, service xi

xii

Preface

optimization, service change, and service trust. This book provides a comprehensive analysis on service trust focusing on reputation as a mechanism to implement trust among services. Deploying services on the Web which can be queried and composed requires a dynamic trust infrastructure that adapts to the Web fluctuations and the inherent lack of any single authority. Reputation techniques are well suited to deal with the distrusted and dynamic nature of the Web, coupled with the lack of any single authority for providing trust credentials and enforcement. This book covers entire aspects of reputation that include issues related to reputation bootstrapping, credential gathering and computation, interaction models, composed reputation, and reputation propagation, among other issues. The book provides a holistic treatise of reputation management in service-oriented environments, which includes analytical models and experiments to assess the proposed solutions. Detroit, MI. USA Canberra, Australia May 2009

Zaki Malik Athman Bouguettaya

Acknowledgments

Two persons who deserve most thanks are my mother and father. I would like to thank them for everything they have provided. Their unwavering love and affection has been instrumental in all aspects of my life. I am also indebted to my wife for her support and encouragement. She has helped me through happy and hard times to stay focused. I thank her for all her patience. I would like to thank my daughter, Ayra, for making my life more joyful. I would also like to thank my sister and her family for all their love. Special thanks goes to my brother, Safi, for continuous encouragement and support in all matters concerning me. He always pushed me to be the best and never hesitated to provide me with the necessary help. My everlasting thanks ! Zaki Malik

I would like to acknowledge the support of my family during the preparation of this book: my wife Malika, my children: Zakaria, Ayoub, and Mohamed-Islam. I would also like to thank my employer CSIRO (Australia) for providing me the environment to successfully finish this work. Athman Bouguettaya

xiii


Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Trust Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.3 Traditional Solutions for Establishing Trust . . . . . . . . . . . . . . 6 1.2 The Role of Reputation in Trust Management . . . . . . . . . . . . . . . . . . . 9 1.3 Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Book Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2

Service-Oriented Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 SOE Interaction Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Entities and Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Service Interactions: Extension through Ontologies . . . . . . . . . . . . . . 2.2.1 Definition of Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Operational Description of Communities . . . . . . . . . . . . . . . . 2.2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 14 14 18 19 22 28

3

Reputation Information Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Parameters Reflecting the Quality of Web Services . . . . . . . . . . . . . . . 3.2 Reputation Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Option I: Adapting Initial Reputation to Majority Behavior . 3.2.2 Option II: Assigned Initial Reputation . . . . . . . . . . . . . . . . . . .

31 31 34 36 38

4

Reputation Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Web Service Reputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Reputation Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Credibility of Raters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Evaluating Rater Credibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Personalized Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Temporal Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 First-hand Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 43 45 46 47 52 52 53 xv

xvi

Contents

4.3 Reputation Assessment with Scarce Ratings . . . . . . . . . . . . . . . . . . . . 55 4.4 Reputation Assessment for Service Compositions . . . . . . . . . . . . . . . . 60 4.4.1 Share the Fame / Share the Blame . . . . . . . . . . . . . . . . . . . . . . 62 5

Robustness and Performance Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1 Reputation Bootstrapping Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1.1 Comparing Bootstrap Approaches . . . . . . . . . . . . . . . . . . . . . . 69 5.1.2 Evaluating the Adaptive Approach . . . . . . . . . . . . . . . . . . . . . . 70 5.1.3 Comparing the Reputation Assignment Approaches . . . . . . . 72 5.2 Rater Credibility Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1 Honest Raters in Majority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2.2 Equal Number of Honest and Dishonest Raters . . . . . . . . . . . 76 5.2.3 Dishonest Raters in Majority . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.3 RATEWeb Evaluation and Comparison . . . . . . . . . . . . . . . . . . . . . . . . 79 5.3.1 Honest Raters in Majority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.3.2 Equal Number of Honest and Dishonest Raters . . . . . . . . . . . 82 5.3.3 Dishonest Raters in Majority . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.3.4 Case of Optimistic Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.5 Case of Pessimistic Consumer . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.3.6 Measuring Transaction Success . . . . . . . . . . . . . . . . . . . . . . . . 87 5.3.7 Changing Rate of Maliciousness . . . . . . . . . . . . . . . . . . . . . . . 88 5.4 Reputation Assessment with Scarce Ratings . . . . . . . . . . . . . . . . . . . . 90 5.4.1 HMM vs ANN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.4.2 No Prediction or Personal Experience Input . . . . . . . . . . . . . . 93 5.4.3 No Prediction but Including Personal Experience . . . . . . . . . . 93 5.5 Composed Services Reputation Evaluation . . . . . . . . . . . . . . . . . . . . . 94 5.5.1 Fuzzy Rules for Composition Reputation . . . . . . . . . . . . . . . . 94 5.5.2 Blame Propagation Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.5.3 Choosing a Blame Forwarding Strategy . . . . . . . . . . . . . . . . . 97 5.5.4 Impact of Orchestrator’s Decision . . . . . . . . . . . . . . . . . . . . . . 99 5.5.5 Blame Forwarding Impact in Relation to Maliciousness . . . . 100 5.6 Reputation Assessment Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.6.1 Model Performance Comparison . . . . . . . . . . . . . . . . . . . . . . . 104 5.6.2 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6

Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.1 Reputation Systems for E-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.1.1 Incentives-based Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.1.2 Credibility-based Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.2 Decentralized Reputation Management . . . . . . . . . . . . . . . . . . . . . . . . 110 6.2.1 Peer-to-Peer Reputation Systems . . . . . . . . . . . . . . . . . . . . . . . 110 6.2.2 Reputation Management on the Grid . . . . . . . . . . . . . . . . . . . . 113 6.2.3 Reputation Management for Multi-Agents Systems . . . . . . . . 114 6.3 Reputation in Game Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.4 Reputation Management for the Web . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Contents

xvii

6.4.1 Search Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.4.2 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.5 Reputation in Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135


Acronyms and Abbreviations

ANN Artificial Neural Network BIC Bayesian Information Criterion BPEL Business Process Execution Language B2B Business-to-Business B2C Business-to-Consumer BSR Bootstrap Success Rate BWA Baum-Welch Algorithm CB Car Broker Web service CD Car Dealer Web service CH Credit History Web service CORBA Common Object Request Broker Architecture Cr (tx ) Credibility of Service Rater tx D Defective transaction FI Financing Web service HMM Hidden Markov Model HTML HyperText Markup Language HTTP HyperText Transfer Protocol IN Insurance Web service LC Lemon Check Web service M Majority Rating OpSign Operational Significance OWL Web Ontology Language ρ Pessimism Factor P2P Peer-to-Peer PerEval Personal Evaluation PSL Privacy Significance Level QoWS Quality of Web Service ℜ Rate of Maliciousness RATEWeb Reputation Assessment for Trust Establishment among Web services RMS Reputation Management System RSV Reputation Significance Vector xix

xx

SOAP SOC TP Uf UDDI URI V VE WSDL WSMS XML

Acronyms and Abbreviations

Simple Object Access Protocol Service-Oriented Computing Trip Planner Enterprise Usefulness Factor Universal Description Discovery and Integration Uniform Resource Identifier Current Reported Rating Virtual Enterprise Web Service Definition Language Web Service Management System Extensible Markup Language

Chapter 1

Introduction

The Web was originally created to enable the sharing of information among scientists. Sir Tim Berners-Lee first proposed the idea of creating a “Web of information” when he suggested a solution to integrate three technologies: HTML (HyperText Markup Language), HTTP (HyperText Transfer Protocol), and Web browsers [131]. HTML was proposed as a language to write Web documents. HTTP was proposed as a protocol to transmit Web pages. Web browser software clients were introduced to receive, interpret and display information. Initially, the Web was mainly perceived as a “worldwide bulletin board,” with data sharing and reuse as its prime objectives. Soon after, governments, businesses, and individual users took active interest in the Web by publishing and accessing information of interest. This resulted in voluminous amount of data potentially accessible to millions of users. Consequently, effective techniques and tools were required to retrieve quality information from the Web. Over the years, numerous applications have been developed for efficient data access and reuse. These data-centric solutions were based on the premise of an “interactive” Web where users’ involvement was necessary for virtually any Webbased transaction. In recent years, Web-related research has shifted from how to access such Web content to exploring new forms of what can be published and accessed in the Web. Application reusability is key to enabling this paradigm shift. The Web that had been essentially a repository of static content has started a steady evolution to become a “vibrant” environment where applications can be automatically invoked by other Web clients. These advances have brought revolutionary changes in building distributed applications [125] with the introduction of the Service Oriented Computing (SOC) paradigm. The service-oriented Web represents an attractive paradigm for tomorrow’s interactions spanning a wide range of domains from e-economy to e-science and e-government. For example, enterprises in the new Service Web would no longer represent single monolithic organizations, but rather be a loose coupling of smaller applications offered by autonomous providers. A key milestone in this regard has been the introduction of Web services. A Web service is an autonomous platform-independent computational element that can be described, published, discovered, orchestrated and programmed using standard proZ. Malik and A. Bouguettaya, Trust Management for Service-Oriented Environments, DOI 10.1007/978-1-4419-0310-5_1, © Springer Science + Business Media, LLC 2009

1

2

1 Introduction

tocols for the purpose of building agile networks of collaborating applications distributed within and across organizational boundaries [106]. Web services have also been defined as: • A Web service is a “stand-alone application accessible over the Web that can be automatically discovered and invoked by applications (and humans)” or a “loosely coupled application using open, cross-platform standards and which inter-operate across organizational and trust boundaries” [132]. • A Web service is a “business function made available via the Internet by a service provider, and accessible by clients that could be human users or software applications” [26]. • A Web service is a set of related functionalities that can be programmatically accessed and manipulated through the Web. More precisely, a Web service is a self-describing software application that can be advertised, located, and used across the Web using a set of standards such as WSDL, UDDI, and SOAP [106]. Web services are being adopted by businesses, government agencies, and scientific communities [71] [28]. Businesses are increasingly using Web services to automate their interactions both with their customers (B2C) and each other (B2B). Web services enable businesses to outsource some of the required functionality to other businesses resulting in a service-oriented enterprise[12] [6]. For example, B2B integration through service composition, allows multiple services from different providers to be combined into a value-added composite service [99] [60]. In e-government, work on several research prototypes (e.g., our own WebDG, WebSenior [21, 98], ARGOS [50]) has shown the viability of the Web service approach in providing e-government services. Web services are also being introduced into several established and emerging research areas. Examples include mobile computing [148], grid computing [129] (e.g., the Open Grid Services Architecture (OGSA) [47]) and statistical sciences (e.g., NISS WebSwap [118]). A plethora of Web services competing in offering similar functionalities are expected for the new “service Web”. A key requirement then is to provide mechanisms for the quality access and retrieval of services. In essence, the major challenge lies in providing a trust framework for enabling the selection and composition of Web services based on trust parameters. The fundamental rationale behind the need for trust is the necessity to interact with unknown entities. The lack of a global monitoring system for the service-oriented environment exacerbates the problem of trust. By definition, Web services are autonomous (i.e., provided by independent service providers), highly volatile (i.e., low reliability), and a priori unknown (i.e., new or no prior history) [99] [106]. Web services can have no particular behavior mandated on them and are highly volatile as they are subject to frequent fluctuations during their lifetime (e.g., unavailability, changes in quality and performance). The inherent open and large-scale nature of Web services means that traditional security approaches cannot aid in instilling trust in service-oriented environments completely. There is a growing consensus that the Web service ‘revolution’ would not eventuate until trust related issues are resolved [18]. Several studies have shown that the lack of trust is the most important reason behind people’s reluctance in us-

1 Introduction

3

ing the Web in risk-involving transactions. For many emerging applications, such as e-government, e-commerce, and e-science, Web services will have to automatically determine to which extent they may trust other services before they interact. Hence, resolving trust issues will be a determining key to optimizing the selection of services. Similarly, trust would be a key criterion to ascertaining privacy preservation in Web service selection. Research results show that reliable reputation systems increase users’ trust in the Web [34]. Many online businesses have recognized the importance of reputation systems in improving customers’ trust and, consequently, stimulating sales [112]. Examples include Ebay and Amazon. In fact, managing reputation has itself become a Web business. Examples of online companies whose prime vocation is reputation collection and dissemination include Bizrate, Epinions, Citysearch [34]. Reputation systems are particularly vital in online marketplaces, also known as C2C e-auctions. Many of these marketplaces would probably not have survived without reputation systems [34]. Several studies have investigated and, generally, confirmed that, in these types of business environments, reputation systems benefit both sellers and buyers [69] [74]. Reputation is also important in achieving properties of Web-based interaction that traditional security mechanisms do not ensure. Security mechanisms, e.g., encryption, authorization, authentication enable a provably secure interaction between Web services and their service requesters. They, however, do not provide the type of functionalities that reputation mechanisms provide. For example, authentication only ensures that a party x is actually the party it claims it is and does not provide any indication or prediction on the quality of the outcome of interacting with that party. Also, authorization only ensures that a given party has the credentials to take a given action. It does not ensure that that party is actually the “best” that can take that action [124]. We anticipate that the deployment of reputation systems will have a significant impact on the growth of the different emerging applications such as e-business, e-government, and e-science. Research on reputation is currently gaining an increasing momentum. Different aspects of reputation are being investigated in various disciplines including economics, computer science, marketing, law, sociology, and psychology [34, 140, 23, 112, 10, 116, 20, 76, 151, 145]. Despite the abundance in reputation-related literature, little research has focused on the reputation of Web services for establishing trust. An exception is the work in [92] where the authors present an interesting model where agents disseminate reputations and endorsements for Web services through a specialized agency. Clearly, such a solution that depends on a central authority presents scalability and trust challenges. The reputation-based trust model in [95] requires human participation for rating Web services. Agents that report reputation ratings are also assumed to be trusted parties. Similarly, the common agencies to whom these ratings are communicated for sharing/aggregation are also expected to behave honestly. We propose to address the above issue in this book. For example, we calculate the reputation of a Web service based on the testimonies of both trusted and malicious raters. Another feature that seems to be at least implicitly overlooked in the previous models, but that we plan to use in assessing reputation, is the incorporation of “local historical information” with the “global reputation view.”

4

1 Introduction

In this book, the objective is to investigate approaches and techniques for reputation management on the service Web. Our research aims to provide a Reputation Management System (RMS) as an efficient trust framework for the trustworthy selection and composition of Web services. Our focus is a service-oriented environment where Web services can act as both consumers (i.e., requesters) and providers of services. The resulting architecture will reflect this mode of interactions. In this regard, we will construct a formal framework and evaluation methodology for reputation-based Web services interactions. In the following, we present a thorough problem discussion. We first discuss the significance of trust in online interactions. We then discuss the traditional solutions for establishing trust and show how these may not provide a comprehensive solution for the service Web. This is followed by a discussion on the role of reputation in trust management. An example scenario is presented towards the end for better understanding.

1.1 Trust Management In this section, we present the motivation for our work. Specifically, we discuss the significance of establishing trust on the service Web. We also provide an insight into the traditional solutions for establishing trust and show how these solutions fall short of addressing the problem of trust on the service Web.

1.1.1 Motivation The last decade has seen explosive growth in the number of “Web users.” The Web is slowly becoming the preferred medium for a myriad of activities. These include but are not limited to: getting news, buying and selling of goods and services (e.g. travel services offered by Expedia, Priceline, Orbitz, etc), research, e-learning, egovernance, resource utilization, etc. Online communities and marketplaces have thus gained popularity as they are not limited by geographical and spatial constraints. Moreover, these communities encourage interactions between complete strangers (often based on prior interaction history). To name a few, Ebay, Yahoo Auctions and the Amazon marketplace have fostered such interactions between unfamiliar participants. However, such interactions involve an element of risk: namely fraudulent behavior. Both providers and consumers face this risk. Fraudulent behavior on part of the provider includes inconsistent delivery of goods or services promised, not delivering the promised commodity, or delivering a sub-standard item or service. Similarly, the consumer may engage in fraud by not paying, providing false details of the interaction for damaging the provider, etc. The success of current systems mentioned above (that support interactions between unknown participants) stems from the fact that these systems are centrally

1.1 Trust Management

5

managed. The central authority acts as an intermediary to facilitate the coordination, communication and cooperation between the participants. However, online interactions are no longer limited to centralized systems. The advent of technology and the growth of the Web has resulted in highly decentralized, self-organizing and autonomous systems. The “service Web” is expected to be decentralized, where a large spectrum of applications will become available in the form of “services.” Web services would often have to interact with other unknown entities on the service Web. Since the services would be mutually unfamiliar, the decision to engage in a transaction with another Web service (i.e., the process of service selection) would not be based on any prior “first-hand” knowledge. This naturally makes it challenging to establish, a priori, whether and to which extent a given service may be entrusted to carry out the required functionality. Solving this dilemma is the main objective of our work. Specifically, our research aims at establishing trust between Web service consumers and Web service providers.

1.1.2 Trust Trust has been defined as “an assured reliance on the character, ability, or strength of someone or something.” Establishing trust is therefore a precondition for any transaction [70]. In a service-oriented environment, trust correlates to the ability of a service to perform the required functionality in an acceptable manner. However, the incentives for establishing trust differ according to the role (consumer or provider) a Web service undertakes. For instance, the key incentive to establish trust for a service acting as a consumer is risk reduction. Trust reduces the uncertainty associated with any interaction. It enables the services’ clients to make “informed” decisions about the expected behavior of the provider service. From the service provider’s perspective, the prime incentive to establish consumers’ trust in its service is to establish/increase/maintain its client base. Since the possibility of self-interested and malicious services cannot be overlooked, the cooperation among services relies on the production of trust. Moreover, the individual (perhaps malicious) motives driving service behavior to maximize benefits may tempt a service to defect. Hence, service-oriented environments need to build trust mechanisms that help in answering the question of whom to trust and whom not to, before undertaking a transaction. As we march towards the service Web, Web services will increasingly be the central building blocks in a large spectrum of Web applications. The share of the service Web segment of the Web will become more important. In particular, Web services will be the major enabling technology for B2B interoperability and integration. This will readily extend the service Web to the biggest component of the Web economy: the B2B e-commerce market. According to a report from IDC, worldwide spending on software in support of Web services-based projects will reach $11 billion by 2008. In 2003, this number was only $1.1 billion [62]. Organizations will increasingly provide Web services that will substitute their traditional Web-based interaction with their audience. Many of these services will handle sensitive infor-

6

1 Introduction

mation. The consequence is that establishing trust will become a key requirement for Web services.

1.1.3 Traditional Solutions for Establishing Trust Figure 1.1 shows four major approaches that have been adopted to enable trustbased interactions on the service Web: (i) regulation, (i) self regulation, (iii) thirdparty certification, and (iv) security technologies. These approaches have attempted to attenuate consumers’ mistrust towards service providers. However, they have achieved little success in closing the trust gap between providers and their consumers. The following discussion elicits the insufficiency and/or inadequacy of these approaches for the service Web. We will use an example to illustrate the main points of our discussion. Assume that PharmacyOne is an online pharmacy that sells brand and generic drugs. PharmacyOne does not actually possess drugs but, orders them on behalf of its customers, from other online pharmacies. Purchasing a drug from PharmacyOne is a four-step process. First, a customer accesses PharmacyOne’s Web site to order one or more drugs. The customer specifies the drugs that he/she wants to purchase, the quantities, and his/her location. PharmacyOne then automatically invokes a number of Web services provided by other online pharmacies. The request that PharmacyOne submits to each of these services includes the name and quantities of the drug(s) to be ordered and the zip code of the customer to which the drug(s) would be delivered. The Web service of each of the pharmacies answers PharmacyOne’s request by a response that includes the amount which that pharmacy would charge PharmacyOne for delivering the drug(s) to the customer. PharmacyOne then selects the “best” offer, adds its overhead and profit, and displays the result to the customer. If the customer submits a purchase order, PharmacyOne sends the customer’s delivery information (name, address, phone) to the selected pharmacy along with the payment for that transaction. PharmacyOne’s business model is known to its customers. However, to maintain its competitive edge, PharmacyOne does not reveal the identity of its suppliers to its customers. This example highlights the following issues: • When selecting the best provider, PharmacyOne typically chooses the one offering the least price. This requires that PharmacyOne must trust the provider’s commitment and ability to (i) deliver the requested drugs to the customer within the promised delays, and, more importantly, (ii) handle the customer’s information according to a privacy policy that does not violate PharmacyOne’s commitment to the customer. • Customers do not know which pharmacy will provide the drugs. A customer’s consent to the transaction assumes a transitive trust model, i.e., the customer trusts PharmacyOne and any party that PharmacyOne trusts. The trust chain may obviously include further links.

1.1 Trust Management

7

• Customers’ trust in PharmacyOne depends on their perception of how it’s suppliers fulfill the orders. In particular, violation to a customer’s privacy that may be linked to a prior transaction with PharmacyOne would have a direct impact on his/her trust in PharmacyOne. Therefore, PharmacyOne must be able to accurately assess the trustworthiness of its suppliers. It must be able to determine to which extent each supplier is responsible for the aggregated (dis)trust that a given customer has in PharmacyOne. We now elaborate on the two major factors justifying the proposed research, namely, the inadequacy of traditional trust solutions and the theoretical and experimental evidences for the viability of reputation-based approaches as ascertained in other contexts:

Fig. 1.1 Traditional Trust Approaches

1.1.3.1 Regulations The emergence of the Web has enabled a new type of across-country business transactions. In these transactions, it is difficult to enforce contracts by law. This is more so when these transactions involve Web services. For example, consider a European citizen purchasing a drug from the US-based PharmacyOne of the earlier example. PharmacyOne selects an Asia-based drug supplier to fulfill the request of that citizen. Assume that the provider of the Asia-based service violates the EU citizen’s privacy by selling his/her personal information to an Australian drug maker. In this case, it is difficult for the citizen to know that his/her privacy was violated. The laws that are applicable in one country may not be applicable in the other. More importantly, even if the privacy violation is detected, no explicit global privacy reg-

8

1 Introduction

ulation exists to establish responsibilities and repress violators. Overall regulations are therefore not enforceable on the service Web. 1.1.3.2 Self Regulation In self regulation, service providers present a set of commitments to their consumers. The providers are themselves the authors of these commitments that they advertise to the services’ consumers. The provider of a service may or may not implement those commitments. Moreover, providers may unilaterally change their commitments. These changes may be retrospective, i.e., be applicable to past interactions. It is therefore not possible to establish trust based on a service provider’s commitment. This simple approach was not effective on the traditional Web and it is likely to be less effective on the service Web. Service consumers would have no rationale to trust claims presented by unknown service providers if they are not able to check the validity of those claims. 1.1.3.3 Third-party Certification In third-party certification, service providers get certified by a third party that is, normally, known and trusted by consumers. This approach clearly does not scale to the service Web. The number of Web services, their workflow’s opacity, potential transience, and dynamic composability are factors that make this approach not feasible on the service Web. For example, assume that the service PharmacyOne gets certified by a third party. PharmacyOne’s partners, however, may or may not be certified. It is not easy for PharmacyOne’s consumers to determine to which extent they may trust PharmacyOne, as their interaction with PharmacyOne may involve partners that are not certified. 1.1.3.4 Security Technologies Security solutions focus on protecting individuals and organizations from outsider attacks. But security mechanisms, e.g., encryption, authorization, authentication, are not sufficient to establish trust. Their prime purpose is to secure the interaction between two parties. They do not provide any guarantees about the potential consequences of interacting with a given party. For example, an authentication mechanism may assure a service consumer that the Web service to which it is disclosing a sensitive information is actually the service it claims it is. However, the Web service may or may not actually implement the terms of its privacy policy. Similarly, a Web service may use only encrypted messages to interact with its consumers. However, this only ensures that the communication between the service and its consumers is confidential. Here again, this is not a guarantee for the service consumer that the service may be trusted. In summary, trust and security are two different concepts

1.3 Example Scenario

9

and should not be mixed. Security is mainly about providing a transaction environment free of intrusions or attacks. Whereas trust is the belief that a consumer has in the abilities of a provider to deliver. Both concepts are equally important and may be used to support each other.

1.2 The Role of Reputation in Trust Management In recent years, an abundant theoretical and experimental research has studied the role of reputation in establishing trust in various contexts. Reputation has been defined as the confidence in the ability of a specific subject to fulfill a certain task [114]. It is a subjective assessment of a characteristic or an attribute ascribed to one entity by another based on observations or past experiences. Normally experiences from more than one source are assimilated to derive the reputation. Thus, in context of Web services, we refer to the aggregated perceptions that the community of service requesters have for a given Web service as service reputation. Reputation is regarded as a predictor of future behavior. This stems from the supposition that past behavior is indicative of future behavior [70]. Any Web service with high reputation would be regarded as one that has performed “satisfactorily” in a consistent manner over the past. This would imply that the service can be trusted to perform as expected in the future as well. In essence, trust is dependent on reputation. This is shown in Figure 1.1. Reliable reputation systems increase the user’s trust and encourage cooperation. A Web service that has low reputation would not be recommended for business transactions. Thus, reputation-based trust management will ultimately result in eliminating poor performers and motivating honest behavior among Web services. In recent years, an abundant theoretical and experimental research has studied the role of reputation systems in establishing trust in various contexts. A brief review is provided in Chapter 6. Most of that research confirmed that reliable reputation systems increase users’ trust in the Web (e.g., [112, 34]). An eloquent example is the impact of reputation systems on e-commerce applications in general and online auctions in particular. Consider the case of eBay, the world’s largest online auctioning site. In 2003, 94.9 million users posted 971 million listings with a gross merchandise sales of $24 billion. Several empirical studies attribute much of eBay’s commercial success to to its reputation mechanism, known as eBay’s Feedback Forum, e.g., [113, 57]. This mechanism has been effective in deterring dishonest behavior and, consequently, stimulating eBay’s growth.

1.3 Example Scenario In this section we provide a scenario to illustrate the need for a reputation management system in a service oriented environment. The example will be used through-

10

1 Introduction

out the remaining chapters of this book to illustrate the major requirements that will drive our work. Consider a car brokerage application (Figure 1.2) where a company deploys a Car Broker service (CB) that offers a car sale package. To handle the users’ request, the CB service may outsource from other Web services. Examples of outsourced services include Car Dealer (CD), Lemon Check (LC), FInancing (FI), Credit History (CH), and INsurance (IN). These services are provided by different vendors. Moreover, it is expected that a large number of vendors would compete with each other to provide the same (or similar) functionality. Y ¢Ye ]"£`TL I

y yu T

y / y s z x y s r ¤ p y / ys z x y v ys ¡ v z u r x m | z ru w | v raw s x z u rao z x z | s y v n r u v yr n y s m | z r u \y w y v | s y v n r u v yr n y s m | z r u /u y Km p/rn ys m | z ru r | z q z x m | z ru/r n ys m | z ru

i e7`Tk I H7eTUaL N4L P Q/L I RTS UTL V i l/W

m v } ~rs \s z z u \y x ras as z z u \y x rs J/I S RTS e g"_/S `^ Z I b N4L P Q/L7I R S UTL V J_W

v yu /y s z x y {Kw r | y K GH IXYI Z\[ L I v x y aw o y Ty v | js z y z | y v | \s y N4L P Q/L I RTS UTL V GXYW s y x y z y n y x z mo jq q y z s v x m o x w o m | yam p /y u | v n y x m o Yq q y s v m v } ~ar s s r o y /K yx } / m v } ~ar s Tm p z u z v | rs p mn n o p ~r s ~ z u m u x z u Y

z u v w s mu x y{Kw r | y Y

m nn o p q ras t u v w s mau x y

n s z x y {w r | y G H IKJ/L7H M L I NOL P#Q/L I RTS UTL V GJ/W

n s r o y /Y y x } caL\d#Z e#G f LTU7[ NOL7P Q/L I RTS UTL V cTGW

n m p Kyu | \mo x w o m | rs q z u m u x z u {Kw r | y h7S e7H eTUTS e g y | Tm p z u z v | rs p n m p z u z v | r s p G I L ] S ^K_/S à^ Z I b N4L7P#Q/L I RTS UTL y | w o z x 7y x rs vn w o z x \y x rs v 4 N L P#Q/L I R S UaL V hji W V G_/W ra z v | r s p y | r z v | r s p u r | z q p \ rw | \w v | rKys \s y z |

s yx y z y jw v | r /yas js y z |

Fig. 1.2 Car Brokerage Application

A customer accesses a CB service to buy a car having a specific make, model, year and mileage. Since car buying involves a number of functionalities, a series of invocations of the above mentioned services would need to take place. The selection of a service by CB at each invocation step can be done in two ways. In a use mode where the reputation of the component Web service is not considered, the customer would start by invoking CB’s sendMePriceQuote operation to get a price quote (step (1)). To get a quote, the CB would transparently interact with a car dealer via CD’s priceQuote operation (step (1.1)). If interested in a used car, the customer would check its history report by invoking CB’s askForProblemCheck operation (step (2)). This operation is processed by outsourcing from LC’s problemCheck operation (step (2.1)). The customer would then apply for financing by invoking the operation applyForFinancing provided by CB (step (3)). Before accepting a financing plan, CB would check the customer’s credit by invoking CH’s payingHistory operation (step (3.1)). If the credit is positive, CB would invoke the financingQuote operation offered by the financing service (step (3.2)). The customer would finally request an insurance quote through CB’s insuranceQuote operation (step (4)). CB would transparently invoke the operation applyforInsurance offered by the insurance ser-

1.3 Example Scenario

11

vice (step (4.1)). This service would outsource from DH’s drivingRecord operation before issuing insurance quotes (step (4.2)). In essence, no guarantees about the delivery of the required functionality could me made before the actual interaction. This implies that any of the services that CB outsources may exhibit irrational behavior. The overall quality of Web service that the customer perceives depends on the behavior of the individual services invoked while answering his request. From the customers’ perspective, the use case described in Figure 1.2 is obviously far from optimal. It does not provide customers the flexibility to make a reputation-based selection of car brokers. Similarly, since the reputation of component services is not considered, any defaulting service may in turn lower the quality of service delivered by CB. In fact, in such a scenario, it is also difficult for a service provider to make a reputation-based composition that results in a CB with the “best” possible quality from the perspective of that provider. Ãº\¨9Ä ¬ §7¦ á/â ã äTå ä æaç èé

¥Á7¦/Æ¦ \¼a§\¦ ¯A§\±"²§\¦ ³7© ´T§

¸7§\¹97º"¥»\§7´7¼ ¯A§\±"²§\¦ ³7© á§ µ ¸\¥ ¶· ¸ §j¹ \º"¥»\§\´ ¼ ¯°§7±9²§7¦ ³7© ´T§ µ ¸ ¥É\· ¸7§\¹ \º"¥»7§\´ ¼ ¯°§j±"²§\¦ ³ © ´T§ µ ¸7¥Ê7· ö èaêYðäðäaâð êYî÷âèç ã ñ ï ø ÛÎ Ü Ý Î Ï Ò × Ô Î Þ Ï Ó ß à Ì Í Î Ï ÐÑ Ò Ó Ô Õ Ö ×Ó Ñ Ø Ù Ö Í Ó Ù Ô ×Ñ Ú

¥Á7¦/Æ¦ \¼T§7¦ ¯°§\±9²§\¦ ³7© ´T§

¿ º7¬ À\¦ Á\º7´T§ ¯A§\±9²/§\¦ ³ © ´T§ µ ¿ Â¶T· ¿ º7¬ À7¦ Á7º\´T§ ¯°§j±"²§\¦ ³ © ´T§ µ ¿ ÂÉj· ê\ê\ëTì äaðí â éðîaî ì ëTâaâç ã ñ ï è

¥Á7¦/Æ¦ \¼T§7¦ ¯°§\±"²§\¦ ³7© ´T§

¥Á\¦KÆ¦ j¼a§\¦ ¯A§7±"² §7¦ ³7© ´T§

\ê êjäTëaðì ò\ðè îëaâå èaç ã ñ ì ¥Á\¦K½§\Á7Å §\¦ ¯°§\±9²§7¦ ³\© ´T§ µ ¥½ ¶a·

ËY© º\Á7º\´T© º\¾ ¥ Áj¦K½§\Á7Å §\¦ ¯A§\±"²§\¦ ³7© ´ § ¥¯°¦ §\§\¨7±9© ªK²«§\© ¦ ¬³7ª © \´T¦ § ® ¯È§\±"²/§j¦ ³7© ´T§ \ê õaäTç â ðëaðâ ï îç â â ç æ ã ñ µ ËK¿ ¶a· µ ¥« ¶a· µ ¥½Éj· Ëj© º\Á7º\´T© º\¾ ¥¦ §\¨\© ªY«© ¬ª \¦ ® ¯A§\±"²§\¦ ³7© ´T§ ¥ \ Á ¦ ½ \ § Á\Å §\¦ ¯°§\±9²§\¦ ³7© ´T§ µ Ë/¿ É\· ¯°§j±"²§\¦ ³ © ´T§ µ ¥« É7· µ ¥½Ê7· ½¦ © ³7© º7¾9«© ¬aª \¦ ® ¥ ¦ §7¨\© ªY« © ¬aª \¦ ® ¯°§\±"²§7¦ ³7© ´T§ ¥Á\¦K½§\Á7Å §\¦ ¯A§\±"²§\¦ ³7© ´T§ µ ½«· ¯°§\±"²§7¦ ³7© ´T§ µ ¥«Ê · µ ¥½ Ç\· êjêYì è äóTðç ã ð ôjîç é âã ç äaã ñ ì ñ

Fig. 1.3 A Reputation-driven Composition and Selection of Car Brokers

Consider now a scenario of a reputation-based selection of car brokers (Figure 1.3). In this scenario several companies compete to provide services in the car brokerage business. Each functionality (e.g, checking customer’s credit history) may be satisfied by several alternate Web services. These services have varying reputations, that may fluctuate over time. In a reputation-aware use case (Figure 1.3), CB providers and customers are aware of the reputations of the Web services. The providers may exploit services’ reputation in composing their CBs. Similarly, customers may also select the “best” CB based on the different CBs’ individual reputation. Customers would be able to select only those CBs that have an acceptable reputation, i.e., their past interaction history is satisfactory. In this way, the best results for the outcome of the interaction can be expected. Similarly, CB can guarantee that its own reputation is not tarnished due to the incompetence of component services.

12

1 Introduction

1.4 Book Organization The remainder of the book is organized as follows: In Chapter 2, we present an overview of service-oriented environments. We then present the current model of interactions on the Service Web. We also define an ontological framework for organizing and describing Web services on the Service Web. We use the concept of community to cater for an ontological organization and description of Web services. The developed ontology, serves as a “template” for describing communities and Web services. In Chapter 3, We show how the concept of Quality of Service can be used to create reputation information. We then propose different bootstrapping models for managing the reputation of Web services. We use the concept of community defined in chapter 2 to define two methods for the bootstrapping process. The first approach relies on the cooperation among services, which computes the reputation of newcomers in a P2P manner. The second approach functions under a “super-peer” topology where the community provider is responsible for assigning the newcomer’s reputation. In Chapter 4, we present a heuristics-based model for assessing the reputation of Web services. We define different metrics to aggregate the different consumer ratings in a fair and accurate manner. We also define a Hidden Markov Model based forecasting model to assess the provider reputations for conditions where adequate number of rater feedbacks are not available. The assessment model does not rely on a centralized repository and is distributed in nature. We do not define a single “system-wide” reputation for a service provider, but each consumer is given the control to assess providers’ reputations according to its own perception and preference. We also present a model for assessing the reputation of Web services involved in a composition. We analyze and determine the impact of a component service’s reputation on the reputation of a composition and vice versa. Our techniques address the problem of reputation management in compositions from two perspectives: (i) ensuring reputation assessment accuracy of component services from the point of view of the composition orchestrator, and (ii) ensuring fairness in decreasing/increasing reputations from the point of view of component services such that no service is wrongfully blamed. In Chapter 5, we present the results of the extensive performance study for the proposed techniques. The experimental study is holistic in the sense that we have verified the accuracy of all the modules we defined under RATEWeb: reputation bootstrapping, reputation collection models, rater credibility evaluation, reputation assessment for individual and composed services, and reputation prediction using a hidden Markov model. In Chapter 6 we describe the major techniques proposed for managing the reputation of service providers that are most closely related to research presented in this book. In Chapter 7, we provide some concluding remarks and discuss directions for future research.

Chapter 2

Service-Oriented Environments

The semantic organization and description of Web services is an important requirement for enabling their automatic selection and composition in service-oriented environments (SOEs). A plethora of Web services are expected to compete in offering similar functionalities in SOEs, or the new service Web in general [153]. The continuously changing and large number of Web services, with service providers potentially located in different parts of the world calls for techniques to organize Web services in a manner that can be efficiently understood and outsourced. In this chapter, we present a semantics-centered framework for organizing and describing Web services. We introduce the concept of community to cater for an ontological organization and description of Web services. We develop an ontology, called community ontology, that serves as a template for describing communities. A Service-Oriented Environment (SOE) is one where participants use the provided infrastructure and technology to create and capture value through interactions. In the following, we define the main components of an SOE namely participants, infrastructure & technology, and interactions. We only provide a brief overview of the components in relation to this work, and do not delve in their detailed description. • Participants: An SOE participant can take on one of two roles: (i)consumer, and (ii)provider. The technical representation of these roles may differ from one SOE to the other. For instance, participants can be human users, agents, or Web services. • Infrastructure & Technology: SOE infrastructure mainly refers to the network communication model adopted by the participants. The client-server model is one of the earliest and most commonly used models adopted in e-commerce. However, with the advent of technology, other network models as peer-to-peer, mobile, etc. are being adopted. The Service-oriented Architecture (SOA) paradigm is driving this change, and as mentioned earlier, the Web services technology is at the center of this change. • Interactions: Any type of business activity such as buying, selling, delivery, marketing, information sharing, etc. may be termed as an interaction. The important thing to note is that the interaction should create some value. Moreover, every Z. Malik and A. Bouguettaya, Trust Management for Service-Oriented Environments, DOI 10.1007/978-1-4419-0310-5_2, © Springer Science + Business Media, LLC 2009

13

14

2 Service-Oriented Environments

interaction has several attributes that distinguish it from the other, e.g., context, quality, etc.

2.1 SOE Interaction Model In this section, we present a model of interactions for the SOE. We first enumerate the key components, i.e., participants, of our model. We then show how these components are related to each other and the modes of interaction between them. Finally, we discuss how services interact in the proposed model.

Fig. 2.1 The Service Web Model

2.1.1 Entities and Interactions Typical interactions on the service Web involve four types of entities: (i) Web services, (ii) service providers, (iii) service registries, and (iv) service consumers. • Web services A Web service is a software application identified by a URI (Uniform Resource Identifier), whose interface and binding are defined, described and discovered by XML artifacts, and supports direct interaction with other software applications using XML messages via Internet-based protocols [138]. Conceptually, a Web service may be viewed as a set of operations, where each operation is a “pro-

2.1 SOE Interaction Model

15

cessing unit” that consumes input values (called its parameters) and generates output values called the result of that operation’s invocation. For the sake of focus and clarity, we assume only a single operation per service. The reputation of the operation or the Web service, thus refer to the same thing in our model. We define Web services as business functionalities that are: – Programmatically accessible: Web services are mainly designed to be invoked by other Web services and applications. They are distributed over the Web and accessible via widely deployed protocols such as HTTP and SMTP. Web services must describe their capabilities to other services including their operations, input and output messages, and the way they can be invoked. – Loosely coupled: Communication among Web services is document-based. Web services generally communicate with each other by exchanging XML documents. The use of a document-based communication model caters for loosely coupled relationships among Web services. • Service providers The service provider is the entity that provides the service, i.e., makes it available to consumers. A service provider may be a business, a government agency, an academic institution, etc. A provider may provide one or more services. A service is provided by a single provider. Providers have publicly known identities. The provider owns the service. It may or may not actually manage the service. For example, the provider of a service may outsource the task of actually operating the service to a third party. Service consumers may or may not be able to discern all the parties involved in delivering a given service. In our model, we do not make a distinction between the service provider and the provided Web service. Thus, when we talk about a service provider, it is the Web service that is actually provided. The terms service provider, provider Web service and provider are synonymous in our model. A service provider’s goal is to increase/maintain its client base. Service providers are expected to behave rationally to achieve their goals. However, since the presence of malicious entities cannot be discounted (similar to the “real world”), service providers may change their behavior dynamically. In other words, service providers may behave honestly in one time instance, and in the next they may act under a malicious motive. • Service registries A service registry is a searchable directory that contains a collection of descriptions of Web services. A service registry has two components: a repository of service descriptions and a registry engine that answers the requests sent to the registry by service providers and service consumers. A service registry may be private or public. Any provider may advertise its capabilities by publishing the Web service in a public registry. A private registry may be used only by a limited, known set of providers to publish services. We focus on the use of public registries in our proposed model. Moreover, we assume no limit on the number of registries. In our model, service registries are only used to locate prospective service providers, and the registries do not store any reputation related information.

16


• Service consumers A service consumer is any entity that invokes a Web service, e.g., an intelligent agent, a Web application, or another Web service. A human user may also invoke a Web service, but we assume that each user is represented by a software component (defined: proxy) in the system. The proxy is thus responsible for all user communication, and managing the functional and non-functional requirements of the user. How this is achieved is not the focus of our work. We assume that the user can generate a proxy in one of two ways: (i) implement a custom proxy using a template, or (ii) download a proxy. In privacy-sensitive cases, users may prefer the first technique while the latter provides ease of use. The template or the actual proxy can be obtained through a registry or portal defined by providers that are generally groups of government agencies, non-profit organizations, and businesses that share a common domain of interest. We refer to such providers as “community providers” in our model. Details follow in Section 2.2. We believe the proxy assumption is reasonable as environments that require minimal human intervention (e.g. the Semantic Web [16, 46]) would necessitate the use of such proxies [99]. Without loss of generality, we will assume a symmetric interaction model where typical interactions involve two Web services: one that provides some functionality and another one, the service consumer, that invokes the first one to request that functionality. We also use the terms consumer and client interchangeably to refer to a service consumer. Three major standardization initiatives have been submitted to the W3C consortium to support interactions among Web services (Figure 2.1): • WSDL (Web Services Description Language): WSDL is an XML-based language for describing operational features of Web services. WSDL descriptions are composed of interface and implementation definitions. The interface is an abstract and reusable service definition that can be referenced by multiple implementations. The implementation describes how the interface is implemented by a given service provider. • UDDI (Universal Description, Discovery and Integration): UDDI defines a programmatic interface for publishing (publication API) and discovering (inquiry API) Web services. The core component of UDDI is the business registry, an XML repository where businesses advertise services so that other businesses can find them. Conceptually, the information provided in a UDDI business registration consists of white pages (contact information), yellow pages (industrial categorization), and green pages (technical information about services). • SOAP (Simple Object Access Protocol): SOAP is a lightweight messaging framework for exchanging XML formatted data among Web services. SOAP can be used with a variety of transport protocols such as HTTP, SMTP, and FTP. A SOAP message has a very simple structure: an XML element (called envelope) with two child elements. The first element, the header includes features such as security and transactions. The second element, the body includes the actual exchanged data.

2.1 SOE Interaction Model

17

The emergence of tools to describe, advertise, and invoke Web services facilitates the development of Web service-based solutions. However, the use of a tagged language such as XML increases the volume of information to be exchanged among Web services. This might overload the network in presence of a large number of services, hence penalizing the scalability of the Web service approach. Additionally, SOAP defines only simple data types. Using complex data types may require the XML parser to get the corresponding XML Schema definitions from remote locations. This might add an overhead for processing SOAP messages. The registry presents another scalability issue. A centralized registry might result in a single point of failure and bottleneck for accessing and publishing Web services. A distributed registry would cater for a more reliable and scalable solution. However, this incurs an additional overhead of managing distributed repositories. An intermediary solution is adopted in UDDI where the registry is physically replicated over multiple nodes. This solution solves the problem of centralized registry. However, it still requires the nodes to exchange data with each other to maintain registry consistency. To make a service available to consumers, a provider publishes the service in a service registry. Service publication is an activity in which the provider of a Web service advertises the capabilities of the service by publishing the service’s description to a service registry. This description specifies information such as the identity of the provider, the service’s address (i.e., URI), its operations, and the number, names, order, and types of each operation’s parameters. Each service provider may publish the service in one or more registries with one or more identities. A service may be published in the same registry more than once with different identities. We consider two instances of the same service with different identities as two distinct services. Service consumers access service registries to discover services. Service discovery is an activity that aims at finding one or more services that may be used to achieve a given functionality. A basic form of service discovery occurs when a client submits a discovery request to a single registry to search for one or more services that may deliver some functionality. The registry engine searches its service directory for one or more services that may be invoked to answer the client’s request. It then sends the description of these services to the client. We assume that registries are neutral, i.e., have an impartial policy vis-à-vis the providers of the different services. Typically, the directory of a service registry may contain several services that all may achieve a given functionality. Under the assumption of neutrality, when a registry receives a request from a client, it answers with the list of all the potential services that may answer the client’s request. Clients, therefore, must be able to select one among several “equivalent” services. Service selection is a process that determines the “best” service to invoke in a given context. In the proposed model, clients are autonomous with regard to service selection. They may use different criteria and may have different service ranking schemes. In some cases, a client may not find any single Web service that may provide a given functionality. It may then initiate a service composition process. Service composition may be defined as the process of “combining” two or more services (called components) from different providers to produce a value-added composite

18


service. Service composition may be recursive: a composite services may result from the composition of other atomic (i.e., non-composite) or composite services. Service composition is carried out by entities called service composers. We consider the composer of a composite service as the provider of that service. In our model, service composers are themselves considered as Web services. Service consumers invoke a Web service through one of its operations. The consumer provides appropriate values for the operations parameters and the service returns an output value as a result of the invocation.

2.2 Service Interactions: Extension through Ontologies In this section we show how RATEWeb extends the existing service interaction model. We propose an ontology-based approach for organizing Web services. Ontologies are poised to play a central role to empower Web services with semantics. They are increasingly viewed as key to enabling semantics-driven data access and processing [25]. We introduce the concept of community to cater for an ontological organization and description of Web services. A community is a “container” that clumps together Web services related to a specific area of interest (e.g., auto makers, car dealers, etc). All Web services that belong to a given community share the same area of interest. Communities provide descriptions of desired services (e.g., providing interfaces for INsurance services in our running example) without referring to any actual service. We develop an ontology, called community ontology, that serves as a template for describing communities and Web services. A community ontology is a metadata (domain [147, 117]) ontology which provides concepts that allow the description of other concepts (communities and Web services in our case). This domain ontology “also describes concept relationships in the application domain, and facilitates the semantic markups on the domain-specific aspects of Web services such as service categories, semantic types of parameters, etc” [144]. Figure 2.2 outlines the process of creating a community and registering Web services with it. Communities are defined by community providers as instances of the community ontology. Community providers are generally groups of government agencies, non-profit organizations, and businesses that share a common domain of interest. Additional responsibilities of a community provider may include defining a reputation policy that: (i) sets a reputation threshold for members to maintain, (ii) sets rules applicable when a member’s reputation goes below the specified threshold, e.g., dissemination within the community of its low reputation, temporary suspension of its membership, and (iii) defining reputation requirements for new members.

2.2 Service Interactions: Extension through Ontologies

t| u9vò u vwp q }9x9l9yoq z {

! 9*w !96

^`_ a-acbd e f g h#d*f _ i _j8g %" %"

! 498K $ t|u4vwo u vwp q }9x9l9yoq z {

19

«¹¬* ®8¯ ° ¯ ± ²³ ´²µ ± ¶4·M«K´º

k-l4mnl9o p q r@l9s Ä-ÅÆ » ¼½@¾¿ À"¿ Á ÂÃ | n o l9u o ppq }9q rl9l o Ä-ÅÇ » ¼!½%¾¿ À"¿ Á ÂÃ | n o l9u o pp q }q r@l4l o

IKJ8LML#N O P Q RSI6U

@ "%%

«$¬®8¯ °4¯± ²³ ´²µ ± ¶4·-«K´ ¸

@ %%@ % @ -Ä Å8È » ¼½%¾¿ À%¿ Á Â!Ã

IKJ8LML#N O P Q RSIT

@ "%%

~!%% """ VW8X Y9P Z W ¥! ! ¡ K¢ £ 9¤! [ 8W \8P ]!Q X R

¥!9 ¨8@! © ¤ £ª6 ¥ ~"% "%

Ä-Å*É » ¼½@¾¿ À@¿ Á ÂÃ Ä-Å*Ê » ¼½@¾¿ À%¿ Á Â!Ã

| no l4u o pp q }9q rl9l o | n o l9u o p pq }q r!l4l o

! ¡94¦ § 9 | no l4u o pp q }9q rl9l o

Fig. 2.2 Community Creation and Service Registration

2.2.1 Definition of Communities A community C i is formally defined by a tuple (Identifieri , Categoryi , G-operationi, Membersi ). The Identifieri clause contains a unique name and a text description that summarizes Ci ’s features. Categoryi describes the area of interest of the community. All Web services that belong to Ci have the same category as C i ’s. Ci is accessible via a set of operations called generic operations. Those are specified in the G-operationi clause. Generic operations are “abstract” operations that summarize the major functions needed by C i ’s members. Community providers define generic operations based on their expertise on the corresponding area of interest that is, C i ’s category. The term “abstract” means that no implementation is provided for generic operations. Community providers only define an interface for each generic operation opik . This interface could subsequently be used and implemented by community members (i.e., actual Web services) interested in offering op ik . We say that those members support or import opik . The execution of opik hence refers to the execution of an actual operation offered by a member that supports opik . The Membersi clause refers to the list of C i ’s members. By being members of C i , Web service providers promise that they will be supporting one or several of C i ’s generic operations. We use OWL-S [137] for describing the proposed ontology. Category The category of a community Ci is formally defined by a tuple (Domaini, Synonymsi, Specializationi, Overlappingi). Domaini gives the area of interest of the community

20


(e.g., “financing”). It takes its value from a taxonomy for domain names. For flexibility purposes, different communities may adopt different taxonomies to specify their category. We use XML namespaces to prefix categories with the taxonomy in which they are defined. Simply put, XML namespaces provide a method for qualifying element and attribute names used in XML documents by associating them with URI references. Synonymsi contains a set of alternative domain names for Ci . For example, “car” is a synonym of “automobile”. Values assigned to this attribute are taken from the same taxonomy as the one used for domains. Specialization i is a set of characteristics of the Ci ’s domain. For example, “car” and “quote” are specialization of “financing”. This means that Ci provides finance quote services for cars. Communities are generally not independent. They are linked to each other via inter-ontology relationships. These relationships are specified in the Overlapping i attribute. Overlappingi contains the list of categories that overlap with Ci ’s category. It is used to provide a peer-to-peer topology for connecting communities with related categories. We say that categoryi overlaps with category j if composing Ci ’s operations with C j ’s is “meaningful”. By meaningful, we mean that the composition provides a value-added benefit (in terms of categories). For example, an operation that belongs to a community whose domain is office workers may be composed with another operation that belong to a community whose domain is insurance. This would enable providing car insurance for office groups. It should be noted that it is the responsibility of the community providers to identify related categories and assign them to the overlapping attribute. Generic Operations A generic operation is defined by a set of functional and non-functional attributes. Functional attributes describe syntactic and semantic features of generic operations. Syntactic attributes represent the structure of a generic operation. An example of syntactic attribute is the list of input and output parameters that define the operation’s messages. Semantic attributes refer to the meaning of the operation or its messages. We consider two types of semantic attributes: static and dynamic semantic attributes. Static semantic attributes (or simply static attributes) describe noncomputational features of generic operations. Those are semantic attributes that are generally independent of the execution of the operation. An example of static attribute is the operation’s category. Dynamic semantic attributes (or simply dynamic attributes) describe computational features of generic operations. They generally refer to the way and constraints under which the operation is executed. An example of dynamic attribute is the business logic of the operation i.e., the results returned by the operation given certain parameters and conditions. Non-functional attributes, also called qualitative attributes, include a set of metrics that measure the quality of the operation. Examples of such attributes include time, availability, security, cost, etc. Two service providers that support the same generic operation may have different values for their qualitative attributes. Non-


21

functional attributes model the competitive advantage that competitors (i.e., Web services that support the same generic operation) may have on each other. While defining a community, community providers assign values to part of the attributes of their generic operations. The rest of the attributes are assigned either by service providers or third parties during the registration of Web services with Ci . For example, the types of input and output messages (e.g., purchase order, registration confirmation) are defined by community providers. The cost (dollar amount) of executing an operation is service-specific and hence defined by the service provider. The other qualitative attributes (e.g., response time, availability) may be assigned by the consumers, underlying infrastructure, or third parties (e.g., trusted parties, monitoring agencies). The way those parties determine the values to be assigned (e.g., through monitoring) is out of the scope of this book. It is worth noting that the values of some attributes may be assigned by both community and service providers. For example, the content of an input and output message is given by community providers. However, service providers may modify this content by adding and/or removing parameters to input and output messages. Community Members Service providers can, at any time, select a community of interest (based on categories) and register their services with it. We say that those services are members of that community. The registration process requires giving an identifier (WS-ID), name, and description for the Web service. The identifier takes the form of a unique UUID. The description summarizes the main features of the Web service. Service providers specify the list of generic operations supported by their services through the imported attribute. We define three constructs for importing generic operations: projection, extension, and adjustment. The projection and extension constructs allow the addition and deletion of message parameters respectively. Adjustment enables the modification of the content of operation attributes. The invocation of an imported operation is translated into the invocation of an “actual” service operation. The correspondence between imported and actual operations is done through the mapping attribute. For each imported operation, the provider gives the ID of the corresponding actual operation. It also defines a one-to-one mapping between the imported operation’s parameters and actual operation’s parameters. Defining mappings between parameters enables the support of “legacy” Web services. Providers do not need to change the message parameters in their actual service codes. Assume that a service provider SP offers a given operation op. The following three cases are then possible: (i) If there is a community Ci that contains a generic operation opik similar to op, SP would import opik “as is”; (ii) If there is a community Ci that contains a generic operation opik “closely” similar to op (e.g., op has less input parameters than defined in opik ), SP would import opik using projection, extension, and/or adjustment technique(s); (iii) If no community has an operation similar or “closely” similar to op, SP would define a new community C j that has op as a generic operation and SP’s service as a member. The latter case is similar to the

22


traditional WSDL/UDDI/SOAP Web service model where service providers create descriptions for their services. The difference is that, in our case, SP instantiates the attributes and concepts of the community ontology while in the traditional model, providers define their service descriptions from scratch.

2.2.2 Operational Description of Communities As mentioned previously, a generic operation is described at four different levels: syntactic, static semantic, dynamic semantic and qualitative levels. In this section, we give a detailed description of generic operation attributes for each of those levels. 2.2.2.1 Syntactic Attributes We define two levels for syntactically describing a generic operation: message and operation levels. Attributes at the message level describe the structure of the messages defined within the operation such as the number of parameters within a message. Attributes at the operation level describe general-purpose features of the generic operation such as the name and ID of the operation. Message Syntax Generic operations have input and output messages. Each input or output message contains one or more parameters defined by their names. The name of a parameter is unique within a given message. Let us for example consider a generic operation checkEligibility which checks consumer’s eligibility for a financing option. The input message of this operation contains income, familySize, and zipCode as parameter names. The output message of checkEligibility has approved and duration as parameter names. Although message parameters are pre-defined by community providers, service providers have the ability to add new parameters or remove pre-defined ones. Therefore, the number of parameters within a messages may be changed by service providers. We define two sets In(opik ) and Out(opik ) for each generic operation opik . In(opik ) and Out(opik ) contain the list of input parameters’ and output parameters’ names of opik respectively. We also define two attributes NIi k and NOi k that give the number of input and output parameters in opik respectively. For example, in the case where opik = checkEligibility, In(opik ) = {income, f amilySize, zipCode}, NIi k = 3, Out(opik ) = {approved, duration}, and NOi k = 2.


23

Operation Syntax A generic operation has a unique identifier, called G-op-ID, that takes the form of a Universally Unique ID (UUID). A UUID is an identifier that is unique across both space and time. The operation has also a name and a text description that summarizes the operation’s features. The binding defines the message formats and protocols used to interact with the operation. An operation may be accessible using several bindings such as SOAP/HTTP and SOAP/MIME. The binding of an operation is assigned by the service provider. This is in contrast to the rest of syntactic attributes whose values are pre-defined by community providers. Indeed, the binding attribute is dependent on the way the generic operation is implemented at the service provider side. A provider may offer SOAP/HTTP access to a generic operation supported by its Web service while another provider may prefer to use SOAP/MIME for the same operation. The mode of an operation refers to the order according to which its input and output messages are sent and received. It states whether the operation initiates interactions or simply replies to invocations from other services. We define two operation modes: In/Out or Out/In. One of these values is assigned by community providers to each operation. In/Out operation first receives an input message from a client, process it (locally or forward it to another service), and then returns an output message to the client. Out/In first sends an output message to a server and receives an input message as a result. checkEligibility is an example of In/Out operation. As specified in the WSDL standard, some operations may be limited to an input or an output message. For example, expirationINS is an operation that automatically notifies consumers about the termination of their insurance. 2.2.2.2 Static Semantic Attributes The static semantics of a generic operation describe semantic properties that are independent of the execution of the operation. It specifies the semantics of the operation itself (e.g., what does the operation do) as well as the semantics of input and output messages defined within the operation. Message Semantics Messages must be semantically described so that they can be “correctly” interpreted by service providers and consumers. For that purpose, we associate a message type MT to each message. MT gives the general semantics of the message. For example, a message may represent a “purchase order” or an “invoice”. Vertical ontologies are the ideal concept to describe the type of message. An example of such ontology is RosettaNet’s PIPs (Partner Interface Processes). The message type does not capture the semantics of message parameters. We define the following attributes to model the semantics of message parameters: data

24


type, business role, unit, and language. The data type gives the range of values that may be assigned to the parameter. We use XML Schema’s built-in data types as the typing system. Built-in types are pre-defined in the XML schema specification. They can be either primitive or derived. Unlike primitive types (e.g., string, decimal), derived types are defined in terms of other types. For example, integer is derived from the decimal primitive type. The business role gives the type of information conveyed by the message parameter. For example, an address parameter may refer to the first (street address and unit number) or second (city and zip code) line of an address. Another example is that of a price parameter. It may represent a total price or price without taxes. Business roles take their values from a pre-defined taxonomy. Every parameter would have a well-defined meaning according to that taxonomy. An example of such taxonomy is RosettaNet’s business dictionary. It contains a common vocabulary that can be used to describe business properties. For example, if the price parameter has an “extendedPrice” role (defined in RosettaNet), then it represents a “total price for a product quantity”. For flexibility purposes, different community providers may adopt different taxonomies to specify their parameters’ business roles. As for categories, we use XML namespaces to prefix business roles with the taxonomy according to which they are defined. The unit attribute refers to the measurement unit in which the parameter’s content is provided. For example, a weight parameter may be expressed in “Kilograms” or “Pounds”. A price parameter may be in “US Dollars”, “Canadian Dollars”, or “Euro”. A time period parameter may be specified in days, weeks, or months. We use standard measurement units (length, area, weight, money code, etc.) to assign values to parameters’ units. If a parameter does not have a unit (e.g., address), its unit is equal to “none”. The content of a message parameter may be specified in different languages. For example, a profession parameter may be expressed in English or Spanish. An English-Urdu-translation operation takes as input, an English word (input parameter) and returns as output, its translation in Urdu (output parameter). We adopt the standard taxonomy for languages to specify the value of this attribute. The content of static semantic attributes is assigned by community providers. The data type, unit, and language attributes may be changed by service providers. This is in contrast to the message type and business role which model the core of the message semantics and hence cannot be altered. Service providers have the flexibility to support a data type, unit, or language different from those specified by community providers. For example, a service provider may decide to support a weight parameter in “Kilograms” although the community providers specified “Pounds” as the measurement unit for this parameter. Operation Semantics The static semantic of an operation is defined by the following attributes: serviceability, provider type, consumer type, purpose, and category. These attributes model


25

the core of the operation’s semantics. Hence, they are exclusively assigned by community providers. The serviceability attribute gives the type of assistance provided by the operation. Examples of values for this attribute are “cash”, “in-kind”, “informational”, and “educational”. In e-government, TANF (Temporary Assistance for Needy Families) is an example of welfare program that provides financial support to needy families. A food stamp is an example of in-kind support available to indigent citizens. Returning the list of senior activity centers is an example of informational support. Enhancing communication skills of visually impaired people is an example of educational support. Other types of support may be mentioned by assigning the value “other” to this attribute. A generic operation may be supported via one or several provider types. A provider may be governmental (“federal”, “state”, “local”, and “tribal”) or non- governmental (“non-profit” and “business”) agencies. Each generic operation performs a certain functionality for a specific area of interest. This is specified through the purpose and category attributes respectively. An operation inherits the category of the community in which it is defined. Hence, all operations that belong to the same community share the same category. The purpose attribute describes the goal of the operation. It is defined by four attributes: function, synonyms, specialization, and overlapping. The function describes the business functionality offered by the operation. Examples of functions are “eligibility”, “registration”, and “mentoring”. Synonyms and specialization attributes work as they do for categories. Overlapping contains the list of purposes that overlap with the purpose of the current operation. Let opik and op jl be two generic operations. We say that purposei k overlaps with purpose j l if composing opik with op jl is “meaningful”. By meaningful, we mean that the composition provides a value-added benefit (in terms of purposes). As for categories, it is the responsibility of the community providers to identify related purposes and assign them to the overlapping attribute. 2.2.2.3 Dynamic Semantics Dynamic semantics allow the description of attributes related to the execution of generic operations. Those attributes may relate the execution of an operation op ik to the execution of other operations (inter-operation attributes) or describe features inherent to the execution of opik (intra-operation attributes). Inter-operation attributes define the execution order of opik with respect to other operations. We identify two inter-operation attributes: pre-operation and post-operation which give the list of operation whose execution precedes and follows opik ’s execution respectively. Intraoperation attribute, also called behavior defines the internal business logic of op ik . The definition of the aforementioned attributes is based on the notion of execution state described below.

26


Operation Execution States The execution of an operation opik generally goes through four major observable states: Ready, Start, Active, and End. The execution of opik is in the Ready state if the request for executing opik has not been made yet. The Start state means that opik execution has been initiated. It refers to one of the following events: (i) an input message is sent to opik if opik ’s mode is In/Out; or (ii) an output message has been sent from opik if opik ’s mode is Out/In. We say that opik is in the Active state if opik has already been initiated and the corresponding request is being processed. After processing the request, the operation reaches the End state during which results are returned. It refers to one of the following events: (i) an output message is sent to the client if opik ’s mode is In/Out; or (ii) an input message is received from the server if opik ’s mode is Out/In. We define a precedence relationship between states, noted −→t , as follows: S1 −→t S2 if S1 occurs before S2. The execution states are totally ordered according to −→t as follows: Ready −→t Start −→t Active −→t End Pre-Operations Executing a Web service operation may require going through a pre-defined process that involves the execution of several operations called pre-operations. This pre-defined process is dictated by government regulations or the internal business process of the Web service. For example, citizens must first register with an Insurance company via checkRegistration operation before obtaining a vehicle. They may also reflect the business logic of the Web service. Let us consider two generic operations opik and op jl that belong to the same or different communities. We say that opik is a pre-operation of op jl if the invocation of op jl is preceded by the execution of opik . We call opik and op jl source and target operations respectively. An operation may have several pre-operations. It may also be the source (i.e., pre-operation) of several operations. We give below a formal definition of the pre-operation relationship. Definition 2.1 - Pre-operation. Let opik and op jl be two generic operations. opik is a pre-operation of op jl if End(opik ) −→t Ready(op jl ).

The definition of a pre-operation relationship includes a source operation op ik , target operation op jl , and the condition and mandatory attributes. The condition is a predicate over opik ’s input and output parameters. op jl can be invoked only if all its pre-operations reached their End state and their conditions are true. If no condition is specified for a given pre-operation then the default value is “true”. The mandatory attribute takes boolean values and specifies whether executing the source operation is mandatory or optional. If this attribute is true then the relationship between op ik and op jl is obligatory. Otherwise, it is recommended.


27

Post-Operations The execution of a given operation may trigger the invocation of other operations called post-operations. For example, a citizen that registers successfully for a car license tag (registerCar) is required to register the car with his/her county of residence (registerCounty). We say that opik is a post-operation of op jl if the termination of op jl precedes the invocation of opik . We call op jl and opik source and target operations respectively. An operation may have several post-operations. It may also be the target (i.e., post-operation) of several operations. Note that if op ik is a pre-operation of op jl , then op jl is not necessarily a post-operation of opik . Definition 2.2 - Post-operation. Let opik and op jl be two generic operations. opik is a post-operation of op jl if End(op jl ) −→t Ready(opik ).

As for pre-operations, we associate a condition and mandatory attribute to each post-operation relationship. A target operation enters the initiation state if at least one of its source operations has reached its End state and the corresponding condition is true. A post-operation may also be mandatory or optional. 2.2.2.4 Qualitative Properties Multiple Web services that belong to the same community may import the same generic operation. It is hence important to define a set attributes that help select the best Web service supporting a given functionality. For this purpose, we define a Quality of Operation (QoP) model based on a set of qualitative attributes that are transversal to all operations such as the cost and response time. The international quality standard ISO 8402 describes quality as “the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs” [99]. We define QoP as a set of non-functional attributes that may impact the quality of the operations imported by a Web service. There are many QoP attributes important to Web services operations. We organize them into three groups of quantifiable attributes based on type of measurement performed by each attribute: run-time, business, and security. Note that this list is not exhaustive by any means, and is presented only for explanatory purposes. Run-time Attributes - These attributes enable the measurement of properties that are related to the execution of an operation opik ). We identify three run-time attributes: response time, reliability, and availability. The response time measures the expected delay in seconds between the moment when op ik ) enters the Start state (i.e., opik ) is initiated) and reaches the End state (i.e., opik ) gets or sends the results). Time(opik )) is computed using the expression Time p rocess(opik ) + Timer esults(opik ). This means that the response time includes the time to process the operation (Time p rocess) and the time to transmit or receive the results (Timer esults). The reliability of opik ) is the ability of the operation to be executed within the maximum expected time frame. Reliability(opik )) is computed based

28


on historical data about previous invocations of the operation using the expression Ns uccess(opik )/Ni nvoked(opik) where Ns uccess(opik ) is the number of times that the operation has been successfully executed within maximum expected time frame and Ni nvoked(opik) is the total number of invocations. The availability is the probability that the operation is accessible. Availability(opik ) is measured by the expression UpTime(opik )/TotalTime(opik ) where UpTime is the time opik was accessible during the total measurement time TotalTime. Business Attributes - These attributes allow the assessment of an operation op ik from a business perspective. We identify two business attributes: cost, and regulatory. The cost gives the dollar amount required to execute op ik . The regulatory property is a measure of how well opik is aligned with government regulations. Regulatory(opik) is value within a range (e.g., between 1 and 10). The lowest value refer to an operation that is highly compliant with government regulations. Security Attributes - These attributes describe whether the operation op ik is compliant with security requirements. Indeed, service providers collect, store, process, and share information about millions of users who have different preferences regarding security of their information. We identify four properties related to security and privacy: encryption, authentication, non-repudiation, and confidentiality. Encryption is a boolean that indicates whether opik ’s message are securely exchanged (using encryption techniques) between servers and clients. Authentication is a boolean that states whether opik ’s consumers (users and other services) are authenticated (e.g., through passwords). Non-repudiation is a boolean that specifies whether participants (consumers and providers) can deny requesting or delivering the service after the fact. The confidentiality attribute indicates which parties are authorized to access the operation’s input and output parameters. Confidentiality(op ik) contains opik ’s input and output parameters that should not be divulged to external entities (i.e., other than the service provider). If a parameter does not belong to Confidentiality(opik), then no confidentiality constraint is specified on that parameter. Assume that confidentiality(opik) = {SSN, salary} where SSN and salary are two opik ’s input parameters. The content of this attribute states that those two parameters are kept private by opik ’s provider.

2.2.3 Interactions In RATEWeb, a community is itself a service that is created, advertised, discovered, and invoked as a regular Web service. The providers of a community assign values to the concepts of the community ontology (Figure 2.2 - step a). Each concept is defined by a set of attributes. Communities are published in a registry (e.g., UDDI) so that they can be discovered by service providers (Figure 2.2 - step b). Service providers (e.g., car broker provider) identify the community of interest (Figure 2.2 - step c) and register their services with it (Figure 2.2 - step d). During the


29

registration of a service WS with a community Ci , the service provider specifies the concepts of Ci that are inherited by WS. For example, WS may inherit only some of the operations defined in Ci . Admitting a service to a community is subject to the admission rules specified in the community’s reputation policy. Moreover, to make a service available to consumers, a provider publishes the service in a service registry. Service publication is an activity in which the provider of a Web service advertises the capabilities of the service by publishing the service’s description to a service registry. This description specifies information such as the identity of the provider, the service’s address (i.e., URI), its operations, and the number, names, order, and types of each operation’s parameters. Each service provider may publish the service in one or more registries. A service may be published in the same registry more than once with different identities. We consider two instances of the same service with different identities as two distinct services. Similarly, a Web service may belong to different communities. For example a composite service (WS4 in Figure 2.2) may outsource operations that have different domains of interest (e.g., auto insurance and finance in our scenario). Since these operations belong to two different communities, the composite service is registered with the auto insurance and financing communities (C 1 and C2 in Figure 2.2). When a service is member of multiple communities, it implies that the service simultaneously fulfills the reputation policy of all communities. Service consumers access service registries to discover the communities and providers of their choice. The consumer’s query consists of the operations it wants to invoke. The list of operations is matched with different communities’ capabilities. It may be the case that the required operations are matched to several different communities. Each community in turn searches its directory for the list of providers that have registered their operations. It then sends the description of these services to the consumer. The registered services may be invoked to answer the consumer’s request. We assume that communities and registries are neutral, i.e., have an impartial policy vis-à-vis the providers of the different services. The service consumer then selects the best service from the list provided. In our model, this selection is based on the reputation of each individual service from the list. We assume that when the consumer queries the community for potential providers’ list, then apart from the “normal” details, the returned description also contains a list of past service consumers that possess feedbacks for the provider being queried. The community thus only acts as a directory of raters and not as a centralized repository of ratings (ratings are kept local with the raters). The consumer may contact these peer consumers to gather the feedbacks, and in turn assess the providers’ reputations. Service consumers then invoke a Web service through one of its listed operations. The consumer provides appropriate values for the operations parameters and the service returns an output value as a result of the invocation. At the end of the interaction, the service consumer rates the provider according to some pre-defined quality attributes. The service consumer also informs the community provider that it possesses the feedback ratings for the provider. These service ratings are used to compute provider reputations accordingly. Note that RATEWeb is not dependent on the proposed community-based ratings collection model, and may be replaced with

30


other models, as in [134, 98, 20, 111]. In the following we list the main properties of our model that are characteristic of most service-oriented environments, and hence require special solutions to the reputation assessment problem. • Private Interactions: The transaction details between a service provider and consumer are hidden from the rest of the community. Only the interacting parties can themselves report the outcome of the transaction (satisfactory vs. unsatisfactory). • No Centralized/Shared Repository: There is no shared repository where transaction outcome details can be stored. Each participant itself stores the information. • No Learning Behavior: Each Web service follows its own defection/cooperation strategy, which is geared towards providing the maximum benefit, and may change over time. The services cannot learn a new strategy from their peers. • Population Dynamics: Services may enter or leave the system at their will. The volatility of the environment implies that traditional security technologies as digital certificates, encryption, etc. prove inadequate for expressing and capturing the uncertainty of trust.

Chapter 3

Reputation Information Creation

The reputation information is generated after the completion of a transaction between two entities. As mentioned in previous chapters, the entity that provides a specific functionality in the transaction is termed as a service provider and the entity requesting that functionality is known as a service consumer in a service oriented environment. Thus, reputation information is created when a consumer rates the services provided by the service provider according to some pre-defined scale. In this chapter, we provide the details about the various facets of reputation information creation on the service Web and the challenges there in. One of the objectives of our research is to design a new approach for reputation management that avoids the drawbacks of third-party reputation systems based on a centralized reputation manager and provides a reliable assessment of a service’s behavior. In our daily lives, we evaluate the behavior of a subject over several attributes and assess the corresponding reputation according to the perceived quality of each attribute. It is the aggregate of all these quality values that determines the reputation of the subject. Similarly, in our proposed approach we view the reputation of a Web service as a reflection of its quality (QoW S).

3.1 Parameters Reflecting the Quality of Web Services The quality of service (QoS), is defined as “a set of qualities related to the collective behavior of one or more objects” [19]. In other words, QoS is “a set of quantitative and qualitative characteristics of a system necessary to achieve the required functionality of an application” [135]. We adopt this definition of QoS and extend its application to the domain of Web services with related constraints, similar to prior works as [88, 75, 93, 78, 49]. The quality of Web service (QoW S) is a mapping between a set of quality parameters and a set of values or ranges of values. There are two types of QoW S parameters: non-exact and exact parameters. Non-exact QoW S parameters are those to which only approximate and often subjective values may be assigned. Examples Z. Malik and A. Bouguettaya, Trust Management for Service-Oriented Environments, DOI 10.1007/978-1-4419-0310-5_3, © Springer Science + Business Media, LLC 2009

31

32

3 Reputation Information Creation

include security, privacy preservation, and scalability. Exact QoW S parameters are those that may be measured and to which numerical values may be assigned. Examples include a services’ response time, invocation fee, availability, accessibility, reliability, etc [75, 88]. A Web service’s response time measures the delay between the moment when a request is sent and the moment when the service is rendered. The invocation fee is the cost that a service requester pays to the service provider to use the service. A service’s availability represents the probability that a service is operating at any given moment and is available to perform its functions. Accessibility is the degree that a Web service is capable of serving a request. It may be measured by the ratio between the number of requests being sent to the Web service and the number of requests that are effectively served. Note that availability is different from accessibility; a service may be available but, due to its overload, it is not accessible to some requesters. A service’s reliability is the probability that a request is served within a maximum expected time frame defined by the Web service. The number of failures per month or year could be a good measure of reliability. In contrast to availability, reliability is defined in terms of a time interval instead of an instance in time. A highly reliable service is one that will most likely continue to work without interruption during a relatively long period of time. This is a subtle but important difference when compared to availability. If a service is down randomly for one millisecond every hour, it has an availability of over 99.9 percent, but is still highly unreliable. Similarly, a service that never fails but is shut down for two weeks every August has a high reliability but only 96 percent availability [38]. The list of QoW S parameters mentioned above is not exhaustive and some readers may have different views regarding the definition / applicability of a few parameters. In defining the RATEWeb system, we assume that mathematical values can be assigned for each quality parameter that is included in the model [88, 75, 93, 78, 49]. In the context of service-oriented environments, three types of QoW S exist: provider-promised QoW S (QoW Sp ), consumer-expected QoWS (QoWSr ), and servicedelivered QoW S (QoW Sd ). The QoW S p values are those that are advertised by the service provider through the service registry. Several models have been proposed over recent years for this purpose that range from extending the service registries with QoW S information to agent-based frameworks that use ontologies [122, 111, 73, 75, 93, 49]. QoW Sr represents the preference of the service consumer for each quality parameter. QoW Sd represents the actual values that are mapped to the different quality parameters after the consumer interacts with the provider. In other words, QoW Sd represents the consumers’ perceived or assigned values for each quality parameter. For example, in Figure 1.2 the Credit History service (CH) may advertise that it is able to provide credit reports of individuals for “last ten years” (i.e., QoW S p : credit record of last ten years). A Car Broker service (CB) may need to retrieve the credit history of an individual for only the “last seven years” (i.e., QoW Sr : credit record of last seven years). Since CH’s QoW S p offer is available along with the service description, CB can see that CH can fulfill its requirement (QoW Sr ) without actually invoking the service. Assume that when CB does interact with CH, it finds that CH only delivered the “credit record of last three years” (i.e. QoW Sd : credit record of last three years). Clearly this is unacceptable

3.1 Parameters Reflecting the Quality of Web Services

33

for CB, and it may not have interacted with CH had it known the true estimate of CH’s QoW Sd . The reputation of CH provides this estimate. Raters can provide their experiences in how much CH’s QoW S p and QoW Sd differed. If this difference is not large CH is deemed trustworthy, as it delivered what it promised. In contrast, a large difference between QoW S p and QoW Sd means CH did not deliver according to its promise, and hence it is untrustworthy. QoW Sd is an approximation of the actual quality of the parameters. Many QoW Sd parameters will depend on various factors as network traffic, communication infrastructures, etc. Consequently, different consumers may perceive the quality differently even when the provider behaves consistently for all consumers. Thus, an exact estimation of such parameters may not be a realistic assumption. This is in accordance with our real-life reputation gathering methods. For example, to evaluate a subject’s reputation, many parameters are assigned random and subjective quality values instead of exact ones. The human individual then assimilates the varied approximate experiences and assesses a reputation value. Although human intelligence is unmatched and human reputation assessment is a complex process, we intend to emulate the human ability of using approximate quality values for reputation assessment. We assume that consumers agree on the ranges, types, etc. of the values they should assign for each parameter. For instance, the ontologies proposed in [25, 93] can be used for this purpose. How different values are assigned to the QoW Sd parameters is out of the scope of our work. Our focus is only on using these values in context of reputation. Let S and T be the set of provider Web services and the set of service consumers respectively. Let Φ be the universal set of quality parameters. Φ may be represented as a p-element vector (φ1 , .., φ p ) where φk is the kth quality parameter. Each Web service s j ∈ S advertises a promised quality QoW S p (s j ) (e.g., appending the service’s QoW S p to its description in the service registry). QoW S p (s j ) assigns values or ranges of values to each quality parameter φk . When a service requester tx ∈ T invokes the service s j , each quality parameter φk in Φ gets assigned a delivered quality xj value φk (post-transaction completion). For this invocation of service s j , the vector QoW Sd (s j ,tx ) = {φ1x j , .., φ px j } is called the delivered quality of Web service. Since multiple quality parameters that are used, may have varied measuring scales, types, etc., we need to first normalize each φk for accurate quality comparisons. In the following, we show how this can be achieved. We will use the notation of φ k instead of φkx j for the kth quality parameter for clarity. Different approaches exist for normalizing attributes in decision making problems. The widely used Simple Additive Weighting method reaches ranking results very close to those of more sophisticated methods [149]. The QoW S values are scaled to lie in the interval [0, 1]. Different quality attributes have different optimal values in the given interval. For example, if cost is considered as a quality attribute, it’s optimal value is close to the minimum (0). Alternately, reliability and availability have optimal values nearing the maximum (1). We denote the quality attributes that have optimal values close to 0 by φk− and the ones that have optimal values close to 1 by φk+ . The values are then normalized as:

34


norm(φk− ) =

φkmax − φk φkmax − φkmin

(3.1)

norm(φk+ ) =

φk − φkmin φkmax − φkmin

(3.2)

where φkmax is the maximum value for the kth. quality attribute and φkmin represents the corresponding minimum value.

3.2 Reputation Bootstrapping Reputation is a social concept, and its applicability in developing communities or maintaining relationships in social networks has been thoroughly studied [109, 151, 91]. The computer science literature extends and builds upon this study of reputation to theoretical areas and practical applications, as a means to establish trust [34]. However, most of these works have focused on solutions for reputations storage, collection and aggregation, incentives-based schemes to encourage feedback reporting, etc. Little attention has been given to the bootstrapping problem, and majority of the proposed solutions assume a “running-system,” where reputations already exist [7]. We focus on reputation bootstrapping, and assume that existing solutions for other facets of reputation management mentioned above are adequate. Comprehensive literature reviews are available in [91, 141, 7]. In what follows, we give a brief overview of the existing solutions for reputation bootstrapping. Since social networks, agent-based communities, auction portals, and P2P systems employ similar and usually overlapping strategies, we provide a generalized discussion of the solutions. The approaches that consider the bootstrapping problem often adopt solutions that may not be fair to all system participants. For instance, a popular approach is based on assigning neutral or default reputation values to newly deployed participants, or newcomers [91]. This approach has the disadvantage that it can either favor existing participants or favor newcomers. If the initial reputation is set high, existing participants are disadvantaged, as the newcomer would get preference over existing participants who may have worked hard to attain their reputation. This encourages malicious providers to deploy new identities periodically for “white-washing” their bad reputation record. Thus, [156] states that “punishing,” i.e., assigning a low initial reputation is the best alternative. However, existing participants are privileged if low initial values are assigned, as a newcomer may not be able to win a consumer’s favor with its low reputation [92, 141]. To the best of our knowledge, only a couple of previous works have attempted to solve the bootstrapping problem without using a default value. For example, the endorsement principle proposed in [92] states that a participant with unknown reputation may acquire reputation through the endorsement of other trusted participants (ones with high credibility), and the endorsee’s actions directly affect the endorser’s

3.2 Reputation Bootstrapping

35

credibility. However, this technique may prove to be problematic as it would not be easy for a newcomer to get itself endorsed by an existing participant. The technique proposed in [44], aggregates all transaction information on first-time interactions with newcomers. The aggregate information enables a consumer to calculate the probability of being cheated by the next newcomer. This adapts well to the current rate of white-washing in the system. Our approach is inspired by this [44] technique. However, our approach differs from this work in that we do not assume that peer services can monitor each other’s interactions. We believe that such a simplifying assumption is unrealistic for the service Web. The expanse of the service Web and privacy considerations are major impediments in this regard. A Web service exposes an interface describing a collection of operations that are network-accessible through standardized XML messaging [106]. We propose to extend the traditional (publish-discover-access) Web service model, and introduce the concept of community to aid in the bootstrapping process. As mentioned earlier, a community is a “container” that groups Web services related to a specific area of interest (e.g., auto makers, car dealers) together. Communities provide descriptions of desired services (e.g., providing interfaces for services) without referring to any actual service. Ontologies are used to serve as templates for describing communities and Web services. An ontology typically consists of a hierarchical description of important concepts in a domain, along with descriptions of their properties. The notion of concept in ontologies is similar to the notion of class in object-oriented programming. Each concept ci has a set of properties Pi = {pi1 , ..., pim } associated with it that describe the different features of the class. An ontology relates classes to each other through ontology relationships. Examples of relationships include “subclassof”, “superclassof”. Communities are defined by community providers as instances of the community ontology (i.e., they assign values to the concepts of the ontology). Community providers are generally groups of government agencies, non-profit organizations, and businesses that share a common domain of interest. In our model, a community is itself a service that is created, advertised, discovered, and invoked as a regular Web service, so that it can be discovered by service providers. Service providers identify the community of interest and register their services with it. We use the Web Ontology Language (OWL) for describing the proposed ontology. However, other Web ontology standards could also be used. Further details on the use of ontologies for describing communities can be found in [15]. In our model, Web services in a particular domain (registered with the same community) may aid each other in assessing the initial reputation of a newcomer [87]. We propose two reputation bootstrapping approaches. The first approach relies on the cooperation among services, which computes the reputation of newcomers in a P2P manner. The second approach functions under a “super-peer” topology where the community provider is responsible for assigning the newcomer’s reputation. Details of the two approaches follow.

36


3.2.1 Option I: Adapting Initial Reputation to Majority Behavior We propose a reputation bootstrapping technique that adapts according to the behavior of majority of services. Our approach is inspired by the techniques presented in [45] for P2P systems. However, our approach differs from [45] in that we do not assume that peer services can monitor each other’s interactions. We believe that such a simplifying assumption is unrealistic for the service Web. The expanse of the service Web and privacy considerations are major impediments in this regard. Thus, unlike [45], our proposed model does not support a “shared” service interactions history, and the sharing of interaction histories is left at the discretion of the participating services. Also, we do not assume reciprocative actions for Web services (they may engage in one-off transactions). Moreover, we provide options to bootstrap the reputation of newcomers in cases where no service is willing to share its interaction history. In Figure 3.1, we provide the stepwise details of our proposed framework. A newcomer registers with a community to offer it’s services (Step 1 in Figure 3.1). After discovering the newcomer, the consumer asks the existing services for the newcomer’s reputation (Step 2 in Figure 3.1). Since no service has yet interacted with the newcomer, it has no reputation record available (Step 3 in Figure 3.1). At this point, the consumer can bootstrap the newcomer’s reputation to decide whether or not to interact with it.

Fig. 3.1 Reputation Bootstrapping Using an Adaptive Approach

Under the proposed mechanism, the consumer can bootstrap the newcomer’s reputation according to the rate of maliciousness in the community. The rate of maliciousness (denoted ℜ) is defined as the ratio of the number of transactions where the providers defect, to the total number of transactions. Thus, ℜ lies in the range [0, 1].


37

A provider’s “defection” is measured after each individual transaction, by the service consumer (denoted rater). Multiple interactions with the same provider count as different transactions. If the provider performs satisfactorily in the transaction, the rater can label the transaction as “acceptable.” Alternatively, the transaction is labeled as “defective.” Thus, defection (denoted D) can be represented as a binary. Since each provider may be rated along several quality attributes, the aggregated value of all the quality attributes can be used to estimate the value of D. For instance, if the aggregated quality value is below a certain threshold, D is true, otherwise it is false. Since service raters can differ in their total number of transactions, and the number of defective transactions experienced, we can expect a variation in the value of ℜ across different service raters. In essence, the value of ℜ would depend on each rater’s personal experience, and the manner in which it estimates D after each transaction. The basic idea of the proposed scheme is for the consumer to assign a high initial reputation value when ℜ is low, and a low reputation value when ℜ is high. This allows the consumer to adapt to the state of the system (i.e., defective vs. acceptable transactions). Formally, for each service consumer i, ℜ is defined as: ℜi =

Di Ti

(3.3)

where Di is the number of transactions where providers have defected for consumer i, and Ti is the total number of transactions that consumer i has undertaken. Note that in defining ℜ, we use a rater’s complete transaction record, instead of using only the transactions conducted with newcomers. It may be argued that ℜ should be measured as the ratio of the number of defective transactions with newcomers to the total number of transactions conducted with the newcomers. However, in our opinion this may not produce the ideal results, as it inspires white-washing. For instance, newcomers can stay honest for the first transaction, and act maliciously thereafter to gain undue advantage (even if it is only for a couple of transactions). Then they can leave the system, and join in later with a new identity. Since the first interaction is labeled satisfactory (for all newcomers), ℜ stays low in the system, ensuring a high reputation-bootstrap value for the newcomers. In contrast, estimating ℜ over all the rater transactions can discourage white-washing. Since dishonest behavior is a prerequisite of white-washing, estimating ℜ over all the rater transactions ensures that ℜ will increase with every defective transaction. This in turn brings the reputationbootstrap value for a newcomer down. Moreover, since the severity of defective transactions varies, the service rater can assign relative weights to the transactions. For example, in a “high impact” transaction where the consumer suffers a huge loss, as a consequence of the provider’s defection, the consumer may count two (or more) defective transactions instead of one (while increasing the Ti count by only one), to increase ℜi . The assignment of such weights is left at the discretion of the service rater. Obtaining Di and Ti from the raters poses a privacy risk as the total transactions volume, transactions identification (defect or not and with which provider), etc. may reveal sensitive information about the raters. Thus, in our model only ℜ i is shared

38


between the different consumers, instead of Di and Ti . We also allow the consumers to specify the time over which ℜ is to be calculated. This allows a consumer to adapt to the “current trend” of the system (depending on how current is defined). The consumer can then aggregate the different ratios collected from the raters. A simplistic solution is to compute a weighted average of all ℜi ’s. The weights are decided according to the credibility of the contributing rater, which may be calculated using techniques similar to ones presented in [91, 7, 64]. This is shown as Step 4 in Figure 3.1, where the credible raters (ones with a “C”) are consulted. In Step 5, all ℜ i ’s are aggregated and the consumer decides whether to interact with the newcomer in Step 6a. If sufficient ratings are not submitted in Step 4, the consumer may turn to the community provider for bootstrapping the newcomer’s reputation (Step 6b in Figure 3.1). The community provider may provide the service for free, or charge a nominal fee (Step 7a in Figure 3.1). The community provider can employ a number of techniques in assigning the initial reputation value (Step 7b in Figure 3.1), which will be discussed shortly. The initial reputation value is then communicated to the consumer in Step 8. Based on this, the consumer can make his decision to interact with the newcomer in Step 9. Thus, even in the absence of sufficient ℜ i , the consumer is still able to bootstrap the newcomer’s reputation. Details of Step 7b follow.

3.2.2 Option II: Assigned Initial Reputation The community provider may assign a reputation value for each newcomer registering with the community and convey the assigned value to any prospective service consumer. The community provider may employ one of two ways in bootstrapping the newcomer’s reputation: assign a default value, or evaluate the newcomer (Case I and II in Figure 3.2 respectively). 3.2.2.1 Option II - Case I: Default Initial Reputation We extend the model presented in Figure 3.1, to show how a default value may be assigned as the newcomer’s reputation. Upon registration, the newcomer may present some credentials that enable it to buy initial reputation from the community provider. The newcomer may belong to the same service provider group as an existing reputable service. In this case, presenting the authenticated credentials of the existing service may guarantee initial reputation equal to that of the existing service. This is shown in steps a, b and c in Figure 3.2-Case I. Endorsement techniques [92] can also be incorporated in this strategy where newcomers may present the credentials of any service that is willing to endorse them. Alternatively, an average of all providers’ reputation may be assigned. In [44], it was shown that such an averag-


39

Fig. 3.2 Reputation Bootstrapping through Assignment

ing technique provides the best results in terms of fairness and accuracy. Without delving into much detail, we also adopt an average model in this case. 3.2.2.2 Option II - Case II: Initial Reputation Evaluation In the second case, the community provider may be asked to evaluate the newcomer. The evaluation period is determined by the community provider, and the newcomer has no knowledge of the time and number of transactions conducted during the evaluation period. It may happen that normal transactions by other consumers (who may have ascertained the newcomer’s reputation through Option-I) are also conducted during the evaluation period. Services with high credibilities (known as elders) are asked to evaluate the newcomer. The feedbacks are weighed according to elder credibilities which are as-

40


sessed using separate techniques [64]. We assume that some form of incentives (monetary or reputation) are present for services to act as evaluators. For instance, during registration (Step 1 in Figure 3.2-Case II), a newcomer may be asked to pay a monetary amount to cover such expenses (Step 2 in Figure 3.2-Case II). Similarly, the reputation incentives may be provided as means to increase the overall reputation of evaluators throughout the community. We assume that service evaluation is a voluntary process and services are not penalized for declining the community provider’s offer to act as evaluators (Step 3 in Figure 3.2-Case II). However, it is expected that with the mentioned incentive mechanisms in place, services will engage in the evaluation process. Our proposed scheme is inspired by the concept of “reviewers” in the academic world. For example, researchers are often asked by the US National Science Foundation (NSF) to act as referees (panelists) for evaluating different funding proposals. The evaluators are provided with nominal monetary and reputation (among their peers) incentives. Although researchers may decline the NSF offer, finding evaluators is guaranteed most of the times. In most situations, the evaluators may be required to pay for the services of the newcomers. “Credit agencies” may aid in such situations so that an evaluator does not suffer a monetary loss by getting a service it did not need in the first place. The evaluators send their “original” account details to the community provider (Step 4 in Figure 3.2-Case II). The community provider informs the credit agency of the evaluation transaction, and the agency is expected to respond with a “disposable” account number which is expected to last for only one transaction (Step 5 in Figure 3.2-Case II). This is analogous to the service started by American Express, where disposable account numbers were assigned to users wishing to engage in e-commerce transactions without disclosing their actual account details [104]. The community provider communicates the generated account number (acc.no.) to the chosen evaluator, to cover the invocation cost (Step 6 in Figure 3.2-Case II). The evaluators collect the required data for the newcomer (Step 8 in Figure 3.2-Case II) through interactions. It is expected that some Web service interactions may require the delivery of tangible products to the consumer (Step 8 in Figure 3.2-Case II). When a transaction is completed, the newcomer is informed by the credit agency about the “fake” charged account (Step 9a in Figure 3.2-Case II). Moreover, the evaluators are required to return the delivered product in a desired amount of time (since this is only an evaluation). Since evaluators are not “charged” (disposable accounts), it is in the best interest of the newcomer to accept the returned product (Step 10 in Figure 3.2-Case II). The delivery and return processes are carried out through a delivery agency which is expected to function in an honest manner since it is not competing with either the newcomer or the evaluator. To ensure transparency, the delivery agency is required to inform the community provider about any product delivery or return (Steps 9a and 11 in Figure 3.2-Case II). This prevents both newcomers and evaluators from lying about the product delivery status. This is analogous to the services provided by delivery agencies as UPS, FedEx, USPS, etc. In cases where the evaluator defaults by not sending the product back in the desired amount of time, the community provider can charge the evaluator’s original account and pay the newcomer. Since the newcomer has no knowledge of the authenticity of the account


41

prior to, or during the transaction, it is expected to behave normally, i.e., the newcomer cannot “pretend” to act fairly to mislead evaluation. Therefore, the evaluation mechanism provides fair and accurate results (at the expense of the evaluation time period).


Chapter 4

Reputation Assessment

In this chapter, we describe the assessment module of the RATEWeb framework: a Reputation Assessment framework for Trust Establishment among Web services. The focus is on providing a comprehensive solution for assessing the reputation of service providers in an accurate, reliable, and decentralized manner. Since reputation forms an integral part of service-oriented environments in relation to the dynamic selection of services, on-the-fly composition of value-added enterprises, and optimization of service tasks, we have chosen Web services as a representative domain. However, RATEWeb can be extended and used in other contexts and domains. The proposed framework takes into account the presence of malicious raters that may exhibit oscillating honest and dishonest behaviors. Previous solutions for reputation assessment make simplifying assumptions that may not apply in a service-oriented environment. For example, [66] relies on pre-existing trusted parties, in [31] and [20] data needs to be distributed according to a certain statistical distribution, a common set of past providers is required in [146] for evaluating rater credibility, and in [95] human intervention is required, meaning the assessment process is not fully automated. Other similar solutions either do not consider all facets of reputation [1, 65, 116] or are focused primarily on efficiency/performance (rather than functionality) [36]. We develop a simple and holistic solution that provides an automated and adaptive reputation mechanism, whereby reputations are evaluated through a number of heuristics with different perspectives providing a fair and accurate assessment [86].

4.1 Web Service Reputation RATEWeb’s reputation model is distributed in nature. In contrast to third-partybased traditional approaches for reputation management, no single entity is responsible for collecting, updating, and disseminating the reputation of Web services. Each service consumer records its own perceptions of the reputation of only the services it actually invokes. This perception is called personal evaluation. For each Z. Malik and A. Bouguettaya, Trust Management for Service-Oriented Environments, DOI 10.1007/978-1-4419-0310-5_4, © Springer Science + Business Media, LLC 2009

43

44

4 Reputation Assessment

service s j that it has invoked, a service consumer tx maintains a p-element vector PerEval x j representing tx ’s perception of s j ’s behavior. In addition to all the quality attributes, PerEval x j contains the time stamp of the interaction between tx and s j . The time stamp is digitally signed by s j to make sure that tx does not claim to have values for PerEval x j without a legitimate interaction. Note that digitally signing the time-stamp does not ensure that tx will report true values for QoW Sd . However, it does ensure the authenticity of the tx :s j interaction. For instance, in our running example from Figure 1.2, in the absence of a time-stamp, CB may provide the vector PerEvalCB:LC , when it has not interacted with LC. The issue of falsifying the experienced quality will be discussed in the upcoming sections. PerEval kx j is tx ’s perception of service s j ’s reputation with regard to the quality parameter φk . Different strategies may be adopted in updating PerEval x j . A simple one may be a perinvocation update. Upon an invocation of service s j , the delivered quality QoW Sd is compared to service s j ’s promised quality QoW S p and, if necessary, a reputation updating algorithm is run to compute the new personal evaluation of service s j . In essence, personal evaluation reflects the QoW S performance of the provider in consumer’s views. The personal evaluation PerEval x j , represents only consumer tx ’s perception of the provider s j ’s reputation. Other service consumers may differ or concur with tx ’s observation of s j . A service consumer that inquires about the reputation of a given service provider from its peers may get various differing personal evaluation “feedbacks.” To get a correct assessment of the service provider’s behavior, all the personal evaluations for s j need to be aggregated. The aggregation of all personal evaluations to derive a single reputation value is defined as the service provider’s assessed reputation in that service’s view. The service consumers may employ different reputation aggregation techniques. Therefore the ‘assessed reputation’ for the provider may be different at each consumer. In light of the feedback-based reputation models, the personal evaluations (as calculated by different service consumers) can be considered as feedbacks, and the assessed reputation as the aggregation of those feedbacks. Note that the notion of assessed reputation as defined in our model differs from the definition of global reputation, in that it is not consistent across all services, i.e., it is an aggregation of all personal evaluations in only consumer tx ’s view. Definition: The reputation of a Web service s j ∈ S, Reputation(s j ), as viewed by a service consumer tx that wants to invoke s j , is the set of all personal evaluations that other service consumers have submitted ratings for service s j . Note that those service consumers which have not interacted with s j do not contribute to s j ’s reputation. Let L denote the set of service consumers which have interacted with s j in the past and are willing to share their personal evaluations of s j . We assume that L is not empty, i.e., some service willing to share information can be found. Thus, L ⊆ T with L 6= 0/ and each service x in L has PerEval xj values for s j . Then, reputation of s j , as viewed by a consumer x is defined as: Reputation(s j ) =

^

x∈L

(PerEval xj )

(4.1)

4.2 Reputation Evaluation Metrics

45

where represents the aggregation function. It can be as simple as representing the union of personal evaluations where the output is a real number, or an elaborate process that considers a number of factors to assess a fairly accurate reputation value. An absolute limit on the maximum value (Amax ) for Reputation(s j ) may also be placed by the service consumer to dilute the effects of indefinite reputation growth. Equation 4.1 provides a first approximation of how the assessed reputation may be calculated. However, the assessed reputation calculation involves various factors that need to be precisely defined and measured. In the following, we build upon this equation to calculate the assessed reputation score. We provide details of the various reputation evaluation metrics defined. V

4.2 Reputation Evaluation Metrics In RATEWeb, reputation management is a cooperative process in which various Web service consumers participate. Since service raters may differ in their provided reputation ratings, it is necessary to define mechanisms that can aid in deriving an accurate reputation value in presence of differing feedbacks. We have attempted to define the evaluation metrics such that the reputation of Web services can be captured as accurately as possible. Previous works as [146, 36, 17, 1, 115, 95] have defined similar metrics. However, none of the existing works have used metrics in such an extensive manner to capture the different facets of reputation, thereby effecting the overall accuracy of the models. RATEWeb is designed in accordance with real world social networks methodologies, which provide better accuracy as they mature, have the ability to evolve, and dynamically evaluate the changing conditions [67]. RATEWeb’s metrics are defined to capture most (if not all) aspects of social reputation. We believe that all the factors are essential for the accurate assessment of a provider’s reputation. The metrics are: 1. Rater Credibility: We enable the service consumers to base their decisions according to the credibility of raters. A service consumer’s credibility determines how much other service consumers may trust its reported ratings regarding the reputation of the Web services it has invoked. This allows us to differentiate between service trust and feedback trust. For instance, a service that does not have high reputation as a provider (low service trust) may be a credible source (high feedback trust) when it comes to judging the behavior of other service providers, and vice versa. The importance of differentiating between service quality and rating quality has been studied before and it is shown that reputation models that do not differentiate offer little resistance to various reputation attacks [146]. 2. Majority Rating: We provide a feedback-based reputation system where service consumers can rate the different Web services. The assessed reputation of a service provider is not a mere aggregation but is evaluated on a majority basis. 3. Past Rating History: We allow the credibility scores of raters to be updated, based on past ratings history.

46


4. Personal Experience for Credibility Evaluation: We consider the possibility of a rater to default, i.e., provide an incorrect feedback. The consumers can evaluate the honesty of the feedback ratings according to the deviation between their personal experience and the ratings reported by other service consumers (raters). 5. Personal Preferences: We provide a personalized reputation evaluation where consumers can weigh the different QRe f attributes according to their own preferences. 6. Personal Experience for Reputation Assessment: We allow incorporating the ‘first-hand interaction’ data in calculating final reputation scores. 7. Temporal Sensitivity: We provide mechanisms to address the temporal sensitivity of ratings, where older ratings are given less weight than present ones. In the following, we define the above mentioned evaluation metrics in detail. We also show how these metrics help in evaluating an accurate reputation score for Web services. Note that we use all the defined metrics in unison to evaluate provider reputations and not in isolation from one another.

4.2.1 Credibility of Raters The foremost drawback of feedback-only based systems is that all ratings are assumed to be honest and unbiased. However, in the real world we clearly distinguish between the testimonies of our sources and weigh the “trusted” ones more than others [130]. A Web service that provides satisfactory service (in accordance with its promised quality (QoW S p )), may get incorrect or false ratings from different evaluators due to several malicious motives. In order to cater for such “bad-mouthing” or possibilities, a reputation management system should weigh the ratings of highly credible raters more than consumers with low credibilities [61, 32, 127, 107, 146]. In RATEWeb, the reputation score of the provider is calculated according to the credibility scores of the raters (used as the weight) [85]. Thus, Equation 4.1 becomes: Reputation(s j ) =

∑tLx =1 (PerEval xj ∗Cr (x)) ∑Lx=1 Cr (x)

(4.2)

where Reputation(s j ) is the assessed reputation of s j as calculated by the service consumer and Cr (x) is the credibility of the service rater x as viewed by the service consumer. The credibility of a service rater lies in the interval [0,1] with 0 identifying a dishonest rater and 1 an honest one. The processes involved in calculating the credibilities of raters are discussed below.


47

4.2.2 Evaluating Rater Credibility There are a few existing online systems such as eBay, Amazon, Yahoo! Auctions, etc. that use a centralized reputation system. Most of these systems rely only on the numerical feedbacks received from different users as a reputation measure, or in some cases supplement these with textual feedbacks also left by the consumer. The reputation values are calculated as simple aggregations of the received ratings, which may not accurately predict the trustworthiness of the providers. For example, in eBay (which is one of the most highly used online reputation systems) the buyers and sellers can rate each other on a three point scale, with +1 for a positive rating, 0 for neutral and -1 for a negative rating. The transaction participants are also asked to leave a textual feedback rating. The centralized eBay reputation system then computes the reputation as a summation of all negative and positive ratings received. Since humans are involved directly in processing the provided information (reputation value plus textual feedback), the eBay system has been successful [113] [57]. Clearly, such a ratings system is not accurate. A user with 50 positive feedback ratings will have a reputation value equaling one with 300 positive and 250 negative feedback ratings [82]. The inability of automated systems to reason in a human-like manner means that the textual feedback will not be of great use. Hence, an eBay-like system may not be practical for the service-oriented environments. We can see from the example of eBay’s reputation calculation methodology that a simple aggregation of feedback ratings does not accurately reflect a user’s reputation. Some other online businesses use an average over all ratings to compute the reputation of a user. For instance, Amazon’s auction site uses this method. It allows transaction participants to rate on a scale from 1 to 5. Then an average of all feedback ratings to date is calculated to compute an overall reputation score. Thus, a user with ratings of 4, 3, 4, 4, 5, and 3 would have an overall reputation score of 3.8. Although this method is an improvement, it still does not accurately reflect the reputation as seen in the real world. Consider another series of ratings: 1, 1, 9, 1, 1, 1, 9, 9, and 1 received for a Web service provider. In an averaging model, the overall reputation score would be 3.7. Clearly, this score is also not in accordance with the ratings received. In online reputation systems similar situations may arise where all the reported ratings are not uniform, either due to differences in raters’ actual experiences or malicious motives. Thus, designing a ratings system that is robust enough to detect and mitigate the effects of disparate ratings is a fundamental issue [33] [143]. To overcome the above mentioned problems, several methods have been proposed in literature that screen the ratings based on their deviations from the majority opinion. Examples include the Beta Deviation Feedback [22], Beta Filtering Feedback [143], Like-mindedness [139], and Entropy-Based Screening [142]. We adopt a similar notion to dilute the effects of unfair or inconsistent ratings. We use a majority rating scheme, in which the “uniformity of ratings” indicates their accuracy. The basic idea of the proposed method is that: if the reported rating agrees with the majority opinion, the rater’s credibility is increased, and decreased otherwise. Unlike previous models, we do not simply disregard/discard the rating if it disagrees

48


with the majority opinion but consider the fact that the rating’s inconsistency may be the result of an actual experience. Hence, only the credibility of the rater is changed, but the rating is still considered. We use a data clustering technique to define the majority opinion by grouping similar feedback ratings together [33] [136]. We use the k-mean clustering algorithm [80] on all current reported ratings to create the clusters. The most densely populated cluster is then labeled as the “majority cluster” and the centroid of the majority cluster is taken as the majority rating (denoted M): M = centroid(max(ℜk )) ∀k where k is the total number of clusters, max(x) gives the cluster ℜ with the largest membership and centroid(x) gives the centroid of the cluster x. The Euclidean distance between the majority rating (M) and the reported rating (V ) is computed to adjust the rater credibility. The change in credibility due to majority rating, denoted by M f is defined as:  √ n p  ∑k=1 (M−Vk )2 1− if ∑nk=1 (M −Vk )2 < σ σ Mf = (4.3) otherwise 1− √ n σ 2 ∑k=1 (M−Vk )

where σ is the standard deviation in all the reported ratings. Note that M f does not denote the rater’s credibility (or the weight), but only defines the effect on credibility due to agreement/disagreement with the majority rating. How this effect is applied will be discussed shortly. There may be cases in which the majority of raters collude to provide an incorrect rating for the provider Web service. Moreover, the outlier raters (ones not belonging to the majority cluster) may be the ones who are first to experience the deviant behavior of the providers. Thus, a majority rating scheme ‘alone’ is not sufficient to accurately measure the reputation of a Web service. We supplement the majority rating scheme by adjusting the credibility of a service rater based on its past behavior as well. The historical information provides an estimate of the trustworthiness of the service raters [143] [127]. The trustworthiness of the service is computed by looking at the ‘last assessed reputation value’, the present majority rating and that service consumer’s provided rating. It is known that precisely defining what constitutes a credible rating is an interesting and hard research problem by itself [146]. However, we have attempted to define the credibility of Web services in a practical manner according to the information available to the service consumer. We define a credible rater as one which has performed consistently, accurately, and has proven to be useful (in terms of ratings provided) over a period of time. Consistency is the defined behavior of a service that exhibits similar results under standard conditions. We believe that under controlled situations (i.e., other variables being the same), a service consumer’s perception of a Web service should not deviate much, but stay consistent over time. We assume the interactions take place at time t and the service consumer already has record of the previously assessed reputations (denoted A), which is defined as:


49

A=

t−k G

t−1

Reputation(s j )t

(4.4)

where Reputation(s j ) is as defined in Equation 4.1 for each time instance t, is the aggregation operator and k is the time duration defined by each service consumer. It can vary from one time instance to the complete past reputation record of s j . Note that A is not the “personal evaluation” of either the service rater or the service consumer but is the “assessed reputation” calculated by the service consumer at the previous time instance(s). If the provider behavior does not change much from the previous time instance, then A and the present rating V should be somewhat similar. Thus, the effect on credibility due to agreement/disagreement with the last assessed reputation value (denoted A f ) is defined in a similar manner as Equation 4.3:  √ n p  ∑k=1 (A−Vk )2 1− if ∑nk=1 (A −Vk )2 < σ σ Af = (4.5) otherwise 1− √ n σ 2 F

∑k=1 (A−Vk )

In real-time situations it is difficult to determine the different factors that cause a change in the state of a Web service. A rater may rate the same service differently without any malicious motive, i.e., accurately (but not consistent with the last reporting). Thus, the credibility of a rater may change in a number of ways, depending on the values of V , M, and A. The equivalence of the majority rating M, submitted personal evaluation rating V and the assessed reputation at the previous time instance A is used in adjusting the service rater’s credibility Cr . The general formula is: Cr (x) = Cr (x) ± ℵ ∗ ϒ

(4.6)

where ℵ is the credibility adjustment normalizing factor, while ϒ represents amount of change in credibility due to the equivalence or difference of V with M and A. The signs ± indicate that either + or − can be used, i.e., the increment or decrement in the credibility depends on the situation. These situations are described in detail in the upcoming discussion. We place more emphasis on the ratings received in the current time instance than the past ones, similar to previous works as [22] [143] [139] [142]. Thus, equivalence or difference of V with M takes a precedence over that of V with A. This can be seen from Equation 4.6, where the + sign with ℵ indicates V ' M while − sign with ℵ means that V 6= M. ℵ is defined as: ℵ = Cr (x) × (1− | Vx − M |)

(4.7)

Equation 4.7 states that value of the normalizing factor ℵ depends on the credibility of the rater and the absolute difference between the rater’s current feedback and the majority rating calculated. Multiplying by the rater’s credibility allows the honest raters to have greater influence over the ratings aggregation process and dishonest raters to lose their credibility quickly in case of a false or malicious rating. The dif-

50


ferent values of ϒ are described next. Adjusting Rater Credibilities: ϒ is made up of M f and/or A f , and a “pessimism factor” (ρ ). The exact value of ρ is left at the discretion of the service consumer, with the exception that its minimum value should be 2. The lower the value of ρ , the more optimistic is the consumer and higher value of ρ are suitable for pessimistic consumers. We define a pessimistic consumer as one that does not trust the raters easily and reduces their credibility drastically on each false feedback. Moreover, honest raters’ reputations are increased at a high rate, meaning that such consumers make friends easily. On the other hand, optimistic consumers tend to “forgive” dishonest feedbacks over short periods (dishonesty over long periods is still punished), and it is difficult to attain high reputation quickly. Only prolonged honesty can guarantee a high credibility in this case. V , M, and A can be related to each other in one of four ways, and each condition specifies how M f and A f are used in the model. In the following, we provide an explanation of each and show how the credibilities are updated in our proposed model using different values for ϒ . 1. The local reported reputation value is similar to both the majority rating and the previously assessed reputation, i.e., (V ' M ' A). The equality M ' A suggests that majority of the raters believe the QoW S of s j has not changed. The service rater’s credibility is updated as: Cr (x) = Cr (x) + ℵ ∗ (

|M f + A f | ) ρ

(4.8)

Equation 4.8 states that since all factors are equal, the credibility is incremented. 2. The individual reported reputation rating is similar to the majority rating but differs from the previously assessed reputation, i.e., (V ' M) and (V 6= A). In this case, the change in the reputation rating could be due to either of the following. First, the rater may be colluding with other service consumers (raters) to increase/decrease the reputation of s j . Second, the QoW S of s j may have actually changed since A was last calculated. The service rater’s credibility is updated as: Mf Cr (x) = Cr (x) + ℵ ∗ ( ) (4.9) ρ Equation 4.9 states that since V ' M, the credibility is incremented, but the factor V 6= A limits the incremental value to ( Mρf ) (not as big as the previous case). 3. The individual reported reputation value is similar to the previously assessed reputation but differs from the majority rating, i.e., (V 6= M) and (V ' A). The individual reported reputation value may differ due to either of the following. First, V may be providing a rating score that is out-dated. In other words, V may not have the latest score. Second, V may be providing a “false” negative/positive rating for s j . The third possibility is that V has the correct rating, while other consumers contributing to M may be colluding to increase/decrease s j ’s reputation. Neither of these three options should be overlooked. Thus, the service rater’s credibility is updated as:


51

Cr (x) = Cr (x) − ℵ ∗ (

Af ) ρ

(4.10)

Equation 4.10 states that since V 6= M, the credibility is decremented. And to cater for the above mentioned possibilities brought in due to the factor V ' A, the value that is subtracted from the previous credibility is adjusted to ( Aρf ). 4. The individual reported reputation value is not similar to either the majority rating or the calculated reputation, i.e., (V 6= M) and (V 6= A). V may differ from the majority rating and the past calculated reputation due to either of the following. First, V may be the first one to experience s j ’s new behavior. Second, V may not know the actual QoW S values. Third, V may be lying to increase/decrease s j ’s reputation. The service rater’s credibility is updated as: Cr (x) = Cr (x) − ℵ ∗ (

|M f + A f | ) ρ

(4.11)

Equation 4.11 states that the inequality of all factors means that rater’s credibility is decremented, where the decremented value is the combination of both the effects M f and A f . Even with the above mentioned techniques in place, every ratings submission that a service consumer receives from service raters may not prove useful. In other words, the consumer’s own experience (denoted OE) with the provider may differ from the rater’s feedback (V ). In RATEWeb, after each interaction, apart from rating the provider s j , the service consumer also evaluates the usefulness of the raters that provided a rating for s j . If the Euclidean distance between OE and Vi (both representing s j ’s assessed reputation) falls below a predefined threshold, Vi is deemed useful, otherwise it is not. The reader may think that the rater and the consumer may disagree depending on some objective feature of the service. RATEWeb avoids such a situation by considering the “personalized preferences” (for different attributes) of both the raters and the consumers. Details are presented in the next section. Service ratings are historical data, i.e., ratings from previous time instances. For example, if the provider is evaluated at time t, then the historical data would contain ratings from times t − 1,t − 2, ...,t − n. The service consumer would submit a “usefulness rating” at time t for the rater’s submission at t − 1. The usefulness of a service is required to calculate a service rater’s “propensity to default,” i.e., the service rater’s tendency to provide false/incorrect ratings. There may also be cases where raters alternate between being useful and not useful, over a period of time. Thus, to get a correct estimate of the rater’s propensity to default, we compute the ratio of the total number of times the ratings submission was useful (k) over the total number of submissions (n). This is similar to the manner in which peer recommendations are evaluated for usefulness in “recommender systems” [72, 128]. The usefulness factor (u f ) is: ∑k Ui u f = ni=1 (4.12) ∑x=1 Vx

52


where Ui is the submission where the rater was termed ‘useful’ and Vx denotes the total number of ratings submissions by that service. The rater’s credibility (calculated using either of Equations 4.8 through 4.11) is then adjusted as: Cr (x) = Cr (x) ∗ u f

(4.13)

4.2.3 Personalized Preferences Service consumers may vary in their reputation evaluations due to their differences in QoW S attribute preferences over which a Web service is evaluated. For instance, consider reliability, availability, price, security, and privacy as the QoW S attributes over which Web service’s reputation is evaluated. Some service consumers may label Web services with high reliability as more reputable while others may consider low-priced services as more reputable. We allow the service consumers to calculate the reputation scores of the Web services according to their own personal preferences. Each service consumer stores its QoW S attribute preferences in a reputation significance vector (RSV). Since, service consumers can change their preferences from one transaction to the other, the RSV is submitted with each ratings submission. The service consumers can then choose either to accept the reputation evaluation scores of the raters or compute the scores themselves if they have a different RSV. In the latter case, the rater is asked for the individual QoW S attribute values instead of the computed personal evaluations. In this manner, the consumers have the ability to weigh the different attributes according to their own preferences. Let φh (s j , u)x denote the rating assigned to attribute h by the service rater x for service provider s j in transaction u, m denote the total number of attributes and RSVh denote the preference of the service consumer for attribute h. Then, the local reputation for s j as reported by service rater x is defined as: PerEval xj =

x ∑m h=1 (φh (s j , u) ∗ RSVh) m ∑h=1 RSVh

(4.14)

4.2.4 Temporal Sensitivity Reputation information of a service provider decays with time [86][90]. Hence all the past reputation data may be of little or no importance. For instance, a Web service performing inconsistently in the past may ameliorate its behavior. Alternatively, a service’s performance may degrade over time. It may be the case that considering all historical data may provide incorrect reputation scores. In order to counter such discrepancies, we incorporate temporal sensitivity in our proposed model. The rating submissions are time-stamped to assign more weight to recent observations and less to older ones. This is termed as “reputation fading” where older perceptions


53

gradually fade and fresh ones take their place. We adjust the value of the ratings as: PerEval x j = PerEval x j ∗ fd

(4.15)

where PerEval x j is as defined above and f d is the reputation fader. In our model, the recent most rating has the fader value 1 while older observations are decremented for each time interval passed. When f d = 0, the consumer’s rating is not considered as it is outdated. The “time interval” is an assigned factor, which could be anywhere from a single reputation inquiry, ten inquiries or even more than that. All inquiries that are grouped in one time interval are assigned the same fader value. In this way, the service consumer can define its own temporal sensitivity degree. For example, a service can omit the fader value’s effect altogether by assigning it a null value. We propose to use a fader value that can then be calculated as: f d = √1P , where u Pu is the time interval difference between the present time and the time in which the rating was collected from the rater. This allows the convergence of reputation to a very small value as time passes. Note that the consumer can assign a group of ratings collected at different times to have the same time-stamp, and hence lie in the same time interval. As mentioned earlier, other calculated values for the fader are also acceptable.

4.2.5 First-hand Knowledge Most of the service consumers that have interacted with a Web service provider in the past and were satisfied, continue/prefer to interact with that particular service. Users seldom switch their basic providers online for fear of degrading quality. Web services are inherently dynamic and new services (with better QoW S) may be introduced in the system any time. Moreover, services with low reputation scores may improve upon their score. However, if service consumers only interact with trusted Web services, they may miss better options in terms of QoW S. We allow the service consumers to incorporate their first-hand interaction knowledge for calculating the final reputation score of the Web services. To the best of our knowledge, presentday reputation systems only allow the users to view/derive a reputation value of the provider based solely on the testimonies of different users. The user’s own experience is of a subjective nature which is not factored in the reputation value. Usually, the users do not consider the providers with whom they had a bad experience in the past, even if they receive good reputation scores from other users. In RATEWeb, reported ratings are combined with first-hand knowledge to derive the reputation score. This enables the consumer to consider all Web service possibilities and select the best one. Thus, the equation for assessed reputation calculation becomes: Reputation(s j ) =

∑Lx=1 [

x ∑m h=1 (φh (s j ,u) ∗RSVh ) m RSV ∑h=1 h ∑Lx=1 Cr (x)

∗ fd ∗Cr (x)]

(4.16)

54


Figure 4.1 shows the pictorial representation of the reputation assessment algorithm that uses the metrics defined above. The input to the algorithm is a list of service raters that have interacted with the service provider(s) in the past and thus have reputation ratings for them. Note that the algorithm iterates over the complete list of potential service providers obtained from a UDDI registry. The output of each algorithm invocation is the service provider with the highest reputation. To simplify the representation, we do not show loops or update processes in Figure 4.1. ð ÔzÝÞÐ ñòÓ éÐ6Ûózé:Ïì ôzÓ í#Ïì Ò#Ð Ï6ì é¡Ð õÒ#Ðqõ:Ò#ô:Ïì ÏÝzÞÐ Ò#Ð Ó ÛÔ#é¡ó Ûì Ð õ:ÏÉöNÓ ó ó Ïì ÏÔÐéÏì ôzÓ í#ÏÝzì ÛôzÓ öNÏì é÷:ÏÓ Ô#Õ}Ó Ôô#ÏzéÐ Ó ÕNÒÐ Ïö

ÎcÏ#Ð6Ñ*ÒÐ Ó ÔÕ

Ös×ÉØgÙ*Ö

î*Û

ÚÛÜÝzÞÐ ÏÖ

ï*Ïé ÚÛzÜÝzÞ'Ð Ïß

ÎlÏ#Ð}ä å

Ú*ÛÜÝ:ÞÐ Ï

ÎlÏ#Ð6æ*çÉÔè/Ò:é'Ð

ÑQÏÝzÞ#Ð Ò#Ð Ó ÛÔ

ê6ëÝ:Ïì Ó ÏÔ:í#Ï

ÎcÏÐ¡á ÚÛÜÝzÞÐ ÏÉÚ*à Î¡Ï#Ð>âã

æcÞÐ Ý:ÞÐ ñ#øÏì ôzÓ í#Ïè

Trust Management for Service-Oriented Environments

Trust Management V

Trust

Trust

Trust

Trust

Trust

Risk Management in Post-Trust Society

Trust

Management Practices in High-Tech Environments

Security and Trust Management - STM 2010

Trust Management, 2 conf., iTrust 2004

Trust Networks for Recommender Systems

The Trust

Unshakeable Trust

Ruthless Trust

Unshakeable Trust

Perfect Trust

Trust Me

Trust Fund

Breeding rice for drought-prone environments

MPLS Environments

Obesogenic Environments

Educational Environments

Perfect Trust

Shattered Trust

Trust Me

Blood Trust

Trust Management for Service-Oriented Environments

Trust Management V

Trust

Trust

Trust

Trust

Trust

Risk Management in Post-Trust Society

Trust

Management Practices in High-Tech Environments

Security and Trust Management - STM 2010

Trust Management, 2 conf., iTrust 2004

Trust Networks for Recommender Systems

The Trust

Unshakeable Trust

Ruthless Trust

Unshakeable Trust

Perfect Trust

Trust Me

Trust Fund

Breeding rice for drought-prone environments

MPLS Environments

Obesogenic Environments

Educational Environments

Perfect Trust

Shattered Trust

Trust Me

Blood Trust

Recommend Documents