中 華 大 學 碩 士 論 文
題目：使用者為中心的適性化網路服務選擇機制
系 所 別：資訊工程學系碩士班 學號姓名：M09502008 蔡文偉 指導教授：張欽智 博士
中華民國 九十七 年 八 月
摘要
近幾年隨著網路服務快速的發展，在網路上的網路服務也越來越多，要從註 冊中心裡眾多的網路服務當中，搜尋並選擇出一個能與符合使用者需求的服務，.
成為目前重要的研究主題。
目前的網路服務選擇機制中多著重於準確率及召回率的計算來選擇出適合 服務，但是在許多商業的運作，人的喜好往往是最後決定的重要因素。在本論文 中，我們提出一個方案，以使用者為中心的適性化網路服務選擇機制，以提供更 符合人性需求的服務。我們利用現有的網路服務的註冊中心，結合我們提出的排 序機制、排名機制與使用者回饋機制，建構出我們的系統。當使用者欲搜尋服務 時，可透過我們提供的搜尋介面，配合排序機制模組與排名機制模組來搜尋與選 擇適合的服務。在排名機制模組中，我們使用了兩種演算法，分別是規則基準法 與權重加權法，來選出最適合的服務推薦給使用者。最後利用使用者回饋機制模 組，當使用者在使用系統及使用後，系統會收集使用者的喜好度及對服務各項屬 性的滿意度等特徵值，將這些特徵值回饋至系統中，動態改變服務屬性的權重配 分，提供給使用者適性化的服務。
我們以旅遊服務搜尋的範例，利用我們的系統依據使用者的喜好度與需求規 劃出一套旅遊行程。最後以評估與分析的方式，相互比較我們在排名機制模組中 所提出的兩種演算法的執行時間效能、平均精準度與其優缺點，並分析比較我們 的系統與其他研究中所提出系統之間的功能性。
關鍵詞：網路服務、註冊中心、服務搜尋、服務選擇
Abstract
With the fast development of Web services in recent years more and more Web services are available and registered with UDDI. To search and select a suitable Web service that can meet user's requirements from the numerous Web services has become an important research topic.
The present selection mechanisms of Web services focus more on calculation of the precision and recall rate. But in a lot of business operations, users' preferences are often the decision factor. In order to offer Web services that satisfy users' preferences we present a user-centered mechanism for adaptive Web service selection in this paper. We use the existing Web service registry and integrate with the sorting, ranking, and feedback mechanisms proposed by us to construct the system. When a user wants to search and select a web service, she or he can use the system interface of our design to accomplish the work. In the ranking mechanisms, we adopt two algorithms: the rule-based and weighting methods, to select a suitable Web Service and recommend to the user. Finally, we use the feedback mechanism. When a user is using or after using the system, the system will collect the rating values of user's preferences and satisfaction characteristics and then feedback them to the system. In order to search and select the most suitable Web Service that meets user’s preferences these feedback values will adjust the weighting of Web Services dynamically, to provide the user with the adaptable Web Services.
We use the tourist service as an example to validate the feasibility of our system.
We will show how a user utilizes our system to plan a trip according to the degree of user's preferences. Finally, we will analyze the algorithms that we present, and compare their advantages and disadvantages. And we also analyze our system and compare with other research work.
Keyword：Web Services、UDDI、Service Discovery、Service Selection
致謝
總算來到了這個階段，我的研究所生涯也即將告一個段落。在這兩年中，首 先非常感謝我的指導老師張欽智博士在這段期間的細心教導，時常在我遇到困難 時能夠給予適時的協助，讓我能夠順利完成我的學業及論文。老師帶給我們的不 僅僅是課業上的協助，風趣的個性，讓我們生活上點點滴滴，添了許多的歡笑。
再來，我要感謝在我大學及研究所這六年當中所結識的所有朋友，多年室友 小巨人與皓呆，愛搞怪虧人的阿仔，常給予課業協助的小吳，同實驗室的思君、
ICE 與紅月，還有阿達、咖口、小强、小工、布然思、、芋頭、阿信、CCrain、
段段、News、阿真、家欣、阿沒……等等數不完的朋友，讓我這幾年的生活上添 了許多的歡樂與色彩。
最後，最必頇要感謝的是我的家人，感謝他們經濟與精神上的支持與鼓勵，
讓我在學習上無後顧之憂，這份恩情我永遠都不會忘記的。雖然從小扶養我長大 的爺爺無法與我一同分享畢業的喜悅，不過我相信在天上的爺爺，一定很為我開 心。最後在一次感謝所有的人，因為有你們，讓我的生活更添風采樂趣。
內容目錄
摘要……….I Abstract………..II 致謝………..III 論文目錄………..IV 表目錄………..VI 圖目錄………...VIII
第一章 緒論………..1
1.1. 研究背景與動機………..1
1.2. 研究目的………..2
1.3. 論文架構………..2
第二章 相關文獻與技術探討………..4
2.1. Web Service 及其相關技術………....…………4
2.1.1. Web Services………4
2.1.2. XML……….4
2.1.3. WSDL……….………..5
2.1.4. SOAP………7
2.1.5. UDDI………7
2.1.6. Service-Oriented Architecture………..9
2.2. 網路服務應用的探討………..10
2.2.1. 網路服務的搜尋………...………10
2.2.2. 網路服務的選擇………...………12
2.2.3. 名聲與推薦機制………...13
第三章 系統架構設計與流程………...……….15
3.1. 系統設計簡介與需求分析…………...…...………15
3.2. 系統架構………...………...16
3.3. 註冊中心 jUDDI………...………...18
3.4. 服務配對流程…...…………..……….21
3.4.1. 排序機制模組………...……….22
3.4.2. 排名機制模組………...………23
3.4.2.1 規則基準法………...………..23
3.4.2.2 權重加權法………...………..24
3.4.3. 使用者回饋模組………...………26
第四章 系統範例實作………...……….28
4.1 系統開發環境…………...………28
4.2 範例設計………...………29
4.2.1 服務註冊………...……….29
4.2.2 系統功能………...……….31
4.3 實作執行與結果………...………32
4.3.1 實作服務註冊………...……….32
4.3.2 實作系統介面………...……….33
第五章 系統實驗分析………...……….40
5.1 執行時間效能………...………40
5.2 平均精準度………...………41
5.3 實驗分析與討論………...………44
5.4 其它系統之比較………...………45
第六章 結論與未來展望………...……….47
參考文獻………...………...48
圖目錄
圖 2.1 XML 文件描述範例………5
圖 2.2 WSDL 文件檔案格式……….6
圖 2.3 WSDL 文件範例……….6
圖 2.4 SOAP 訊息格式範例………..7
圖 2.5 UDDI 儲存的資料結構………..8
圖 2.6 WSDL 與 UDDI 的對應關係………..9
圖 2.7 服務導向架構圖………10
圖 2.8 訂旅館的網路服務組合範例………11
圖 3.1 系統架構圖………17
圖 3.2 jUDDI 資料庫表格關連圖………18
圖 3.3 jUDDI 處理 client 端要求處理程序……….…….20
圖 3.4 服務配對流程………21
圖 3.5 規則基準法選擇範例………23
圖 4.1 送出需求後示意圖………31
圖 4.2 jUDDI 內建畫面………32
圖 4.3 UDDI Browser 註冊服務圖………..33
圖 4.4 系統主畫面………34
圖 4.5 行程組合-規則基準法服務選擇畫面………...34
圖 4.6 行程組合-權重加權法服務選擇畫面………..35
圖 4.7 行程組合的 SOAP 需求訊息……….35
圖 4.8 飲食的 SOAP 需求訊息………36
圖 4.9 旅館的 SOAP 需求訊息………36
圖 4.10 行程排程服務結果畫面……….….37
圖 4.11 飲食服務的推薦結果畫面……….….37
圖 4.12 旅館服務的推薦結果畫面-規則基準法………38
圖 4.13 旅館服務的推薦結果畫面-權重加權法………38
圖 4.14 回饋模組介面……….39
圖 5.1 程式執行時間效能的結果………41
圖 5.2 使用者輸入需求花費時間………41
圖 5.3 旅館服務選擇 MAP 比較……….42
圖 5.4 旅館服務選擇 MAP 平均值比較……….43
圖 5.5 飲食服務選擇 MAP 比較……….43
圖 5.6 飲食服務選擇 MAP 平均值比較……….44
表目錄
表 3.1 jUDDI API……….………19
表 3.2 Inquiry API………19
表 3.3 Publishers API………...19
表 3.4 排序機制模組演算法………22
表 3.5 排名機制模組演算法-規則基準法………..24
表 3.6 排名機制模組演算法-權重加權法………..25
表 3.7 使用者回饋模組演算法………26
表 4.1 系統實作環境………28
表 4.2 旅館服務分類及其資訊………29
表 4.3 飲食服務分類及其資訊………30
表 4.4 行程服務分類及其資訊………30
表 5.1 規則基準法與權重加權法的較………45
表 5.2 各系統功能之比較………46
第一章 緒論
近幾年隨著網路服務(Web Services)快速的發展，服務提供者發佈(Publish) 服務至服務的註冊器 Universal Description, Discovery and Integration (UDDI)，服 務需求者可透過 UDDI 去發現(Find)並呼叫服務。在網路服務越來越多的情況，
要從眾多的網路服務當中搜尋並選擇出一個能與使用者需求配對的服務，傳統的 UDDI 並無法有效地達成，因此如何有效選取是現在許多研究者所努力的一個目 標。在 1.1 節說明本論文的研究背景與動機，1.2 節說明本論文的目的，1.3 則會 介紹本論文的章節架構。
1.1 研究背景與動機
數年前，網路發展剛起步時，只有一般單純的文件網頁(document Web)能供 瀏覽，透過網路分享資訊與服務。而隨著網路的快速發展與頻寬的增進，網路成 為商業活動主要的媒介之一，一般單純的文件網頁的發佈與瀏覽已經無法滿足大 多的商業公司與使用者的需要，人們更近一步需要的是資訊整合與應用程式整合，
但是大多的商業公司所發佈的應用程式，可能都有各自的規格與平台，也可能因 所使用不同的作業系統，而無法達到應用程式整合與資訊整合的目標。為了解決 此問題，所以有了網路服務等技術的產生。
在傳統的系統應用整合技術中，包括了 COBRA、COM+、RMI 等中介軟體，
其用意都在解決企業應用程式整合的問題，卻礙於各種應用程式的介面與規格的 不同，未能達到資訊及應用程式整合的目的。直到 Web Service 相關規格技術的 產生，這個問題才逐漸解決。網路服務技術與服務導向架構(Service-Oriented Architecture, SOA)的結合，進而達到資訊與應用程式跨平台性的整合，成為目前 新興電子商務交易最流行的平台之ㄧ。
網路服務的應用研究之中，網路服務組合(Service Composition)、服務搜尋 (Service Discovery)與服務選擇(Service Selection)是重要的一環，從眾多的服務當 中，搜尋並選擇出最符合需求的服務，並且當單一服務無法滿足需求時，則必頇 選出多個服務並協調組合後提供給予使用者，這些都是值得研究的主題。
UDDI 雖然為網路服務的規格標準之一，但是其搜尋功能性與實用性並不高，
例如：先前註冊在 UDDI 中的服務可能已經被更改，但是服務提供者尚未至 UDDI 中更新，會造成搜尋結果的錯誤，此問題可能解決方法就是加入外掛程式，週期 性的至 UDDI 中檢查所有服務是否仍然存在或者已被更改。另一方面，在 UDDI 中只能利用關鍵字搜尋去搜尋出單一服務，並且必頇明確知道所需服務的正確分 類名稱與相關服務的描述(Service Description)，才能搜尋出使用者自己真正想要。
上述問題必頇透過額外的搜尋法則和組合服務技術來解決，而本論文中，會提出 搜尋法則來配合 UDDI 去搜尋並選出適合的服務。
1.2 研究目的
目前在網路服務搜尋與選擇的研究當中，多著重於準確率(precision)與召回 率(recall)的相似度計算來評估選擇出最適合的服務，但是在許多的商業運作中，
人的喜好往往是最後決定的因素。
在本論文中，我們提出一個方案，以使用者為中心的適性化網路服務選擇機 制，其中我們利用開放軟體 Apache jUDDI 實際架設我們的註冊中心，並配合我 們所提出的三個主要模組：排序機制模組、排名機制模組、與使用者回饋機制模 組。三個模組中，以排序與排名機制模組來強化 jUDDI 的搜尋與選擇功能，並 以使用者的喜好度為基準來選擇出最適合使用者的服務。另外，在排名機制模組 中，我們提出了兩種演算法，分別是規則基準法與權重加權法，再利用使用者回 饋機制模組，動態改變服務屬性的權重配分，達成服務對使用者的適性化。
系統實驗中，我們以旅遊服務搜尋的範例，可利用我們的系統查詢所有服務 項目與服務相關內容，並依使用者喜好度規劃出一套完整的旅遊行程。最後我們 會評估所提出的兩個演算法的效能與優缺點，並分析比較我們的系統與其他研究 中所提出系統之間的功能性。
1.3 論文架構
本論文中一共分為六章。第一章為論文研究的緒論，說明我們的研究為何、
為何要研究此論文、與此論文的研究方法。第二章為論文相關技術與文獻探討，
我們會針對本篇論文中所提及的相關技術與研究，依序探討說明。第三章為系統 架構，此章節為本論文的核心，說明我們研究當中所提出的系統架構流程與研究 方法，並細部的討論架構中所有元件與演算法。第四章為系統範例實作，會以 JAVA 平台開發出我們所提出的系統，並應用在旅遊服務搜尋，針對各使用者，
規劃出一套完整行程。第五章為系統評估，針對我們所提出的研究方法，細部討 論當中細節，藉以比較與驗證我們所提出的方法，並且會比較以前研究者所提出 的系統，比較各系統彼此的功能性。。第六章為結論與未來展望，針對本篇論文 作總結，並討論未來可進一步的研究方向。
第二章 相關文獻與技術探討
在本章中，將概述本篇論文會涉及到的一些知識與技術，包括了服務導向計 算、網路服務、服務註冊中心與服務搜尋與選擇等等，藉此更進一步了解網路服 務知識與技術的背景。在 2.1 節中將簡介 Web Service 與相關的技術知識，包括 了 XML、WSDL、SOAP、UDDI 與 SOA 等。在 2.2 節中將簡介目前網路服務搜 尋與網路服務選擇的相關知識與目前研究狀況。
2.1 Web Services 及其相關技術
2.1.1 Web Services
Web Services 一般稱為網路服務，為一種整合跨平台應用程式的技術，目的 在於解決資訊與應用程式整合時所遭遇到互通性的問題，經由 XML 語言定義與 描述其公開介面，將應用程式包裝成服務，透過合乎網際網路訊息協定標準，交 換服務的規格及描述，不論兩者間作業系統是否相同，皆可透過 URI 去辨識並 存取網路上所有的服務。簡單的說，Web Services 是以 XML 為溝通媒介，在網 際網路上提供其他程式或系統呼叫使用的程式。Web Services 功能特性包含有：
重複使用性、獨立性、物件導向等特色。
Web Services 主要包含了 XML、WSDL、SOAP、UDDI 等標準技術規格。
Web Service 的運作是透過 WSDL 服務描述與 SOAP 的訊息交換，藉此達成電腦 或程式之間的溝通。下面將詳細介紹這些標準技術規格。
2.1.2 XML
XML(eXtensible Markup Language)稱為延伸標記語言，資料結構屬於樹狀結 構，利用能讓電腦理解的標籤方式，並採用以文字為基礎的描述方式，圖 2.1 為 XML 文件的範例，所描述的是個人資訊。要讓電腦去理解一份 XML 文件，必 頇 利 用 程 式 透 過 剖 析 器 (Parser) 的 協 助 處 理 ， 常 用 剖 析 方 式 包 括 有 ： DOM(Document Object Model)與 SAX(Simple API for XML)。
圖 2.1 XML 文件描述範例
DOM 是利用物件驅動的方式，將整個 XML 文件以物件樹狀展開，藉此可 以方便搜尋、新增、刪除或修改 XML 文件，缺點是記憶體使用量大。SAX 是利 用事件驅動的方式，連續處理解釋 XML 文件內容，不需讀取全部的 XML 文件，
記憶體相對使用較少，效率上比較高，不過只適用在單項或者有順序性的查詢。
2.1.3 WSDL
WSDL(Web Service Description Language)稱為網路服務描述語言，以 XML 為基礎描述一個服務的介面(interface)與執行，規範出網路服務輸入與輸出的參 數，使用者藉由 WSDL 文件的規格，能了解服務相關資訊與如何去存取並使用 這個服務。簡單的說就是讓使用者明白這個服務是什麼與如何去使用。WSDL 藉由 XML Schema 界定文件內的元素、屬性，去描述一個服務。XML Schema 中包含六個主要 元素，此六 元素在描述架構上又可分為 介面描述 (Interface Description)與執行描述(Implementation Description)兩個部分，如圖 2.2 所示[4]。
介面描述定義出 WSDL 檔案資料的格式、傳遞溝通的訊息、以及執行的方式，
執行介面主要說明如何執行服務。圖 2.3 為一個 WSDL 文件的範例：
<?xml version="1.0" encoding="Big5"?>
<!DOCTYPE Personal_Info SYSTEM
http://www.ws.org.tw/xml/Personal_Info.dtd>
< Personal_Info >
<Number>9502008</Number>
<Name>蔡小明</Name>
<Major>資訊工程所</Major>
<Email>Tsai@chu.edu.tw</Email>
<Phone>03-530-5400</Phone>
</Personal_Info >
圖 2.2 WSDL 文件檔案格式[4]
圖 2.3 WSDL 文件範例
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="LoanRequest" targetNamespace="http://j2ee.netbeans.org/wsdl/LoanRequest"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="http://xml.netbeans.org/schema/LoanRequest"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://j2ee.netbeans.org/wsdl/LoanRequest">
<types>
<xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/LoanRequest">
<xsd:import namespace="http://xml.netbeans.org/schema/LoanRequest" schemaLocation="LoanRequest.xsd"/>
</xsd:schema>
</types>
<message name="LoanRequestOperationRequest"><part name="reqMessage" element="ns:ReqElement"/></message>
<message name="LoanRequestOperationReply"><part name="respMessage" element="ns:RespElement"/></message>
<portType name="LoanRequestPortType">
<operation name="LoanRequestOperation">
<input name="in" message="tns:LoanReqRequest"/><output name="out" message="tns:LoanRequReply"/>
</operation>
</portType>
<binding name="LoanRequestBinding" type="tns:LoanRequestPortType">//~~~~~~~~~~</binding>
<service name="LoanRequestService">
<port name="LoanRequestPort" binding="tns:LoanRequestBinding">
<soap:address location="http://localhost:18181/LoanRequestService/LoanRequestPort"/></port>
</service>
</definitions>
介面描述
Interface Description
Type 資料類型集
資料交換時所用的檔案類型
執行描述
Implementation Description
Service 實作服務 封裝所有服務內容
Port 服務端點 服務位置 Message 訊息 服務的細節抽象概念
PortType 介面定義 定義送接收的訊息
Binding 連結 定義訊息格式與協定
2.1.4 SOAP
SOAP(Simple Object Access Protocol)稱為簡單物件存取協定，以 XML 為基 礎，定義規範資訊交換的協定。SOAP 可搭配 HTTP 協定作同步(synchronous)傳 輸，或利用 SMTP 作非同步(asynchronous)傳輸。RPC(Remote Procedure Call)稱 做遠端呼叫程式，表示需求端與服務端之間的訊息交談程序，如果以 XML 當作 為編碼法，則稱 XML-RPC。SOAP 簡單的說就是透過 HTTP 以 XML 文件型式 作服務的遠端呼叫。
一個 SOAP 訊息格式的根元素為 SOAP Envelope，在裡面包含了 SOAP Header 與 SOAP Body 兩部分。Header 定義出 SOAP 的內文、資料型態、編碼法 等，而 Body 則是客戶端與伺服端間互相傳遞的訊息內容。圖 2.4 為一個 SOAP 訊息格式的範例。
圖 2.4 SOAP 訊息格式範例
2.1.5 UDDI
UDDI(Universal Discovery Description and Integration)[33]稱為通用發現描述 與整合，以 XML 為基礎定義服務註冊與搜尋的一個規格與技術。UDDI 存在的 目的是為了讓網路服務的使用者能動態地取得服務端點的位置。類似搜尋引擎，
扮演仲介者的角色，主要提供三種功能：註冊、發佈、查詢等。商業公司之間可
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header/>
<S:Body>
<ns2:PorcessApplicOperation xmlns:ns2="http://LoacProcessor/">
<socialSecurityNumber>001004</socialSecurityNumber>
<applicantName>mingo</applicantName>
<applicantAddress>Taiwan</applicantAddress>
<applicantEmailAddress>mingo@cc.chu</applicantEmailAddress>
<applicantAge>25</applicantAge>
<applicantGender>male</applicantGender>
<annualSalary>35000.0</annualSalary>
<amountRequested>50000.0</amountRequested>
</ns2:PorcessApplicOperation>
</S:Body>
</S:Envelope>
以透過 UDDI 將他們的產業整合起來，彼此之間可以互相取得產業相關資訊。目 前已有許多組織與企業，例如 IBM、Microsoft、SAP、與 HP 等等，都已經設計 出 UDDI 註冊中心。一個網路服務儲存在 UDDI 中含有三種資訊：
1. 白頁(White pages) ：服務名稱、位置、通訊方式及其它商業資訊 2. 黃頁(Yellow pages)：標準分類法的資訊
3. 綠頁(Green pages) ：呼叫與使用 Web services 所需的技術細節
另外在 UDDI 儲存的資料結構，包含五個主要元素，如圖 2.5：
1. businessEntity：提供服務的商業公司的詳細資訊，擁有唯一的實體辨別 號碼，可包含一個或多個 businessServices
2. businessServices：一個特定服務的描述資訊，擁有唯一的服務辨別號碼，
可包含一個或多個 bindingTemplate
3. bindingTemplate：服務的連結點與規格技術的資訊，對應到一個 tModel 4. tModel：服務的介面規格，包括了服務技術資訊與描述的專有名詞 5. PublicAssertion：多公司團體之間的關聯性
圖 2.5 UDDI 儲存的資料結構
<PublisherAssertion>
<businessEntity>
<businessServices>
<bindingTemplate>
<tModel>
UDDI API 將各種處理方式集合起來，分成工作(Node)端 API 與客戶(Client) 端 API。UDDI API 可使用的功能為 Inquiry API 與 Publishers API。Inquiry API 提供查詢 UDDI 中的服務資訊。Publishers API 則提供可以去儲存、更新或刪除 儲存在 UDDI 中的資料。
一份 WSDL 文件儲存於 UDDI 中，有其相對應的關係，也就是 WSDL 中的 介面(Interface)描述會與 UDDI 的 tModel 元素的資料結構相對應。另一個是，
WSDL 的 執 行 (Implementation) 描 述 與 UDDI 的 bindingTemplate 與 businessServices 元素的資料結構相對應，如圖 2.6 所示
圖 2.6 WSDL 與 UDDI 的對應關係
2.1.6 Service-Oriented Architecture
服務導向架構(SOA)是一種應用軟體架構的概念，目的是在建構一個統一的 計算模式架構，在此計算環境中，資源以清楚分割、可再使用(Reuse)的跨平台服 務方式呈現，使用標準化的介面互相溝通，藉此提供更具效率以及資訊整合的環 境。在服務導向計算環境主要包含服務需求者(Service Requester)、服務提供者 (Service Provider)與服務仲介者(Service Broker)等三種角色和註冊(Publish)、發現
介面描述 Type Message PortType Binding
執行描述
Service Port Port
<businessEntity>
<businessServices>
<tModel>
<bindingTemplate>
(Find)、連結(Binding)等三個功能動作所建構出來，其中 UDDI 所擔任的是服務 仲介者的角色，如圖 2.7：
圖 2.7 服務導向架構圖
2.2 網路服務配對
2.2.1 網路服務的搜尋(Web Service Discovery)
網路服務的搜尋(Web Services Discovery)目的是在從 UDDI 裡眾多的服務當 中，選出一組功能特性可能符合需求的服務。網路服務搜尋以 UDDI 搜尋法為最 基礎的方法，UDDI 搜尋法就類似是關鍵字分類搜尋法，搜尋時需要知道明確的 服務名稱、分類並符合文法，而且只能簡單比對 WSDL 的規格，回覆可能的服 務，但是往往無法選出最適合的服務，所以在實用性上並不高，因此有不少的研 究在強化 UDDI 功能。服務搜尋不足的地方除了 UDDI 功能不足的原因之外，還 有就是選擇的正確性，因為在搜尋結果中，通常只要服務者需求能夠與 WSDL 相符，就會被挑選出來，如此，可能會造成搜尋結果有過多的情況發生。因此在 服務選擇的方法上，也已經有許多研究者致力於其中，我們將在下一個小節上介 紹。
搜尋部分還包括了網路服務組合(Web Service Composition)，當單一的網路 服務中介者
服務提供者 服務需求者
發現 註冊
連結
服務無法滿足需求時，就會挑選出多個能夠符合需求的服務，然後將它們組合起 來，再提供給使用者，圖 2.8 為一個簡單的組合服務範例，某顧客想去日本旅遊，
由於幣值的不同，頇先透過轉匯率的運算，再去訂購旅館服務。
圖 2.8 訂旅館的網路服務組合範例
服務組合區分為兩種，一種為靜態組合，另一種為動態組合。這兩種差別是 在靜態組合必頇在執行前就必頇將整個流程組合包裝好，而動態組合能夠在執行 期間中選出適合的服務，然後再行組合動作。標準的 UDDI，並無法滿足服務組 合的功能，只能夠單純的選出一個服務，如果所有單一服務都無法滿足需求時，
或許就無法提供任何的服務給予使用者。因此如果想要能夠動態的組合服務，勢 必 需 要 額 外 附 加 方 法 才 能 夠 達 成 。 由 Current Solutions for Web Service Composition[8]此篇論文的觀點來說，要完成一個完整的組合服務，有四個需求 必需要達成：連接性(Connectivity)、非功能性(Nonfunctional)、正確性(Correctness)、
延展性(Scalability)。此篇論文也提到，目前標準的服務組合方法已經有許多，包 括了有 BPEL、OWL-S、Web Components、Algebraic Process、Petri-Net 與 Finite State Machine 等技術方法。除了上述的標準方法，其他目前在網路組合的研究也 已經相當多[9,10,11,12,13,14]，以 A Business Model for Dynamic Composition of Telecommunication Web Services 為例[9]，這篇論文是以能夠達到動態的服務組合 為 目 標 ， 所 使 用 的 方 法 是 利 用 標 準 的 Web Services business model 與 Telecommunication business model：TINA 等兩種模組，整合設計出他們所提出的 模組，以達到動態服務組合的目的。
組合結果 使用者需求
轉匯率 訂旅館
服務組合程序
2.2.2 網路服務的選擇(Web Service Selection)
網路服務的選擇(Web Services Selection)則是從一組可能的服務當中，經過 某種方法，挑選出與需求最相符的服務，推薦給使用者。目前也有許多有關於服 務選擇方面的研究，下面我們將會介紹一些可以用來幫助網路服務選擇的方法。
在 Service-Oriented Architecture[7]這本書中提到，網路服務選擇可分為語意 式服務選擇(Semantic Service Selection)、社交式服務選擇(Social Service Selection) 與經濟式服務選擇(Economic Service Selection)等三大類。語意式服務選擇是利用 語意的方式對網路服務描述它的功能，解譯使用者需求的語意，然後分析兩者彼 此的語意相似程度，以選擇出最適合的服務。社交式服務選擇 是利用回饋 (feedback)的方式來達到服務與使用者之間的互動，藉以能對各種不同的人選出 個別所適合的服務。經濟式服務選擇是以經濟利益上來考量，包括了商業公司上 利益營收與使用者付費上等等的考量，商業公司如何能有最大營利或者使用者如 何能以最低的費用找出最適合的服務，是這裡所想要探討的。
排名機制(Ranking)是許多研究者在網路服務選擇的研究上[15,16,17]，時常 選擇的方法，是以使用本體論(Ontology)為基礎來推論服務特性與使用者需求的 相似程度，藉以找出最適當的服務。排名機制功用在於，通常我們搜尋出的結果 往往可能都不只一個或者可能並非真正使用者所想要的，而排名機制可以推論服 務特性與需求的相似程度，然後推薦相似程度高的給予使用者。目前已經有相當 多與排名機制相關的研究。以 Web Service Selection Mechanisms in the Web Service Execution Environment(WSMX)為例[16]，提出一個服務選擇的計算環境。第一步，
首先排序使用者的喜好度，藉以事先過濾較低層次的服務。第二步，在不同使用 者但相同的需求目標下，會推薦先前使用者所選擇的服務。方法是紀錄網路服務 個別的被使用次數，然後利用此數值去跟第一步所產生的結果作運算，最後選出 最合適的服務推薦給使用者。
語意(Semantic)搜尋也是目前相當熱門的研究方向主題[17,18,19,20,21]，而且 語意經常與排名機制配合使用。標準 UDDI 搜尋只能夠利用合乎語法的需求去搜 尋，如果加入 語意 功能，必定更能選出更符合需求的服務。 以 A Ranking Mechanism for Semantic Web Service Discovery 為例[17]，利用語意分析配合排名 機制，計算服務特性與需求的語意相似程度，選出程度較高者，其中所使用的相
似度計算方法為準確率(Precision)與召回率(Recall)的計算。
O. Fragoso 等人所提出的案例式推導(Case-based Reasoning) [23]服務選擇方 法，是利用案例領域(Domain)的分類的方式，建構成可以讓服務提供者自行去描 述他的服務特性功能，系統在幫助使用者選擇服務時，會透過他們裡面所提出的 演算法，先從知識庫中去挑選出一個案例(Case)，然後與使用者的需求去配對。
服務品質 (Quality of Service，QoS) 驅動方式去選擇適當的服務也是熱門的 研究主題[24,28,29]。例如：W. Lin 等人所提出的 QCMA[24]是利用模糊理論 (Fuzzy)的方法，來協助去運算 QoS 的一致性，並且實作出一套工具，使用在預 訂旅館的應用上面。
2.2.3 名聲與推薦機制
前 述 三 大 類 服 務 選 擇 方 法 中 ， 社 交 式 服 務 選 擇 方 法 裡 常 可 區 分 名 聲 (Reputation)機制與推薦(Recommender)機制。名聲機制是利用使用者去評價以被 使用過的服務，給予其他正在搜尋與選擇服務的使用者作為參考，單獨使用一個 參數來評價一個服務。此種方法已經廣泛的被利用在電子商務(e-commerce)的應 用上，例如 eBay，買家購買東西後，可給予賣家一個名聲評價，評價可為 0、1 與-1 等三種數值。此缺點為使用者可能惡性給分的情況，例如某人對某賣家有其 他因素的不滿意，可能會聯合其他朋友一起給予負評價，造成此賣家的名聲減低，
影響以後其他買家對此賣家的印象。
推薦機制可用來去預測一個使用者的需求或者興趣，此種方法也已經廣泛的 被使用，例如 amazon.com 使用了 collaborative filtering(CF)演算法。在 CF 演算 法中，使用者給予不同服務的評等會集中儲存於伺服端，而服務的評等是由使用 者購買服務時所紀錄。而 CF 推薦系統會根據這些存於伺服端的評等來推薦使用 者去購買一些服務。例如，甲使用者在先前買了 A、B 與 C 三項產品，而乙使用 者買了 A 與 C 兩項產品，則 CF 推薦系統就會推薦乙使用者購買 B 這項產品。
利用此兩種機制作服務選擇的研究已經有許多，在 C.H. Hsu[5]所提出的系 統中，擁有語意比較的功能，並可儲存個人化的服務喜好資訊，利用使用者對服 務喜好的資訊，作為往後服務選擇中的參考依據。S. Kalepu[25]等所提出的是以 SLA (Service level agreement)為基礎，使用的方法是名聲機制，此名聲的計算方
法，是利用承諾值(Compliance)、可靠值(Verity)與使用者評價(Ranking)三項參數 為準則來選出一個適合的服務。E. M. Maximilien[26]等提出的系統，則透過代理 人(agent) 讓使用者所需要的服務特性與服務提供者能自定的服務特性，再利用 比對演算法(Policy matching algorithm)來比對雙方提出的特性，自動找出符合使 用者所要求的服務。H. Wang[27]等所提出的系統會依照使用者的輸入與輸出來 選擇服務，當中會評估語意與使用者的偏好來選擇出適合的服務。
第三章 系統設計架構與流程
在本章中，是本篇論文中最主要的部分，將會說明在論文中所設計的系統細 節，包括了系統架構、系統流程、註冊中心、與服務選擇流程裡的三個模組等等，
讓大家能夠充分了解本篇論文所提出的研究與方法。
3.1 系統設計簡介與需求分析
本篇論文研究的主要目標，是在實作建置一個以使用者為中心的適性化網路 服務選擇平台系統，讓商業公司可以透過一個介面，註冊他們的服務至 UDDI，
使用者可以透過我們所提出的方法自動去搜尋所需要的服務。此系統的建置上，
我們實際架設 jUDDI 當作我們的註冊中心，加入我們所提出的排序機制模組與 排名機制模組輔助 jUDDI 去搜尋最適合的服務，而利用使用者回饋模組來動態 改變服務屬性的權重分數。最後實際應用在旅遊搜尋的範例上。
經過在第二章的文獻與相關技術的探討與上面系統設計的簡介，大略分析出 在設計我們所需的系統中，需要包括以下的幾種相關技術：
1. UDDI 註冊中心：UDDI 的架設可以說是最主要的部分，它也是 SOA 裡 最核心的部分，可以讓不同的公司註冊他們的服務，提供使用者去搜尋 與使用。
2. 服務選擇流程模組：在我們所提出的演算法中，包含了三個模組：第一 個是排序機制模組，用來事先篩選剔除與服務屬性相差較多的服務。第 二是排名機制模組，用來計算篩選過後還存留的服務與使用者需求之間 的相似程度，我們在此模組裡，提出規則基準法與權重加權法使用在這 裡面。第三是使用者回饋模組：讓使用者能夠回饋對服務屬性的調整，
動態的改變服務屬性的權重分數。
3. 服務註冊的介面：必頇有一個提供商業公司註冊服務的介面。
4. 服務搜尋的介面：必頇有一個提供使用者能夠去搜尋呼叫服務的介面，
在這個介面中，我們所用的方式是網頁選項式的勾選，可以讓使用者勾 選他們所需要的服務類型與各種服務屬性的權重，幫助我們再搜尋與選
擇服務時更能選出符合需求的服務。
3.2 系統架構
在我們的系統架構設計中，依循上面所分析的必頇具備的元件，利用 jUDDI、
服務選擇流程模組、註冊介面與搜尋頁面等元件，來設計出我們的系統架構，系 統整體架構圖如圖 3.1。
在系統架構流程上，主要分成服務提供者註冊服務與使用者搜尋服務兩個方 面。在服務提供者方面：
1. 透過註冊介面 UDDI Browser 註冊他們所提供的 Web Services 至 jUDDI 裡，讓使用者能夠搜尋與使用
2. 填寫 Web Services 資料，內容包括了服務名稱、分類、描述、與功能特 性等等資訊
3. 填寫完畢，便會自動轉成 WSDL 文件檔至 jUDDI 中，然後存入與 jUDDI 配合的資料庫裡面
4. 服務提供者一樣能透過 UDDI Browser 去修改先前註冊在 jUDDI 裡的 Web Services 資訊
另一方面，使用者搜尋服務：
1. 使用者透過系統的搜尋頁面輸入需求。
2. 使用者送出需求後，系統會去分析使用者對搜尋屬性的優先順序與喜好 度，對於使用者比較偏好的屬性會給予較高的配分權重。
3. 分析出需求後，會自動轉成 SOAP 文件訊息，傳送至 jUDDI，再到資料 庫中去抓取資料，最後將資料傳至服務搜尋與選擇程序去運算。
4. 排序機制模組：然後依據分析結果的權重配分來先後排序，會將排序後 的結果，比較低層次先行剔除，減少以後的運算量。
5. 排名機制模組：接收排序機制模組運算過後的資料，進一步去計算服務 功能屬性與需求的相似程度，且會計算存在 Cache 中的網路服務，給予 權重加權，來評估並推薦最符合需求的服務提供給使用者。
6. 使用者呼叫想要使用的網路服務。
7. 使用者回饋模組：當使用者收到服務選擇後的結果，假如對結果不滿意，
可以提出重新配對的要求，選出另一組網路服務。而當使用者滿意選出 結果，並且確定使用完網路服務之後，系統會自動幫使用過的網路服務 的權重提高，並存入 Cache。另外給予使用者另一個介面，填寫服務的 滿意程度，以此方式服務會隨著使用者的回饋自動調整服務屬性的權重，
達到服務屬性的動態改變，更能符合人性化。
圖 3.1 系統架構圖 WSDL SOAP
服務搜尋與選擇程序 jUDDI
資料庫
排名機制模組 排序機制模組
選擇結果
搜尋頁面 註冊介面
使用者回饋模組 Cache
3.3 註冊中心 jUDDI
jUDDI(Java implementation of the Universal Description, Discovery and Integration specification for Web Services)[6,31]是利用 Java 所開發的一套免費自 由軟體，可以透過 jUDDI 來建置屬於自己的註冊中心[32]。jUDDI 裡包括了 UDDI 中的 businessEntity、businessServices、bindingTemplate 與 tModel 等四個主要元 件。另外 jUDDI 所支援的資料庫相當的多，包括了 MySQL、Oracle、HSQLdb、
DB2、PostreSQL，圖 3.2 所示為 jUDDI 資料庫裡資料表的關聯性，可以看出主 要是以上述所提的四個元件為主要關聯。我們可以透過此軟體與資料庫結合來建 置屬於我們自己的註冊中心，且在其中可以註冊服務與搜尋服務。
圖 3.2 jUDDI 資料庫表格關連圖
下列表 3.1 是 jUDDI API 可使用的函數方法，表 3.2 是在 Inquiry API 裡可使 用的函數方法，而表 3.3 是在 Publishers API 裡可使用的函數方法[32]。
表 3.1 jUDDI API
方法名稱 描述
get_registryInfo 取得一序列 jUDDI 的特性 find_publisher 回傳欲查詢的 publisher 目錄
get_publisherDetail 取得已知的 publisher 相關的詳細資訊 save_publisher 新增或修改 publisher 的相關內容 delete_publisher 刪除 publisher 的相關內容
表 3.2 Inquiry API
方法名稱 描述
find_business 搜尋與參數相符的 business 的相關訊息 find_service 搜尋與參數相符的 service 的相關訊息 find_binding 搜尋與參數相符的 binding 的相關訊息 find_tModel 搜尋與參數相符的 tModel 的相關訊息
find_relatedBusinesses 搜尋與參數相符的 relatedBusiness 的相關訊息 get_businessDetail 取得與參數相符的 business 的相關訊息
get_businessDetailExt 取得與參數相符的 business 延伸的相關訊息 get_serviceDetail 取得與參數相符的 service 的完整訊息 get_bindingDetail 取得與參數相符的 binding 的完整訊息 get_tModleDetail 取得與參數相符的 tModel 的相關訊息
表 3.3 Publishers API
方法名稱 描述
get_authToken 顯示一個 authentication token
get_registeredInfo 取得 publisher 所有 business 與 tModel 檔案的目錄 discard_authToken 通知消除已經過期的 authentication token
save_business 儲存或更新 business 的資訊 save_service 儲存或更新 service 的資訊 save_binding 儲存或更新 binding 的資訊 save_tModel 儲存或更新 tModel 的資訊
delete_business 從 UDDI 中移除 business 的註冊資訊 delete_service 從 UDDI 中移除 service 的註冊資訊 delete_binding 從 UDDI 中移除 binding 介面的註冊資訊 delete_tModel 從 UDDI 中移除 tModel 結構的註冊資訊 add_publisherAssertions 新增一個與一個 publisher 有關聯的 publisher set_publisherAssertions 替換一個與一個 publisher 有關聯的 publisher get_publisherAssertions 取得所有與一個 publisher 有關聯的 publisher delete_publisherAssertions 刪除與一個 publisher 有關聯的 publisher get_assertionStatusReport 取得 assertion 目前的資料狀況
圖 3.3 是說明 jUDDI 處理一個 client 端需求的處理流程[32]，使用 Axis 類別 去處理 SOAP 訊息，Axis 定義出可以讓不同的 Transport 協定能夠去協調使用。
而 AxisServlet 是用來處理 HTTP 要求的類別，在 jUDDI 中，利用三個 servlet 來 延伸 AxisServlet 類別：AdminServlet、PublishServlet、InquiryServlet，而使用者 要求主要都是由 AxisHandler 去處理。
圖 3.3 jUDDI 處理 client 端要求處理程序[32]
BusinessEntity
BusinessEntityHandler
BusinessEntityTable
DataBase HandlerMaker
SaveBusinessFunction FunctionMaker
DataStoreFactory
DataStore RegistryEngine
SaveBusiness
SaveBusinessHandler RegistrySerlet
AxisProcessor
AxisHandler
Client Request
3.4 服務配對流程
在服務選擇配對流程中，包括了由排序機制、排名機制與回饋機制模組組合 而成，這三項模組本身自己也是一個 Web Service，我們使用了 BPEL(Business Process Execution Language)將所有流程包裝起來，形成一個靜態的服務組合，如 圖 3.4。收到系統的搜尋頁面所傳來的使用者需求集合後，便會對之去分析使用 者對服務的喜好度與特徵。然後經過排序機制與排名機制的演算法運算過後，得 出一個配對結果，在詢問使用者是否滿意，不滿意則重新配對，滿意則呼叫使用 服務，最後透過使用者回饋模組來填寫使用過的服務的滿意度，藉以動態改變服 務的屬性權重。
圖 3.4 服務配對流程
Y N
分析需求
排序機制模組
排名機制模組
使用者回饋機制 模組
服務配對結果
使用者
是否滿意 資料庫
呼叫服務
Cache
3.4.1 排序機制模組
在排序機制模組中，主要的目的就是對註冊中心 UDDI 中的所有服務進行與 使用者喜好度相關的排序，藉以選出與需求比較符合而剔除不符合的服務。此模 組中所需要的輸入資料為使用者需求 Ureq 、UDDI 中所有服務 WSall 與服務功能 屬性 WSchar 。
當收到需求分析資料 UApre 後，會得到使用者對服務的權重喜好高低，將服 務的屬性先後排序，得到部分較符合需求由高至低的服務 WSsort ，剔除排序後較 低層次的服務，如此不僅可減少往後運算的運算時間，往後也更能選出較符合人 性需求的服務。下列表 3.4 為排序機制的演算法過程。
表 3.4 排序機制模組演算法 演算法 1
WSall ← {ws1, ws2 , ws3 , … , wsm} //所有服務 Ureq ← {ur1, ur2 , ur3 , … , urn} //使用者需求
WSi_char ← {wsc1, wsc2 , wsc3 , … , wscx} //服務屬性 i ← 0
for each uri
UApre[] ← analyze(uri) end
i ← 0 , j ← 0
//Send to Sorting Model for each uri in UApre
for each wscj in WSi_char
if uri= wscj then WSall [] ← sort(wscj ) end
end end
//Dismiss low level of WSsort m ← b
WSsort ← WSall //Output of Sorting Model Return WSsort
3.4.2 排名機制模組
在排名機制模組中，主要的目的就是選出最符合需求的服務，推薦給予使用 者。在先前分析需求的結果，除了包含在排序機制所需的資料外，另外還有分析 出另一組在排名機制所需的資料 UBpre 。所以在排名機制模組中所需的輸入資料 為使用者需求 Ureq 、與排序模組所得出的結果 WSsort 。
經過排序機制模組得到的初步結果 WSsort 與 Ureq 的另一組分析資料 UBpre 之後，接下來就是利用排名機制模組將 UBpre 與在 WSsort 中的 WSchar作最後的評 估運算，在這個機制的評估運算中，我們使用了兩種方法，以利往後工作的分析，
分析此兩種方法個別的準確度以及優缺點。而這兩種方法分別是規則基準法 (Rule-based)與權重加權計算法(Weighting)。
3.4.2.1 規則基準法
規則基準法主要是透過使用者需求裡，偏好對服務功能屬性的優先順序，從 優先權較低的開始選，選出一定數量，再由第二低的從前一次選出的結果再選出 一定數量，以此類推，選到優先權最高的屬性時，只會從中挑選出一個最合適的 服務推薦給使用者。圖 3.5 為一個簡單的範例，先從屬性 1 中挑選出一定數量符 合需求的服務，在從屬性 1 中被挑選出的服務集合中挑選一定數量出符合屬性 2 的服務，以此類推。表 3.5 為規則基準法來選出適合服務的演算法過程。
圖 3.5 規則基準法選擇範例
WS1
WS2
… WSo
… WSx
WS1
WS2
… WSn
… WSo
WS1
WS2
…
… WSm
屬性 1 屬性 2 屬性 3
表 3.5 排名機制模組演算法-規則基準法 演算法 2-1
WSsort = {ws1, ws2 , ws3 , … , wsm} //初步結果 Ureq = {ur1, ur2 , ur3 , … , urn} //使用者需求
WSi_char = {wsc1, wsc2 , wsc3 , … , wscx} //服務屬性 i ← 0
for each uri
UBpre[] ← analyze(uri) end
//Send to Ranking Model i ← 0 , j ← 0 , k ← 0 for each uri in UBpre
for each wsj in WSsort for each wsck in WSi_char
if wsck = uri then WSrank[] ←wsj
end end end
//Select high level WS in WSrank WSrank ← WSall [1]
//Output of Ranking Model
3.4.2.2 權重加權法
權重加權法主要是透過使用者需求裡，偏好對服務功能特徵的優先順序，然 後對於此優先順序給予適當的權重加權加成，最高者給予加權越高分，並且儲存 在 Cache 中的網路服務也有權重的加權，每個屬性都給予權重配分並加乘後，最 後將總分計算出來，選出總分最高分的推薦給予使用者。而且需要先將網路服務 的特徵正規化，在我們後面的實作範例設計中，所使用的正規化方法是十進位正 規化其公式如下：
v
′= v/10
i(1)
其中 i 為使得 Max v′ ≦ 1 的最小整數，v′為正規化後的值
上列公式可將數值正規化壓縮到區間[0,1]的情況。下列表 3.6 為權重加權法 來選出適合服務的演算法過程。而在排名模組中所使用的計分法為內積法，其公 式如下：
vector x = [ x
1, x
2, x
3, … , x
n] 、 y = [ y
1, y
2, y
3, … , y
n]
x‧y =
ni=1x
i∗ y
i(2)
表 3.6 排名機制模組演算法-權重加權法 演算法 2-2
WSsort = {ws1, ws2 , ws3 , … , wsm} //初步結果 Ureq = {ur1, ur2 , ur3 , … , urn} //使用者需求
WSi_char = {wsc1, wsc2 , wsc3 , … , wscx} //服務屬性 i ← 0
for each uri
UBpre[] ← analyze(uri) //分析權重配分 end
//Send to Ranking Model
To get WS and WSchar in Cache //normalization
i ← 0 , j ← 0 , k ← 0 for each wsi in WSsort for each urj in UBpre
for each wsck in WSi_char
WSweight[i] ←urj * wsck + WSweight[i]
end end end
//Select highest point of wai in WSsort and Put into WSrank WSrank ←WSweight[highest]
//Output of Ranking Model Return WSrank
3.4.3 使用者回饋模組
使用者回饋模組是我們這篇論文最主要的部分，目的是讓所有在 UDDI 中的 服務能夠動態的適應使用者喜好度。藉由系統提供的介面給使用者去填寫對服務 屬性的滿意度，並且會自動幫確實被使用的服務權重作調整，藉此不斷的對服務 所有屬性的動態調整，以達到服務搜尋與選擇的適性化，符合人性的需求，能有 更佳的結果。使用者回饋模組中所需的資料為服務屬性 WSsort，與使用者所填寫 的回饋資料 Uws。
經過上述兩個模組的服務選擇與推薦後，並且使用者確切的使用了服務，則 系統提供一個介面給予填寫服務屬性的滿意度 Uws，並且自動對被使用的服務加 分，而所填的 Uws會去與原先在資料庫裡的資料，重新加以計算，得出一個最新 的服務屬性權重 WSchar。下列表 3.7 為使用者回饋模組的演算法過程。
表 3.7 使用者回饋模組演算法 演算法 3
WSi_char = {wsc1, wsc2 , wsc3 , … , wscx} //被使用的服務的服務屬性 //User fills the feedback interface system to get Uws
Get Uws = {rws1, rws2 , rws3 , … , rwsn} //使用者回饋 for each wsci in WSi_char
average ← compute(Uws , WSi_char) //重新計算回饋的服務屬性 WSchar ← average //更新在資料庫中的服務屬性數值 end
Cache ← wsi //被使用的服務自動儲存至 Cache
舉例說明：
第一步驟，假設經過分析Ureq，得到使用者注重旅館的舒適度、整潔度與便 利性，則 UApre = {舒適度、整潔度、便利性}，然後依照權重的由低至高先後將 在 WSall 裡旅館服務的便利性、整潔度與舒適度作排序，得到WSsort。第二步驟，
再分析 Ureq，得到UBpre={價錢*1.5、回應時間*1.3、服務滿意度*1.1}，搜尋候選 項目為 3 個，會去與 WSchar 去作內積運算，找出最適合的 3 個候選服務 WSrank ，
推薦給使用者。當顧客使用完後，系統給予介面去填寫 Uws，例如填寫旅館整潔 度為 3 分，則系統會自動與原本的屬性分數去計算，去更新目前服務屬性分數，
並且自動為此服務的權重家分與存到 Cache 當中。
第四章 系統範例實作
在這一章中，我們將會利用在第三章裡我們所提出的概念，套用旅遊行程組 合的範例，來實作出我們的系統。在 4.1 節中，我們系統使用 jUDDI 當作我們的 註冊中心 UDDI，並且實際註冊服務到 UDDI 中，其中服務分成旅館、飲食與行 程三大類。在 4.2 節利用旅遊範例來實作我們的系統，系統的功能上有行程組合、
各類服務查詢與顧客意見回饋等。在 4.3 節中會有我們系統執行與結果的畫面展 現。
4.1 系統開發環境
在這個研究中所使用的開發環境為在 Windows Server2003 作業系統下，使 用 NetBeans[30]當作開發平台，配合使用語言為 JAVA 與 JSP 來撰寫程式，其中 JAVA 版本為 jdk-6u2。利用 Glassfish v2 來架設我們的網頁伺服器，並使用 jUDDI 當作我們的註冊中心，所搭配的資料庫為 MySQL6.0。詳細資訊如下表 4.1 所示：
表 4.1 系統實作環境 硬體 CPU Intel Xeon ,3.2GHz
主機板 Ausu NCCH-DL 記憶體 4GB DDR
網路卡 Intel(R) PRO/1000 CT
軟體 作業系統 Windows Server 2003, Enterprise Edition 開發平台 NetBeans IDE6.1
開發程式語言 JAVA 與 JSP JAVA 版本 jdk-6u2
網頁伺服器 Glassfish V2 UDDI jUDDI-2.0rc5 資料庫 MySQL 6.0
4.2 範例系統設計
我們所設計的系統主要是要應用在旅遊行程的組合排程，透過我們的系統，
可以提出你所喜好的旅遊類型，系統會為你排程出一整套的行程服務，並同時預 定旅館與飲食服務。在服務註冊中，主要包括了旅館、飲食與行程三大類，其中 細分的項目，會在 4.2.1 小節詳細解說。而在系統功能方面上，包括有行程組合、
各類服務查詢與顧客意見回饋等功能供使用者使用，在 4.2.2 小節會加以細說。
4.2.1 服務註冊
在服務註冊中分為了旅遊服務、飲食服務與行程服務三大類。此三大類之中，
又有其各自不同的服務特徵。旅館服務方面，共有 53 個服務，其服務特徵主要 為旅館類型、房間人數、地點、價格與服務屬性等。旅館類型就包含了豪華旅館、
精緻旅館、小木屋、渡假村、民宿與露營等六種類型。旅館房間人數分為一、二 與四人房等三種。地點包括了有墾丁、花東、綠島與外島。而在服務屬性上包括 了服務員、整潔度、舒適度、消防配備、便利性與整體滿意度，另外還有人氣度 與綜合平均。人氣度是當服務確定被使用後，系統會自動為此服務增加人氣數值，
而綜合平均則是再上述六項服務屬性的平均值。旅館服務的詳細資訊如表 4.2：
表 4.2 旅館服務分類及其資訊
類型 人數 地點 價格 服務屬性
豪華旅館 精緻旅館 小木屋 渡假村 民宿 露營
1 人 2 人 4 人
墾丁 花東 綠島 外島
依各服務所制定價格 服務員 整潔度 舒適度 消防設施
便利性 整體滿意度
綜合平均 人氣值
飲食服務方面，共有 40 個服務註冊，主要特徵為飲食類型、時間、價格與 服務屬性。其中飲食類型分成有烤肉、簡餐、火鍋、異國餐、高級餐廳、當地小 吃與合菜等七項。飲食時間分成了早餐、午餐與晚餐。而服務屬性則包括了服務 員、整潔度、舒適度、消防配備、菜色與綜合平均，另外也包含了人氣值與綜合 滿意度。表 4.3 為飲食服務的詳細資訊：
表 4.3 飲食服務分類及其資訊
類型 時間 價格 服務屬性
烤肉 簡餐 火鍋 異國餐 高級餐廳 當地小吃
合菜
早餐 午餐 晚餐
依各服務所制定價格 服務員 整潔度 舒適度 消防設施
菜色 整體滿意度
綜合平均 人氣值
行程服務方面，共有 57 個服務註冊，在行程方面的服務屬性就比較簡單，
只有行程類型與服務屬性，而其中屬性只包括了人氣值、整體滿意度與綜合平均。
表 4.4 為行程服務的詳細資訊：
表 4.4 行程服務分類及其資訊 類型 服務屬性 休閒
觀光 水上 刺激 綜合 自助
整體滿意度 人氣值 綜合平均
4.2.2 系統功能
我們的系統功能上，包括有行程組合、各類服務查詢與顧客意見回饋等功能 供使用者使用，這些功能本身也就是 Web Services。行程組合服務功能是系統上 最主要的功能，藉由系統所提供的網頁介面收集使用者需求，而且使用者可以輸 入決定系統推薦的個數，然後套用論文所提出的排序與排名模組，幫助使用者推 薦出一套完整的行程，讓使用者自行判斷是否滿意或者重新選擇。而在這個行程 組合功能中，除了組合出一套旅遊行程外，並同時預定了旅館與飲食服務，當使 用者送出需求後，系統是同時執行此三項工作，如圖 4.1。各類查詢服務功能，
可查詢旅館、飲食與行程等等所有服務的詳細資訊。使用者回饋功能則是讓使用 者使用完服務之後，提供一個介面給予填寫服務滿意度，藉以動態改變服務屬性 的分數。
圖 4.1 送出需求後示意圖 SOAP SOAP
SOAP
搜尋頁面
旅館選擇 飲食選擇 行程組合
搜尋結果
4.3 實驗執行與結果
本節將利用圖案的方式，展現出我們的實驗與實作的結果畫面，分成實作服 務註冊與實作系統介面。
4.3.1 實作服務註冊
論文註冊服務實作中，我們使用 jUDDi 來架設屬於我們自己的註冊中心，
圖 4.2 為 jUDDI 的內建介面，不過它的內建介面一次只能夠使用一個函數方法，
使用上很不方便，所以我們另外使用 UDDI Browser[34]當作我們的工具來註冊服 務至 jUDUD 當中。利用 UDDI Browser 工具，不僅能註冊服務，還能寫入服務 名稱、描述、分類、URI…等服務詳細資訊，還包括 buninessEntity 的名稱、地 址、電話、Email 等各種詳細資訊，圖 4.3 為註冊完 153 個服務之後的畫面。
圖 4.2 jUDDI 內建畫面
圖 4.3 UDDI Browser 註冊服務
4.3.2 實作系統介面
圖 4.4 為系統的主畫面，如同上述所設計的，功能包括了行程組合、旅館查 詢、飲食查詢、行程查詢與顧客回饋評分等，並且行程組合還包括了規則基準法 與權重加權法兩種不同方法的搜尋頁面，圖 4.5 為規則基準法的搜尋畫面，而圖 4.6 為權重加權法的搜尋畫面。在使用者需求輸入中，我們所使用的方法是表格 式的輸入，一方面是讓使用者方便輸入，而另一方面是讓系統能明確的分析出使 用者需求。在行程組合的功能中，藉由此主畫面讓使用者填入需求，在送出需求 後，會自動轉變成三個不同的 SOAP 訊息需求，分別呼叫旅館選擇、飲食選擇與 行程組合選擇等三個 Web Service 程式。
圖 4.4 系統主畫面
圖 4.5 行程組合-規則基準法服務選擇畫面
圖 4.6 行程組合-權重加權法服務選擇畫面
以上圖 4.5 為例，所需求的需求為對服務選擇注重項目依序為費用、整體滿 意度與服務人氣度，而其費用預算普通，旅遊天數一天、人數四人、旅遊類型為 刺激類型，旅館類型為精緻旅館、小木屋與渡假村，而其特徵屬性依序注重整潔 度、舒適度與服務員服務品質等，飲食類型為不拘，其特徵屬性依序注重服務員 服務品質、整體滿意度與菜色。送出此需求後，會轉成三種不同的 SOAP 訊息分 別去呼叫三個服務選擇服務。圖 4.7 為送出行程組合的 SOAP 需求訊息，圖 4.8 為飲食的 SOAP 需求訊息，而圖 4.9 則為旅館的 SOAP 需求訊息。
圖 4.7 行程組合的 SOAP 需求訊息
圖 4.8 飲食的 SOAP 需求訊息
圖 4.9 旅館的 SOAP 需求訊息
當送出上面 3 個 SOAP 需求後，系統就會自動選出適合的旅館服務、飲食服 務與旅遊行程組合推薦給使用者，再由使用者決定是否使用這些服務。下面圖 4.10 為系統所推薦的行程排程服務結果畫面，圖 4.11 為飲食服務的推薦結果畫 面，圖 4.12 為旅館服務的推薦結果畫面。畫面中各有三個候選服務項目，其中 飲食服務包括了午餐與晚餐的各三項候選服務。
圖 4.10 行程排程服務結果畫面
圖 4.11 飲食服務的推薦結果畫面圖
圖 4.12 旅館服務的推薦結果畫面-規則基準法
上面的服務推薦結果，都是經由規則基準法所計算出來的，在下面我們將利 用權重加權法來比較，兩個演算法的結果差異，將會在下一個小節加以分析結果 的不同。由上圖 4.6 的搜尋頁面所得到的使用者輸入結果與圖 4.5 項目差不多，
不過由於權重加權法中有加入了權重的項目，所以多了三項選項，而畫面中所選 的為費用 6 分、整體滿意度 5 分與服務人氣度 4 分。其旅館服務選擇的執行結果 如下圖 4.13：
圖 4.13 旅館服務的推薦結果畫面-權重加權法
最後的使用者回饋機制模組，當使用者確定選擇他所想要的服務之後，也確 定使用過了服務，除了系統會自動幫使用過的服務權重加分外，我們也提供一個 介面，讓使用者能填寫服務使用後的滿意度，下圖 4.14 為我們所提出的回饋模 組介面：
圖 4.14 回饋模組介面
第五章 系統實驗分析
在本章裡，我們將會比較我們所提出的規則基準法與權重加權法兩種服務選 擇方法。在 5.1 節中將利用執行時間效能與使用者系統操作時間比較兩者所花費 的時間。在 5.2 節中我們利用平均精準度(Mean Average Precision, MAP)方法來評 估我們最後所選出的服務精準度如何，並且比較兩種演算法，何種方法 MAP 值 較高。在 5.3 節分析與討論中，我們將討論時間效能與 MAP 實驗結果，並比較 兩種演算法的優缺點為何。在 5.4 節將比較論文提出的系統與再第二章時所提及 的系統作分析比較。
5.1 執行時間效能
這裡我們會比較兩種演算法的時間花費，我們所比較的時間花費分成了使用 者輸入需求時間與程式執行時間。使用者輸入需求時間是代表當使用者進入我們 系統後，選擇了行程服務的功能，從這個時間算起到輸入完需求且送出後，之間 所花費的時間總合。程式執行時間是代表，當使用者送出需求後，系統分別呼叫 三個服務選擇的網路服務程式，經過程式運算並回傳適合使用者的服務，之間所 花費的時間總合。這個時間效能實驗中，當送出 SOAP 需求後，分成五種案例，
分別是重複執行 10 次、20 次、50 次、100 次與 500 次服務選擇的工作，然後在 算出平均執行一次所需的時間，需求當中包含四組不同的 SOAP 需求，每組需求 各送出 5 次。下圖 5.1 為時間效能實驗的結果，平均來說，權重加權法的平均時 間都比規則基準法低，而且時間分佈曲線也比較平穩，可以知道使用權重加權法 時，不論執行次數的多寡狀況下，執行效能比較平均。
另一方面，使用者輸入需求時間，經由 30 個實驗室同學與朋友的案例測試 使用，在權重加權法的頁面所需要的時間明顯比規則基準法要多出許多時間，如 圖 5.2，可分析出原因為權重加權法因為多了使用者自己決定屬性特徵權重的選 項，這些選項可能會影響到必頇要去思考的因素，且也需花費時間點選，因而在 輸入需求花費總和上，會比規則基準法的時間總合上多出些許時間。
