以共識為基礎的服務搜尋機制

全文

(1)國立交通大學資訊管理研究所博士論文. 以共識為基礎的服務搜尋機制 An Approach to Consensus-Based Service Discovery. 研. 究. 生：黃俊龍. 指導教授：羅濟群共同指導教授：趙國銘中華民國九十五年九月.

(2) 以共識為基礎的服務搜尋機制 An Approach to Consensus-Based Service Discovery. 研究生：黃俊龍. Student：Chun-Lung Huang. 指導教授：羅濟群. Advisor：Chi-Chun Lo. 共同指導教授：趙國銘. Co-Advisor：Kuo-Ming Chao. 國立交通大學資訊管理研究所博士論文. A Dissertation Submitted to Institute of Information Management College of Management National Chiao Tung University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Information Management September 2006. Hsinchu, Taiwan, Republic of China. 中華民國九十五年九月.

(3) 以共識為基礎的服務搜尋機制學生：黃俊龍. 指導教授：羅濟群博士共同指導教授：趙國銘博士國立交通大學資訊管理研究所. 中文摘要網路服務(Web services)廣泛的被應用在電子商務、網格服務(Grid Services)與電子化政府等各種不同的領域，它通常分散在異質網路環境之中，而且能夠透過整合(composition) 被加以再利用並衍生出其他功能更強大的服務。有效率的服務搜尋機制是網路服務能否被充分利用的先決條件，然而網路服務的搜尋首先遭遇到的問題就是搜尋機制通常根據服務本身所提供的說明標籤、介面的特徵或者服務的功能性描述進行搜尋，無法根據服務本身所包含的內容(content)本身進行搜尋。換言之，服務使用者需要靠其他額外的判斷準則，方能在許多重複或者是相似的服務之中選取真正適合的服務；其次、目前的研究趨勢在於如何動態的搜尋，並同時整合既有的網路服務。唯大部分現有的服務搜尋方法，無論是由服務的功能性或者非功能性觀點進行搜尋，都無法有效解決認知差距所造成之搜尋不準確的問題。因為不論服務使用者對網路服務進行搜尋，或者服務提供者對服務進行宣傳時，對服務內容通常抱持著不同的主觀期待或是偏好，由於雙方對於服務內容有不同的觀點或評價，導致正確搜尋服務的效率顯得不盡人意。本研究提出一個以共識為基礎的服務搜尋方法，嘗試來降低因認知差距所引起的搜尋不準確問題。此法能夠收集個人主觀的意見，以模糊化的方式加以表達，並協助服務的使用者與提供者在進行搜尋之前先達成一個共識，藉以提升服務搜尋的準確率。本法採用一系列的模糊群體決策制定理論以及語意網路(Semantic Web)的技術，使得不同的主觀意見得以整合成為一個共識並利用它對服務內容進行分類與搜尋。本法可以重複的被執行，因此新的主觀意見得以被納入並且持續提升搜尋的效率。此外除了將研究開發成雛型系統之外，也將利用各種不同的數據實際測試之，期待實驗的結果能夠展示出本研究所提方法的效能。關鍵詞：調節式模糊網路服務搜尋、群體共識、模糊喜好關係、語意查詢、語意網路. -i-.

(4) An Approach to Consensus-Based Service Discovery Student: Chun-Lung Huang. Advisor: Dr. Chi-Chun Lo Co-Advisor: Dr. Kuo-Ming Chao. Institute of Information Management National Chiao Tung University. Abstract Web services are used for developing and integrating highly distributed and heterogeneous systems in different domains such as e-business, Grid services, and e-government systems. Service discovery is a crucial process for Web service utilization. However, the issues associated with service discovery that involves the Web service having data repositories are not well addressed by the existing methods which focus on service capabilities, interface signatures, or functionalities. These methods are inadequate to identify appropriate services among the services which have similar functionalities, so it requires service consumers to include additional aspects (i.e. content of service or reputation) to evaluate the services. An effective service discovery mechanism is able to support the identification of the required services in a dynamic environment and form composite services that provide the required functionality. The service consumers and providers often have different views on the content of services. The existing service discovery approaches, based on either functional or non-functional attributes, do not address the issues associated with the impact of the diverse preferences and subjective expectations of the service consumers and providers which are generally used in searching for or in advertising Web services. This study attempts to alleviate such diversity by proposing a consensus-based service discovery approach to model subjective and fuzzy opinions. This will assist service consumers and providers in reaching a common consensus so that the efficiency of service discovery can be increased. The approach which is based on fuzzy group decision making methods and semantic web technologies can be executed iteratively and therefore further fuzzy opinions and preferences can be added to improve the precision of Web service discovery. The proposed approach will be implemented as a prototype system and to be tested through various experiments in order to demonstrate the effectiveness of the proposed approach. Keywords: Moderated Fuzzy Discovery, Web Services Discovery and Composition, Group Consensus, Fuzzy Preference Relations, Linguistic Query, Semantic Web, POPM. - ii -.

(5) 誌. 謝. 本論文得以順利完成，首先得感謝我的兩位指導教授──羅濟群博士(台灣)，以及趙國銘博士(英國)於研究過程中的悉心指導。在交通大學碩、博士修業的七年當中，幸有羅老師一路的提攜，使我在研究方向的規劃上，以及研究能力的養成上都能有長足的進步，特別是專案開發的經驗，為我累積了許多技術上的基礎；旅英期間則有賴趙教授在研究方法、研究討論、文章修改、論文投稿以及國外生活上所給予的極大協助，使我能有愉快且充實的國外求學經驗。兩位老師豐富的經驗、宏觀的視野與嚴謹的研究態度讓我受益良多，進而能奠定我日後獨立研究的能力。在此謹致上我最誠摰的感謝之意。同時由衷地感謝口試委員陳彥良老師、陳鴻基老師、楊建民老師、劉敦仁老師與蔡銘箴老師對論文的細心審閱與費心指導，讓本篇論文的內容能夠更加充實、完善；在此也特別的感謝英國的 Nick Godwin 博士，感謝他對本論文所提供的諸多建議，尤其是在英文文章的潤稿與修訂上所給予的莫大協助。除了師長們在研究上的教導與指正，在此同時感謝本所諸位優秀的同窗夥伴們，王平、俊傑、宗智、曉芸、鵬雲、怡鎮、芳萍、明華、榮發、順吉、秉文、志坤、美玉、怡璋、鍾斌等人，有你們的陪伴使我在漫長的研究路上不感孤單。尤其王平學長在研究內容上，所適時給予的具體建議讓我備感受用；也感謝通訊網路研究室的學弟妹，道馨、鼎元以及真理大學孫鵬虯等人，在研究期間於學業與生活上的相互支援。也謝謝本所助理淑惠、秀文在許多事務上的幫忙。最後，更要感謝我的父母與家人一路上的支援，以及女友瓊瑤的鼓勵與支持，讓我能夠無後顧之憂地攻讀學位。如今，完成學業、論文付梓，謹獻上最真誠的謝意給我親愛的家人，並與他們分享這喜悅的一刻。本論文謹獻給任何幫助我的朋友們。謝謝。. 黃俊龍國立交通大學資訊管理研究所中國民國九十五年九月 - iii -.

(6) TABLE OF CONTENTS 中文摘要(Abstract in Chinese).................................................................................................i Abstract .....................................................................................................................................ii 誌. 謝(Acknowledgements in Chinese) ................................................................................iii. Table of Contents .....................................................................................................................iv List of Figures .........................................................................................................................vii List of Tables ..........................................................................................................................viii Chapter 1 Introduction ............................................................................................................1 1.1 Research background...................................................................................................1 1.2 Motivation and objective .............................................................................................3 1.3 Research approach.......................................................................................................5 1.4 Organization ................................................................................................................6 Chapter 2 Literature Review...................................................................................................7 2.1 Web service..................................................................................................................7 2.1.1 Universal Description, Discovery and Integration (UDDI)...............................9 2.1.2 Simple Object Access Protocol (SOAP)..........................................................10 2.1.3 Web Services Description Language (WSDL) ................................................12 2.2 Semantic Web ............................................................................................................14 2.2.1 Semantic Web and ontology ............................................................................14 2.2.2 Web Ontology Language (OWL) ....................................................................16 2.2.3 Web Ontology Language for Services (OWL-S).............................................18 2.2.4 The mapping between UDDI and OWL-S ......................................................20 2.3 Service composition ..................................................................................................22 2.3.1 Service composition ........................................................................................22 2.3.2 Centralized and decentralized orchestration....................................................25 2.4 Service discovery.......................................................................................................27 2.4.1 Three basic models for Web service discovery ...............................................27 2.4.2 Functional service discovery –capability discovery.......................................29 2.4.3 Non-functional service discovery –QoS-aware discovery .............................33 - iv -.

(7) Chapter 3 Fuzzy Aggregation and Fuzzy Preference for Group Consensus.....................38 3.1 Fuzzy set theory.........................................................................................................39 3.1.1 Membership functions .....................................................................................40 3.1.1.1 Trapezoidal membership function ........................................................40 3.1.1.2 S-membership function ........................................................................40 3.1.1.3 Z-membership function ........................................................................41 3.1.1.4 Gaussian membership function ............................................................42 3.1.2 Basic operation ................................................................................................42 3.1.2.1 Union ....................................................................................................42 3.1.2.2 Intersection ...........................................................................................43 3.1.2.2 Complement .........................................................................................43 3.2 Similarity Aggregation Method (SAM).....................................................................43 3.3 Resolution Methods for Group Decision Problem (RMGDP) ..................................46 3.3.1 The transformation phase ................................................................................47 3.3.2 The aggregation phase .....................................................................................48 3.3.3 The exploitation phase.....................................................................................48 3.3.3.1 Quantifier Guided Non-Dominance Degree (QGNDD).......................49 3.3.3.2 Quantifier Guided Dominance Degree (QGDD)..................................50 3.4 Pseudo-Order Preference Model (POPM).................................................................50 Chapter 4 The Proposed Architecture –An Approach to Consensus-Based Service Discovery ........................................................................................................................55 4.1 Elaboration for the architecture and the key components .........................................55 4.1.1 General description and basic scenario ...........................................................56 4.1.2 UDDI / OWL-S Registry.................................................................................57 4.1.3 Fuzzy Classifier and Fuzzy Engine .................................................................58 4.1.4 Fuzzy Discovery ..............................................................................................60 4.1.5 Fuzzy Moderator .............................................................................................61 4.2 System range and constraints ....................................................................................63 4.3 Implementation considerations..................................................................................64 4.3.1 Implementation suggestions ............................................................................64 4.3.2 Handling the outliers .......................................................................................65 4.3.3 System sensitivity............................................................................................65 Chapter 5 Case Studies and Performance Evaluations.......................................................66 5.1 Case I - Flight booking case study with primitive term ............................................67 5.1.1 Scenario and the moderation process for Case I..............................................67 -v-.

(8) 5.1.2 Performance evaluation for Case I ..................................................................72 5.1.2.1 Capability Discovery Method (CDM)..................................................72 5.1.2.2 Fuzzy Discovery Method (FDM) .........................................................73 5.1.2.3 Moderated Fuzzy Discovery Method (MFDM) ...................................75 5.1.2.4 Summary of Case I ...............................................................................76 5.2 Case II - Flight booking case study with composite term .........................................78 5.2.1 Scenario and the moderation process for Case II ............................................78 5.2.2 Performance evaluation for Case II .................................................................91 5.2.2.1 Capability Discovery Method (CDM)..................................................91 5.2.2.2 Fuzzy Discovery Method (FDM) .........................................................93 5.2.2.3 Moderated Fuzzy Discovery Method (MFDM) ...................................95 5.2.2.4 Summary of Case II..............................................................................99 5.3 Case III - Flight booking case study with numerous criteria...................................102 5.3.1 Scenario and the moderation process for Case III.........................................102 5.3.2 Performance evaluation for Case III..............................................................108 Chapter 6 Conclusion and Future Works .......................................................................... 111 Acknowledgements ............................................................................................................... 115 Reference ............................................................................................................................... 115 Appendix ...............................................................................................................................122. - vi -.

(9) LIST OF FIGURES Figure 2-1 Figure 2-2 Figure 2-3 Figure 2-4 Figure 2-5 Figure 2-6 Figure 2-7 Figure 2-8 Figure 2-9 Figure 2-10 Figure 2-11 Figure 2-12 Figure 2-13 Figure 2-14 Figure 2-15 Figure 2-16 Figure 2-17 Figure 2-18 Figure 2-19 Figure 3-1 Figure 3-2 Figure 3-3 Figure 3-4 Figure 3-5 Figure 4-1 Figure 4-2 Figure 4-3 Figure 5-1. Service Oriented Architecture [23].........................................................................8 The UDDI registry information model [24] .........................................................10 An example for SOAP message to request an inquiry [26].................................. 11 An example for SOAP message to response an inquiry [26] ...............................12 An example for WSDL document [25].................................................................13 Semantic Web Stack [29]......................................................................................15 Three species for Web Ontology Language (OWL) [14] .....................................17 An example for Web Ontology Language (OWL) ...............................................18 The components of OWL-S [15] ..........................................................................19 The mapping between OWL-S and UDDI specification [35] ............................21 Ontology-based description of Web services [9] ................................................24 Centralized orchestration of a composite Web service [44] ...............................25 Decentralized orchestration of a composite Web service [44] ...........................26 Three Models of Service Discovery [46] ...........................................................27 Seeking flows for a specific service via UDDI Registry....................................29 An overview for matchmaking using LARKS [16]............................................31 The rating procedures and ranking result for algorithm [11],[48]......................32 Overview of proposed approach by B. Medjhed, et al. [9] ................................33 Service ontology for restaurant booking [60].....................................................35 Trapezoidal membership function [22] ................................................................40 S-membership function [22].................................................................................41 Z-membership function [22].................................................................................41 Gaussian Membership Function [22] ...................................................................42 A trapezoidal fuzzy number..................................................................................44 The proposed architecture for a consensus-based service discovery ...................56 An example for the classification process ............................................................60 An example of OWL definition............................................................................65 ~ C init ( 0,0,14500 ,16500 ) .......................................................................................67. Figure 5-2 Four different fuzzy sets for Cheap ......................................................................69 ~ Figure 5-3 C init (0,0,700 ,1000 ) ............................................................................................80 Figure 5-4 QGDD and QGNDD for alternatives ...................................................................90 Figure 5-5 The consensus weightings (CW) for alternatives .................................................90 Figure 5-6 Average Precision Rates for CDM, FDM and MFDM....................................... 110. - vii -.

(10) LIST OF TABLES Table 2-1 Table 2-2 Table 2-3 Table 2-4 Table 2-5 Table 2-6 Table 4-1 Table 5-1 Table 5-2. Four core data structures in UDDI Registry [5],[23] ...............................................9 SOAP elements [10][26] ........................................................................................ 11 The basic WSDL document structure [25].............................................................13 Summary of BPEL constructs and notation [44]....................................................23 The frame structure of a LARKS specification [16]..............................................31 QoS criteria and their aggregation functions in [19]..............................................34 Implementation suggestions...................................................................................64 CDM precision rates for service Consumer 1 to 4 ................................................73 ~ Classification results for each service with C init ( 0,0,14500 ,16500 ) ..................74. Table 5-3 FDM pr e c i s i onr a t e sf orCons ume r1t o4wi t hθ=0. 25.......................................74 Table 5-4 FDM pr e c i s i onr a t e sf orCons ume r1t o4wi t hθ=0. 5.........................................75 Table 5-5 Classification results for each service with moderated ~ C (0, 0, 13314.333, 14925.007) ...............................................................................75 Table 5-6 MFDM pr e c i s i onr a t e sf orCons ume r1t o4wi t hθ=0. 25....................................76 Table 5-7 MFDM pr e c i s i onr a t e sf orCons ume r1t o4wi t hθ=0. 5......................................76 Table 5-8 Precision rates for CDM, FDM and MFDM with different thresholds..................77 Table 5-9 Cons ume r s ’pr e f e r e nc e sf orCheap ........................................................................82 Table 5-10 Cons ume r s ’pr e f e r e nc e sf orDepartureTime ........................................................82 Table 5-1 1 Cons ume r s ’pr e f e r e nc e sf orTravelTime...............................................................83 Table 5-12 Cons ume r s ’pr e f e r e nc e sf orArrivalTime .............................................................83 Table 5-13 Cons ume r s ’pr e f e r e nc e sf orStops ........................................................................83 Table 5-14 Individual preferences on a list of alternatives, A {a1 , a 2 , a3 , a 4 , a5 } ................88 Table 5-15 Ok {o1k , o2k ,.., omk } ................................................................................................88 Table 5-16 QGDD, QGNDD and the consensus weightings for alternatives ........................90 Table 5-17 CDM precision rates for Consumer 1, 2, 29, and 30............................................92. ~. Table 5-18 Classification results for each service with Satisfaction, Qinit , with equal weightings............................................................................................................93 Table 5-19 FDM precision rates for Consumer 1, 2, 29,a nd30wi t hθ=0. 45......................94. ~. Table 5-20 Classification results for each service with moderated Satisfaction, Q , with equal weightings............................................................................................................96 Table 5-21 MFDM pr e c i s i onr a t e sf orCons ume r1,2,29,a nd30wi t hθ=0. 45( wi t he q ua l weightings) ..........................................................................................................97. ~. Table 5-22 Classification results for each service with moderated Satisfaction, Q , with consensus weightings ..........................................................................................97 Table 5-23 MFDM pr e c i s i onr a t e sf orCons ume r1,2,29,a nd30wi t hθ=0. 45( wi t h consensus weightings) .........................................................................................98 - viii -.

(11) Table 5-24 Table 5-25 Table 5-26 Table 5-27 Table 5-28 Table 5-29 Table 5-30. Ave r a g epr e c i s i onr a t ef orCDM,FDM a ndMFDM wi t hθ=0. 45.....................99 Average precision rate for CDM, FDM and MFDM when0. 45<θ<0. 5.........100 Ave r a g epr e c i s i onr a t ef orCDM,FDM a ndMFDM wi t hθ=0. 5.....................100 Average precision rate f orCDM,FDM a ndMFDM wi t hθ=0. 55...................100 Average precision rate for CDM, FDM and MFDM with best choice ..............101 Derived distinct preference orders for six alternatives with various thresholds 105 QGDD, QGNDD and the consensus weightings for alternatives ......................108. - ix -.

(12) CHAPTER 1 INTRODUCTION 1.1 Research background The Web was originally used for sharing information among scientists.. At the. beginning, this Document Web was used to store and share static information but it has gained increasing attention due to the advance of Internet technologies and the enhancement of hardware capabilities. The Web has changed its direction into being a Service Web which provides not only support for document sharing, but also the ability to enable organizations to provide their applications or services via the Web –the Internet.. Consequently, the concept. of Web services [1],[2],[3] has become widely relevant.. A Web service is a set of related functionalities which can be automatically accessed through the Web [3] and it makes information and software available and executable over the Internet, so it can be utilized as a building block for applications [4]. Web services can be registered (advertised) and queried (searched) by using Universal Description, Discovery and Integration (UDDI) [5].. In the meantime the Web Services Description Language (WSDL). [6] and the Simple Object Access Protocol (SOAP) [10] provide a machine-processable interface in which components that contribute to a composite web service can be executed automatically.. Two types of Web services are identified: simple and composite [9].. A simple service, a. primitive service, is standalone and Internet-ba s e da ppl i c a t i onwhi c hc a nf ul f i l lc ons ume r s ’ requests without any other Web services.. A composite service is conceived as a. conglomeration of several simple Web services over a designated flow structure [7],[8]. These primitive services can be grouped and they interact with each other to provide consumers a complete value-added service.. For example, car dealer, insurance, and financial -1-.

(13) loan services can be combined as a comprehensive car sale service.. Widely available and standardized Web service technologies make collaboration among different organizations possible. Web services are now used for developing and integrating highly distributed and heterogeneous systems in different domains such as e-business, grid services, and e-government systems. With service popularity and complexity, the concept of Service Oriented Architecture (SOA) or Service Oriented Computing (SOC) [23],[38],[55] has been introduced and it has gained increasing significance in the research field of information systems.. It attempts to provide a systematic approach for service composition in. order to achieve Web services (components) sharing and reuse.. Two related concept in SOA / SOC are composite services and service composition.. A. composite service is a complex Web service which is composed of a number of simple (primitive) Web services. services [8].. Service composition is the construction process of composite. Ideally, different primitive Web services within a complex Web service can. come from diverse service providers and this leads to a new arduous problem –the issue of service semantics.. Even though one output parameter of one primitive Web service has the. same name and type with an input parameter of another primitive Web service, it is not necessary that these parameters can be linked up to form a consistent composite service.. The Semantic Web [13] has been proposed to dispose of the semantic issues.. Many. academic researchers and developers are endeavouring to build ontology for Web services. The goal of the Semantic Web is to make the Web services not only understandable by humans but also by machines through adding semantic information to the advertised services and to the service requirement specifications in order to increase interoperability among primitive Web services.. Several standards such as the Web Ontology Language (OWL) [14]. and the Web Ontology Language for Services (OWL-S or formerly DAML-S) [15] have been -2-.

(14) introduced to achieve this goal. These standards help to handle the semantic issues that occur in Web service utilization.. 1.2 Motivation and objective In order to fully realize the benefit of the automation of Web service composition, service discovery is a crucial process for Web service utilization.. Most of existing service. composition approaches [38],[42],[43] assume that all primitive services are ready-to-use in someplace or can be identified via simple UDDI queries.. Discovery or so-called. matchmaking1 is considered as a search problem in a bounded space.. It takes service. c ons ume r s ’r e que s t sa ndac ol l e c t i onofs e r vi c e sf r om s e r vi c e spr ovi de r sa si nputvi ai t s discovery mechanism to identify a list of best matched pairs.. Some researches [16],[18]. handle the discovery problem by incorporating Semantic Web technologies.. However, there. are still two major problems that should be tackled in order to achieve an effective and efficient discovery process.. Principally, the issues associated with service discovery that involve the Web service having data repositories are not well addressed by the existing methods which focus on service capabilities, interface signatures, or functionalities. These methods are inadequate to identify appropriate services among the services which have similar functionalities, so it requires service consumers to include additional aspects (i.e. content of service or reputation) to evaluate services.. In the context of Web service discovery, the representation of services. and the selection of searching criteria are the critical factors to determine the quality of the output.. Measuring the similarity between a s e r vi c ec ons ume r ’ sr e que s t s and the provided. services in terms of: the software signatures; the capabilities; the syntax, and the semantics of services is a common element in discovery [12],[16],[18],[51].. 1. However, recent work on. In this thesis, the term discovery will be used for consistency when discussing search or matchmaking. -3-.

(15) Web service discovery has not paid sufficient attention to the use of underlying data and information about services as a search criterion.. Second, an effective service discovery mechanism to enable the formation of the required composite services that provide the required functionality is able to support the identification of the required services in a dynamic environment.. The service consumers and. providers often have different views on the content of services.. Most of the existing service. discovery approaches such as [12],[16],[17],[18],[19],[49],[50] and [51], based on either functional or non-functional attributes, do not address the issues associated with the impact of the diverse preferences and subjective expectations of the service consumers and providers which are generally used in searching for or in advertising Web services.. Because. consumers and providers often have different views on the content of services, the selected results ma ynotc onf or mt oc ons ume r s ’e xpe c t a t i ons and this hinders the efficiency of service discovery.. This study proposed a consensus-based service discovery approach which attempts to use the underlying data and information about services as a search criterion (quality rating). Pre-classified services provide supplementary information with a higher level of abstraction, such as a quality rating for Cheap. associated with services.. This represents the capabilities and the underlying data. The proposed method attempts to refine the search space and to. increase the precision rate in discovery.. In the meanwhile, consumers are allowed to do. search by using linguistic terms such as Cheap or Comfortable.. Moreover, this. consensus-based approach models subjective and fuzzy opinions and assists service consumers and providers in reaching a common consensus so that the cognitive differences among service consumers can be mitigated and the efficiency of service discovery can be increased.. This approach, which is based on fuzzy group decision making methods and. Semantic Web technologies, can be executed iteratively and therefore further fuzzy opinions -4-.

(16) and preferences can be added to improve the precision of Web service discovery. The proposed approach will be implemented as a prototype system and tested through various experiments to demonstrate the effectiveness of the proposed approach.. 1.3 Research approach In this study, five research steps were adopted to solve the problems of service discovery mentioned above.. These are described as follows:. (1) Overall literature review: reviewing the existing works about the Web services, Web services composition, Service Oriented Architecture (SOA) / Service Oriented Computing (SOC), the Semantic Web, and the tools for realizing these concepts.. (2) Research concept development: the research concept was generated mainly through literature review.. In addition brainstorming and consultation with experts at. international conferences was used to help identify a viable solution to the problem.. (3) Detailed literature review: the use of fuzzy set concepts being identified the research process focussed on studies of fuzzy set and theory, related to reaching a consensus. These were concerns with concepts such as: fuzzy opinion representation; fuzzy majorities; fuzzy similarity measurement; fuzzy aggregation; reaching consensus; resolution methods for group decision problems; and, the methodologies used to collect imprecise preferences.. (4) Architecture development: the proposed approach was implemented as a prototype system to solve the two major issues of service discovery mentioned in Section 1.2. The main modules were employed to pre-classify the Web services in terms of different QoS terms.. A method for reaching consensus over these terms used. among service consumers and providers was implemented. -5-.

(17) (5) Architecture verification: the proposed approach was tested through various experiments in which the data were collected from several famous website. The results demonstrate the effectiveness of the proposed approach.. 1.4 Organization The rest of this dissertation is structured as follows.. Chapter 2 contains the literature. reviews which include the descriptions of Web service composition, discovery and its related technologies. Chapter 3 will describe the fuzzy set theories which are used in reaching a consensus. The proposed architecture, including its scope, constraints and implementation considerations, will be presented in Chapter 4. presented in Chapter 5.. Case studies and performance evaluations are. Chapter 6 concludes this work and proposes the future work.. Finally, the references and appendix are attached at the end of the dissertation.. -6-.

(18) CHAPTER 2 LITERATURE REVIEW Based on SOA / SOC, several Web services can be assembled into a composite web service.. In this chapter, literature related to Web services, service composition, service. discovery, and Semantic Web, will be reviewed and discussed briefly.. 2.1 Web service The major differences between traditional Web applications and Web services is that the former are designed to be read and used by human and the latter are designed to increase the interoperability among machines by providing a machine-processable format which can help Web services to be searched and utilized autonomously. is:. A W3C definition for Web services. “A We b s e r v i c e i sa s o f t war e s y s t e m de s i gne d t o s uppor ti nt e r op e r abl e. machine-to-machine interaction over a network.. It has an interface described in a. machine-processable format (specifically WSDL).. Other systems interact with the Web. service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-relateds t andar ds . ” [20]. In other words, Web services are self-contained, self-describing and modular applications which can be published, located, and invoked across the web [22].. At the initial stage, Web. service is just a concept, but with the efforts contributed by the worldwide researchers and developers, many standards [1],[5],[6],[10],[13],[14],[15] have been proposed to support the implementation of Web services.. Up to now, Web services are treated as the basic. components of the Service Oriented Architecture (SOA) shown in Figure 2-1.. -7-.

(19) Figure 2-1 Service Oriented Architecture [23]. Three different roles are identified within a SOA which are Service Broker, Service Provider and Service Requestor.. A Service Provider is the one who actually builds Web. services and provides services for Service Requestors to consume.. The Service Provider can. choose either actively or passively to advertise its Web services with detail descriptions on the Web.. A Service Requestor is the service consumer which seeks the Web services it needs.. A Service Broker acts as the mediator for Web services.. It provides Service Providers the. ability to advertise their services in a registry and provides Service Requestors a channel to find the suitable Web services.. A Service Broker helps Service Providers and Service. Requestors find each other, but it is not necessarily for the broker to deal with the subsequent contracts and executions.. There are several technologies that contribute to the realization of a SOA such as: Universal Description, Discovery and Integration (UDDI) [5]: Web Services Description Language (WSDL) [6]: Simple Object Access Protocol (SOAP) [10]: and, Web Ontology Language for Services (OWL-S or formerly DAML-S) [15]. technologies will be explained in the following sections. -8-. The detail of these.

(20) 2.1.1 Universal Description, Discovery and Integration (UDDI). Web services can be registered (advertised) and queried (searched) by using Universal Description, Discovery and Integration (UDDI) [5].. It is provided by the OASIS Standard. and consists of an XML schema for defining its data structures and APIs.. Microsoft and. IBM made considerable efforts to develop the UDDI specifications to support more complicated business logic and to promote UDDI as a public standard [23]. Table 2-1. Categories. White pages. Yellow pages. Four core data structures in UDDI Registry [5],[23]. Type. Description. businessEntity. Containing descriptive information about a business or organization such as the name, address, telephone number, and other contact information of a given business.. businessService. Describing a service belong to a businessEntity. Representing a logical service and containing descriptive information in business terms such as the names and categories of the services.. Providing technical information necessary to invoke a Web service, typically given in bindingTemplate the form of a URL and information about method names, argument types, and so on. Green pages tModel. UDDI acts as a directory service.. Service Specification Detail: This is metadata about the various specifications implemented by a given Web service. Human and programs can discover how to interact with Web services they do not know much about. A Service Provider implements its Web services and. registers them along with their detail descriptions at an UDDI server.. When a Service. Requestor seeks for a service from UDDI, the UDDI server looks up the database for the suitable services by searching the detail descriptions from a list of the registered services. -9-.

(21) Once a matched service is found, UDDI returns the identified service and its related information to the Service Requestor.. These descriptions are classified into four core data. types which are shown in Table 2-1.. One businessEntity (business company) could have many businessServices.. Besides,. one businessService contains a list of binding Templates that in turn contain a tModel. The bindingTemplate and the tModel represent the technical information about how to access and exploit Web services.. As mentioned above UDDI acts as a directory service, Service. Requestors use SOAP (detail at 2.1.3) as the communication protocol to negotiate with a UDDI server to obtain the WSDL (detail at 2.1.2) information of any suitable Web services. Figure 2-2 shows the necessary detailed descriptions when a Service Provider advertises its services in a UDDI registry server.. Figure 2-2. The UDDI registry information model [24]. 2.1.2 Simple Object Access Protocol (SOAP) Simple Object Access Protocol (SOAP) [10] is a text-based (specifically XML-based) communication protocol which can be conveyed by other underlying transmission protocols such as HTTP, SMTP, FTP or any other proprietary messaging protocol. - 10 -. SOAP messages.

(22) increase the interoperability of different executable components of Web services when these components are distributed in the heterogeneous environment.. In other words, SOAP is a tool used to exchange data.. SOAP uses XML documents to. package and exchange messages among diverse counterparts.. A SOAP message is. composed of four major elements which are briefly in Table 2-2. Table 2-2. SOAP elements [10][26]. Element. Descriptions. <Envolope>. The root element of a SOAP message. Specify the encodingStyle and namespace xmlns:soap= http://www.w3.org/2001/12/soap-envelope. <Header>. The application specific information (like authentication, pa y me nta nde t c …). <Body>. Actual SOAP message (transmitted data). <Fault>. Fault handling information and rules when a identified error occurs. Figure 2-3 and Figure 2-4 are two simple examples to illustrate how SOAP messages are used to carry data.. The former one shows that a name-value pair for a parameter is. Item-Apples which is a query request to a Web service and the response name-value pair is price-1.90 that indicates that the price for item Apples is 1.90. <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope> Figure 2-3. An example for SOAP message to request an inquiry [26]. - 11 -.

(23) SOAP was created by Microsoft for the data exchange in Microsoft .Net framework and SOAP 1.1 was proposed to W3C in May 2000 [26] which means that SOAP is widely accepted by the community.. The architecture proposed by this dissertation is also powered. by SOAP due to its convenient referencing capabilities.. In addition to the SOAP. specification, some Web service APIs are also available for building Web services [21]. <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope> Figure 2-4. An example for SOAP message to response an inquiry [26]. 2.1.3 Web Services Description Language (WSDL). Web Services Description Language (WSDL) [6] provides a machine-processable interface through which components that contribute to a composite Web service can be executed automatically.. WSDL is also based on XML technology (an XML document) and. is used to define how to describe the details of a Web service, such as the location of the service and the operations (methods) the service exposes.. Those messages themselves are. described abstractly and then bound to a concrete network protocol and message format [20].. WSDL service definitions provide documentation for distributed systems and are used as recipes for automating operation invocation [22].. WSDL allows descriptions of Web. services and their messages to be represented explicitly in a way that facilitates their communication no matter what message formats or network protocols used. used in conjunction with SOAP 1.1, HTTP GET/POST, and MIME [6]. - 12 -. WSDL is now.

(24) The major elements with in a WSDL document are shown in Table 2-3. <portType> is the most important WSDL element.. The element. It describes a Web service and its. operation (like subroutine or function) which can be invoked and the messages involved. The element <message> defines the name and type for a specific parameter.. The <binding>. element defines the message format and protocol details for each <portType>. Table 2-3. The basic WSDL document structure [25]. Element. Descriptions. <portType>. The operations performed by the Web service. <message>. The messages used by the Web service. <types>. The data types used by the Web service. <binding>. The communication protocols used by the Web service. <definition> <message name="getTermRequest"> <part name="term" type="xs:string"/> </message> <message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType> <binding type="glossaryTerms" name="b1"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation> <soap:operation soapAction="http://example.com/getTerm"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> </definitions> Figure 2-5. An example for WSDL document [25] - 13 -.

(25) Figure 2-5 is a simple WSDL document.. In this example, the Web service is. glossaryTerms and it has only one operation (function) called getTerm which involved one input parameter getTermRequest and one output parameter getTermResponse.. The. <binding> element shows that this Web service can use SOAP as communication protocol. The messages are conveyed by HTTP and the operation (function) is located at the following URL: http://example.com/getTerm .. With the detailed abstract information provided by WSDL documents, one Web service can be invoked by the other programs (Web services, agents or applications) regardless of the environment in which the calling party exists.. 2.2 Semantic Web This section briefly reviews the technologies related to the Semantic Web such as Ontology, Web Ontology Language (OWL), Web Ontology Language for Services (OWL-S) and the integration of OWL-S and UDDI.. 2.2.1 Semantic Web and ontology. The Web was originally used for sharing information among scientists.. At the. beginning, this Document Web was used to store and share static information but it has gained increasing attentions due to the advance of Internet technologies and the enhancement of hardware capabilities. However, the large amount of data available on the Web can only be understood by humans or by very specialized programs.. The goal of the Semantic Web. [1],[13] is to make the data not only understandable by humans but also by machines.. Regarding the Web services, different primitive Web services within a composite Web service derive from diverse service providers and contribution is prone to the semantic misunderstandings.. WSDL provides a machine-processable interface in which components - 14 -.

(26) that contribute to a composite Web service can be executed automatically. machine-processable is not identical to machine-understandable. support for semantic description of Web services [9].. However,. WSDL provides less. Even if one output parameter of one. primitive Web service has the same name and type as an input parameter of another primitive Web service, it is not necessary that these parameters can be linked up to form a consistent composite service.. The Semantic Web is designed to increase the interoperability among machines by providing a machine-processable format with additional semantic information which can help the primitive Web services be searched and utilized autonomously hence increasing interoperability among Web services.. Figure 2-6. Semantic Web Stack [29]. The definition of ontology is: “Ont ol ogyi saf o r mal ,e x pl i c i ts pe c i f i c at i onofas har e d c onc e pt ual i z at i on”[27]. The author of [28] introduced this concept into the domain of Artificial Intelligent (AI) by extending the meaning of ontology to “Ont ol ogyasVoc abul ar y ”. The Semantic Web tries to create the vocabulary (ontology) for a specific domain and - 15 -.

(27) therefore different Web services in a heterogeneous environment can understand each other in this context.. The stack for the Semantic Web is shown in Figure 2-6.. Several standards were introduced to achieve this goal such as Web Ontology Language (OWL) [14],[30],[31],[32] and Web Ontology Language for Services (OWL-S or formerly DAML-S) [15].. These standards help to handle the semantic issues occurring in Web. service utilization.. 2.2.2 Web Ontology Language (OWL). The Semantic Web tries to build the ontologies for the Web in which information is given explicit meaning, making it easier for machines to automatically process and integrate information.. This concept can be realized by the Web Ontology Language (OWL) [14].. It. is a W3C recommendation language for defining Web Ontology.. OWL is based on XML, XML Schema, RDF and RDF Schema and it is derived from DARPA Agent Markup Language and the Ontology Inference Layer, in short DAML+OIL. In order to increase interoperability among machines, OWL is used to represent the meaning and semantics of terms on the Web explicitly and to describe explicitly the relationships between these terms.. Figure 2-7 shows three different species (sub-language) of OWL, OWL Full, OWL DL and OWL Lite, whose expressive abilities are decreased in order but the computational abilities are increased in reverse order.. OWL Full is meant for users who want maximum. expressiveness and the syntactic freedom of RDF with no computational guarantees.. OWL. DL (Description Logics) supports those who want the maximum expressiveness without losing computational completeness.. OWL Lite supports users primarily needing a. classification hierarchy with simple constraints. [14] - 16 -.

(28) OWL Full OWL DL OWL Lite. Figure 2-7. Three species for Web Ontology Language (OWL) [14]. In the simple example given in Figure 2-8, OWL is used to describe and define the semantics of terms.. In this case, the term cost (line 11) is a subclass of price (line 13) and. the term value (line 31) is also a subclass of price.. Therefore, one communication. counterpart can deduce and understand that cost can be related to value when the others talk about the notion price by using these different terms. beyond this example.. Certainly, the power of OWL goes. OWL can express notions and their complicated relationships,. constraints, data types, and other metadata.. The W3C article [30] presents the abstract syntax of the Web Ontology Language (OWL) and the test cases for the OWL approved by the Web Ontology Working Group can be found in the document [32]. Tools for supporting OWL such as DAMLJessKB and OWLJessKB can be found from [33],[34] respectively.. - 17 -.

(29) 1 <?xml version="1.0"?> 2 <rdf:RDF 3 xmlns:p1="http://protege.stanford.edu/plugins/owl/protege#" 4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 5 xmlns:xsd="http://www.w3.org/2001/XMLSchema#" 6 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 7 xmlns:owl="http://www.w3.org/2002/07/owl#" 8 xmlns="http://localhost:8080/tests/definition.owl#" 9 xml:base="http://localhost:8080/tests/definition.owl"> 10 <owl:Ontology rdf:about=""/> 11 <owl:Class rdf:ID="cost"> 12 <rdfs:subClassOf> 13 <owl:Class rdf:ID="price"/> 14 </rdfs:subClassOf> 15 </owl:Class> 16 <owl:Class rdf:ID="airperiod"> 17 <rdfs:subClassOf> 18 <owl:Class rdf:ID="airtime"/> 19 </rdfs:subClassOf> 20 </owl:Class> 21 <owl:Class rdf:ID="arrtime"> 22 <rdfs:subClassOf> 23 <owl:Class rdf:ID="arrivaltime"/> 24 </rdfs:subClassOf> 25 </owl:Class> 26 <owl:Class rdf:ID="stop"> 27 <rdfs:subClassOf> 28 <owl:Class rdf:ID="stops"/> 29 </rdfs:subClassOf> 30 </owl:Class> 31 <owl:Class rdf:ID="value"> 32 <rdfs:subClassOf rdf:resource="#price"/> 33 </owl:Class> 34 <owl:Class rdf:ID="enroute"> 35 <rdfs:subClassOf rdf:resource="#stops"/> 36 </owl:Class> 37 </rdf:RDF> Figure 2-8. An example for Web Ontology Language (OWL). 2.2.3 Web Ontology Language for Services (OWL-S). Web Ontology Language for Services (OWL-S), originally called DAML-S.. It is an. OWL-based ontology language which is used to describe the capabilities and properties of Web services in unambiguous and machine-understandable form. of the service ontology in OWL-S [15].. Figure 2-9 is the top level. In OWL-S, a Web service will be represented by. three essential types of knowledge which are as follows: - 18 -.

(30) (1) ServiceProfile: Describe “whatt he s e r v i c e doe s ?” Each Web service should present its own ServiceProfile to describe the capability, functionality and / or the contact information of a service.. These messages are normally for human users.. (2) ServiceModel: Elaborate “how t hes e r v i c ewor k sandhow t ous et hes e r v i c e ?” This information contains the structure (workflow) of a service including input, output, precondition and effects, usually referred to as IOPE.. If a Web service is. composed of several simple (primitive) services, OWL-S will use an element called a controlConstruct to describe the workflow among simple services.. These flow. control constructs include Sequence, Split, Split+Join, Unordered, Choice, If-Then-Else, Iterate, and Repeat-Until.. These messages are the main body of a. OWL-S document. (3) ServiceGrounding: Describe “howt oac c e s st hi ss e r v i c e ?” This message maps the abstract interface to concrete binding information by specifying the communication protocol, message formats, and other service-specific details such as port numbers.. Figure 2-9. The components of OWL-S [15]. OWL-S can be regard as a specialization of OWL which is dedicated for the domain of Web service.. An OWL-S document can therefore be understood not only by humans but. - 19 -.

(31) also by machines.. Briefly, ServiceProfile can be read and searched by humans; the. ServiceModel explains the workflow that the machines should obey when any process is invoked via the detailed protocol and format provided by ServiceGrounding.. 2.2.4 The mapping between UDDI and OWL-S. Web service providers adopt standard UDDI as a tool for advertising their Web services. However, the information represented in UDDI lacks semantic meaning, so it cannot fully support computers and people in cooperation.. With the complementary support from. Semantic Web technologies, the detail descriptions for a Web service can be modeled by OWL-S which is designed to handle the semantic issues associated with representing a Web service.. Retaining a list of semantic meanings in UDDI provides a convenient way to. support discovery of Web services, as the ServiceGrounding in OWL-S is able to locate WSDL documents and the associated Web services.. With OWL-S, the descriptions of Web. services can become machine-understandable concepts.. Figure 2-10 shows the mappings. between UDDI and OWL-S [35]. This enables UDDI and OWL-S to work seamlessly together for autonomous Web service discovery and execution.. The element qualityRating which resides in the ServiceProfile, shown in Figure 2-10, is the parameter used to record the higher level abstractions about the quality provided by a particular Web service.. The proposed approach uses this element and its corresponding. tModel to evaluate every Web services.. - 20 -.

(32) Figure 2-10. The mapping between OWL-S and UDDI specification [35]. Some elements such as e-mail, serviceName and textDescription are mapped directly from ServiceProfile to UDDI, whereas the OWL-S specific attributes such as input, output, and qualityRating are represented by the tModel structure.. A detailed illustration of how to. import the OWL-S profile file into the UDDI registry is discussed in [35]. brings the power of the Semantic Web into the UDDI registry.. This mapping. With this feature, information. stored in the UDDI registry can not only be understandable by humans but also by machines.. - 21 -.

(33) 2.3 Service composition The technologies or standards related to service composition will be reviewed in this s e c t i ons uc hBPEL4WS,CSSL,BPWS4 J ,e t c …. I na ddi t i on,t wodi f f e r e ntr unt i mes t r a t e g i e s. (centralized and decentralized) will be introduced as well.. 2.3.1 Service composition. Service composition is the construction process of composite services [8]. A composite service is a complex Web service which is composed of several simple (primitive) Web services.. There are many research programmes endeavour in this field such as BPEL4WS. [36],[37],[38], CSSL [9], WSIPL [41], WSCI [40], WSFL [39] and [8],[42],[43], etc.. Some. of these focus on the mechanisms of how to compose Web services while others are concerned with the semantic issues in composing a complex Web service.. The most frequently referenced language for Web service composition is the Business Process Execution Language for Web Services (BPEL4WS) [36],[37],[38] which has been developed jointly by IBM, BEA Systems, Microsoft, et al.. BPEL4WS is a high-level. distributed XML-based language which is used for assembling Web services to form a composite Web service. BPEL4WS enhances the Web services interaction model by supporting business transactions. The script language is used to describe the interactions among Web services by clarifying the control flow constructs (sequential, concurrent, conditional, etc.), the data structures and the activities (invoke, receive, compute, etc.) of a composite Web service as summarized in Table 2-4.. The BPEL4WS runtime engine. interprets BPEL4WS scripts to determine the execution process of a composite Web service.. - 22 -.

(34) Table 2-4 BPEL construct. Summary of BPEL constructs and notation [44] Description. Notation. Control Flow Constructs sequence switch while pick flow link variable invoke1 invoke2. receive reply assign. compute. sequential flow conditional flow iterative flow non-deterministic flow concurrent flow wait-notify type of synchronization Data Structures variables include a set of parts analogous to fields Activities synchronous (blocking) invocation on a partner P, sending data from an input variable in and receiving the response in the output variable out asynchronous (oneway, nonblocking) invocation on a partner P, sending data using an input variable in (no response variable) blocking receive of data from a partner P into a variable var send response to a partner P from a variable var assignment. Multiple assignments can be specified in a single assign statement, which executes atomically arithmetic or logical operation. s e que n c e… e nd-sequence s wi t c h… e nd-switch whi l e… e nd-while pi c k… e nd-pick f l ow… e nd-flow. source(linkId), target(linkId) v a r i a bl e Na me{ pa r t 1,pa r t 2 …} invoke(P, in, out). send(P, in). receive(P, var) reply(P, var) var1.p1.g1 = var2.p1.g3. The BPEL4WS flow constructs provide the ability for a developer to model the concurrent tasks within a composite Web service and to invoke them simultaneously. allows a service to wait for the response from other Web services.. It also. It can be treated as a. workflow control language.. In other works [7],[8], the authors try to model semantic service requests for composite Web services by enhancing OWL-S with language construct extensions. These works help to achieve a uniform semantic representation of service requests before service composition. It also enables discovery agents to unambiguously understand the service.. The authors of [9] define a Composite Service Specification Language (CSSL) which is based on XML and is a WSDL-like language for composite services.. This language extends. WSDL to provide the semantic feature of Web services and defines the specification of the - 23 -.

(35) control flow between composite service operations.. This work [9] proposed an. ontology-based framework to accomplish service composition as shown in Figure 2-11. They model the ontology using directed graphs i nwhi c ht henode sr e pr e s e ntt heont ol ogy ’ s concepts, the unfilled nodes refer to WSDL concepts, the gray nodes refer to extended features, and the e dge sr e pr e s e ntr e l a t i ons hi psbe t we e nt heont ol ogy ’ sc onc e pt sl a be l l e dwith the cardinality of the corresponding relationship.. In the research on service composition, most researchers focus on how to describe a composite Web service or model the process of service composition by assuming that all primitive services are ready-to-use or can be identified via simple UDDI queries. service discovery and selection are not the main concerns in this field.. Therefore,. The proposed. approach of this dissertation, a consensus-based service discovery, tries to touch upon this question to assist the consumer in service discovery and selection during the process of service composition.. Figure 2-11. Ontology-based description of Web services [9]. The most interesting idea of the CSSL work [9] is that the authors define a composability model for Web services to determine whether two Web services are composable or not. - 24 -. This.

(36) composability model uses two set of rules, syntactic rules and semantic rules, to estimate the composition possibility for two Web services. composability and (2) binding composability.. The syntactic rules concern (1) mode The semantic rules consider (1) message. composability, (2) operation semantics composability, (3) qualitative composability, and (4) composition soundness.. 2.3.2 Centralized and decentralized orchestration. The script languages introduced in Section 2.3.1 are used to describe the processes of Web services.. During runtime, the execution of a composite Web service is governed by a. runtime engine such as Business Process Execution Language for Web Services JavaTM Run Time (BPWS4J) [45]. Once a complex Web service is composed, it can be executed by a BPWS4J engine as shown in Figure 2-12 [44].. Figure 2-12. Centralized orchestration of a composite Web service [44]. In this example, a client has composed three primitive services AddressBook(1), AddressBook(2) and TrainRoute into a composite service called FindRoute.. FindRoute. needs two names, name1 and name2, from the client, then sends name1 to AddressBook(1) and name2 to AddressBook(2) for acquiring the addr1 for name1 and addr2 for name2 simultaneously.. FindRoute extracts only the city and zipcode from the returned two - 25 -.

(37) addresses as input parameters for TrainRoute. address1 to address2.. Figure 2-13. TrainRoute will return the train route from. This is so-called centralized orchestration or centralized execution.. Decentralized orchestration of a composite Web service [44]. During the runtime, however, BPEL4WS, WSIPL, WSCI, executed by BPWS4J can be modified for decentralized orchestration as shown in Figure 2-13.. A BPWS4J engine [45] is. required to be installed in each of the distributed primitive Web services.. The code for. FindRoute will be divided and distributed to each of the corresponding BPWS4J engine (D0, D1, D2, and D3).. FindRoute also receives name1 and name2 from client, and then send. name1 to D1 and name2 to D2 in parallel for acquiring the address. addr2 will not be forward back to the D0.. However, addr1 and. They will be directly sent to the D3 for carrying. out the TrainRoute and only the result of TrainRoute will be forward to D0.. This is known. as decentralized orchestration. These research projects, [4],[44], try to simulate and analyze the performances of different orchestration from various points of view such as throughput and response time. They find the performance of decentralized orchestration is somewhat better then centralized orchestration but it raises some questions in relation to fault handling.. Again, researchers in this field focus on how to handle the data flow and pay their attention to fault propagation. locate.. They assume that all primitive services are easy to find and. Service discovery and selection are not the main concerns in this field.. - 26 -.

(38) 2.4 Service discovery This section will briefly review the research and developments related to Web service discovery including three models for Web service discovery and two types of approach to service discovery.. 2.4.1 Three basic models for Web service discovery. Service discovery is a crucial process for Web service utilization.. Three basic models. for Web service discovery are identified: matchmaking, broker and peer-to-peer (P2P) as shown in Figure 2-14 [11],[46],[48].. The job for all discovery mechanisms are (a) take. Service Requestors (consumers) description of the required Web service to interact with advertisements of Service Providers, (b) find the Web service(s) that closely fit the description, and (c) get a flexible matching which shows the relation between advertisement and requests [46].. Figure 2-14. Three Models of Service Discovery [46] - 27 -.

(39) The first mode, matchmaking, is usually based on a centralized registry in which service advertisements from various Service Providers are stored.. When a Service Requestor. (consumer) seeks a service, he (she) submits his (her) requirements to the matchmaker.. The. matchmaker compares the requirements with the descriptions in the advertisements (such as ServiceProfiles) to find the suitable service(s).. Then, the registry responds with detailed. descriptions of the found services (such as ServiceGroundings) to the Service Requestor. Following reception of an embedded description, Service Requestors can invoke a service. Relevant research can be found in [12],[16],[51].. The second mode, broker, is slightly different from the previous one. discovery and mediation for a client [46].. It performs both. It also stores the advertisements of Web services. submitted by Service Providers and compares requests from Service Requestors with the advertisements.. If any suitable service is found, the broker acts as a proxy server by relaying. the interactions (request-response) between a Service Requestor and a Service Provider. That is, a Service Requestor talks to the Service Provider indirectly.. Similar research can be. found in [49],[50].. There is no centralized registry in the third mode, peer-to-peer (P2P).. In this scenario,. Service Requestors themselves find the Service Providers by message passing between peers. There is no matchmaker or broker.. When a Service Requestor seeks a service, it broadcasts. its requirements via a P2P network.. Any Service Provider getting this request will compare. its capabilities with the requirements and responds to the Service Requestor when its capabilities match the requirements.. This mode is useful for ad-hoc networks and ubiquitous. computing due to its dynamical nature.. Relevant research can be found in [47],[52],[53].. - 28 -.

(40) 2.4.2 Functional service discovery –capability discovery. The OASIS research on service discovery [5] is based on technologies of pattern matching and searching techniques that have been applied in the field of Very Large Databases (VLDB).. The proposed process searches for the required object in a huge amount. of data by the use of classified catalogues.. For example, it compares the requested name,. address, type of service or region information to the data stored in the registry, and returns the found bindingTemplate to the requestor if there is any match. indicates the URL of the found service.. The bindingTemplate. Using the URL, clients can download the WSDL. description and then starts to interact with the service as shown in Figure 2-15.. However,. UDDI provides a keyword search of Web services but not of capability [46]. It is hard to find a specific airline booking service through this approach because the service is advertized by its function.. Figure 2-15. Seeking flows for a specific service via UDDI Registry. Functional service discovery means searching by functionalities which are provided by Service Providers.. It is not only a simple pattern matching but also semantic searching.. For example, Se r vi c eRe que s t or sma yr e f e rt o‘ a i r l i nebooki ngs e r vi c e s ’t obookaf l i g ht .The discovery service should return booking services for airlines and not include other booking services, for example, for football or concert tickets. - 29 -. It is known as capability discovery..

(41) The work by a team at the Carnegie Mellon University (CMU), M. Paolucci et al. [15],[35],[46],[50], integrates the OWL-S matching engine into UDDI which enables capability search in a semantic context.. I tc ompa r e st heSe r vi c eRe que s t or s ’r e qui r e me nt s. wi t hSe r vi c ePr ovi de r s ’c a pa bi l i t i e sbased on semantic descriptions.. The approach proposed. by this dissertation will also leverage their work to enable service discovery using semantic descriptions.. This study proposes a consensus-based service discovery approach which. attempts to use the underlying data and information about services as a search criterion (quality rating).. With this feature, Service Requestors can discovery services by using. linguistic terms (vague queries) such as Cheap or Comfortable during their search for a flight booking service for example.. In [54], the authors argue that search by the information in the ServiceProfile is not enough to find a service properly.. The limitations arise due to the logical relationships. among the inputs and outputs of a process. outputs, o1 and o2.. Assume that a simple process produces two. If a request requires both of these outputs, it will result in a positive. match when the search is simply based on the ServiceProfile.. The authors of [54] develop. algorithms which do not search using the ServiceProfile but use the ServiceModel to examine the detailed execution process of a Web service.. They declared that analyzing the logical. nature within the process would increase accuracy.. However, the authors of [11] criticize. this idea and claim that the ServiceModel is not primarily provided to express properties to be used for finding matches.. Moreover, the use of underlying data referring to services as a. search criterion still has not been addressed in [54].. Another important project in the field of service discovery is the Language for Advertisement and Request for Knowledge Sharing (LARKS) [16].. It emphasizes that. matching should be based on other elements, NOT ONLY on keyword retrieval.. The. semantics of requests and advertisements should be taken into consideration. The discovery - 30 -.

(42) process of LARKS contains both syntactic and semantic concerns.. Table 2-5 shows the. frame structure of a LARKS specification used for service discovery. Table 2-5. The frame structure of a LARKS specification [16]. Context Types Input Output InConstraints OutConstraints ConcDescriptions TextDescription. Context of specification Declaration of used variable types Declaration of input variables Declaration of output variables Constraints on input variables Constraints on output variables Ontological descriptions of used words Textual description of specification. An overview for matchmaking using LARKS is shown in Figure 2-16.. The LARKS. approach offers the option to use application domain knowledge in any advertisement or request using a local ontology. functionality.. Briefly, LARKS provides discovery based on capability or. This point of view is important to the researches thereafter.. As mentioned. before, however, the approach proposed by this dissertation is not only interested in the semantic issues but also the vague queries based on the quality rating of the underlying data about Web services.. Figure 2-16. An overview for matchmaking using LARKS [16] - 31 -.

(43) In [11] and in earlier work [48], an algorithm to rank the corresponding Web services according to OWL-S descriptions during the discovery process is proposed.. In this. algorithm, all possible Web services will be analyzed in four stages: (1) the matching of inputs, (2) the matching of outputs, (3) the matching of service category, and (4) the matching of user-defined criteria. Each Web service will be rated during these four stages and the results will be aggregated to become the final assessment as shown in Figure 2-17. the assessments, a rank for Web services can be made for further selection.. According to. The ranking idea. has contributed to service discovery and is somewhat similar to what this dissertation proposes.. The concept of quality rating is also adopted by this dissertation.. In addition to. the concept of quality rating, this dissertation also details a rating procedure, describing how to evaluate a service using consensus based opinion, which has not been fully explored in [11],[48].. Figure 2-17. The rating procedures and ranking result for algorithm [11],[48]. Other work in functional discovery, such as [55], contribute their efforts in designing the detailed discovery algorithm for functional context reasoning within semantic environments.. However, all studies mentioned in this section are based on functional or capability search, but they have not paid sufficient attention to the use of underlying data and - 32 -.