A Reputation Pattern for Service Oriented Computing

A Reputation Pattern for Service Oriented Computing Pan Li, Meng Xiangxu

Shen Zhiqi

Yu Han

Department of Computer Science and Technology Shandong University Jinan, China [email protected], [email protected]

School of Electrical & Electronic Engineering Nanyang Technological University Singapore [email protected]

School of Computer Engineering Nanyang Technological University Singapore [email protected]

Abstract—Trust problems exist in open distributed service oriented computing environments. A lot of research work has been done on the theories and applications of trust and reputation management in service oriented environment. However, the design expertise on trust is not well documented yet. In this paper we propose to use trust patterns for documenting solutions for trust problems. The main benefit of using trust patterns is that it decouples the application domain expertise from the trust expertise. We also present a reputation service pattern as a solution to the trust problem in service provision which is one of the significant problems in service oriented computing environments. Keywords- service oriented computing; design pattern; trust; trust pattern

I.

INTRODUCTION

Service oriented computing (SOC) [1] is a new and promising paradigm for open, distributed applications. Web Services, along with a group of standards, has become de facto integration technology for realizing SOC. Simple Object Access Control Protocol (SOAP) is commonly used as the communication protocol. Web Services Description Language (WSDL) has become the de facto standard for describing the interfaces of a Web service. And The Universal Description, Discovery and Integration (UDDI) specification defines a directory service for Web services. UDDI enables Web service clients to locate candidate services and discover their details. Service consumers and service providers utilize these standards to perform SOA’s basic operations. SOC provides a way of building software focused on open systems where new services, clients and providers may constantly join or leave the system. In service oriented computing environments, service consumers use services offered by providers to accomplish their tasks. Like other open distributed systems, trust problems arise in service oriented computing environments. One of the significant trust problems is service consumers’ lack of trust on providers, which is classified as service provision trust [2]. A service provider publishes its service function description by which a service consumer can find the service. But in a redundant open system, a service consumer faces a dilemma in having to make a choice from a bunch of services offering the same functionality. At this time, a service consumer needs to know not only what tasks a service can accomplish, but also how well a service can accomplish those tasks, evaluated according to some quality of

978-1-4244-4657-5/09/$25.00 ©2009 IEEE

service (QoS) metrics. Service providers are supposed, but not obliged, to deliver services in an expected quality. Trust problems arise in such situations, i.e., deciding whether a service encountered in the network can be trusted to serve the consumer’s request up to a certain standard. One important factor in trust decisions is a service’s reputation, derived from the information about its past behavior. The most reliable reputation information can be derived from a consumer’s own experience. However, much more data becomes available when reputation information is shared among a community. A larger number of reputation reports allows a better estimation of reputation information and reduces the occurrence of errors in reporting. Reputation systems provide a way for entities to be able to trust other entities [3]. And there is a need for a high-level and abstract way of specifying and managing trust and reputation, which can be easily integrated into applications and used on any platform. And during the past few decades, the field of trust has experienced rapid growth. There is a large pool of recent literature on the theories and applications of trust and reputation management in the service oriented environment. However, design expertise on trust is not well documented yet. We propose to use trust patterns as a solution for this problem. Design patterns represent a method for presenting solutions to problems in a way that enables the reuse of existing proven design expertise. The purpose of a pattern, or set of patterns, is to capture this design expertise in a form that people can use effectively. Patterns were initially introduced by Alexander in the context of architecture [4]. Since then, design patterns have been widely applied to object-oriented programming, and one of the most fundamental examples of this is the set of 23 patterns presented by Gamma et al. [5]. Software patterns and pattern languages have gained wide acceptance in the field of software development, because they provide a systematic reuse strategy for design knowledge [6]. Each pattern is a three-part rule, which describes the context in which it occurred, the problem that it resolved, and the detailed solution that resolved the problem. Trust patterns presented in this paper represent solutions that integrate trust into applications in the context of service oriented environments. Since applications have become increasingly complex and because the design of trustworthy systems necessitates some kind of trust expertise, we believe that patterns are a good solution to effectively convey trust concepts in analysis and design for trustworthy applications.

ICICS 2009

This paper first provides a brief overview of trust and trust patterns in service oriented computing environments. Then in Section III, we will present the reputation service pattern for documenting proven design expertise of solving service provision trust problems by reputation systems in service oriented computing. Section IV gives an overview of the research work that are most related to ours and Section V concludes the paper with possible future research directions. II.

TRUST AND TRUST PATTERNS IN SOC

A. Trust And Reputation The manifestations of trust are easy to recognize because we experience and rely on it every day. However, at the same time trust is quite challenging to define because it manifests itself in many different forms. There is no consensus in the literature on what trust is and on what constitutes trust management. The definition for trust by Gambetta (1988) [7] is often quoted in the literature: “… trust (or, symmetrically, distrust) is a particular level of the subjective probability with which an agent will perform a particular action, both before [it] can monitor such action (or independently of his capacity of ever to be able to monitor it) and in a context in which it affects [the agent’s] own action”. The concept of reputation is closely linked to that of trustworthiness. Reputation can be considered as a collective measure of trustworthiness based on the history of interactions with or observations of an entity, either directly with the evaluator or as reported by others. In Service oriented computing environments, we define service provision trust as the subjective probability by which a consumer (i.e., the truster) expects the service provider (the trustee) delivers the service with expected quality. The reputation of the trustee is one piece of information considered by the truster when taking the decision. While trust is subjective reputation is mainly assumed to be more objective than trustworthiness because it is a collective opinion of the whole community. Reputation information is disseminated by a reputation system and can be seen by all consumers. B. Trust Patterns Patterns are reusable solutions to recurring design problems. In the field of trust, a problem occurs whenever an entity encounters uncertainty on interactions with potential partner entities. A trust pattern describes a particular recurring trust problem that arises in specific contexts, and presents a well-proven generic solution for it. The solution consists of a set of interacting roles that can be arranged into multiple concrete design structures, as well as a process to create one particular such structure. It also documents the system qualities achieved by the application of this pattern. Trust patterns will help designers to create designs quicker through the availability of already proven solutions they can rely on. They help to identify, record and catalog successful designs to capture knowledge including trade-offs and design alternatives. The main benefit of using trust patterns is that it decouples the application domain expertise from the trust expertise (embodied in the trust patterns), that are both needed to build a

trustworthy application: It is usually difficult for non-trust specialist to design a trust application. On the other hand, a trust expert would have to become an expert in an application’s domain model to understand where to apply trust mechanisms and what trust mechanisms are adequate. With trust patterns approach, the trust expertise is embodied in the trust patterns, and it facilitates the integration of those patterns’ solution into the application design and implementation. Thus, the application designers and developers can add trust to their applications easily. Trust patterns can also provide application designers and trust domain experts with a shared vocabulary to discuss and comment on design alternatives. Trust patterns codify basic trust knowledge in a structured and understandable way. In service oriented computing field, because patterns are already used to capture system engineering knowledge, using patterns to capture trust knowledge helps to improve the integration of trust into systems. C. A Description Schem for Trust Patterns Pattern description schemata are collections of aspects that, when taken together, fully capture a design pattern. The major advantage of such schemata is that they introduce a structured way to understand, explain and reason about patterns. Furthermore, they allows for a more effective communication among software engineers and domain experts because a particular pattern description scheme provides the language to talk about patterns. And by describing patterns uniformly, it helps us to compare one pattern with another, especially when we are looking for alternative solutions to a problem. TABLE I.

Name

Context Problem Solution Structure Dynamics Implementation Consequences

DESCRIPTION FIELDS FOR TRUST PATTERNS

Describes a name for referring to the pattern and other names by which the pattern is described, if any. Describes situations in which the problem occurs. Defines the recurring problem that the general solution is defined to solve. Describes the fundamental solution principle underlying the pattern. Describes a detailed specification of the structural aspects of the pattern. Gives typical scenarios describing the runtime behavior of the pattern. Describes guidelines for implementing the pattern. Describes the benefits the pattern provides, and any potential liabilities.

A good description helps us grasp the essence of a pattern immediately—what is the problem the pattern addresses, and what is the proposed solution? The basic Context-ProblemSolution structure proposed by Alexander provides us with a good starting point for a description format that meets the above requirements. It captures the essential characteristics of a pattern, and provides you with the key ideas. We have therefore based our description template on this structure. However,

describing a pattern based exclusively on a Context-ProblemSolution schema is not enough. A good description should also provide us with all the details necessary to implement a pattern, and to consider the consequences of its application. As is shown in Table 1, our proposed description format for trust patterns uses eight sections—Name, Context, Problem, Solution, Structure, Dynamics, Implementation and Consequences. And in the next section we will present a reputation service pattern for service provision trust following our proposed description format for trust patterns. By using this format, both conceptual, structural and design problems related to trust will be covered. D. Pattern Languages for Trust A pattern can therefore be considered a rule that transforms the system in such a way as to achieve certain desired nonfunctional requirements. Furthermore, individual patterns can be linked to each other in the form of pattern languages, which guide the designer through the design process. A pattern language is a collection of patterns that solve the prevalent problems in a particular domain and context, and, as a language of patterns, it specifically focuses on the pattern relationships in this domain and context. The development of trust pattern languages is important for trust patterns to be successful. Pattern languages can help a developer to build entire systems. For example, an individual trust pattern can help you design a specific aspect of your application, such as how it solves service provision trust problem, but a pattern language can help you to use those patterns to solve multiple trust problems by putting and combining individual patterns into context. And in next section we will present a trust reputation service pattern, which is meant to be the start of trust pattern language for SOC. III.

THE REPUTATION SERVICE PATTERN

In this section we will first discuss how to solve service provision trust problems by using reputation system. And then we will propose a reputation service pattern which was captured from our own experience of designing reputation system for SOC. A. Reputation System The basic idea of reputation systems is to let parties rate each other after the completion of an interaction, and use the aggregated ratings about a given party to derive a trust or reputation score, which can assist other entities in deciding whether or not to transact with that entity in the future [8]. It is assumed that entities, acting as witness of interactions, can transmit information about each other. Information takes the form of a performance rating. In a typical reputation system, ratings about current interactions are captured, distributed and aggregated, thus giving rise to the concept of reputation. The goal of reputation systems in a service oriented environment is to encourage trustworthiness in service transactions by using past behavior as a publicly available

predictor of likely future behavior. A natural side effect is that it also provides an incentive for good behavior, and therefore tends to have a positive effect on market quality [8]. The service consumers rate the service providers they interact with and this rating is provided to future service consumers for them to make decisions on choosing the most reliable provider(s). So reputation enables consumers to choose the best providers in the system. Moreover, reputation can induce service providers to behave well if they know they are going to be avoided by future consumers as a result of their reputation going down due to bad behavior. B. The Reputation Service Pattern In this section we will propose a trust pattern which represents the solution that integrates service provision trust into applications in the context of service oriented environments, named Reputation Service Pattern. The pattern description is as follows: Name: The Reputation Service Pattern. Context: Service oriented computing environment is a dynamic, autonomous network of parties—service providers and service consumers; that is, any party in the network can behave autonomously, usually without involving any centralized administration. Service providers are offering services to consumers and they publish service functions as well as the advertised QoS through the Service Registry, which is part of a service broker. Service consumers look up the Service Registry to get available services and their descriptions including functional and non-functional information (QoS). Problem: The consumer has an idea of what kind of service it needs and it may consult the Service Registry to get available services that can implement the required business function, along with the advertised QoS information of the services. However, the consumer cannot easily predict the quality of service (QoS) that a given service instance will deliver. That is partly because the consumer may not be able to trust the service or its providers. How to build trust between service consumers and service providers? How do consumers know which service they can rely on?

Figure 1.

Architecture of the proposed solution

Solution: As shown in Figure 1, the solution is to use a reputation system and wrap it as a service which can be then integrated into the service-oriented computing environment. Service consumers invoke the reputation service via web service client on consumer side. Before a service consumer invokes a potential service, it invokes the reputation service for the potential service’s reputation and decides on whether to pick up the service. And after the service consumer completes a service invocation, it will invoke the reputation service again to add a rating.

Figure 2. Class diagram of the reputation service pattern

Structure: As shown in Figure 2, the reputation system is composed of three subsystems: ReputationComputationCompoent, RatingsAggregator and RatingRepository. The RatingRepository is used to manage ratings. It is a facade, which isolates ratings objects from the data objects in a persistent data store such as a database. The RatingsAggregator is responsible for aggregating ratings. The ReputationComputationCompoent encapsulates algorithm for deriving reputation from ratings. The ReputationSystemImplFacade works as an entry point to each subsystem of the reputation system. And it also acts as a service implementation facade by aggregating available system behaviors and providing an enforcement point for service compliance. Dynamics: See Figure 3.

Implementation: 1. Implementing reputation system components. Implement reputation computation algorithm, ratings aggregating algorithm and encapsulate them individually as reputation computation component, rating aggregating component. Implement ratings repository component following the Repository Pattern [9]. 2. Implementing reputation system facade. It can be implemented following the Façade Pattern proposed by [5]. 3. Wrapping the reputation system as a web service and deploying it. This process can be helped by some tools. From a Java web service perspective, the Apache Axis running on a Tomcat Web Server will take part in deploying the web services. The developers will only need to write a WSDD file to tell Apache Axis how to deploy it. A snapshot of the WSDD file for the reputation web service is as follows:

Figure 3. Dynamics of a service provision

Consequences: The reputation service pattern improves the modularity and reusability.

1. By breaking the reputation system into components, it is more modular and encourages reuse. 2. The repository pattern improves reusability and makes the code more understandable by abstracting the persistent data away from application domain. 3. The reputation system facade encapsulates the complexity of the system and provides standardized access point for other applications to use. 4. By wrapping the reputation system as a service, it can be more easily and flexibly integrated into a service oriented environment. In fact it can be used in any environment that implements a web service client. And its modification will not affect the consumer of the service, which is coupled only with the description of the exposed service interface. The implementation of the reputation system can be changed, as long as it remains semantically equivalent and conforms to the interface of the ReputationSystemImplFacade. The later decision to replace either component will not affect reputation service’s consumers. IV.

RELATED WORK

The problem of trust and reputation has been studied extensively in the field of service oriented computing. A lot of work has been done on trust theories and trust management. Recently, pattern-based approaches have been proposed for service oriented applications. The authors of [10] introduced a survey of technology-independent patterns that are relevant for SOAs, and worked towards a formalized pattern-based reference architectural model to describe SOA concepts. The authors of [11, 12] proposed architectural design patterns for service interaction and service composition respectively. These works solved the low level problems for service oriented computing such as service interaction, service synchronization, service composition and etc. To the best of our knowledge, no work on trust patterns for service oriented computing has been published yet. However, there are two papers on trust patterns not under context of service oriented computing. [13] proposed patterns of trust in ubiquitous computing environments. They discussed the possibility to use patterns to enable the depiction of trust as a design factor and to provide proven and reusable examples of how the concept can be implemented within the ubiquitous computing environments. And they also developed and described such patterns and showed the usefulness and the applications of them for the design of interaction within ubiquitous computing environments. [14] proposed the trust stable analysis pattern to provide a conceptual model that embodies the main aspects of the trust concept. The level of abstraction of the proposed Trust pattern makes it applicable for a wide spectrum of applications. Compared with our work, both of these two papers focused on the abstract aspects of trust, and trust system design issues are not covered.

V.

CONCLUSIONS AND FUTURE WORK

In this paper we discussed the factors of trust and reputation that play an important role in service oriented computing (SOC) environments. We further discussed what trust pattern is, why we need trust patterns and how should we describe trust patterns. Trust patterns are a novel technique for encapsulating and disseminating trust expertise. And we proposed a service pattern for reputation system, which covers both conceptual and technical design aspects of a reputation service and solves the service provision trust problems in SOC. The proposed reputation service pattern improves modularity and reusability. In subsequent work, we plan to complement the proposed pattern by solving other trust problems in SOC and at last arrive at a trust pattern language for SOC. REFERENCES [1]

[2]

[3] [4]

[5]

[6]

[7] [8]

[9] [10]

[11]

[12]

[13]

[14]

M. Papazoglou and D. Georgakopoulos. “ Introduction to a special issue on service oriented computing”, Communication of ACM, 2003: p.2528. T. Grandison and M. Sloman. “A Survey of Trust in Internet Applications”, IEEE Communications Surveys and Tutorials, 2000: p.36-41 P. Resnick, R. Zeckhauser, R. Friedman, and K. Kuwabara. Reputation Systems. Communications of the ACM, 43(12):45.48, December 2000. C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. FiksdahlKing, and S. Angel, A Pattern Language. New York: Oxford Univ. Press, 1977. J. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison- Wesley, 1995. D. C. Schmidt, F. Buschmann: Patterns, Frameworks, and Middleware: Their Synergistic Relationships, Proceedings of the 25th International Conference on Software Engineering, May 2003. D. Gambetta , Trust: Making and Breaking Cooperative Relations, Oxford: Basil Blackwell, 1988. A Jøsang, R. Ismail, and C. Boyd . A survey of trust and reputation systems for online service provision Decision Support Systems, 43(2) 2007, p.618-644. E. Evans, Domain-Driven Design: Tackling Complexity at the Heart of Software, Addison-Wesley, 2003. U. Zdun, C. Hentrich, and W. van der Aalst, 2006. A survey of patterns for service-oriented architectures. Int. J. Intern. Protocol Techn. 1, 3, 132–143. C. Zirpins, W Lamersdorf, and T. Baier, "Flexible coordination of service interaction patterns ," Proc. of the 2nd Inter. Conf. on Service Oriented Comp (ICSOC'04), 2004. A. Barros, M. Dumas, and A. H.M. ter Hofstede: Service Interactions Patterns. In Proceedings of the 3rd International Conference on Business Process Management (BPM), Nancy, France, September 2005. Springer Verlag, pp. 302-218. B. Biel , T. Grill and V. Gruhn, Patterns of trust in ubiquitous environments, Proceedings of the 6th International Conference on Advances in Mobile Computing and Multimedia, November, 2008. M.E. Fayad, and H Hamza.: The Trust Analysis Pattern. In the Proc. of 3rd Latin American Conference on Pattern Languages of Programming (SugarLoafPLoP04) ,2004.