Journal of Convergence Information Technology Vol. 3 No. 2, June 2008
QoS–Aware Web Services Discovery with Trust Management Yukyong Kim Division of Computer Science and Engineering, Hanyang University, 1271 Sa-dong, Ansan, Gyeonggi-do, 426-791 Korea
[email protected] Abstract As the number of available Web services increases, there is a growing demand to find the service that best fits the user’s requirements. Especially, when a set of services fulfilling user’s functional requirements have been discovered, among these services which one will be invoked by the user depends mostly on the Quality of Services (QoS). The problem, however, is that the service providers may have varying levels of quality, and advertised QoS information of Web services is not always valid. In this paper, we propose QoS based discovery and selection of Web services using trust ratings. We adapt OWL-S to describe QoS information for Web services discovery. Services that meet user’s capability and QoS requirements are selected using the service trust rates which are evaluated and assigned by the QoS broker. As the QoS broker manages the trustworthy degree of the service providers, it provides a method to improve the possibility to find services that match user’s QoS and trust requirements. Because we use the reputation by considering feedback from service users, advertised QoS information may be verified.
Keywords Semantic Web, intelligent Web services discovery, Quality of Service (QoS), trust rating
1. Introduction Web services can be interoperable across platforms and neutral to programming languages and applications can access Web services without concern with details of each service implementation. The advantages make Web services one of the most promising technologies. A key issue in the Web service area is to discover the most relevant service meeting the user’s requirements. With an increasing number of Web services providing similar functionalities, more emphasis is being placed on how to find the service that best fits the user’s
requirements [1]. Because e–Business applications also would like to discover services that most accurately meet their requirements in terms of Quality of Service (QoS), QoS–based service discovery mechanisms will play an essential role in Service-Oriented Architectures (SOA), especially when the semantic matchmaking process returns lots of Web services with comparable functionalities [2]. Recently, QoS is becoming more and more imperative for service consumers. In distributed and heterogeneous Web services environments, the critical quality attributes such as availability and reliability of Web services are uncertain, because the potential number of services can be extremely large and there is no guarantee that the service will be available at a particular time. Moreover, the service providers may have varying levels of quality. To select the right service provider is a challenging problem for users. Service consumers have to decide which services satisfy closely to their needs and worry about the reliability of the service provider. Thus a way to efficiently find and select Web services is needed. However, it is difficult to solve this problem by the current service discovery technique based on Universal Description, Discovery and Integration (UDDI). The current UDDI registries only support Web services discovery based on the functional aspect of services. In this paper, we present a model of QoS based service discovery with trust rate. The QoS requirement can be used as a finer constraint to find services. We allow current users to rate the service they received and aggregate of service ratings for a service from users over a specific period of time. Using the ratings, we compute trust level of the service provider. This provides a general and overall estimate of the reliability of a service provider. We adopt OWL–S to describe the semantics of service profiles and service user’s QoS requirements. By facilitating QoS driven discovery and selection, users can easily and efficiently select a trustworthy service that is more suitable to their needs. We propose a Web services discovery model based on a QoS broker. From the user’s functional and QoS including trust requirements, the
67
QoS–Aware Web Services Discovery with Trust Management Yukyong Kim
QoS broker contacts the UDDI registry to find Web services that match the given requirements. The QoS broker is responsible for processing ratings of services from users, then assigning and updating the trust rate of the related service. We assume that the ratings are trustworthy. Our model contains service matching and selection algorithms that find services that match user’s requirements and select services based on the trust type and QoS information. The rest of the paper is organized as follows: Section 2 reviews related works on Web services discovery and QoS issues. Section 3 introduces trust management and QoS attributes of this paper. A QoS based Web services discovery model including the QoS broker is defined in Section 4. In Section 5, we present the result of experiments. Finally, Section 6 summarizes and discusses future works.
2. Background and Related Studies This section gives a brief introduction to Web services discovery with QoS, Semantic Web and ontology.
2.1 Web Services Discovery with QoS Although the traditional UDDI standard does not refer to QoS for Web services, many researches have been devised to extend the original model and described web service’s quality capabilities. Dynamic composition (i.e. that done using late binding at runtime) affects all aspects of using QoS in SOA based systems and is a very active area of research and development. In [3], eFlow has investigated dynamic service selection based on user requirements. eFlow focuses on optimizing service selection at single task level (it is called local selection). Moreover, no QoS model is explicitly supported. The Web service composition model is suggested in [4]. They focus on optimizing service selection at a composite service level, based on a generic QoS model, and using established linear programming techniques. However, their work is more focused on defining the service selection model and proposes a linear programming technique to solve the service selection problem. Some research on QoS is done in the workflow area, such as METEOR project [5]. In [6], they present a QoS-aware middleware for Web services composition. The research proposes a quality-driven approach to select component services for a composite service. The service level agreement (SLA) framework in [7] is to provide QoS guaranteed Web services. The service levels are defined according to many variables such as responsiveness, availability and performance.
68
Although all of these works propose some method of service discovery with QoS, they are based entirely on advertised QoS, which may not be trustworthy. We shall consider feedback from the service users.
2.2 The Semantic Web and Ontology The Semantic Web is “an extension of the current Web in which information is given well-defined meaning, enabling computers and people to work in better cooperation”[8]. It is a mesh of information that can be automatically processed and understood by machines. RDF, stands for Resource Description Framework, is a basic semantic markup language for representing information about resources on the Web. The Web Ontology Language (OWL) is used to “publish and share sets of terms called ontology, supporting advanced Web search, software agents and knowledge management”. It provides more vocabulary for describing properties and classes of RDF resources. OWL-S, the Web Ontology Language for Services, is an OWL based Web service ontology [9]. It provides a language to describe the properties and capabilities of Web services. OWL-S supports both views of the capabilities of Web services. Within the OWL-S framework, the Service Profile provides a way to describe the services offered by the providers, and the services needed by the requesters. It provides a high level description of services and a view of the Web service as a process which requires inputs, and some precondition to be valid, and it results in outputs and some effects to become true. More precisely, the Service Profile provides two types of information: functional description of the Web service and a set of non-functional properties that specify constraints on the service provided. Figure 1 shows selected classes and properties of the Service Profile [9].
Figure 1. The Service Profile
Journal of Convergence Information Technology Vol. 3 No. 2, June 2008
Ontology is a specification of a conceptualization. It uses a formal language, such as OWL, to describe the concepts and relationships in a domain. A common ontology for Web services is the DAML-S ontology, which is defined to facilitate automatic Web services discovery, invocation and composition. It defines properties and capabilities of Web services but does not provide details about how to describe and represent QoS attributes. There are researches to represent QoS properties. In [10], a DAML-QoS ontology is proposed to describe QoS property constraints and present a matchmaking algorithm. Some other studies develop a QoS ontology that aims to formally describe quality attributes and support QoS-aware Web service provision.
3. Trust management and QoS As multiple service providers make themselves available on-line, the trustworthiness of services as well as QoS becomes significant. In this section, we explain our QoS representation and trust rating model to support QoS based Web services discovery.
3.1 QoS Information with OWL-S QoS information of the Web service can be attached to the Service Profile in OWL-S. A new class QoS is defined as a subclass of the class ServiceParameter already defined in OWL-S. With this class, additional quality attributes are defined as shown in Table 1. Future extensions also can be realized using the class ServiceParameter. Table 1. Defined elements for QoS attributes Property/ Data Explanation subclasses type ServiceQuality/ ServicePrice ResponseTime Availability Throughput TrustLevel
Quality attributes information Float
Service price per transaction Float Average response time x.xx seconds Float Available time rate xx.xxx % Integer Transaction numbers per second Float Trust score to represent trust degree
ServiceParameter consists of serviceParameterName, the actual name of the parameter, defined as literal or URI, and sParameter a link to the value within an OWL ontology. The following Table 2 shows the
definition of ServiceQuality in OWL-S as an example. ServicePrice, ResponseTime, Availability, Throughput and TrustLevel are defined as data type properties. They have type xsd:float and type xsd:integer in the class ServiceQualityInfo that is defined as a subclass of owl:Thing. Table 2. Definition of ServiceQuality in OWL-S
3.2 Trust management To select QoS guaranteed services or credible service providers, we define the trust rating model to evaluate and assign the trust rate to each Web service. The trust rate is determined by the reputation score from service users and the reliability score from the QoS broker using history data of past invocations.
69
QoS–Aware Web Services Discovery with Trust Management Yukyong Kim
We assume that service consumers provide a score indicating the level of satisfaction after use and the ratings are available and valid. Only one rating for a service per user is effective. New ratings from same users for the same service replace older ratings. The timestamp is used to distinguish the out of dated value. The computation of reputation score repuScore for a service is based on the study by [11] and [12]. repuScore =
∑i=1 SRiγ i ∑i=1γ i for γ i = λ N
N
di
,
where SRi is the i-th service rating, γi is the aging value for i-th service rating, λ is the inclusion factor, 0 < λ < 1, and di is the number of the days between the current time and the i-th rating time. The inclusion factor is used to adjust the responsiveness of the reputation rate. The smaller λ means only recent ratings are included. The reliability score relScore is computed by the time interval between errors including the system down and the failure for the request. We can define the reliability score as MTBE (Mean Time Between Errors) per unit time. When d is the number of days representing the time slot for computing MTBE, we define reliability score as the following: (up time − down time ) E rate MTBE =
∑
Here, Erate is the number of errors during d from the current time.
relScore = MTBE / unit time
The calculation of overall trust rate is given by the following equation: trust i = repuScore i * w repuScore + relScore i * w relScore where, for the service si, w is the weight for each score specified by users.
4. QoS-Aware Web Services Discovery In this section, we present a conceptual framework which enables trust and QoS based service discovery and selection. Then, service matching and selection algorithm will be described.
Figure 2. Model framework
70
4.1 Dynamic Service Discovery The traditional Web services model has three roles: service provider, service consumer and UDDI registry. In our framework, a new role, QoS broker, is added as shown in Figure 2. In this framework, a user (that is, Service Consumer) requests to find out the service meeting his/her QoS requirements as well as functional requirements. The Query Processor (QP) makes execution plans to run the user’s input such as the service request, OWL-S Service Profile and QoS requirements, and invokes the Matching Engine (ME). The ME attempts to match the service request with the service description in the service repository according to matching filters and requests Trust Rating Manager (TM) to select the optimal service with the highest value of trust rate. If the match does not succeed, the ME receives the failed message, and then requests Service Composer (SC) to retrieve composite services that provide the same functionality. As with the ME, the SC will request the TM to select a highly trusted service that meets the user’s requirements. The TM assigns the trust rate to composite services based on trust value for each service from the rating DB. The TM then returns trust rate of composite services. Table 3 shows the detailed steps of how the QoS broker finds services that meet the user’s QoS needs including trust as well as functional requirements. Table 3. Steps of service discovery process //Functional matching 1: Find services that meet the user’s functional requirements //QoS matching For each service that meet the user’s functional requirements 2: Find the service entity representing the service with the Service Profile 3: Find the ServiceQualityInfo representing the QoS information for the service 4: Add the service entity to the service candidate list if the service’s QoS information meets the user’s QoS requirements //Trust matching 5: Compute the trust rate for each service in the candidate list 6: Find the service meets the user’s trust requirement in the service candidate list //Selection 7: Rank the services in the candidate list based on trust rates and their QoS information 8: Select and return the specified number of services based on the user’s requirement
Journal of Convergence Information Technology Vol. 3 No. 2, June 2008
Because the services are graded according to the trust level, it is essential to use the Service Profile with QoS for semantic service discovery. The UDDI registry stores advertisements provided by service providers and advertised information includes basic ability description and QoS specification of the service. After receiving a user’s request, the ME chooses the advertisements that are relevant for the current request from the UDDI registry according to the matching algorithm. This matching algorithm will be detailed in the next section.
4.2 Service Matching Algorithm
SComposer( ): It returns a list of services that are composed by the SC to fulfill the functionality. QMatch( ): This method removes services whose QoS scores are below the QoS requirement QR in SR from the list and returns the list of remaining services. Sort(ResultMatch, SR.TR): It removes services whose trust rates are below the trust level requirement TR in SR from the list. Then, it sorts services in the list of remaining services by the trust rate in descending order and returns the list ResultMatch. Finally, findServices provides services meeting the user’s requirement according to the maximum number of services to be returned in the discovery request.
Some earlier matching algorithms are too restrictive. An advertisement matches a request, when the advertisement and the request describe exactly the same service. We thus define the semantic matching as subsume matching which the inputs and outputs of the advertisement are a subclass of the inputs and outputs of the request [13]. To match and substitute services more accurately, data type compatibility checking after semantic matching may be used. The user provides his requirements for the expected service, which are formed into a requirement profile, noted as SR = (FR, QR, TR). Denotations in SR are the identifiers of Functionality, Quality and Trust. On the other hand, there can be thousands of available services published in UDDI repository. The advertisement of a service S is denoted as SA = (FA, QA, TA), similarly. Both of SR and SA are described using OWL-S. Table 4. Service matching algorithm findServices(SR, maxNumServices) { ResultMatch = empty; ResultMatch.add(FMatch(SR.FR)); If (ResultMatch is empty) then ResultMatch.add(SComposer(SR.FR)); QMatch(ResultMatch, SR.QR); Sort(ResultMatch, SR.TR); }
Return ResultMatch.top(maxNumServices);
At first, we will present the main module in Table 4. The request is matched against all advertisements. When a match between SR and any of SA is found, it is recorded and sorted to find the matches with the highest QoS and trust score. The module findServices comprises the following methods: FMatch( ): It returns a list of services that meet the functional requirement FR in SR.
Figure 3. Summary of QoS information
5. Evaluation To evaluate our QoS based service discovery model, we assume the QoS information for 27 services in total including response time, availability, throughput and price as used in [1]. Figure 3 shows the details of the QoS information of these services. To simulate our model using the QoS information, we assume that a service user has QoS and trust requirements (0.1, 0.03, 99.95, 700, 8) as (price, response time, availability, throughput, trust level), and specifies that the maximum number of services to be returned is one. For each service, QoS score is computed using the equation in [14]. Figure 4 shows OWL-S description of the user’s QoS requirement.
71
QoS–Aware Web Services Discovery with Trust Management Yukyong Kim
6. Conclusion
Figure 4. Example of service requirement description If the service user wants to find the service that meets more than 3 QoS requirements, then the method QMatch will return the list of services {S3, S6, S9, S12, S15, S18, S21, S24, S27}. Because the service user’s trust requirement is 8, services {S9, S18, S27} will be remained. Finally, the QoS broker returns the service S9 having the highest QoS score in the list. The result of this experiment is consistent with the existing study.
In distributed Web services environments, the potential number of Web services providing similar functionalities can be extremely large. Moreover, there is no guarantee that the service will be available at a particular time and the service providers may have varying levels of quality. In this context, to select the right service providers is a challenging problem for users. Thus a way to efficiently find and select Web services is needed. In this paper, we present a model of QoS based service discovery with trust rate. The QoS requirement can be used as a finer constraint to find services. We allow current users to rate the service they received and aggregate of service ratings for a service from users over a specific period of time. Using the ratings, we compute trust level of the service providers. This provides a general and overall estimate of the reliability of a service provider. We adopt OWL–S to describe the semantics of service profiles and service user’s QoS requirements. By facilitating QoS driven discovery and selection, users can easily and efficiently select a trustworthy service that is more suitable to their needs. We propose a Web services discovery model based on a QoS broker. From the user’s functional and QoS including trust requirements, the QoS broker contacts the UDDI registry to find Web services that match the given requirements. The QoS broker is responsible for processing ratings of services from users, then assigning and updating the trust rate of the related service. We assume that the ratings are trustworthy. Our model contains a service matching and selection algorithm that finds services that match a user’s requirements and selects services based on the trust type and QoS information. As the QoS broker manages the trustworthy degree of the service providers, it provides a method to improve the possibility to find services that match a user’s QoS and trust requirements. Because we use the reputation by considering feedback from service users, advertised QoS information may be verified. We assume the service ratings are all trustworthy but it could be invalid. Thus trust ratings should be refined. In addition, service discovery process is tuning up to classify and measure on which specify more QoS attributes including the user’s preference.
7. References Figure 5. The result of calculation QoS score
72
[1] Ziqiang Xu, Reputation-Enhanced Web Services Discovery with QoS, MS Thesis of the School of Computing, Queen’s University, Kingston Ontario, Canada, August 2006.
Journal of Convergence Information Technology Vol. 3 No. 2, June 2008
[2] Le H. Vu et al, "QoS–based Service Selection and Ranking with Trust and Reputation Management", Lecture Notes in Computer Science, Vol. 3760, Springer Berlin, pp. 446-483, November 2005. [3] F. Casati et al., "Adaptive and Dynamic Service Composition in eFlow", Lecture Notes in Computer Science, Vol.1789, Springer London, pp.13-31, 2000. [4] L. Zeng et al., "Quality-Driven Web Services Composition", Proceedings of WWW 2003, ACM, pp. 411421, 2003. [5] J. Cardoso, Quality of service and semantic composition of workflows, Ph.D. Thesis, University of Georgia, 2002. [6] L. Zeng et al, "QoS-Aware middleware for Web Services Composition", IEEE Transactions on Software Engineering, Vol. 3, No. 5, IEEE Computer, pp.311-327, 2004. [7] A. Dan et al., "Web Services on demand: WSLAdriven automated management", IBM system journal, Vol. 43, No. 1, pp. 136-158, 2004. [8] T. Berners Lee, E. Miller, "The Semantic Web lifts off", ERCIM news, No.51, October 2002. [9] David Martin et al, "OWL-S: Semantic Markup for Web Services", W3C Member Submission, November 2004, from http://www.w3.org/Submission/OWL-S/ (last accessed: Feb. 26, 2008) [10] C. Zhou et al, "DAML-QoS Ontology for Web Services", Proceedings of International Conference on Web Services, IEEE Computer, pp.472-479, 2004. [11] S. Majithia et al, "Reputation based Semantic Service Discovery", Proceedings of International Workshops on Enabling Technologies (WETIEC ′04), Italy, pp.297-302, June 2004. [12] R. Wishart et al, "SuperstringRep: Reputation-enhanced Service Discovery", Proceedings of ACCS, Vol. 38, pp.4957, 2005. [13] M. Paolucci et al., "Semantic matching of web services capabilities", Proceedings of ISWC 2002, Lecture Notes in Computer Science, Vol.2342, pp.333-347, 2002. [14] Y. Kim, K. Doh, "Trust Type based Semantic Web Services Assessment and Selection", Proceedings of ICACT, IEEE Computer, pp. 2048-2053, 2008.
73
