具回饋性之個人化網路服務選擇機制─以旅遊資訊系統為例

(1)

中華大學碩士論文

具回饋性之個人化網路服務選擇機制─以旅遊資訊系統為例

Personalized Web Service Selection with Feedback Mechanism – A Case Study of Travel

Information System

系所別：資訊工程學系碩士班學號姓名：M09602044 郭竹晏指導教授：張欽智博士

中華民國 101 年 8 月

(2)

摘要

隨著網路服務技術的成熟，網路服務的數量也越來越多，當使用者搜尋網路服務過多時，使用者會花費太多的時間在網路服務選擇上，如何幫助使用者選擇網路服務是個值得探討的問題。而目前網路服務選擇的研究中，多數都是藉由使用者填寫網路服務的需求與服務品質的條件來選擇網路服務，但顯少考慮到使用者對網路服務的評價也是個參考的服務品質項目。

在本論文中，提出具回饋性之個人化網路服務選擇機制，針對不同使用者的喜好給予不同的網路服務選擇。此機制利用可用性的網路服務品質監測來篩選可用的網路服務，並藉由使用者對網路服務的評分回饋與計算使用者相似度之協同過濾的個人化方法來幫助使用者選擇網路服務。我們以旅遊資訊網路服務選擇系統來實作本論文所提出的方法，最後以模擬實驗來計算平均精準度觀察本論文方法的準確率。

關鍵字：網路服務、網路服務選擇、回饋機制、個人化

(3)

Abstract

With the popularity of the Web service technology the amount of Web services is increasing. The more available Web services there are, the more time the user might spend on selecting a service. How to help the user quickly select a suitable service is an important issue. In recent studies on the Web service selection, the most approaches are based on service requirements and quality of services designated by the user but less take the user’s own evaluation into account.

In this thesis, we propose a personalized Web service selection with feedback mechanism from the user. In this mechanism the quality of service of Web services, the feedback from the users, and similarity among the users are evaluated for helping the user select Web services. The proposed method is verified by a case study of a travel information system and then the Mean Average Precision (MAP) is evaluated by the experiments.

Keywords: Web services, Web service selection, Feedback mechanism, Personalization

(4)

致謝

在寫下致謝這一頁的同時，我也將整個研究所的求學過程快速的回顧了一遍，曾經一度懷疑自己是不是沒有能力可以完成論文、是不是沒有解決問題的解決能力；但在這過程中，我遇到了很多幫助我的人，不管是學術上或生活上都讓我留下許多深刻且美好的體驗與回憶。因為這些體驗，讓我每每遇到困難時，總是可以將負面的想法轉換成正面的能量，也讓我更有動力去完成這本論文，在此，非常感謝大家的幫助。

首先我要感謝的是指導教授張欽智老師的教導與鼓勵，讓我在網路服務的研究領域越來越有興趣，每次與老師討論之後，總是讓我有更多的想法解決研究上的問題。

儘管我表達我的想法並不是很完整，老師仍清楚的指引我方向；儘管我論文進度緩慢，

老師仍耐心地協助我；儘管我曾經一度想放棄學業，老師仍鼓勵我完成學業，讓我有信心完成這本論文。

再來要感謝的是實驗室的同學偉峰、世宗，跟你們在同一個實驗室，總是那麼地歡樂、有趣，就算在煩悶的心情都會不見，以及感謝文偉、晏晟、大頭、廷嘉、阿達、

禹仲、泫廷、新隆、啟賢與實驗室的各位學弟們，陪我一起運動、談心。再來要感謝中華大學壘球聯隊的隊員與土木系壘的同學，謝謝你們邀請我一起打球，也讓我能藉著打其釋放研讀文獻與論文撰寫的壓力。

另外我要感謝阿德、小昭、小豬、家瑋、小狗、小安，雖然各忙各的學業與事業，

但常常答應我的請求，幫我分擔了不少雜事，讓我有更多的時間專心完成論文。還有感謝康賀順經理，在我打工期間分享了不少研究的經驗與建議，對我的論文有很大的幫助。

最後，我要感謝我的父母，讓我沒有經濟上的煩憂，全心全意的支持我，在我論文遇到瓶頸時給我加油與安慰，每當接到你們的來電噓寒問暖時，我的心中總是有莫名的感動，感謝你們對我的照顧與包容，讓我可以順利完成碩士學位。

(5)

圖目錄

圖 2-1 服務導向架構 ... 5

圖 2-2 WSDL 文件架構 ... 6

圖 2-3 SOAP request 範例 ... 7

圖 2-4 SOAP response 範例 ... 7

圖 2-5 UDDI 資料結構 ... 8

圖 2-6 WebserviceX.NET 分類搜尋 ... 9

圖 2-7 XMethods 網路服務列表 ... 9

圖 3-1 網路服務選擇機制之系統設計模型 ... 18

圖 3-2 系統架構 ... 19

圖 3-3 JUDDI Web Services Registry ... 21

圖 3-4 搜尋 Business 的 SOAP request 範例 ... 22

圖 3-5 搜尋 Business 成功的 SOAP respone 訊息 ... 23

圖 3-6 JUDDI Server 處理客戶端 SOAP request 訊息的流程 ... 23

圖 3-7 Business 註冊問題 ... 24

圖 3-8 UDDI 客戶端流程 ... 25

圖 3-9 個人化網路服務選擇流程 ... 27

圖 3-10 個人化網路服務選擇演算法 ... 29

圖 4-1 旅遊資訊網路服務呼叫流程 ... 35

圖 4-2 JUUDI Console ... 36

圖 4-3 系統登入畫面 ... 36

圖 4-4 UDDI Client 之功能 ... 36

圖 4-5 Business 註冊畫面與結果 ... 37

圖 4-6 Service 註冊畫面與結果 ... 37

圖 4-7 網路服務 QoS 偵測介面 ... 38

圖 4-8 網路服務 QoS 偵測記錄 ... 38

圖 4-9 旅遊景點網路服務搜尋介面 ... 39

圖 4-10 系統選擇結果 ... 39

(8)

圖 4-11 網路服務呼叫結果 ... 39

圖 4-12 評分回饋頁面 ... 40

圖 4-13 評分回饋資料表 ... 40

圖 4-14 網路服務個數不同之 MAP 比較 ... 42

圖 4-15 使用人數不同與 Top-k 不同之 MAP 比較 ... 43

圖 4-16 不同推薦方法之 MAP 比較 ... 44

(9)

表目錄

表 2-1 網路服務選擇方法之比較 ... 12

表 2-2 網路服務的服務品質項目表 ... 13

表 2-3 個人化推薦方法比較 ... 15

表 2-4 相似度矩陣 ... 15

表 2-5 使用者對產品評分表 ... 16

表 3-1 JUDDI API ... 21

表 3-2 Inquiry API ... 21

表 3-3 Publish API ... 22

表 3-4 網路服務評分表 ... 30

表 3-5 使用者與使用者間的相似度 ... 30

表 3-6 網路服務平均評分值 ... 31

表 3-7 使用者之網路服務推薦分數表 ... 31

表 3-8 回饋評分表 ... 32

表 4-1 系統實作環境資訊 ... 33

表 4-2 網路服務建置環境資訊 ... 34

表 4-3 旅遊資訊網路服務名稱與類型 ... 34

表 4-4 網路服務個數不同之 MAP 值 ... 41

表 4-5 使用人數不同與 Top-k 不同的 MAP 值 ... 42

(10)

第一章緒論

網路的發展，由原本的區域網路應用，逐漸演變成全球資訊網際網路，而最早的網際網路，只是單純的靜態資訊傳遞，最常見的就是靜態網頁，靜態網頁只是透過網頁分享靜態的資料，但當資料變動時，就必需將整個網頁更新，而近幾年網際網路技術的迅速發展，開始以高速網路進行各種活動，包括網路商業交易、商業運算、即時通訊等網路應用，但這些都必須使用不同公司、研究團隊所開發的應用程式與系統，

才能透過網路進行，而這些應用程式可能都有各自的開發平台與環境，並無法相互運用與整合。為了整合異質應用系統，因此有了網路服務(Web Service)技術的產生。隨著服務導向架構(Service-Oriented Architecture, SOA)與雲端(Cloud)技術的發展，網路服務也成服務導向計算與為雲端技術的核心技術之一，因此網路服務的重要性不可言喻。

1.1 研究背景與動機

近幾年來，不管是在企業界或是學術界，都已經開始廣泛的應用與討論網路服務 (Web Service)，以此技術來實現服務導向架構下的異質環境應用系統整合，進而成為雲端技術的核心。過去應用系統整合的技術，如 CORBA(Common Object Request Broker Architecture)、RMI(Remote Method Invocation)等架構及規格都必需建立在自己的基礎技術標準上，並無法整合異質的應用系統；而 Web Service 是以現有的網路通訊協定 HTTP(HyperText Transfer Protocol)和由開放式標準資料格式 XML(eXtensible Markup Language)建立的 WSDL(Web Services Description Language)、SOAP(Simple Object Access Protocol)、與 UDDI(Universal Description, Discovery and Integration)等標準組合而成，因此增加了整合異質應用系統的彈性與跨平台性。

隨著 Web Service 技術解決了整合異質應用系統的問題，Web Service 的數量也越來越多，遍佈在網路各個地方，雖然 UDDI 註冊中心提供了網路服務的註冊與搜尋，

但是使用率並不高，因為使用 UDDI 時，使用者必需建立 SOAP request 訊息發送給 UDDI，而 UDDI 回傳的是 SOAP Response 訊息，並沒有一個有效且方便的使用介面

(11)

提供使用者註冊與網路服務查詢。而且在網路服務選擇的研究，多數以語意相似度計算或系統偵測的網路服務品質為考量，對於網路服務品質與使用者需求並無法兼顧。

隨著個人化時代的來臨，提供客製化的服務更為重要。

1.2 研究問題描述

服務提供者透過 SOAP 訊息將網路服務註冊在 UDDI 中，服務需求者也可以透過 SOAP 向服務仲介者查詢所需的 Web Service 並取得 Web Service 的 WSDL 文件，

服務需求者根據 WSDL 文件的描述內容，送出 SOAP 呼叫服務提供者所提供的 Web Service。

而 UDDI 註冊中心，雖然提供了註冊與搜尋的功能，但是 Web Service 的數量越來越多、應用範圍越來越廣，出現了下列幾個問題：

1. UDDI 使用率並不高，因為 UDDI 註冊中心須傳遞 SOAP 訊息對 UDDI 註冊中心註冊與查詢網路服務，而使用者必需先了解 SOAP 訊息格式標準規範，

造成註冊與查詢上的不方便。

2. 以目前常見的列表式、關鍵字、分類等搜尋方式，都必需要使用者從搜尋結果的列表清單中，自己尋找出所需的 Web Service，以至於無法有效率的搜尋出符合使用者需求的 Web Service。

3. Web Service 是一種以「服務」為導向的技術，電腦系統並不知道 Web Service 提供的服務好與壞，如何從符合使用者需求的 Web Services 清單中，選擇到一個好的 Web Service，而 Web Service 的服務品質(Quality of Service, QoS) 是個很重要的考量。

4. 使用者對於服務品質，各有不同的主觀認定，由系統或專家偵測的網路服務品質計算方式與定義，使用者並不一定了解。

5. 使用者對於 Web Service 的喜好不同，如何針對不同的使用者的喜好，給予不同的個人化網路服務選擇，是個很值得探討的問題。

(12)

1.3 研究目的

為了解決 1.2 節所提到的問題，本篇論文提出一個網路服務選擇機制：具回饋性之個人化網路服務選擇機制，這個機制可以套用在不同應用領域的網路服務選擇。讓使用者在網路服務搜尋與選擇時，系統將會取得使用者對於網路服務評分，並結合服務品質篩選，使得使用者可以更快速的選擇出一個符合使用者需求的 Web Service，

而這個 Web Service 是可用的、有效的。而使用者也可以給予 Web Service 適當的評分回饋，讓系統可以參考其他使用者的評價，幫助下一個使用者選擇出服務品質較佳的個人化網路服務。

而本論文將以旅遊資訊網路服務選擇系統為例，實作具回饋性之個人化網路服務選擇系統，並希望可以達到以下四個目的：

1. 建立 UDDI 客戶端介面，讓使用者方便註冊與查詢。

2. 透過系統篩選出可用的網路服務。

3. 記錄使用者的回饋評價，並針對不同的使用者給予個人化的網路服務選擇。

4. 讓使用者在本系統可以快速的找到適合的網路服務。

1.4 論文架構

本論文總共分為五個章節，第一章是緒論，說明本論文研究的動機與問題，並提出相關的解決方法；第二章是相關技術與文獻探討，介紹 Web Services 的相關技術與本論文的相關研究文獻，並加以探討；第三章是網路服務選擇機制之設計，將完整說明本論文所提出的網路服務選擇機制與系統架構，並針對所有的流程與方法詳加描述；

第四章是網路服務選擇機制之實作與實驗，以 Java 為開發平台實作本論文提出的個人化網路服務選擇機制，應用在旅遊資訊的網路服務搜尋與選擇，與模擬實驗本論文所提出的個人化方法，並加以分析；第五章是結論與未來展望，敘述本論文的研究心得與未來之研究方向。

(13)

第二章相關技術與文獻探討

在本章中，將探討本篇論文涉及的相關技術與研究，包括服務導向架構、網路服務相關技術，網路服務搜尋與選擇、個人化方法等，藉此更進一步了解網路服務的相關技術與研究。在 2.1 節中將簡單說明 Web Services 的相關技術與知識，包括 WSDL、

SOAP、UDDI 等技術；在 2.2 節介紹目前網路服務搜尋與選擇的相關研究；2.3 節將介紹個人化的相關方法。

2.1 服務導向架構與網路服務相關技術

2.1.1 服務導向架構

服務導向架構是一種應用程式架構的概念，將應用程式及資源以可重複使用的

「服務(Service)」方式呈現，使用標準化的介面相互溝通，藉此提供更高彈性、更高效率、及資訊整合的資訊技術環境。但是過去的軟體整合環境 CORBA、RMI、

DCOM(Distributed Component Object Model)等平台都有專屬的協定與規範，導致異質環境之間還是無法互相溝通、互相連結；直到網路服務的出現，更加實現服務導向架構的跨平台特性，有效地解決異質環境的整合問題。

服務導向架構中，有服務提供者、服務仲介者、服務需求者三個主要的角色，並且透過註冊(Publish)、搜尋(Discover)、連結(Binding)這幾個功能所連結型成的架構，

它們的關係如圖 2-1。

1. 註冊：服務提供者將網路服務註冊到服務仲介者(如：Web Services 的 UDDI、

CORBA 的 ORB 等)。

2. 搜尋：服務需求者向服務仲介者搜尋網路服務資訊。

3. 連結：服務需求者取得網路服務資訊後，與服務提供者端的網路服務進行連結與呼叫。

(14)

圖 2-1 服務導向架構

2.1.2 網路服務(Web Services)

Web Services 是一個以 XML 為基礎的整合跨平台應用程式的技術，定義與描述 XML 語言並透過 HTTP 協定傳遞資料的方式來達到呼叫遠端的網路服務，不論服務需求者與服務提供者所使用的作業系統與平台是否相同，皆可以透過 Web Services 的技術來達到跨平台程式呼叫。Web Services 包含網路服務描述語言(WSDL, Web Services Description Language) 、簡單物件存取協定 (SOAP, Simple Object Access Protocol)、統一描述、查詢與整合協定(UDDI, Universal Description, Discovery and Integration)等，皆為以 XML 為基礎的技術標準。

WSDL 是描述網路服務的介面，SOAP 是透過 HTTP 來交換 XML 為基礎的訊息，

以達到訊息互通之目標，UDDI 是一個註冊中心、服務儲存庫，網路服務必預先註冊在裡面，使用者在透過它來搜尋網路服務。

2.1.3 WSDL (Web Services Description Language)

WSDL[20]是以 XML 為基礎所定義的網路服務描述語言，用來描述一個網路服務如何連結與使用網路服務的描述，也就是描述存取網路服務時，需要連結的訊息格式、參數與通訊協定，讓使用者可以藉由 WSDL 文件，瞭解網路服務相關資訊與如

(15)

何去存取與使用網路服務。WSDL 可以說是一連串定義的文件架構，文件架構可分成服務實作定義與服務介面定義兩部分，如圖 2-2。

1. 服務介面定義(Service Interface Definition)：此部分用來描述網路服務介面，

包括 Types、Message、PortType 和 Binding。Types 是定義 Message 實際對應的資料型態；Message 是定義網路服務輸入與輸出的參數訊息；PortType 是定義網路服務中所有的 operation，Binding 是定義特定的 PortType 所使用的通訊協定與連結方式。

2. 服務實作定義(Service Implementation Definition)：此部分描述網路服務介面的實作資料，如網路服務名稱、服務提供者、網路服務的網路位址，包括 service 和 port。Service 是用來描述網路服務名稱、服務提供者之訊息；port 是定義使用者呼叫 service 的所有連接埠，每一個 port 會指定一個 Binding 的方式。

圖 2-2 WSDL 文件架構

(16)

2.1.4 SOAP (Simple Object Access Protocol)

SOAP[18]稱為簡單物件存取協定，是以 HTTP 傳輸協定來傳送 XML 文件，可以藉由此協定在分散式架構的環境中達到資料交換的目的。也就是說 SOAP 能讓不同的應用程式以 XML 為基礎的訊息格式，透過 HTTP 傳輸訊息，達到跨平台的遠端程式呼叫(RPC，Remote Procedure Call)與資料交換，並不需要知道彼此的作業平台，或是如何實作應用程式等細節資訊。

SOAP 的主要元素有三個部分：SOAP Envelope、SOAP Header、SOAP Body。一個 SOAP Envelope 只能包含一個 SOAP Body，SOAP Body 的內容是經過嚴格定義的 XML 文件，包括了所有的呼叫描述與回應的內容；SOAP Header 定義 SOAP 的內文、

編碼、與訊息傳遞所需的資訊。SOAP request 與 SOAP response 範例如圖 2-3 與圖 2-4。

圖 2-3 SOAP request 範例

圖 2-4 SOAP response 範例

<SOAP-ENV:Envelope>

<SOAP-ENV:Body>

<xmlns:ns2="http://www.stock.org.tw/stock" />

<ns2:GetStockPriceResponse>

</ns2:GetStockPriceResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

<SOAP-ENV:Envelope>

<SOAP-ENV:Body>

<xmlns:ns2="http://www.stock.org.tw/stock" />

<ns2:GetStockPrice>

</ns2:GetStockPrice>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

(17)

2.1.5 UDDI (Universal Description, Discovery and Integration)

UDDI[19]是統一描述、發現與整合的縮寫，以 XML 為基礎定義網路服務註冊與搜尋之規格與技術，是一個獨立性平台的註冊中心，提供程式開發者與企業註冊與搜尋網路服務之資訊，當個服務仲介者的角色。網路服務的使用者可以從 UDDI 中搜尋網路服務，取得網路服務的端點位置與資訊，便可以透過傳遞 SOAP 呼叫遠端的網路服務。UDDI 的資訊分為三大類：

1. 白頁(White pages)：企業名稱、地址和通訊方式等企業資訊。跟電話簿的白頁一樣，根據姓名、公司名稱查詢電話；在 UDDI 中可以輸入公司名稱從 UDDI 中查詢公司的地址與相關的連絡方式。

2. 黃頁(Yellow pages)：企業類型與網路服務功能之分類。如同電話簿中的黃頁，

將不同類型的企業與網路服務進行分類，如產品分類、工業分類等標準進行分類；使用者可以從 UDDI 中透過分類來搜尋網路服務。

3. 綠頁(Green pages)：網路服務的技術資訊。主要是網路服務相關技術內容，

如網路服務的端點位址與 WSDL 文件位置等有關連結網路服務的技術資訊。

圖 2-5 UDDI 資料結構

在 UDDI 註冊的資料結構由四個元素組成，分別是：businessEntity、businessService、

bindingTemplate 與 tModel。businessEntity 是有關發佈網路服務的公司團體資訊，每一個 businessEntity 可以發佈一個以上的 businessService；businessService 是描述網路服務的資訊，每一個 businessService 可以有一個以上的 bindingTemplate ；

(18)

bindingTemplate 是網路服務的端點與技術規格的資訊，而每一個 bindingTemplate 對應一個 tModel；tModel 是用來描述資料，將服務的技術規範與描述的專有名詞(如：

輸入輸出參數型態、連結的通訊協定等)透過 tModel 來描述，如圖 2-5。

2.2 網路服務搜尋與選擇

2.2.1 網路服務搜尋(Web Service Discovery)

現今網路服務搜尋的方可分為兩種，非語意網路服務搜尋和語意網路服務搜尋。

非語意網路服務搜尋，都是透過 Web 介面或是利用 UDDI 的 API 到網路服務儲存庫搜尋想要的服務，如 WebserviceX.NET[21]、XMETHODS[22]等目前常見的網路服務儲存庫，不過都僅以列表、分類的方式提供清單瀏覽和關鍵字的方法提供搜尋，如圖 2-6 與圖 2-7。

圖 2-6 WebserviceX.NET 分類搜尋

圖 2-7 XMethods 網路服務列表

(19)

語意網路服務是將語意網與網路服務結合。語意網是由全球資訊網的創始者 Tim Berners-Lee 所提出，是一種可以處理全球資訊網上語意的技術，在全球資訊網中加入詮釋資料(Metadata)，用來描述網路上的資源，如 HTML 文件等，使得電腦能跟人類一樣可以理解資源的內涵。語意網中的 XML、RDF(Resource Description Framework) 和 Ontology 都是用來表示網路資訊的語意。

語意網路服務常見的技術有 OWL-S(Web Ontology Language for Services)、

WSMO(Web Service Modeling Ontology)等，目前語意網路服務搜尋的方法，主要都是利用 OWL-S 文件來取得使用者噵向之服務互動的語意，再將服務需求者的 OWL-S 文件與發佈的服務做相似度比對，取得使用者所需的服務，但是 OWL-S 和 WSMO 這些都是需要花費很大的成本和時間來建立完整的知識架構(Ontology)。

而在目前 UDDI 只提供的關鍵字與分類搜尋方法，雖然可以結合語意的方式搜尋，

但是可能造成搜尋結果過多，導致使用者在搜尋結果的清單中，需要花費很多的時間尋找符合需求且可用的網路服務，因此如何幫助使用者選擇一個適合的網路服務個很值得探討的問題。

2.2.2 網路服務選擇(Web Service Selection)

網路服務選擇是從網路服務搜尋之後的結果，挑選出比較符合使用者需求的網路服務給使用者，減少使用者在挑選網路服務時的花費時間。網路服務搜尋時，主要是針對功能性需求搜尋網路服務；在網路服務選擇時，則是針對非功能性的需求進行選擇。就像是一個旅遊的消費者挑選旅行社幫忙規劃旅遊行程時，會先尋找可以提供訂房、行程安排等功能性服務的旅行社，再從尋找到的旅行社中挑選自己喜歡或是服務態度較佳的旅行社。在[12]中將網路服務選擇分為三大類：語意式網路服務選擇 (Semantic Service Selection)、社群式網路服務選擇(Social Service Selection)、經濟式網路服務選擇(Economic Service Selection)。

(20)

 語意式網路服務選擇(Semantic Service Selection)

語意式網路服務選擇是利用語意網路、關鍵字、分類等形式配合不同領域專屬的知識架構(Ontology)所定義的關鍵字來做為網路服務分類(Classification)和網路服務檢索 (Retrieval) 來選擇網路服務，主要的方法有兩種：一種為語意配對 (Semantic Matchmaking)，由使用者描述網路服務非功能性的需求(如：網路服務的 input、output 的資料型態等)搭配知識架構(Ontology)來進行語意分析，再與網路服務的 profile(如：

WSDL)進行配對，找尋其匹配的網路服務；另一種是當網路服務註冊或發佈時，透過知識架構分析網路服務非功能性之描述，將網路服務進行分類，以利於與使用者選擇或配對。

 社群式網路服務選擇(Social Service Selection)

社群式網路服務選擇，主要是由評價機制(Reputation Mechanisms)與推薦技術 (Recommender Techniques)搭配來給予使用者適合的網路服務推薦。收集使用者對網路服務的評價分數，再由不同的推薦技術來分析計算網路服務所獲得的分數，推薦網路服務給使用者。如：使用者可以給予網路服務評價分數(+1, 0, -1)，而系統會收集所有使用者的評價分數，並計算每一個網路服務獲得的總分數，將統計分數高者之網路服務推薦給使用者。

 經濟式網路服務選擇(Economic Service Selection)

經濟式網路服務選擇是以經濟利益為考量來進行網路服務選擇，包括使用者付費、

商業公司營收利益等來做為網路服務選擇的基準。如：商業公司如何購買網路服務來獲得最大利益，或是使用者如何以便宜的價格找到適合的網路服務。通常網路服務選擇都是透過第三方系統來幫助選擇，容易因為利益得失，造成市場壟斷、利益分配等問題，如：網路服務選擇系統可能因收取某公司之回饋，將這家公司之網路服務列為優先推薦，或是網路服務選擇系統以收費價格為便宜為選擇目標，會導致收費較高但服務品質較好之網路服務無法獲得推薦。

(21)

以下將以表 2-1 分析這三種網路服務選擇方法之優缺點。

表 2-1 網路服務選擇方法之比較

網路服務選擇類型 優點缺點

語意式網路服務選擇

1. 有效地選擇出符合需求之網路服務

1. 需建構龐大的知識架構(Ontology) 2. 使用者需完整描述

需求社群式網路服務選擇

1. 可參考使用者之評價

2. 不需完整分析網路服務之描述內容

1. 評價之可信度問題

經濟式網路服務選擇

1. 商業公司可獲取較高的利益 2. 消費者容易找尋收費便宜的

網路服務

1. 容易造成市場壟斷、利益分配之問題

在[2]的研究是結合社群式與經濟式網路服務選擇的方法，其方法是藉由使用者輸入的服務需求與收費價格條件來篩選網路服務，並收集使用者對網路服的服務品質項目之評分，計算每一個網路服務獲得的評分平均值，透過使用者給予不同服務品質項目之權重值，以服務品質項目評分平均值與權重相乘並且加以總和，以總和高者的網路服務推薦給使用者進行選擇。

2.3 網路服務的服務品質(QoS)

網路服務選擇以非功能性之需求來選擇網路服務，而網路服務的服務品質對使用者選擇網路服務時，也是非功能性需求的考慮因素。網路服務的服務品質包含網路品質與網路服務本身的品質，因此網路頻寬不同、連線狀況不穩定或是網路服務本身的執行效能、執行結果、伺服器穩定性，都是網路服務品質優劣的因素。在網路服務選擇中，大部分都以服務品質作為網路服務評估的量化指標。

在[10]中將服務品質分為主觀的(Subjective)服務品質與客觀的(Objective)服務品質。客觀的服務品質： [9]是使用可靠度(Reliability)的計算來選擇網路服務；[1]以可用性(Availability)與可靠度來選擇網路服務；[17]則是探討可用性、回應時間(Response Time)、安全性(Security)、處理量(Throughput)；[6] [7] [13] [14] [15]都提出了幾個服

(22)

務品質的項目和模型，像是價格(Price)、執行時間(Execution Duration)、回覆時間與可靠度等以網路服務為中心的服務品質項目。主觀的網路服務：使用者評分、專家評分等以使用者為中心的評價(Reputation)。網路服務的服務品質項目相當多，常因為評估的角度不同而有不同定義與解釋，我們由表 2-2 列出常見的服務品質項目與說明。

表 2-2 網路服務的服務品質項目表

類型 服務品質項目 說明

客觀

可用性(Availability) 網路服務提供可用時間的比率可靠度(Reliability) 正確執行服務需求的比率

回應時間(Response Time) 網路服務對各種類型的要求之回應時間處理量(Throughput) 在某段時間內所能處理的服務需求最大上限主觀評價(Reputation) 使用者、專家之評分回饋

而在客觀的服務品質項目中的可靠度、回應時間、處理量的偵測需要藉由服務提供者來提供呼叫或回應結果來比對正確性，可用性則可直接透過網路服務來偵測。而本論文中採用可用性偵測與使用者評價來選擇適合使用者的網路服務。

2.4 個人化方法之探討

個人化推薦技術是透過使用者的記錄資料，瞭解使用者的興趣與喜好，針對使用者的興趣與喜好，推薦使用者感興趣與喜好的東西之推薦技術。使用者的興趣與喜好的取得，可以從使用者的註冊資料、問卷調查、使用者行為與回饋等等方式來取得。

在個人化推薦的技術已經有相當多的個人化推薦方法，最常見的可分為四大類[5]：

知識推薦法(Knowledge-based Approaches)、內容式過濾法(Content-based Filtering)與協同過濾法(Collaborative Filtering)、混合式推薦法(Hybrid Approaches)。以下將針對這四種個人化方法做詳細介紹：

 知識推薦法(Knowledge-based Approaches)

知識推薦法主要是利用使用者註冊資料、問卷調查的方式直接詢問使用者的需求與喜好等問題，透過這些問題來了解使用者的需求，再以使用者回答的資料為知識規則，推薦適合使用者喜好的資訊或產品。知識推薦法與其他個人化方法的技術不同，

其他的方法只需要使用者提供特定的內容來幫助系統選擇，而知識推薦法會要求使用

(23)

者填寫一連串的問卷，才能明確知道使用者之需求。

 內容過濾法(Content-based Filtering)

內容過濾法是先在資料庫建立資料或產品的特徵項目，再記錄使用者的註冊資料、

使用行為、使用習慣與興趣等資料，利用這些使用者的記錄資料來分析使用者對各項特徵項目的喜好程度，藉由喜好程度給予各項特徵項目不同的權重，並與資料內容的特徵項目進行推算與分析，進而找出使用者可能喜歡的資訊或產品。

 協同過濾法(Collaborative Filtering)

藉由記錄使用者的喜好或評分，根據使用者的喜好或評分來推算使用者之間的相似度，並參考其他使用者的喜好呈現使用者可能感興趣的產品或資訊。雖然每個人都是不同的個體，但綜觀之下某些人的年紀、經驗與興趣等都有相似之處，因此協同過濾法就是利用興趣相投或是有共同經驗的族群，以族群的喜好來推薦使用者感興趣的資訊或產品。

 混合式推薦法(Hybrid Approaches)

混合式推薦法就是使用兩種或兩種以上的推薦方法即為混合式推薦法。混合式推薦法可以針對不同問題的特性，結合不同個人化推薦方法的優點來彌補系統在特定的問題處理上的缺點與不足之處。

在不同的個人化推薦方法有其不同之處與優缺點，表 2-3 顯示以上四種方法之優缺點。而網路服務其實是一家公司出產的應用程式軟體，可透過網頁去使用，放在遠端成為雲端應用程式的基礎，也可以視為一個產品，當我們在選擇產品時，通常都會優先考慮自己喜好來選擇。在網路服務選擇的研究中，顯少針對個人化的網路服務選擇進行研究。在[10]的研究是採用協同過濾法來進行個人化網路服務選擇，主要是考量對同一個網路服務有相同評價者其相似度程度越高，並以表 2-4 來計算使用者與使用者之間的相似度。

(24)

表 2-3 個人化推薦方法比較

個人化推薦方法 優點缺點

知識推薦法 1. 不需要記錄使用者的使用行為

2. 不需要複雜的相似度計算

1. 須要完整地建立使用者需求的知識規則

2. 使用者須花許多時間回答問題

內容過濾法 1. 有效的找出使用者以前喜愛的或曾經接觸的產品或資訊

1. 只能針對特定的特徵項目進行過濾

2. 難以推薦出使用者未曾接觸過，但可能有興趣的產品或資訊

協同過濾法 1. 不須處理難以分析的特徵項目

2. 可參考其他人的評價與經驗

3. 可自動化處理

1. 冷啟動問題：新使用者或新的產品加入時，因無評價記錄，難以進行有效的推薦 2. 共同評價的商品稀少之問

題。

混合式過濾法 1. 可集結不同方法的優點，彌補單一方法之缺點與不足之處

1. 方法較複雜

表 2-4 相似度矩陣

User(j)

User(i)

評價 5 4 3 2 1

5 1 0.8 0.2 0 0

4 0.8 1 0.3 0 0

3 0.2 0.3 1 0.3 0.2

2 0 0 0.3 1 0.8

1 0 0 0.2 0.8 1

表 2-4 的矩陣表示使用者 i 與使用者 j 共同對某一個網路服務評分的語意相似度矩陣，當使用者 i 與使用者 j 皆給該服務 3 分時，而他們之間的相似度為 1，再以平均誤差的方式計算使用者之間的可信度，藉由使用者之間的語意相似度和可信度，推算出使用者的喜好，並給予個人化的網路服務選擇推薦。但每個人的評分標準不同，

根據評分分數給予固定的相似度，是無法達到真正的相似度計算。

本論文探討到資訊搜尋領域中， [3] 的研究是以皮爾森相關系數 (Pearson

(25)

Correlation Coefficient)來計算使用者與使用者之間的相似度，相似度數值介於 1 到-1 之間，當數值越高表示相似度越高，此方法不會因為使用者的評分標準不同，而有所差異。其計算公式如公式(2.1)，並以使用者對商品的評分做舉例：

(2.1)

表示使用者與使用者之間的相似度；為了使皮爾森相關系數計算正確，我們將篩選出使用者與使用者已經共同評分過之商品，以與表示使用者與使用者的評分記錄，其中為商品編號，其符號表式如下：

表示使用者已經評分過的商品之集合；

表示使用者與使用者共同評分過的商品之交集；

表示使用者對商品的評分；

表示使用者對已經評分過的商品的平均評分值；

表示使用者對商品的評分；

表示使用者對已評分過商品的平均評分值；

例如：假設有三個使用者、、對三個產品、、，的評分值，如表 2-5。

我們以皮爾森相關系數來計算與之間的相似度、與之間的相似度。

表 2-5 使用者對產品評分表

我們預先分別計算使用者、、對所有產品評分的平均值、、，使用者對產品、、的評分為，使用者對產品、、

(26)

的評分為，以公式(2.1)計算使用者與使用者之間的相似度與，計算方法如下：

使用者對使用者、的相似度分別為 0.87 與 1，表示使用者與使用者對產品喜好的相似度比較高。使用者與的評分標準雖然不同，但他們對產品喜好的差異其實是相似的，因此有比較高的相似度。

(27)

第三章個人化網路服務選擇機制之設計

本章節是本篇論文最主要的部份，將分為五個部分：網路服務選擇機制之簡介、

網路服務選擇機制之系統架構、UDDI、網路服務品質監測、個人化網路服務選擇。

3.1 網路服務選擇機制之簡介

本論文研究的主要目標，是在建置一個具回饋性之個人化網路服務選擇機制，並加以實作。讓服務提供者可以透過一個有系統的註冊介面，註冊網路服務到 UDDI 中，服務需求者可以透過本論文所提出的機制，自動的選擇出可用的、有效的個人化網路服務。

圖 3-1 網路服務選擇機制之系統設計模型

網路服務選擇機制主要的設計模式是透過網頁輸入需求，藉由代理人向 UDDI 進行註冊與搜尋，並自動的幫助使用者選擇符合使用者需求的個人化網路服務，如圖 3-1。服務提供者可透過代理人(Broker)設計的服務註冊介面，將服務註冊到 UDDI 中；

管理者透過 Monitor Server 監測網路服務的服務品質；服務需求者送出需求給代理人，

(28)

經由代理人透過本論文所提出的個人化網路服務選擇機制，選擇可用且符合使用者需求的個人化網路服務，並由網路服務需求者給網路服務回饋評價。

3.2 系統架構

在本論文建置的系統架構如圖 3-2，此系統架構分為五個部分：User、Provider、

UDDI Server、Monitor Server、Store Server、Broker Server。

圖 3-2 系統架構

1. User：網路服務需求者。User 搜尋網路服務時，發送網路服務需求給 Broker Server，藉由 Personalization Web Service Selection Agent 中的個人化網路服務選擇機制，選擇出符合需求的個人化網路服務。

2. Provider：網路服務提供者。Provider 可以透過 Register Agent 向 UDDI Server 註冊、修改、刪除網路服務。

3. UDDI Server：網路服務仲介者。提供網路服務註冊與查詢。

(29)

4. Monitor Server：服務品質監測伺服器。監測 UDDI Server 中，所有網路服務的服務品質，並儲存在 QoS Database。

5. Store Server：資料儲存伺服器。用來儲存 Feedback Database 儲存使用者對網路服務的評分回饋，與 Monitor Server 監測網路服務的服務品質資料。

6. Broker Server：代理伺服器。其中包含 Register Agent 與 Personalization Web Service Selection Agent，Register Agent 主要是提供介面幫助 Provider 進行網路服務註冊、修改、刪除；Personalization Web Service Selection Agent 提供使用者介面並使用本論文所提出的具回饋性之網路服務選擇機制，幫助 User 進行個人化網路服務搜尋與選擇，User 也可以給予網路服務適當的評分回饋。

而 Personalization Web Service Selection Agent 部分也是本論文的研究重點。

3.3 JUDDI

在本論文中，我們使用 JUDDI 建置 UDDI 註冊中心。JUDDI(Java implementation of the Universal Description, Discovery and Integration)是利用 Java 程式語言所開發的一套免費自由開軟體且符合 UDDI 規範的實作，且可以連結 MySQL、Oracle、DB2、

PostgreSQL 等多種資料庫存取網路服務註冊資料。JUDDI 是屬於 Web 應用，可以配置在任何應用伺服器或 Servlet 引擎中，如圖 3-3。

JUDDI 提供 API 的功能分為三個部份：JUDDI API、Inquiry API、Publish API。

JUDDI API 主要是提供給管理者的管理功能，如表 3-1；Inquiry API 則是提供使用者查詢的功能，如表 3-2；Publish API 是提供網路服務提供者存取網路服務相關資訊的功能，如表 3-3。

(30)

圖 3-3 JUDDI Web Services Registry 表 3-1 JUDDI API

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 的相關訊息

(31)

表 3-3 Publish 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 目前的資料狀況

使用 JUDDI 提供的 API 時，使用者必需根據 UDDI 規範，根據不同的 API 建立 SOAP request 訊息發送給 JUDDI Server，圖 3-4 是建立搜尋 Business 的 SOAP request 訊息範例，紅色框中是表示透過 caseSensitiveMatch 的搜尋方式，尋找一個名字叫 test 的 Business，而 JUDDI 處理完後會回復 SOAP Response 訊息，圖 3-5 是顯示搜尋成功回復的 SOAP Response 訊息。JUDDI Server 是使用 Apache 組織所開發 Axis 類別來解析客戶端的 SOAP 訊息，Axis 是一種給伺服端跟客戶端處理 SOAP 訊息的 Java Library。

圖 3-4 搜尋 Business 的 SOAP request 範例

(32)

圖 3-5 搜尋 Business 成功的 SOAP respone 訊息

圖 3-6 是說明 JUDDI 使用 Axis 類別處理客戶端 SOAP request 訊息的流程，Axis 定義出可以讓不同的 Transport 協定能夠去協調使用。而 AxisServlet 是用來處理 HTTP 要求的類別，在 JUDDI 中，利用三個 Servlet 來延伸 AxiaServlet 類別：AdminServlet、

PublishServlet、InquiryServlet，而使用者要求主要都是由 AxisHandler 處理。

圖 3-6 JUDDI Server 處理客戶端 SOAP request 訊息的流程

3.3.1 註冊

UDDI 規範中雖然提供了一套標準的資料儲存結構與調用 UDDI 的 SOAP 訊息格式，但是並沒有一套完整的調用 UDDI 流程。例如：網路服務提供者註冊網路服務時，

必需先註冊 Business 取得 Business Key，再註冊網路服務，但是 UDDI 的結構中，

Business Name 卻可以重複註冊，使得同一個 Business Name 有多組不同的 Business

(33)

Key，造成使用者在修改刪除的時候卻可修改其他人所建構的 BusinessEntity 等多種問題，而網路服務的註冊也有相似的問題，圖 3-7 所顯示的是註冊兩次相同的 Business Name 為 test2 時，UDDI 並無法判斷此 Business 是否已經註冊，導致 Business 重複註冊，並造成其他使用者可以修改及查詢其資料。因此本系統在 Broker Server 建置了 UDDI 客戶端介面方便提供使用者註冊與查詢，以解決上述之問題。

圖 3-7 Business 註冊問題

3.3.2 UDDI 客戶端

在 UDDI 客戶端的建置，本論文採用 uddi4j 類別來開發 UDDI 網頁客戶端介面，

uddi4j 是由 IBM 以 Java 程式語言開發 UDDI 客戶端 API，用來與 UDDI 伺服端交換 SOAP 訊息。

圖 3-8 是本論文系統的使用流程，並建置 UDDI Client Controller 幫使用者做 SOAP 訊息的處理，方便使用者對 UDDI 進行網路服務註冊與查詢；當使用者註冊帳號時，會透過 Controller 同時在 UDDI Server 與本機制的 User Profile Database 同時註冊帳號。

得到不同的 business key 註冊相同的 business name

(34)

圖 3-8 UDDI 客戶端流程

3.4 網路服務品質

因為網路服務本身並沒有提供服務品質項目的偵測方式，所以很難取得網路服務的服務品質，而 UDDI 本身也沒有對網路服務偵測網路服務品質之功能。在本論文中的方法是藉由 Monitor Server 採用讀取網路服務的 WSDL 文件並分析網路服務之功能，

(35)

藉此偵測網路服務是否存在，讓網路服務需求者搜尋網路服務時，可以確保網路服務是可用的。在[1]中對於可用性(Availability)的定義是「在某一時間內，網際服務可以使用的次數之於總使用次數所佔的比率」。而本論文根據此定義設計一個計算方式如下：

(3.1)

最近第次偵測時，網路服務是存在的最近第次偵測時，網路服務是不存在的

：是計算網路服務 i 的可用性比率

：網路服務 i

N：最近 N 次的網路服務個數

是用來表示最近第 n 次 Monitor Server 偵測網路服務 i 的結果，如果網路服務 i 是存在的，則設定為 1，如果是不存在，則設定為 0；再由公式(3.1)計算最近 n 次的可用性比率。

3.5 個人化網路服務選擇

3.5.1 個人化網路服務選擇流程

在本論文提出的個人化網路服務選擇，如圖 3-9 流程如下：

1. 由使用者登入系統並輸入關鍵字進行查詢網路服務。

2. 將使用者輸入的關鍵字轉換成網路服務搜尋的 SOAP Request，並發送給 UDDI Server 請求網路服務搜尋，UDDI Server 會回覆 SOAP Response 查詢結果訊息，再藉由系統分析 SOAP Response 訊息，取得網路服務列表與網路服務資訊，如 Service Key、Service Name、Binding Key、EndPoint URI 等。

3. 從 QoS Database 取得網路服務列表的可用性比率，並篩選出可用性大於 α的網路服務，在本系統中預設α值為 0.5。

4. 從 Feedback Database 中，取得對網路服務列表有評價紀錄的使用者與使用者評價，並使用本文所提出的個人化方法，選擇出符合使用者需求的網路服務

(36)

列表。

5. 將結果顯示在頁面上，並讓使用者可以從中查詢網路服務 WSDL。

6. 使用者可以針對選擇出的網路服務給予評價回饋，並記錄在 Feedback Database 中。

圖 3-9 個人化網路服務選擇流程

3.5.2 個人化網路服務選擇

在網路服務選擇時，使用者通常根據網路服務本身的可用性、可靠性、安全性等網路服務品質項目進行篩選，但使用者並不一定知道系統設定的可用性、可靠性、與安全性之定義與計算方式，並無法真正選擇到符合使用者的網路服務。

(37)

在本論文的個人化網路服務選擇機制中採用[3]中所提到的皮爾森相關係數，藉由網路服務需求者的評分回饋，來計算網路服務需求者之間的相似度，計算公式如公式(3.2)。

(3.2)

各符號代表意思如下：

表示使用者與使用者之間的相似度；

表示使用者已經評分過的網路服務之集合；

表示使用者與使用者共同評分過的網路服務之交集；

表示使用者對網路服務的評分；

表示使用者對已經評分過的網路服務的平均評分值；

表示使用者對已評分過網路服務的平均評分值；

計算完使用者之間的相似度之後，我們以公式(3.3)來預測使用者對網路服務的個人化推薦分數，再由分數高到低排名網路服務，將排名前三名的網路服務顯示給網路服務需求者。個人化網路服務選擇演算法，如圖 3-10。

(3.3)

表示預測網路服務在使用者的推薦分數；

表示所有使用者對網路服務評分的平均值；

表示的使用者；

表示使用者與使用者的相似度；

(38)

個人化網路服務選擇演算法

//篩選可用性高於 0.5 之網路服務清單

Variables：

n：WS 中的網路服務個數

m：給予 WS 中的網路服務評分之使用者人數 current_user：當前系統使用者

i, j ：計數變數

ratings[m][n]：WS 中，使用者對網路服務的評分 WS_rank[m][n]：個人化網路服務選擇推薦分數

Step 1：Data collecting //取得使用者對網路服務的評分資料 Begin

Collect rating[m][n] from all users by WS;

End;

Step 2：Similarity calculating //使用皮爾森相關系數計算使用者之間相似度 Begin

For i = 1 to m

For j = 1 to m For k = 1 to n

IF ratings[i][k] empty or ratings[j][k] empty

Compute sim(i, j) using Pearson correlation coefficient;

Next Next

Next

End;

Step 3：Recommendation computing Begin

For i = 1 to n

Compute WS_rank[current_user][i]; //網路服務在目前使用者的排名分數 Next

Select top three scores to current_user;

End;

圖 3-10 個人化網路服務選擇演算法

本論文的個人化網路服務選擇方法分為三部分：

1. 收集有對篩選後的網路服務給予評分之使用者，並取得使用者評分；

2. 計算使用者與使用者間的相似度；

3. 計算網路服務之推薦分數。

(39)

例如：

1. 假設使用者

輸入關鍵字搜尋網路服務，系統藉由使用者輸入的關鍵字從 UDDI

中搜尋並篩選出可用性高於 0.5 之網路服務集合，並從 Feedback Database 中找出對 WS 中的網路服務有評分記錄的所有使用者

，假設系統找出 5 個網路服務與 6 個有對其評分的使用者，評分值如表 3-4。

表 3-4 網路服務評分表網路服務

使用者

10 2 4 8 10

5 1 2 4 5

2 4 6 7 3

4 4 4 8 9

2 1 2 4 5

10 3 3 9 5

2. 使用公式(3.2)計算使用者與使用者之間的相似度，如表 3-5。

表 3-5 使用者與使用者間的相似度

使用者

使用者

1 1 -0.38 0.57 0.7 0.75 1 1 -0.38 0.57 0.7 0.75 -0.38 -0.38 1 0.16 0.1 -0.15

0.57 0.57 0.16 1 0.97 0.21 0.7 0.7 0.1 0.97 1 0.28 0.75 0.75 -0.15 0.21 0.28 1

3. 在公式(3.3)中，考慮到當新加入的使用者沒有評分記錄，因此在計算某一個網路服

務的推薦分數時，我們加入所有使用者對此網路服務之平均評分值之計算，並以

(40)

此分數當為推薦基準，在此範例中每一個網路服務的平均評分值如表 3-6。

表 3-6 網路服務平均評分值

網路服務

平均評分值 5.5 2.5 3.5 6.67 6.17

本論文在公式(3.3)中是將使用者之間的相似度當為使用者之間的可信度，使用者

當可信度高時，其對網路服務的評分值的參考價值也比較高，計算方式是使用者對

使用者的信任度乘以使用者對網路服務的評分。

在此範例中是以使用者為網路服務選擇之推薦對象，系統會以公式(3.3)來計算每一個網路服務推薦給使用者的推薦分數，推薦分數如表 3-7。我們以網路服務推薦給使用者為例，由表 3-4 與表 3-5 得知使用者使用者、、、、、

對網路服務評分值分別為 10、5、2、4、2、10，對使用者、、、、、的相似度分別為 1、1、-0.38、0.57、0.7、0.75，而系統推薦網路服務給使用者的推薦分數為 30.91，其計算方法如下：

=30.91

表 3-7 使用者之網路服務推薦分數表

網路服務

推薦分數 30.91 9.2 13.14 30.11 32.44

而本論文是推薦排名前三名的網路服務給使用者，由上表得知推薦給使用者的

網路服務之順序為 > > 。

3.5.3 回饋方法

回饋方法的目的是在動態地適應每一個使用者的喜好度與需求。在本論文所設計的回饋方法是經由使用者使用網路服務之後，提供一個介面讓使用者可以給予網路

(41)

服務適當的評分，並以使用者對於網路服務的滿意度回饋給系統，在我們的系統中將滿意度分成五個刻度：非常滿意、滿意、普通、不滿意、非常不滿意。表 3-8 為本論文回饋機制之回饋評分表，系統會根據此回饋評分表，記錄每一個使用者對網路服務的評分，並且以累計評分的方式計算，再將計算結果存回 Feedback Database 中，使得使用者在下一次登入與使用本系統時，能根據使用者對網路服務的回饋評分，給予不同的個人化網路服務選擇。

表 3-8 回饋評分表

回饋行為 評分值

使用者評價為「非常滿意」 +5

使用者評價為「滿意」 +4

使用者評價為「普通」 +3

使用者評價為「不滿意」 +2

使用者評價為「非常不滿意」 +1

例如：當一個使用者對本論文之方法所選擇出來的某一個網路服務有興趣時，會擊點「呼叫」之動作來得知網路服務執行之結果，並產生一個回饋評分的介面，提供使用者給予網路服務滿意度之評分。而原本使用者在 Feedback 資料庫中，對此網路服務的評分值為 12 分，所以使用者對此網路服務之回饋評分值計算方式為 5 分(非常滿意) ，並以累計的方式儲存在 Feedback 資料庫中，因此將 12+5=17，所以將 17 分記錄為使用者對此網路服務之總評分。

(42)

第四章網路服務選擇機制之系統建置與實驗

在本章中將以旅遊資訊網路服務選擇系統建置本論文所提出的個人化網路服務選擇方法與個人化選擇方法之模擬實驗。在 4.1 節中，將呈現 UDDI、UDDI Client、

網路服務註冊、網路服務選擇之實作結果。在 4.2 節中，本論文將以 Jester DataSet [23]

中的使用者評分資料，來模擬實驗本論文所提出的個人化網路服務選擇方法。

4.1 個人化網路服務選擇系統之建置

4.1.1 建置環境

本論文在 Windows XP 作業系統下，以 Apache Tomcat 架設 Web Server，並以 juddi 實際建置一個 UDDI 註冊中心在 Web Server 上，而在 Broker Server 的部分，以 JSP 撰寫 UDDI Client，搭配 MySQL Server 5.0 資料庫來做為資料儲存中心。詳細環境資訊如表 4-1。

表 4-1 系統實作環境資訊

硬體

CPU Intel Core™2 Quad Q6600 ,2.40GHz 主機板 Gigabyte GA-G31MX-S2

晶片組 Intel Bearlake G31 記憶體 2GB DDRII-667

軟體

作業系統 Windows 7 開發平台 Eclipse 3.4.1 開發程式語言 Java、Jsp SDK jdk-5u22

Web Server Apache Tomcat 5.5 UDDI Server jUDDI-0.9rc4 UDDI Client API uddi4j-2.0.5 資料庫 MySQL 5.0

(43)

4.1.2 網路服務建置

本論文是以旅遊資訊網路服務選擇系統將具回饋性之個人化網路服務選擇機制實作出來，在本小節主要介紹以旅遊資訊網路服務之建置，而我們以 Axis2 網路服務引擎來開發景點資訊的網路服務。網路服務建置的環境如表 4-2。

表 4-2 網路服務建置環境資訊

硬體

CPU Intel Core™2 Quad Q6600 ,2.40GHz 主機板 Gigabyte GA-G31MX-S2

晶片組 Intel Bearlake G31 記憶體 2GB DDRII-667

軟體

作業系統 Windows 7 開發平台 Eclipse 3.0.1 開發程式語言 Java

SDK jdk-5u22

Web Server Apache Tomcat 5.5 Web Service API Apache Axis2-1.4.1 資料庫 MySQL 5.0

在旅遊資訊的網路服務建置上，我們預先在資料庫建立超過 100 個景點資訊，並以 Axis2 建置 30 個景點查詢網路服務，掛載於 Apache Axis2 Server，服務名稱與類型如表 4-3 所示。而每一個網路服務都連結到我們的旅遊景點資料庫，當使用者呼叫網路服務時，透過網路服務連結資料庫取得景點資訊回傳給使用者。旅遊資訊網路服務運作流程如圖 4-1。

表 4-3 旅遊資訊網路服務名稱與類型

服務類型 服務名稱(關鍵字) 個數

景點資訊查詢 Attraction 26

Spot 4

(44)

圖 4-1 旅遊資訊網路服務呼叫流程

4.1.3 旅遊資訊網路服務選擇系統實作

我們實作的系統可分為四大部分： UDDI 註冊與網路服務發佈、網路服務的 QoS 監測、網路服務搜尋與選擇、使用者回饋。在以下將一一介紹我們實作的功能與實作結果。

 UDDI 註冊與網路服務發佈

在系統的實作上，我們以 JUDDI 來架設屬於我們自己的 UDDI 註冊中心。圖 4-2 為 JUDDI 提供的介面，當使用 JUDDI 的 API 時，必須自行建立 SOAP 發送給 JUDDI Server，而且一次只能使用一個 API，在使用上相當不方便，所以我們以 uddi4j 自行開發 UDDI Client 的介面，使用者由圖 4-3 之畫面登入系統，進行註冊或查詢網路服務。網路服務提供者可以藉由登入系統進行 Business 與 Service 的新增、修改、刪除，

圖 4-4、圖 4-5 與圖 4-6 之畫面。

(45)

圖 4-2 JUUDI Console

圖 4-3 系統登入畫面

圖 4-4 UDDI Client 之功能

(46)

圖 4-5 Business 註冊畫面與結果

圖 4-6 Service 註冊畫面與結果

 網路服務的 QoS 監測

本系統監測的網路服務品項目以可用性為主。由 QoS Server 從 UDDI Server 中搜尋所有註冊的網路服務，並取得網路服務的 WSDL URL 位址，再由 QoS Server 去偵測每一個網路服務的 WSDL 是否存在，來判定網路服務是否可用。當存在時，網路服務的狀態設為 1，不存在則為 0，並記錄在 QoS 資料庫中。圖 4-7 為偵測每一個網路服務之後的結果，Status 為 Success 時，表示讀取 WSDL 成功，也表示 WSDL 是存在的，反之則顯示為 Fail，圖 4-8 為 QoS 偵測記錄的資料庫。

(47)

圖 4-7 網路服務 QoS 偵測介面

圖 4-8 網路服務 QoS 偵測記錄

 網路服務搜尋與選擇

我們提供網路服務的關鍵字搜尋，以及呼叫網路服務所需的 input 字串(如：地點)。

使用者可從介面輸入關鍵字與地點，系統會根據使用者輸入的關鍵字到 UDDI 搜尋相關的網路服務，再由本論文所提出的個人化網路選擇機制，幫使用者選擇網路服務並顯示結果。圖 4-9 為系統旅遊資訊服務查詢介面，使用者輸入的關鍵字為 spot 來搜尋網路服務，並選擇地點為新竹市，提供呼叫服務時所需的輸入地點字串。而圖 4-10 為經由個人化網路服務選擇機制選擇出來的結果，使用者可以進行網路服務呼叫或是查看 WSDL 文件。

(48)

圖 4-9 旅遊景點網路服務搜尋介面

圖 4-10 系統選擇結果

在選擇結果的頁面當中，我們設計了自動呼叫網路服務的功能，使用者可以選擇喜歡的網路服務進行呼叫，系統會將使用者輸入的地點發送給遠端的網路服務，而網路服務會回傳呼叫之後的結果，圖 4-11 為使用者以「桃園縣」為 input 字串，呼叫 SpotService_B 旅遊景點資訊網路服務，SpotService_B 網路服務會回傳新竹市的旅遊景點資訊。

圖 4-11 網路服務呼叫結果

(49)

 使用者回饋

當使用者呼叫網路服務之後，我們提供了一個介面，讓使用可以給予網路服務評分回饋，並儲存於 Feedback Database。圖 4-12 是 SpotService_B 的評分回饋頁面，當使用者呼叫網路服務後，可以點選回饋的連結，連結到回饋評分頁面給予網路服務評分回饋；圖 4-13 為評分回饋資料儲存資料表。

圖 4-12 評分回饋頁面

圖 4-13 評分回饋資料表

4.2 模擬實驗

在本節中，本論文採用 Jester DataSet 來模擬實驗我們的所提出的個人化網路服務選擇方法，Jester DataSet 收集了從 1999 年 4 月到 2003 年 5 月期間，73421 個使用對 100 則笑話的評分，總共有 410 萬個評分。而本論文是藉由使用者對於網路服務的評分回饋，透過個人化網路服務選擇方法推算使用者喜好，給予網路服務選擇排名，

因此我們可以將笑話假設為網路服務，將笑話的評分資料視為網路服務的評分資料。

在本實驗中採用平均精準度(MAP, Mean Average Precision)來評估本論文提出的方法之效能，根據系統選擇出來的網路服務排名與系統篩選後的所有網路服務在使用者評分資料中的排名，以公式(4.1)計算 MAP，系統選出來的網路服務在使用者對篩選出來的網路服務評分排名比較前面時，則 MAP 值越大，反之排名越後面時，MAP

(50)

值越小。

(4.1) N 代表系統選出來的服務個數

為網路服務 i 在使用者的評分排名的名次

假設系統所選出來排名前三名的網路服務，在使用者的評分排的名次分別為 1、

5、7 名，MAP 的計算方式如下：

^=0.610

在本論文設計了三個實驗：實驗一是當篩選的網路服務數量不同時，觀察 MAP 的變化；實驗二是當使用者數量不同時，觀察 MAP 的變化，並加以分析；實驗三是共同以 100 個使用者對 30 個網路服務分別以三種個人化方法進行網路服務選擇，以每個方法所計算出來 Top-3、Top-5、Top-10 的網路服務推薦給使用者，觀察這三種方法之 MAP 值。

實驗一：本實驗假設 10 個不同的使用者，在本系統搜尋網路服務時，本系統篩選出 10 個、20 個、30 個網路服務，並根據系統選擇出的前三名網路服務計算不同使用者的 MAP 值，觀察篩選後的網路服務數量不同時，本系統的準確率與效能。實驗數據顯示於表 4-4。

表 4-4 網路服務個數不同之 MAP 值

使用者服務個數

1 2 3 4 5 6 7 8 9 10

10 個 0.758 1.000 0.495 1.000 0.615 0.439 1.000 0.500 1.000 0.491 20 個 0.533 1.000 0.679 1.000 0.700 0.558 1.000 0.657 1.000 0.528 30 個 0.867 1.000 0.833 1.000 1.000 0.806 1.000 0.806 1.000 0.806

圖 4-14 中顯示當系統透過篩選的網路服務 10 個時，不同使用者之間的 MAP 值波動比較大，但當網路服務增加到 30 個的時候，平均每個使用者的 MAP 值都在 0.8

(51)

以上。由此圖可知道，當系統中註冊可用的網路服務越來越多時，本論文提出的個人化網路服務選擇機制，會越趨穩定。

圖 4-14 網路服務個數不同之 MAP 比較

實驗二：本實驗設定不同數量的使用者使用本系統時，針對 30 個網路服務進行個人化選擇，並根據系統選擇出來的前三名(Top-3)、前五名(Top-5)、前 10 名(Top-10) 的網路服務，計算其平均 MAP 值，此目的在觀察本系統的使用者數量多寡，本系統的準確率如何。實驗數據如表 4-5。

表 4-5 使用人數不同與 Top-k 不同的 MAP 值

人數 Top-k

100 200 300 400 500 600 700 800 900 1000 Top-3 0.784 0.811 0.819 0.823 0.837 0.847 0.841 0.840 0.845 0.840 Top-5 0.802 0.829 0.833 0.837 0.846 0.850 0.850 0.846 0.853 0.851 Top-10 0.845 0.851 0.840 0.843 0.852 0.854 0.854 0.847 0.849 0.847

圖 4-15 為系統的使用者人數的不同時，經過本論文方法來選擇出的網路服務的平均 MAP 值。由圖可看出，本系統選擇出的 Top-3，當使用者人數越多時 MAP 越來越穩定。而 Top-5 與 Top-10 的平均 MAP 值，比 Top-3 的平均 MAP 值高，因為當系統顯示推薦選擇個數較多，系統選到使用者所喜好的網路服務，機率也比較高。

0 0.2 0.4 0.6 0.8 1 1.2

1 2 3 4 5 6 7 8 9 10

MAP

使用者

30個網路服務 20個網路服務 10個網路服務

具回饋性之個人化網路服務選擇機制─以旅 遊資訊系統為例

中 華 大 學 碩 士 論 文