中 華 大 學 碩 士 論 文
題目：
Web Services 的最小 Hop 數整合問題之研究
系 所 別：資訊工程學系碩士班 學號姓名：M09502037 陳 敏 郎 指導教授： 歐 陽 雯 博 士
中華民國 九十八 年 八 月
摘要
由於網際網路快速的蓬勃發展，服務導向架構(Service-Oriented Architectures, SOA)實現了分散式計算與整合的優點，其相關研究近年來受到相當重視。其中，
Web Services 更是一項非常流行且廣泛被採用來實作服務導向的技術。Web Services 的使用保留了鬆散耦合系統(Loosely-coupled system)中，所有組成元件可 獨立開發平台的優點，且 Web Services 彼此之間可經由網路採用開發標準的 Web Services 協定彼此連結。然而，Web Services 的應用有愈來愈複雜的趨勢。許多 服務請求不再只是依賴單一 Web Services，而是整合一個群集的 Web Services。
因此，在系統開發與設計的過程中，如何有效率地組成與整合不同的 Web Services 以提供複雜的服務請求，是一個不可或缺的議題。本篇論文主要探討 Web Services 整合問題，提出運用 Hop 數來評估 Web Services 整合的整體品質。
並進一步根據服務請求的工作任務相依關係，提出兩個不同的問題，加以研究探 討。當這些需被完成的工作任務彼此之間沒有優先順序關係，這樣的問題已被證 實為 NP-complete。這意味著這個 Web Services 整合問題是 NP-hard。當這些工 作任務彼此之間有一個特定的線性順序關係，針對這樣的案例，我們提出一個最 佳化的 Web Services 整合方法，利用貪婪策略方法排程所有整合的 Web Services 以完整地完成所有工作任務。這個方法可以達到整合網路中使用最少 Hop 數的 Web Services 以完成服務請求的目的。本篤論文亦提出此 Web Services 整合系統 的架構。
關鍵詞：Web Services、服務導向架構、Web Services 整合、Web Services 組合
ABSTRACT
Due to the fast advancement of network technologies, the study of service-oriented architectures (SOA) has attracted much attention recently, taking advantage of the benefits of distributed computing and integration. Web Service is a very popular and widely accepted implementation of SOA. The use of Web Services holds the advantages of a loosely-coupled system where all components can be developed at independent platforms and be connected with the Web Service protocols via the network. At the same time, the tendency for methods of applying Web Services over the network is getting more and more complex. Many applications rely on not just one Web Service, but a whole school of them. Thus, how to compose and integrate different Web Services efficiently to provide complicated network services has become an essential topic in system development and design. This thesis investigates the Web Services Integration Problem, and further, proposes the method to estimate the QoS by the number of hops of Web Services. This thesis proposes two different problems in terms of the precedence relationship between the tasks. First, when there are no precedence relationships between the tasks. This thesis also proves the decision problem is NP-complete. This implies that this Web Services integration problem is NP-hard. Second, for the case when the relationships between the tasks are in linear order, a polynomial-time, optimal Web Service integration algorithm is provided which uses greedy strategy to schedule the Web Services in order to complete those tasks. This method can achieve the goal of using the minimum number of hops of Web Services over the network. A Web Services integration system architecture is also presented in this thesis.
Keywords：Web Services, Service-Oriented Architectures, Web Service Integration,
Web Service Composition.目錄
摘要...ii
ABSTRACT... iii
目錄...iv
圖目錄...vi
表目錄... viii
第一章 緒論...1
1.1 研究背景...1
1.2 研究動機...3
1.3 研究目的...5
1.4 論文架構...6
第二章 相關技術...7
2.1 RPC ...8
2.2 CORBA...9
2.3 DCOM...10
2.4 Java RMI ...10
2.5 Web Services... 11
2.5.1 WSDL ...12
2.5.2 UDDL ...13
2.5.3 SOAP ...13
第三章 文獻探討...15
3.1 Web Services 的探索...16
3.2 Web Services 的溝通...17
3.3 Web Services 的服務品質...17
Web Services 的安全性 ...19
Web Services 的可靠度 ...20
3.4 Web Services 組成與 Web Services 整合 ...20
第四章 問題探討說明及系統架構...23
4.1 系統架構...25
4.2 問題假設...27
4.3 問題探討...28
4.3.1 獨立順序 Web Services 整合問題...28
4.3.2 IWSIP 的探討與模擬實驗...30
第五章 線性順序 Web Services 整合問題...42
5.1 OPT 演算法 ...43
5.2 案例說明...45
5.3 OPT 演算法為最佳化 ...52
5.4 OPT 演算法時間複雜度 ...54
第六章 結論與未來展望...55
參考文獻...57
圖目錄
圖 2.1 Web Services 架構圖...12
圖 2.2 WSDL、UDDI、SOAP 運作圖 ...14
圖 4.1 多功能 Web Services 請求傳遞時間示意圖...24
圖 4.2 多功能 Web Services 請求 Hop 數示意圖...24
圖 4.3 多功能 Web Services 請求縮減 Hop 數示意圖...25
圖 4.4 系統架構圖...26
圖 4.5 Web Services 搜尋代理架構...27
圖 4.6 Greedy 演算法流程圖...31
圖 4.7 HGS 演算法流程圖...32
圖 4.8 IHGS 演算法流程圖 ...34
圖 4.9 常態與波氏機率分佈曲線圖...38
圖 4.10 隨機支援關係平均引用 Web Services 個數直條圖...40
圖 4.11 限定支援關係平均引用 Web Services 個數直條圖...40
圖 4.12 常態機率分佈支援關係平均引用 Web Services 個數直條圖...40
圖 4.13 波式機率分佈支援關係平均引用 Web Services 個數直條圖...41
圖 5.1 OPT 演算法流程圖 ...44
圖 5.2 工作任務與 Web Services 關係圖...45
圖 5.3 Web Services 細化支援圖...46
圖 5.4 工作任務與微型 Web Services 關係圖按工作任務排序...46
圖 5.5 移除多餘的微型 Web Services ws22和 ws51...47
圖 5.6 工作任務分派最後結果...48
圖 5.7 微型 Web Services 支援工作任務對照圖...51
圖 5.8 Sr與 Sopt的解集合...52
圖 5.9 比較 Sr與 Sopt的第一個 chunk，Wa1大於 Wb1...52
圖 5.10 比較 Sr與 Sopt的第一個 chunk，Wa1等於 Wb1...53 圖 5.11 比較 Sr與 Sopt的第一個 chunk，Wa1小於 Wb1...53
表目錄
表 2.1 UDDI 服務列表...13
表 4.1 Web Services 與工作任務支援關係表 ...34
表 4.2 Tasks 的基數表 ...35
表 4.3 Web Services 可支援的工作數 ...36
表 4.4 Greedy、HGS 與 IHGS 演算法支援關係集合 ...37
表 4.5 常態分佈與波氏分佈機率值...38
表 4.6 平均引用 Web Services 個數表...39
表 5.1 Web Services 與工作任務關係...49
表 5.2 Web Services 與微型 Web Services 關係表 ...49
表 5.3 排序後工作任務與微型 Web Services 關係表...50
表 5.4 工作任務與有順序的微型 Web Services 清單關係表...51
第一章 緒論
近年來，由於網際網路蓬勃發展，資訊科技(Information Technology, IT)產業 的架構演進，從 1980 年代的主機(Mainframe)架構，到 1990 年代的主從式 (Client/Server)架構，再到 1999 年時已是以網路為中心的(Network centric)架構，
而程式的架構也由 Client/Server、3-tier 演進到 n-tier model-view-controller, MVC 的架構，程式的執行不再被局限於單一電腦上。分散式架構的運用與方法慢慢被 發展，到 2004 年時已複雜到所謂的服務導向架構(Service-Oriented Architecture, SOA)。SOA [1][2][3][4][5]被提出以便管理維護如此龐雜多工的系統，並進而達 到系統整合與分散式處理的目的。SOA 方面的相關研究，在近幾年內更是被廣 泛的討論，實現 SOA 的方法不斷被提出，Web Services 便是其中最廣泛被用都 實現 SOA 的技術，Web Services 的相關議題，更是受到極大的重視。本篇論文 即是針對 Web Services 的整合問題，加以研究探討。我們將於 1.1 節介紹本研究 的想法背景，1.2 節介紹研究的動機，1.3 節介紹研究的目的，1.4 節簡單說明本 篇論文的架構。
1.1 研究背景
SOA 嚴然已成為現今軟體發展的重要架構，透過 SOA 讓異質性系統的整合 變得更加容易，程式再使用度也提高。不必自行開發或擁有所有的程式元件，發 展者可以視其需要，組合網路上已發佈可行最好的服務。SOA 的高模組化和平 台獨立的特性，確實改善了商業的彈性和適應性，不再受限於特定廠商的產品功 能或是平台，進而達到真正的開放性。[6][7]更點出現今 IT 部門如何從內部流程 轉移到公然尋求企業伙伴合作提供服務或產品以保有市場競爭力的挑戰。而 SOA 即可滿足這樣的目的。顯然地，SOA 繼承了軟體元件化開發(Component Based Development, CBD)的概念，因此在開發流程中，SOA 的整合和組成扮演著不可 或缺的角色。Natis [8]和 McCormick [9]點出六個 SOA 成功的關鍵：
(1) 將服務導向架構訓練逐步導入組織 (2) 大的計劃但開始點小
(3) 投資整合基礎建設 (4) 有系統地設計服務 (5) 投資meta-data管理 (6) 預料障礙
這顯露如何成功實作 SOA 的挑戰，亦指出元件整合需要相當多重視及扮演 著 SOA 應用實行上一個不可或缺的角色。軟體應用的效能更是緊密地依賴著被 組成或被整合以支援相對應應用的服務。然而，僅管 SOA 服務導向架構獲得許 多企業，例如 Intel、Microsoft、Oracle、IBM、BEA、Sun、HP、SAP 和 T-mobil [1][2][3][5][7][10][11][12]等的認可，甚致他們的產品或公司內部企業流程系統亦 採用 SOA 原理。
但 SOA 的實行仍面臨許多挑戰和障礙。許多現行的 SOA 開發依然專注於靜 態的軟體應用。然而，當被動態組成或整合的軟體應用得到愈來愈多的流行，動 態的商業流程模組被視為改善企業組織競爭力的方法。它可被應用在下面三個動 態軟體應用情況：
(1)當某一個應用第一次被構成時：它伴隨著可能會有許多網路上的 Web Services 在那等著被呼叫使用。選擇取得適合的 Web Services 將會嚴重地影響應 用的效能。
(2)重要的系統需要有容錯策略，總是需要一個備份計劃：總是會有一些時 候，網路上的節點執行它的功能時，會因某些意外或因素而發生錯誤。因此，有 些 Web Services 提供者可能提供多餘的節點，以避免喪失服務。在某些緊急的情 況和系統，視功能有多緊急和該 Web Services 有多不可被取代而定，這些容錯策 略或備份計劃是必要的。考量另一些情況，當 Web Services 是可以被替代，我們 如何找到一個好的代替者取代該 Web Services 以完成服務，這個問題亦是一個討 論價值的題目。
(3)當軟體允許動態組成時：舉例來說，動態的商業流程或一些遊戲軟體可 能允許遊戲玩家利用一些已開發好可使用的軟體模組集合，動態地組成開發他們 需要的商業流程或自己設想的遊戲。軟體開發流程在實作的過程，總需要軟體開 發專家的參與，而一般軟體開發流程的思維，使用者只是意見和提議的貢獻者。
更先進的共同開發平台則允許使用者自己決定是否參與開發，這種趨勢可追溯到 許多公開的線上服務。例如：Google Video [13]、YouTube [14]直到 Wikipedia [15]。這些服務鼓勵使用者也可成為作者以增加所有使用者之間的互動。相同的 概念也可以運用在軟體開發。例如：遊戲玩家可以自行重新利用已建立的元件創 造新的遊戲，甚致使用現有可行的服務建立新的遊戲元件。在這例子中，當有很 多可以支援的 Web Services 的時候，如何更廣泛地選擇現有的元件，對於組成軟 體的執行是極為重要的。
Lin [16]提出一個 Web Services 可說明性的概念。Web Services 有平台獨立，
元件重覆使用性和彈性的優點。然而，公然地整合經由網路而來的所有來自不同 來源或平台的服務而成的整體系統，其品質總會有一個利害關係。故鬆散耦合結 構一樣有可能造成服務品質問題。如此，需要一個全面的機制以確保服務品質不 會有所損害。這想法是建立一個服務可說明性的管理體制以確保服務，尤其是從 外部資源而來的服務，可以維持效能和穩定性。IBM Research 的全球科技展望 (Global Technology Outlook, GTO)包含了 Managing Business Integrity [17]，隨著 一個新興的系統開發趨勢，在未來幾年資訊科技領域中，包含了遍及整家公司企 業的策略整合、流程整合、核心實體資訊整合的管理，都將有值得注意的影響。
1.2 研究動機
現今，XML 標準與 Web Services 技術的提出並加入至 SOA 中，讓 SOA 邁 入更新的層次及更高的價值。開放、廣泛通行運用的 XML、Web Services 技術，
讓 SOA 能廣泛地適用於企業內所有的資訊技術以及所有已部署的應用程式。
SOA 就如同物件導向、軟體元件等軟體技術一般，運用小的零組件組合成應用
系統。透過 XML 的使用，程式師可以輕易轉變應用程式的資料，而不需去理會 資料以何種方式呈現。
Web Services 是一種平台中立的服務，可單獨使用或是與其它 Web Services 結合互動，以執行複雜的、整體的服務請求或大企業的交易。讓應用程式可以透 過 URL (Uniform/Universal Resource Locator，統一資源定位符)，指定存取網際網 路上任何一台電腦提供的服務，且不管對方的電腦是使用那一種作業平台或應用 程式類型，雙方只要遵循開放標準的傳輸方式(例如：HTTP)進行程式之間的資 訊傳遞，透過開放標準的協定方式(SOAP)就可進行程式之間的溝通運作。基於 平台中立的特性，軟體開發人員可以將已設計好的 Web Services，利用開放標準 的描述方式(WSDL)來提供服務介面描述，進而公佈在網際網路供其他應用程式 或服務使用，其他的開發人員則可以重複使用這些現有的服務來建構分散式應用 程式，而無須花時間重新設計相同功能的軟體元件。Web Services 的應用更是受 到軟體大廠的重視，而且不斷有新穎的、支援不同功能的 Web Services 被發佈。
許多的研究都專注在 SOA，尤其在 Web Services 應用方面。有些許的研究討論 如何組合這些 Web Services，或是如何用應用 Web Services 以完成一些服務。亦 有些許學者探討 Web Services 的非功能性的特性，例如：如何確保 Web Services 安全、如何提供高可靠度的 Web Services 和如何評估 Web Services 的效能。
由於網際網路技術的快速發展及應用需求有愈來愈複雜的趨勢，Web Services 的應用不再只是尋求單一 Web Services 以完成單一功能。且從面對商務 上或應用上遭遇的問題角度來看，單一的服務只能滿足部份需求，我們必需滿足 複雜需求的所有的服務請求，其解決的方法在於將各個服務串連起來。因此，如 何動態整合不同的 Web Services 以達到較好的效能及適應全球性的改變，是一個 極需解決的重要問題。本篇論文更是針對 Web Services 整合問題加以研究探討。
1.3 研究目的
本篇論文主要探討 Web Services 整合的問題，考量到不同的 Web Services 可能位於網路不同的節點上，且一個複雜的服務請求，可能需要整合位於網路上 不同節點的 Web Services。在探討關於 Web Services 整合這方面的議題時，我們 首先對 Web Services 整合數量的做一些簡單的研究探討，更進而提出了一個運用 Hop 數來評估整體 Web Services 整合的品質，希望可以求得一個達到最少 Hop 數的 Web Services 整合，以便降低完成服務請求的整體反應時間。
一個複雜的服務請求包含了許多不同功能的工作任務，我們在整合不同的 Web Services 以完成這些工作任務時，必需花費些許時間以便讓完成各服務工作 任務的 Web Services 傳送一些相關且必要的資訊、參數給即將需要完成、支援下 一個工作任務的 Web Services。而如何減少不同的 Web Services 彼此之間必要資 訊傳遞的次數，以提昇完成服務請求的整體反應時間，便是本篇論文首要提出考 量的議題。本篇論文在探討 Web Servcies 整合問題的議題時，提出一些假設條 件，並以這些假設條件成立為前提，考量工作任務的相依關係的不同，探討兩個 Web Services 整合問題。第一個問題探討工作任務彼此之間不具有相依關係，即 彼此獨立不會互相影響，為獨立 Web Services 整合問題(Independent Web Servcies Intergration Problem, IWSIP)。本篇論文證明獨立 Web Services 整合問題為一個 NP-complete 問題，除了運用兩種不同的 Heuristics 演算法來求得解，並改進 HGS 演算法，進而提出新的 IHGS 演算法，最後再進行實驗模擬，加以比較三者的效 能。除此之外，因為完成服務請求可能需要按照某一種特定的順序去建一完成的 不同的功能工作任務，因此本篇論文亦考量工作任務需照一定的順序被完成時，
提出一個線性順序 Web Services 整合問題(Linear Order Web Services Integration Problem, LOWSIP)，針對線性順序 Web Servcies 整合問題，本篇論文提出一個最 佳化 Web Services 排程演算法，以針對線性順序 Web Services 整合問題求得一個 最佳解。
1.4 論文架構
本篇論文在第一章緒論，簡介了作此研究的想法背景、研究的動機以及本篇 論文所希望達到的目的。在第二章相關技術中，介紹一些 SOA 的相關技術背景，
並簡單介紹幾個可實作 SOA 的分散式技術，亦對 Web Services 做一個簡單的介 紹。我們在第三章的文獻探討，針對 Web Services 的相關研究文獻，做廣泛且有 系統的概略介紹。第四章問題探討說明與系統架構，在此章節我們說明本篇論文 在探討的 Web Services 整合問題時，運用 Hop 數來評估整體 Web Services 整合 品質的理由，將問題分為獨立 Web Services 整合問題與線性順序 Web Services 整合問題。先證明獨立 Web Services 整合問題為 NP-Complete 問題，並除了提出 一個新的演算法外，並運用一些學者提出來演算法做實驗模擬，再進一步研究分 析效能，在此章節，我們亦提出一個系統架構，加以說明本篇論文所提出的 Web Services 整合架構。第五章介紹本篇論文所探討的第二個問題，線性順序 Web Services 整合問題，探討 Web Services 整合時，工作任務彼此之間具特定線性順 序關係的問題，並進一步提出一個最佳化的 OPT 演算法，以便找出整合最少 Hop 數的 Web Services，便可完成此複雜的服務請求以降低整體的反應時間。我們亦 運用兩個例子，圖示案例及二元資料結構案例加以詳細說明，在線性順序 Web Services 整合問題中，運用本篇論文所提出的 OPT 演算法的步驟流程的詳細過 程。最後提出證明 OPT 演算法是一個最佳化的演算法，並分析 OPT 演算法的時 間複雜度。最後是結論及未來展望。
第二章 相關技術
服務導向架構(Service-Oriented Architecture, SOA) [1][2][3][4][5]，簡單地定 義，是一個能夠動態連結資源的系統，將應用程式或資源以「可重複使用 (Reusable)」的「服務(Services)」方式呈現，藉由各個服務功能的明確描述，與 使用標準化的 IO(Input/Output)介面的清楚定義以便相互溝通。在連結整合不同 的服務之下，來形成不同的服務請求，藉此提供更高彈性、更高效率、及資訊整 合的 IT 環境。SOA 乃是以標準化的開放式架構(Standard based Open Architecture) 做為基礎，運用最先進的技術以達系統整合與分散式處理的目的。
SOA 強調的是如何將彼此關係鬆散的應用功能元件在網路上發行、組合及 使用。SOA 具有下列技術特性：
分散式架構(Distributed)－SOA的組成元件是由許多分散在網路上的應用元 件組合而來。例如Web Services 服務技術就是利用HTTP協定來相互連結的。
鬆散耦合的界面(Loosely coupled)－傳統的系統主要是將應用功能需求切割 成相互關聯的模組、物件或元件，開發者需花費極大的心力去了解元件是如 何設計及使用，以確保不會違反元件連接關係的限制。如此，若要以不同元 件替換原始設計，就會變成一件困難的事。SOA的作法是以界面標準來組合 系統，只要符合界面要求，元件可以任意替換，大幅地提高系統變更的彈性 度。
依據開放的標準(Open standard)－使用開放標準是SOA的核心特色，過去的 軟體元件平台如CORBA、DCOM、RMI採用專屬協定作為元件連結的規範，
使得不同平台的元件無法相通。SOA則著重於標準與互動性，將可避免不同 平台所開發程式間相互整合的困擾。
以流程角度出發(Process centric)－在建構系統時，首先了解特定工作的流程 要求，並將其切割成服務界面(包括輸入與輸出資料格式)，如此其他的開發 者就可以依據服務界面開發(或選擇)合適的元件來完成工作。
由於 SOA 的興起與 Web Services 技術成為標準的潮流有密不可分的關係，
因此常常將 Web Services 與 SOA 的實現畫上等號。然而，SOA 的實現並不局限 於 Web Services；大多數的分散式應用系統用以存取另一台電腦上服務的遠端程 序呼叫(Remote Procedure Call, RPC)方式，例如由 OMG 設立並進行控制的通用 物件請求代理架構(Common Object Request Broker Architecture, CORBA) [18]、微 軟推行的分散式元件物件模型(Distributed Component Object Model, DCOM) [19]
或昇陽的 Java Remote Method Invocation, RMI [20]等都是可以實現 SOA 的方 式。但這些技術都有一個共同的缺點，就是會跟特定的作業系統或軟體綁在一 起，使用不同的傳輸協定或資料格式，使得彼此無法溝通。
而 Web Services 技術的優點在於它一種平台中立的 Web Services，應用程式 可以透過 URL 指定存取網際網路上任何一台電腦提供的服務，不管對方的電腦 是使用什麼作業平台或是什麼應用程式的類型，雙方只要遵循公開標準的協定就 可以溝通，使用者隨時可依需求取得需要的應用或服務。微軟、昇陽或 IBM 等 平台的提供者也都相繼推出開發 Web Services 的工具，不可否認的 Web Services 將會是實現 SOA 的最佳途徑。以下我們亦簡單介紹各用不同實現 SOA 的技術。
2.1 RPC
遠端程序呼叫(Remote Procedure Call, RPC)是 Windows 作業系統所使用的 計算機通訊協定。RPC 提供程序之間的通訊機制，以便允許在電腦上執行的程 序，可以使用這個協定請求網路中另一台計算機上的子程序的服務，而不需要知 道網路細節。RPC 跨越了網路通信的開發系統連結模型中的傳輸與應用層。RPC 使得一個包涵分散網路中的多個程序之應用程序的開發變得更容易。通訊協定本 身衍生於「開放軟體基金會」(OSF，Open Software Foundation)RPC 通訊協定，
但加入了某些 Microsoft 特定的擴充功能。RPC 是一個分散式計算的客戶端-伺服 器（Client/Server）的例子，請求程序是 Client，而服務提供程序則為 Server，它 簡單而又廣受歡迎。RPC 總是由客戶端對伺服器發出一個執行若干程序請求，
並用客戶端提供的參數。執行結果將回傳給客戶端。由於存在各式各樣的變體和 細節差異，相對地衍生了多種遠端程序呼叫協議，而且它們並不互相兼容。RPC 首次在 UNIX 平台上普及的執行工具程序是 SUN 公司的 RPC（現在叫 ONC RPC）。它被用作 SUN 的 NFC 的主要部件。ONC RPC 今天仍在伺服器上被廣 泛使用。
2.2 CORBA
通 用 物 件 請 求 代 理 架 構 (Common Object Request Broker Architecture, CORBA)標準由物件管理組織(Object Management Group, OMG)設立並進行控 制，CORBA 定義了一系列 API、通信協定和物件/服務信息模型，用於使異質應 用程序能夠互相操作，這些應用程式用不同的程式語言編寫，運行在不同的平台 上。主要發展理念是為了讓應用程式在發展與運作有一個共通的標準通訊介面，
並共同規範物件在網路上傳遞的方式，使之能相互溝通，並且能夠在跨平台的環 境上運作，期能整合廣大的物件系統。CORBA 標準的設計應該「與作業平台無 關、與程式語言無關、與網路通訊協定無關」。「與作業平台無關」，所以物件 在各種作業系統上皆可通訊。「與程式語言無關」，所以物件可以任何一種語言 寫成，但須遵循物件的介面 (Interface) 規定。「與網路通訊無關」，所以物件 可以在各種網路環境上通訊，而這事實上便是一個簡單的應用程式通訊協定 (Application Protocol) ，將電腦兩端的物件以各種格式，互相傳遞訊息。CORBA 因此為定義明確的物件提供了平台和位置的透明性，這些物件是分散式計算平台 的基礎。通常來說，CORBA 把用其他語言開發的程序代碼和關於該程序代碼能 力和如何調用該程序代碼的信息包到一個開發包（Package）中，開發包中的物 件則可以在網絡上被其他程序（或 CORBA 物件）調用。在這個意義上來講，
CORBA 可以被看作是一個機器可讀的文件格式，類似於標頭文件（Header），
但是具有相當多的信息。CORBA 使用一種介面定義語言用於刻畫物件將呈現出 來的介面。
2.3 DCOM
DCOM 是一項為了協助建立分散式系統而設計的技術，一個分散式系統是 一個軟體個體的集合，這些個體實際上是跨越數台不同電腦而存在，為了達到共 同的目地而一起運作。DCOM 是一個高階的網路協定，讓位於兩台不同電腦上 的行程內之 COM 元件可以相互運作，DCOM 完成這項工作，這樣一來程式設計 師就不用幫那些要跨越網路互動的分散式元件撰寫處理網路通訊所需的程式 碼。DCOM 提一個透明的網路協定讓 COM 元件可以跨越網路互相運作。
分散式元件模型 DCOM 是微軟的 COM 規格的網路化版本，又可以稱 Network OLE，分散式元件模型允許 COM 元件可以利用網路來傳輸資料，並且 它是以二進位格式來傳輸，在效能表現上並不差，早期的微軟分散式應用程式技 術中，分散式元件模型是其中重要的介面之一，但是在網路安全開始被重視，並 且企業開始架設防火牆開始，分散式元件模型無法通過防火牆的缺點被嚴重的暴 露出來，因此現在使用分散式元件模型來開發的應用程式已經相當少，大多數都 改 用 其 他 的 分 散 式 技 術 來 取 代 。 分 散 式 元 件 模 型 當 時 的 主 要 競 爭 對 手 為 CORBA，以及其他具有遠端程序呼叫能力的應用平台。
2.4 Java RMI
Java 遠程方法呼叫，即 Java RMI (Java Remote Method Invocation) 是 Java 程式語言中，一種用於實現遠程過程呼叫的應用程序編程介面。它使客戶端機器 上運行的程序可以呼叫遠程伺服器上的對象。遠程方法呼叫特性使 Java 編程人 員能夠在網路環境中分佈操作。RMI 全部的宗旨就是盡可能簡化遠程介面對象 的使用。Java RMI 極大地依賴於介面。在需要創建一個遠程對象的時候，程式 設計師通過傳遞一個介面來隱藏底層的實現細節。程式設計師只需關心如何通過 自己的介面發送消息。介面的兩種常見實現方式是：最初使用 JRMP（Java Remote Message Protocol，Java 遠程消息交換協議）實現；此外還可以用與 CORBA 兼容
的方法實現。RMI 一般指的是編程介面，也有時候同時包括 JRMP 和 API（應用 程序編程介面），而 RMI-IIOP 則一般指 RMI 介面接管絕大部分的功能，以支持 CORBA 的實現。最初的 RMI API 設計為通用地支持不同形式的介面實現。後 來，CORBA 增加了傳值 (pass by value) 功能，以實現 RMI 介面。然而 RMI-IIOP 和 JRMP 實現的介面並不完全一致。
2.5 Web Services
Web Services 技術最廣泛被用來實現 SOA 的技術。Web Services 技術會受到 大家的注目是因為 Web Services 技術的優點在於它是鬆散耦合的(loosely-coupled) 分散式架構，是一種平台中立的 Web Services，應用程式可以透過 URL 指定存 取網際網路上任何一台電腦提供的服務，從個人電腦到大型主機、從 Visual Basic 到 Java，不管對方的電腦是什麼作業平台或是應用程式的類型，雙方只要遵循公 開標準的協定就可以溝通，使用者隨時可依需求取得需要的應用或服務，或者商 業伙伴之間可透過事先已建立的服務元件進行流程整合。且 Web Services 技術所 產生的應用服務及使用服務的工具日益成熟，可由現有的功能重新包裝開始，未 必要需要使用者重新開發設計。使得入門的困難度大幅地減低很多，再加上各主 要軟體大廠的大力推廣，因此造就了今日的流行。
Web Services 是一個具備鬆散耦合特性並能夠互相呼叫連結的元件，此外還 可跨平台、跨語言，徹底解決異質平台資訊交換的問題。Web Services 運作方式 包含了三個主要的角色：服務的提供者(Provider)，服務的請求者(Requester)或消 費者(Consumer)，與介於兩者之間的服務登錄中介者(Broker)，參考如下圖 2.1：
服務的提供者負責建立 Web Services 描述，將服務描述刊登到一個或多個服 務登入中介者，以及接受從一個或多個服務請求者發出的呼叫引用訊息。服務提 供者可以是任何提供 Web Services 在網路上被引用的公司。任何 Web Services 的消費者皆可以被視為服務請求者，服務請求者尋找刊登在一個或多個服務登錄 中介者上的服務描述，以及負責使用服務描述來連結或呼叫引用由服務提供者提
供的 Web Services。服務登入中介者負責廣告服務提供者刊登其上的 Web Services，以及讓服務請求者搜尋已登錄的服務描述集合。故服務登入中介者的 角色很簡單，成為服務請求者和服務提供者之間的媒人。一旦服務請求者找到符 合的服務描述，它的角色就會消失，其餘互動會直接發生在服務提供者和服務請 求者之間的 Web Services 呼叫引用。
圖 2.1 Web Services 架構圖
Web Services 運作除了包含上述的三個主要的角色，也需要一些 Web Services 技術的支援。以下即簡單介紹三個主要的開放標準 Web Services 技術；
Web Services 描述語言(Web Service Description Language, WSDL) [21]用以描述 整 個 Web Services 的 相 關 資 訊 ； 統 一 描 述 探 索 整 合 (Universal Description, Discovery and Integration, UDDI) [22]則發佈 Web Services 所在的位置以及相關服 務資訊，使用者可到各個 UDDI 網站找到可滿足所需服務的 Web Services 以請求 服務；簡易物件存取協定(Simple Object Access Protocol, SOAP) [23]提供 Web Services 彼此之間，用以溝通的訊息交換協定。
2.5.1 WSDL
一個以 XML 為基礎的描述語言，用以描述一個 Web Services 所支援的方 法、參數資訊和傳回值的型別等資料。當你在網路上找到一個 Web Services，你 如何知道要怎樣使用它？它提供了什麼服務？要傳遞哪些參數？這些問題的答 案就是 WSDL。WSDL 是一份以 XML 撰寫的文件，其主要的用途是「描述 Web
Services」，也就是讓服務請求者知道如何使用 Web Services。WSDL 的文件內 容也有一個共同的標準，以便與各種服務請求用戶端應用程式相互整合，此標準 是由 IBM 與 Microsoft 共同研發擬定。
2.5.2 UDDL
當有越來越多的 Web Services 出現在網際網路的世界時，要如何知道有那些 Web Services 可用，就需要類似像電話簿的服務來提供 Web Services 的清單。
UDDI 就如同 Web Services 中的電話簿，主要提供三個功能。第一，發佈(publish)，
Web Services 的提供者註冊 Web Services 資訊描述；第二，尋找(Find)，應用程 式找出需要的特定 Web Services；第三，連繫(Bind)，找到 Web Services 之後，
用程式連接至 Web Services。當開發人員將一個 Web Services 設計實作完成之 後，可以將它登錄到一個集中的地方，其他人就可以向這個集中地查詢找到、連 繫至需要的 Web Services。這個登錄--查詢--連繫的機制主要就是依靠 UDDI 來達 成。
目前有幾家廠商提供了測試用的 UDDI 儲存庫[24][25]，如 Microsoft、IBM、
SAP、NTT、NOVELL 等，其位址如下表 2.1 所列，我們可以將開發好的 Web Services 位址公布到這些 UDDI 讓其他有興趣的使用者呼叫使用，此外也可透過 一些程式 API 的方式自動化搜尋並呼叫繫結服務。
表 2.1 UDDI 服務列表
廠商 UDDI 服務位址 Microsoft http://uddi.microsoft.com/
IBM http://www-3.ibm.com/services/uddi/
SAP http://uddi.sap.com/
NTT http://www.ntt.com/uddi/
NOVELL http://developer.novell.com/uddi/
2.5.3 SOAP
SOAP，這是一個以 XML 為基礎的編碼技術，用以將溝通用的內官包裝在 一份 SOAP 訊息中，它提供了豐富的資料型別描述方式，來有效進行跟平台的資
料傳遞作業。至於在通訊的協定上，它採用了 HTTP 這個廣泛使用的協定，因此 它也會和 Web 的應用環境緊密結合。
SOAP 是架構在 HTTP 之上的物件存取協定，也就是說透過 HTTP 來傳遞訊 息，而訊息的內容則是以 XML 格式來描述。當用戶端程式需要要求服務時，可 以將這項要求封裝成 SOAP 呼叫傳遞給遠端的 Web Services，當 Web Services 收 到了用戶端的請求便去執行其指定的服務，並且在執行完畢之後傳回結果。
瞭解了 WSDL、UDDI、SOAP 等技術的用途之後，透過下圖 2.2 可一覽這 三者彼此之間的關係及使用方法。首先 Web Services 請求者會透過 UDDI 搜尋所 需要的服務，若有找到符合的 Web Services，UDDI 會將服務提供者的 WSDL 位 址提供給服務請求者，接著服務請求者會使用此 WSDL 位址找尋服務者實際的 位置，服務者會將服務的詳細內容回傳給使用者，最後請求者會使用開發工具來 使用並繫結此 WSDL 文件所提供的服務，雙方便會開始使用 SOAP 來做資料的 交換傳遞。我們可以看到這中間所有的過程所使用的協定，HTTP、SOAP、UDDI、
WSDL、XML，全部都是跨平台、跨語言的國際標準，因此用戶端、服務端雙方 即便使用不同的作業平台或開發環境，都可以無礙的使用或提供服務的內容。
圖 2.2 WSDL、UDDI、SOAP 運作圖
第三章 文獻探討
自從 XML、SOAP、WSDL、UDDI 等 Web Services 技術的興起以來，快速 成為各界共奉的技術標準，由其衍生出的各種可能的應用，更是寬廣無限，因而 創造了 SOA 概念的興起。SOA 的興起更是提供一些企業組織組合不同服務資源 的概念。近年來，對於 SOA 的研究探討[26][27]也愈來愈多。例如：Ha [28]等人 提 出 一 個 服 務 導 向 無 所 不 在 自 動 化 架 構 (Service-oriented Ubiquitous Robotic Framework, SURF)，這個架構在無所不在的計算環境中，運用服務導向的方法，
使用語義 Web Services 技術以及 AI-based planning 技術，使網路中的各個搖控裝 置及在計算環境中的裝置彼此間可以溝通互動，以達到自動整合存在網路中的各 個搖控裝置資源。
由於 SOA 的興起與 Web Services 相關技術成為標準的潮流密不可分，因此 常常將 Web Services 與 SOA 的實現畫上等號。針對 Web Services 的研究也愈來 愈多人加以深入探討[29][30]。例如 Lee [29]等提出一個 Web Services 恢復架構，
以便在原本引用的 Web Services 在斷線或是損壞時，利用 VSM 和 BitCube 的概 念，能有效找到相同功能或類似的 Web Services，以便持續提供服務；Guan [30]
等則提出一個管理 Web Services 架構以解決在整合不同 Web Services 時，不同 Web Services 互動時所面臨的問題。
Lin [16]更是提出一個 Web Services 可說明性的架構，以便檢查、診斷及去 除一些 Services 的缺失。該架構提供四個機制，包含基於服務品質為基準來選擇 servcies、服務階層協定的監控，可能性推論以驗證問題發生原因及信用機制以 預防未來可能的問題。並設計一個 LLAMA 管理架構，以支援監控、分析及配置 服務的程序。亦建立一個 LLAMA ASB(Accountability Service Bus)使得整合其它 的 services 更加簡單，且支援自動動態重新配置服務的程序。對整合 Web Servcies，從 Services 的選擇，分配，到管理，重新配置，提供一個完整且有系 統的架構。除此之外，根據我們的研究探討，可大概將對於 Web Services 的相關
論文研究大略分成下列幾個較大的議題來研究探討。但 Web Services 的相關論文 研究並不只局限在這些議題。
3.1 Web Services 的探索
由於 SOAP、WSDL、UDDI 等協定標準的採用，請求 Web Services 可以不 需理會 Web Services 提供者所提供的 Web Services，其所在位置在何或是所使用 的是什麼類型的作業平台，只需要經由 HTTP 協定可以呼叫使用 Web Services。
現今，有愈來愈多的 Web Services 被開發，建立。由於 Web Services 的快速增長，
且通常分散在網路中不同的節點上，找到一個滿足需求的 Web Services 變得愈來 愈不容易。UDDI 便是一個常用以解決 Web Services 探索問題的方法。UDDI 如 同是一個暫存容器，它允許企業在此描述和註冊登錄他們的 Web Services。它也 允許企業在此探索適合他們需求的 Web Services 以整合到他們的元件。現行服務 的組成或協調依然很多是停留在手工處理的階段，這是很沒有效率的。於是近年 來，有許多基於語義基礎(Semantic-Based)的服務探索方法被提出以便增進服務 探索時的效率。例如：OWL-S [31]、WSMO [32]、WSDL-S [33]等等。
然而，大部份語義基礎的服務探索方法，在服務探索的步驟時，需要許多邏 輯的推理參考，以致於在搜找一個服務可能會需要很長的反應時間。為了解決這 樣的問題，Ren [34]等針對服務的探索提出一個有效率的演算法以及提出一個服 務實例選擇的方法。該演算法首先在發佈服務時，依據 Ontology 概念分析語義，
並建立一個特殊的資料結構存放這些對應的 Ontology 概念，這些資料結構將構 成一個快速服務詢問列表(Quick Service Query List)。因此在服務探索時，就可以 快速且有效率的從快速服務詢問列表找到需要的服務而不需要太多的邏輯推 論。這一演算法不但確保語義基礎服務探索帶來的高恢復率和準確率的優點，亦 保證一個快速的回應時間。
3.2 Web Services 的溝通
不同的 Web Services 之間彼此溝通，建立在一個 SOAP 的標準之上，SOAP 是架構在 HTTP 之上的物件存取協定，也就是說透過 HTTP 來傳遞訊息，而訊息 的內容則是以 XML 格式來描述。當用戶端程式需要要求服務時，可以將這項要 求封裝成 SOAP 訊息呼叫傳遞給遠端的 Web Services，當 Web Services 收到了用 戶端的請求便去執行其指定的服務，並且在執行完畢之後傳回結果。此外，有許 多文獻基於 SOAP，發展不同的溝通或 Bing 機制。例如：Lai 等[35]比較不同的 SOAP binding，探討 SOAP-over-HTTP、SOAP-over-TCP 和 SOAP-over-UDP 三 者的效能比較。根據結果提出雖然 HTTP 和 TCP 包含了可通過 firewall 和可靠度 的優點，但這樣的特性並不是所有的應用都需要的。在無線網路環境中 HTTP 或 TCP 亦有一些限制和效能不足的地方。經過大量的實驗後，發現 SOAP 使用 HTTP 或 TCP binding 的負載會高於使用 UDP。除此之外，SOAP-over-UDP 的總處理 能力卻是近於 SOAP-over-HTTP 的 10 倍量。
由於無線網路技術的發展和 Web Services 技術的盛行，使得移動式的 Web Services (Mobile Web Service)開始被注重。移動式 Web Services 需要將即時訊息 盡快傳送以確保彼此的關聯，較不需要像 TCP 傳送的交付保證機制，因此 UDP 於是很自然地被選擇以用做為即時資料傳送的方法。Gehlen 等[36]亦延伸 SOAP-over-UDP [37]的技術規範以及使用 Web Services Addressing [38]規範，提 出一個有選擇能力可重覆的 ARQ 協定以提昇 UDP 的 SOAP binding 的可靠傳輸。
3.3 Web Services 的服務品質
除了探討 Web Services 的溝通、探索之外，由於現行的網路上存在愈來愈多 可行的 Web Services，通常符合某特定功能需求的 Web Services 會有許多個，除 了尋找適合可行的 Web Services，另外 Web Services 的品質亦是相當重要的考 量。且當各別的 Web Services 無法滿足複雜的服務請求時，則可以組合不同的數
個 Web Services 創造一個新的服務應用以滿足複雜的服務請求，而在組合不同的 Web Services 以達到特定的服務應用時，如何去選擇適合可行的 Web Services 是 非常重要的步驟，需考量的因素非常多，其中服務品質(Quality of Service)更是扮 演著相當重要的準則。例如 Yu 和 Lin [39]研究由數個 Web Services 構成新的 Web Services 時，在考量 End-To-End 的服務品質時，探討的 Web Services 服務品質 因素包含了回應時間、服務成本、網路延遲及服務的有效性。並提出一個服務品 質代理者，負責協調各別的 Web Services 以解決服務品質的限制。
更有非常多的論文研討 Web Services 的服務品質。然而，服務品質的擁有許 多不同的特性以描述 Web Services 不同的品質觀點，例如服務品質可能是回應時 間，latency、可行性、可存取性、安全性等等[40]。在許多不同的案例之中，服 務品質特性的值是非常難以準確地定義，TRAN 和 TSUJI [41]便提出一個在尋 找、選擇 Web Services 時運用模糊集合[42]的方法的一個概觀。說明許多依據不 同的服務品質，運用模糊方法加以分等的機制[43][44][45][46]。其它許多的相關 研究論文亦廣泛的討論 Web Services 的服務品質議題，例如 Yu [47]等針點 Web Services 與軟體元件加以比較研究；[48][49][50][51]等論文皆有提出一些收集不 同的 Web Services 加以探討分析的一些數據及評估目前 Web Services 的發展情 況。Choi [52]等提出如何去度量 Web Services 的相關論點；Hu [53]等考量請求者 的愛好程度做為一個選擇 Web Services 的非功能特性以反映出請求者的主觀需 求，更進而提出一個新的服務品質模組做為 Web Services 選擇媒合演算法的基 準；Chua [54]等利用 Web Services 的服務品質為作基準，提出一個視覺化的 Web Services 探索與選擇的架構。
以上都是針對 Web Services 品質的綜合性評估或研究，當然也有不少論文只 針對單一項非功能性的效能做探討研究。例如：安全性，可靠度…等等。以下我 們亦簡單說明一些相關的研究文獻。
z Web Services 的安全性
在 Web Services 安全性議題方面，不管是安全程序、安全評估、安全管理等 等各方面議題都有許多學者研究探討[55][56][59][60][61][62][63][64]。例如：
Gutiérrez [64]等提出一個安全性程序(Process for Web Services Security, PWSSec) 幫助使用者在開發或整合不同的 Web Services 以完成某項特定的服務，提供安全 性的機制。PWSSec 包含三個步驟：第一，Web Services security requirement，用 以說明開發目標系統時所需特殊的安全需求。第二，Web Services security architecture，確認第一步驟所說明的安全上的需求，再找出有適合且符合安全需 求的 Web Services 組織模式或機制。第三，Web Services security technologies，
以用定義，根據先前步驟所確認的抽象安全服務所實作出來的標準。PWSSec 基 於這三個步驟，概括一套較完整的開發整合 Web Services 的安全程序；
Chen [55]等則提出一個綜合性的效能評估以探討 Web Services 安全性。並設 計一個簡單的比較基準，依照訊息是否有運用基本的 Web Services 安全策略而造 成的訊息大小差異，來測試 Web Services 的效能。測試結果得到一致且重要的觀 察，Web Services 安全簽章的成本是非常高於 Web Services 安全加密。且在 Web Services 安全部署時，使用 Username 或是 X509 做為公開金鑰不會有太大的效能 差異，Chen 等人提出這綜合性的效能評估，探討 Web Services 安全性，可為 Web Services 安全實作時，運用現行的 XML 安全技術提供一個清楚的指導方針。
而在安全性管理方面 Wu [56]認為在聯邦的網路環境中，信任的管理是資訊 分享及線上合作一個極為重要的關鍵。提出一個架構以幫助在聯邦網路環境中的 信任管理機制，可讓安全性標記在不同的自治的安全領域之間做轉變。由於使用 Web Services 是一個比較實用的方法去轉變信任相關資訊，包含隱藏內部結構及 系統較詳細資訊的安全標記。而此架構可提供更廣泛的基礎設備以幫助聯邦網路 環境中的信任管理，轉化其信任的相關資訊。
除此之外，亦有一些安全性上的標準被建立、提出。例如在存取控制(Access
control)方面，OASIS 組織發展了幾個不同的 Web Services 安全標準。例如安全 宣示標記語言(Security Assertion Markup Language, SAML)[57]、可延伸讀取控制 標籤語言(eXtensible Access Control Markup Language, XACML)[58]。這些標準提 供在網際網路上安全交換結構化資訊的詳細說明。
z Web Services 的可靠度
在 Web Services 可靠度的相關議題，Abramowicz [65]等的論文則根據 Provider 跟 Client 兩者不同的觀點，去度量 Web Services 的可靠度。Zo [66]等人 提出一個組合不同 Web Services 以達到服務請求可靠度的度量基礎。由於組合不 同的 Web Services 以達到特定的服務請求，需很明確的選擇不同特定功能的 Web Services 以滿足不同功能需求的工作任務，而在組合不同的 Web Services 時，可 能因所選擇用來滿足不同工作任務的 Web Services 不同，而有所不同的效能或可 靠度。故如何從滿足某一特定功能需求的眾多 Web Services 之中，選定一組 Web Services 完全滿足服務請求並有效好的效能或可靠度是確切重要的。Zo 等人考量 使用者以可靠度作為準則以選擇組合 Web Services。故提出一套運用組合不同的 Web Services 以達到服務請求之可靠度度量基礎，如此使用者可以計算出組合出 的 Web Services 之可靠度為何，進而求得較高可靠度的組合。而 Chan [67]等利 用 Round-robin 及 N-version 兩個方法以達到空間上的冗餘(redundancy)，並採用 請求重試或是服務再啟動以達到時間上的冗餘，利用空間及時間上的冗餘以提供 容錯能力，使得在選擇提供服務的 Web Services 時，能使整個系統可有更好的容 錯以提供一個更高可靠度的系統
3.4 Web Services 組成與 Web Services 整合
即使 Web Services 的領域，被探討研究這麼多年，但由於 Web Services 的功 能有愈來愈複雜的趨勢，不再只是一個單一功能的服務，現行的網路上存在愈來 愈多可行的 Web Services。Web Services 可以很便利的整合從不同的提供者所提
供的服務構成一個新的服務組成，不管提供者服務所在的位置、所使用的平台。
且有愈來愈多的服務組合被發展，通常以被某一個服務提供者用以提供一些常見 的服務，例如搜尋服務。因此，有些學者探討如何將不同的 Web Services 結合起 來[68][69]，整合服務不同需求的 Web Services 以完成較複雜的服務請求，
例如 Cheng 等[68]從使用者的角度出發，讓使用者可以將現有個別的 Web Services 資源視為自己的資源，可以任意去重組並設計這些 Web Services 資源；
讓使用者可以不怕依賴 Web Services 提供者而可自行整合這些服務資源，故提出 Web Services 整合工具(Web Service Integration Tool, WSIT)，將各網站所提供的 功能服務視為一個已存在的 API；利用 WSIT 網路行為記錄功能，將網路服務包 裝成個別流程圖，猶如個別 API；進一步利用 WSIT 的設計功能，對此 APIs 進 行設計與串接，即可產生可重複使用新的 APIs；接下來利用 WSIT 的邏輯設計 功能，將這些個別的 API 整合於使用者想要的邏輯中，使用者便可以不需要熟悉 程式技巧，即可串接不同的 Web Services 模組以成為新的 Web Services。WSIT 工 具提供更方便、更有彈性的方式來組合及串接 Web Services。從與網路伺服器的 溝通、Session 資訊的維護、網路資料擷取、不同 Web Services 串接、到網頁結 構變更的偵測、和例外處理，WSIT 都有完整的功能實作。同時對於使用 WSIT 使用者而言，程式的撰寫是不必要的，使用者只需會使用瀏覽器及有基礎之邏輯 觀念，即可運用 WSIT 工具，發揮想像力即可組合出不同新的 Web Services。
Mohanty 和 Mulchandani [69]提出一個架構，利用有限狀態機(Finial state machine, FSM)的技術，將不同的 Web Services 模組起來，以便完成較複雜的 Web Services 請求。但因實際上，很大或很複雜的 Web Services 可能是需要處理比較 多不同層面上的服務，因此這篇論文亦提出一個正式的遞增方法，針對有限狀態 機的模組再定義一些橫向和階層的組合規則，而且也考量到執行整個模組化的任 務時，可能發生的順序及同步，故亦將時間需求因素加進模組，所提出的方法可 讓一個服務適當改變或延伸以滿足未來更複雜的服務需求。
雖然有不少學者提出一些如何結合不同 Web Services 的方法。但就我們所
知，大部份的論文都在探討如何組合或模組不同的 Web Services 以滿足複雜的服 務請求。而 Lin [39]提出運用一個服務品質代理者來負責協調各別的或組成的 Web Services 的品質。並且有系統地探討兩種不同的組成結構，pipeline 和 DAG 結構。探討這兩種不同的 Web Services 組成結構，並考慮整體服務品質的因素，
如何去選擇比較適合的 Web Services 以完成請求者的服務請求。而本篇論文亦是 主要討論 Web Services 整合問題，運用 Hop 數的觀點來評估整體 Web Services 的品質，並針對 Web Services 的整合，提出獨立順序以及線性順序兩個問題以加 以研究探討。如何整合最少 Web Services Hop 數的 Web Services 集合以加速整體 服務請求的反應時間。
第四章 問題探討說明及系統架構
由於現今 Web Services 的數量不斷劇增，應用領域愈來愈廣，且功能也有愈 來愈複雜的傾向。一個服務請求可能包含著許多個不同功能需求的工作任務，在 此我們將一個工作任務定義為一個多功能的服務請求中必需被滿足完成的單一 功能程序(Functional process)或子服務(Sub-service)。當單一的 Web Services 可能 無法滿足複雜的服務請求時，則需要整合位於網路中不同的數個 Web Services 以滿足服務請求複雜的功能需求，提供使用者更完整的服務請求，是必然的趨 勢。然而經由網路搜尋後，非常有可能會有許多個不同的 Web Services 可提供支 援完成相同功能需求的工作任務(Tasks)。
整合不同的數個 Web Services 成一個新的服務，將不同的工作任務分派給不 盡相同 Web Services 以支援完成該工作任務，進而達到滿足一個包含多樣且複雜 的功能需求的服務請求。其中 Web Services 整合的服務品質(QoS)扮演著相當重 要的準則，而服務品質具有許多不同的特性加以描述，例如回應時間、可靠度、
安全性…等等。本篇論文即是運用 Hop 數來評估完成服務請求的反應時間做為 探討網路服務整合品質的依據。我們希望可以整合一個達到最少 Hop 數的 Web Services，以減少完成服務請求的反應時間。
完成一個服務請求所需要的反應時間，包含了 Web Services 完成工作任務的 計算時間以及不同的 Web Services 在不同的節點用以溝通、傳送相關資料的傳 遞時間。我們舉一個簡單的例子來加以說明。假如使用者發出一個國外旅行服務 的請求，而這個請求需要完成機票訂購、飯店訂房服務以及預約交通工具服務共 三件不同的工作任務，如下圖 4.1 所示，我們整合引用三個不同的 Web Services 來完成所需要三個不同的工作任務。使用者發出服務請求後，將請求訊息發送到 第一個被請求完成工作任務的 Web Services，即機票訂購 Web Services，此時需 要一次的傳遞時間，而在機票訂購 Web Services 完成工作任務後，將請求訊息及 相關資訊，轉達傳送到下一個被請求完成服務任務的 Web Services，即飯店訂房
Web Services，亦需要一次的傳遞時間。相同的，從飯店訂房 Web Services 轉達 請求訊息以預約交通工具 Web Services 請求，此時亦需要一次的傳遞時間。依序 完成所有請求的 Web Services 的工作任務後，將結果回應給使用者亦需要一次的 傳遞時間。所以觀察這個例子，我們可以發現，依順序完成這一個服務請求，我 們一共需要 4 次不同的傳遞時間及 3 個不同的 Web Services 完成不同工作任務的 計算時間。
圖 4.1 多功能 Web Services 請求傳遞時間示意圖
我們定義 Hop 數為不同 Web Services 彼此間需要傳遞資訊的次數，即兩個 位於不同網路節點上的相異 Web Services，彼此之間需要一個 Hop 數來做資訊的 交換作為溝通之用。如下圖 4.2 所示，不同 Web Services 彼此間需要的傳遞時間，
我們可利用 Hop 數來代替。因此，完成此服務請求需要的總 Hop 數為 4。
圖 4.2 多功能 Web Services 請求 Hop 數示意圖
假如我們可以利用相同一個 Web Services，可以完成兩個或兩個以上不同的 工作任務，如下圖 4.3 所示，利用同一 Web Services 來完成飯店訂房工作任務及 預約交通工具兩個工作任務，如此一來即可減少 Hop 數，即減少將服務請求轉 達給其它的 Web Services 所需要通訊時間。而本篇論文主要的目的，即是希望可 以完成一個複雜的服務請求時，需要整合最少 Hop 數的 Web Services 以減少 Web Services 的通訊時間次數，加速整體服務請求的反應時間。
圖 4.3 多功能 Web Services 請求縮減 Hop 數示意圖
4.1
系統架構本篇論文所提出的系統架構圖如下圖 4.4 所示。Web Services 整合系統(Web Services Integration System, WSIS)包含幾個部份：Web Services 整合代理者(Web Services Integration Agent, WSIA)、Web Services 搜尋代理者(Web Services Search Agent, WSSA)以及 Web Services 資料庫(Web Services Database, WSDB)。
當一個服務請求發出需要整合不同的 Web Services 以完成請求時，將整合需 求發送給 WSIS，此整合需求包含所有需要被完成的任務(Tasks)的相關資訊。
WSIA 接收到服務請求後，WSIA 會依接收到的整合需求中取得需要完成的工作 任務清單，並依照該工作任務清單向 WSSA 傳送功能需求；WSSA 根據 WSIA 的需求，從網際網路或 WSDB 中收集可支援需要被完成的任務的 Web Services 資訊，並將收集得到的相關資訊回傳給 WSIA。WSIA 收到 WSSA 者回傳的資訊 後，再利用一些適合的方法或演算法，例如採用本篇提出的 OPT 演算法，決定 所需要被完成的任務分別由那些 Web Services 所完成。WSIA 再回傳經由系統運 用演算法選定要分別要完成任務的 Web Services 相關資訊給服務請求者，服務請 求者得到經由 WSSA 搜尋，WSIA 決策選出的結果，再引用相對應的 Web Services 以完成整個服務請求或工作。
圖 4.4 系統架構圖
由於網路中隨時有可能會有新的 Web Services 動態地被發佈、移除或變更，
除了服務請求者發出的第一次的整合需求而建立的服務整合，有時會因 Web Services 的改變，或是因整合需求變更而造成的任務改變等因素，常使得此整合 需求服務需頻繁地被引用執行。Web Services 整合代理者根據任務之的優先順序 關係的特性而使用不同的對策，進而找出整合的結果再回傳給請求者加以應用。
最後這些應用將直接連結 Web Services 而得到需求的結果。
而 WSSA 的負責的工作，如下圖 4.5 所示，WSSA 利用從 WSIA 傳送過來的 功能需求資訊中，採集出請求 Web Services 的需求資訊，再從 WSDB 或網際網 路中，尋找更完整可滿足完成所有工作任務的 Web Services 清單。此搜尋工作可 被服務請求者使用不同的形式加以具體說明。舉例來說：假設服務請求者說明的 形式為「靜態」，則 WSSA 只從現有的 WSDB 中去尋找媒合條件的 Web Services；
而假設服務請求者說明的形式為「動態」，則 WSSA 將從資源豐富的網際網路 中，尋找更多媒合的 Web Services 資訊，再回傳給 WSIA，並將該尋找出的 Web
Services 資訊儲存在 WSDB 中。如果 Web Services 搜尋處於等待狀況時，即 WSIA 沒有發送需要搜尋代理的指令時，WSSA 可以利用背景作業以更新或增加 WSDB 的資源。
圖 4.5 Web Services 搜尋代理架構
此 WSIS 就某種意義來說，最少需要一個 WSSA 及最少一個 WSIA 來達到 分擔工作量的目的，以便提升統的即時效能。或者使用階層的 Web Services 搜尋 代理子系統或 Web Services 整合代理子系統以取代單一的搜尋代理，亦可達到相 同的功效。
4.2
問題假設本篇論文考量面臨的問題，做了以下三點假設條件：
一、每一個工作任務被完成的計算時間，其影響因素非常多。本篇論文所探討的 問題先不將 Web Services 的計算時間列入考量因素。
二、每一個 Web Services 可利用 SOAP 訊息將服務請求傳遞給下一個需要完成服 務請求的 Web Services。因此，使用者整合不同的 Web Services 以滿足多功 能的需求時，不需要逐一呼叫不同的 Web Services 以完成服務，如此可加速 完成服務請求的反應時間。
三、不同的 Web Services 位在網路上不同的計算機節點上，也就是不同的 Web Services 彼此間的 Hop 數都是 1。且需要網路來讓彼此可以溝通。相同的一 個 Web Services 有可能處理或服務不同且多樣的功能任務。若同一計算機節 點上，同時存在多個不同的 Web Services，則我們將這些位於同一節點上的 不同 Web Services 視為一個可滿足更多功能的 Web Services。
4.3
問題探討本篇論文運用 Hop 數來評估 Web Services 整合的品質，加以探討研究 Web Services 的整合問題(Web Services Integration Problem, WSIP)，本篇論文根據不同 的工作任務相依關係，考量兩個不同的整合 Web Services 的問題。第一個問題是 工作任務彼此之間不具有相對應的先後順序關係，即每一個工作任務彼此獨立，
不會影響其它工作任務的進行，亦不受其他工作任務的影響，只需要將所有的工 作任務完成即可完成該服務請求。本篇論文將此問題定義為獨立 Web Services 整合問題(Independent Web Services Integration Problem, IWSIP)，此問題可利用集 合覆蓋問題(Set Cover Problem, SCP) [70] 的轉化，被證明為 NP-complete，提出 IHGS 演算法以求得解。並進一步與兩種不同的 Heuristics 演算法進行實驗模擬，
加以比較三者的效能。另一個問題是指工作任務彼此之間具有特定的線性順序關 係，即需要按照特定的線性順序逐一被完成。本篇將此問題定義為線性順序 Web Services 整合問題(Linearly Order Web Services Integration Problem, LOWSIP)，本 篇論文亦針對此問題提出一個最佳化演算法以求得一個達到最少 Hop 數的 Web Services 整合。
4.3.1 獨立順序 Web Services 整合問題
本篇論文主要在探討Web Services整合問題，而其中所考量的第一個問題為 獨 立 Web Services 整 合 問 題 (Independent Web Services Integration Problem, IWSIP)，考慮如果需要被完成的工作任務集合中，工作任務彼此之間不具特定的
先後順序關係，換句話說，工作任務不需等待其它的工作任務完成，每一個工作 任務都是彼此獨立的，不影響其它工作任務的進行，亦不受其它工作任務的完成 與否影響，只需要將所有的工作任務都完成即可。在這樣的情況下，當然我們可 以將每一個工作任務都分派給不同的Web Services來完成，在同步運作的情況 下，完成服務的執行時間可以達到最好的效能。但本篇論文並不考慮Web Services 完今各工作任務的計算時間，因此我們只要整合最少數量的Web Services完成所 有的工作，即整合Web Services具達到最少Hop數的目的。找出最少數量的Web Services以滿足所有應用或服務請求的工作任務集合，理論上，本篇論文可以再 進一步利用集合覆蓋問題(Set Cover Problem, SCP) [70] 延伸轉化為獨立Web Services整合問題，證明獨立Web Services整合問題為NP complete。事實上，集合 覆蓋問題乃是Karp的21個NP-complete問題其中之一 [71]為解決集合覆蓋問題，
陸陸續續有許多探索式演算法被提出[72][73][74][75][76][77]。亦有一個近代的探 索式成果，將[78]的概念分析直接應用在解決Test suite最小化問題。SCP的解決 之道是用最少數量的集合可以涵蓋SCP中所有的元素，可對應到IWSIP引用最少 數量的Web Services以滿足完成一個服務所需完成的所有工作任務。如此一來，
SCP便可轉化成IWSIP，因此證明IWSIP亦是一個NP-complete。
定理一、IWSIP屬於NP-complete問題 證明：
1． 證明IWSIP屬於NP問題：IWSIP很明顯的屬於NP，因為給予一組解，可以很 簡單的在多項式時間內驗證這組解可以完成所有工作。
2． SCP可在多項式時間轉化成IWSIP：SCP為用最少數量n個的集合，涵蓋問題 中所有的m個元素，而IWSIP為用最少數量s個的Web Services，完成所有的t 個工作。
i. 有一個函數f，使得SCP中的m個元素轉化成IWSIP中的m個工作任務。所 需 要 的 時 間 為 O(m) ； SCP 的 n 個 集 合 轉 化 為 IWSIP 中 的 n 一 個 Web Services。所需要的時間為O(n)；因此SCP轉化成IWSIP所需的時間為
O(m+n) ，
為多項式時間可計算出的。ii. 函數f(xi
)使得對所有x
i而言， xi屬於SCP的解，則f(xi)屬於IWSIP的解，
i=1~n，反之亦然：若x
1到xn這n個集合的聯集可涵蓋所有的元素，則，x1到xn這n個Web Services聯集可完成所有的工作。反之，x1到xn這n個Web Services的聯絡可完成所有的工作，則x1到xn這n個集合的聯集可涵蓋所有 的元素，故得證。
iii. 因此，我們最後可以得證，SCP可在多項式時間內轉化成IWSIP。
因此，得證獨立Web Services問題為NP-complete問題。
定理二、最小Hop數的WSIP是屬於NP-hard問題。
證明：由於IWSIP是WSIP的子集合。且定理一證明IWSIP為一個NP-complete，所 以最小Hop數的WSIP是屬於NP-hard問題是屬於NP-hard。
4.3.2 IWSIP 的探討與模擬實驗
本篇論文所探討的獨立 Web Services 整合問題乃是引用最少數量的 Web Services 以滿足完成一個服務請求所需要完成的所有工作任務，是為 一 個 NP-complete。本篇論文利用兩個已知的啟發式演算法，Chvatal [74]所提出的 Greedy 演算法，及 Harrold 等[76]所提出 HGS 演算法。這兩個方法，原本是用 於解決 Test Suite 最小化的問題。而在本篇論文中，用以解決獨立 Web Services 整合問題，以求得完成某一特定服務之所有工作任務時，需整合的最小 Web Services 數 量 。 本 篇 論 文 並 改 進 HGS 演 算 法 ， 進 而 提 出 一 個 新 的 方 法 IHGS(Improve HGS)，並實驗模擬加以比較三個演算法的效能。而 Web Services 與工作任務的支援對應關係，根據本篇論文的研究調查，提出四種不同的分佈情 況，進行模擬研究。
Greedy 演算法
如下圖 4.6 所示，為 Chvatal [74]所提出的 Greedy 演算法流程圖。根據 Greedy 演算法，首先是選擇步驟，從所有候選 Web Services (Candidate Web Services)中，
選擇出一個 Next Web Services，在此 Next Web Services 是指下一個選定的 Web Services，該 Web Services 為可以支援未被支援工作任務為最多的 Web Services。
選出 Next Web Services 後。第二步為分派步驟，由此 Next Web Services 去支援 所有可支援的工作任務。分派支援後，再根據剩餘未被支援的工作任務，找出所 有能支援部份或完整未支援工作任務的 Web Services，做為下一次選擇時的候選 Web Services。如此不斷的重複選擇、分派，直到所有的工作任務都被支援為止。
如此可選擇出來近似最少的 Web Services 數量以滿足支援所有需要被完成的工 作任務集合。
圖 4.6
Greedy 演算法流程圖
HGS 演算法
HGS 演算法為 Harrold 等[76]所提出，其流程步驟如下所示。首先計算針對 每一個工作任務，計算出可支援該工作任務的所有 Web Services 的個數，作為考 量的基數(Cardinal Number)。第二步為分派所有基數為 1 的工作任務。基數為 1 表示該工作任務只有一個 Web Services 可以支援，所以必然選擇該 Web Services
來支援。分派完基數為 1 的工作任務後，再考慮基數為 2 的工作任務，找出可以 支援基數為 2 的工作任務中所有的 Web Services，再從這些 Web Services 選出可 以支援最多工作任務的 Web Services，作為候選 Web Services (Candidate Web Services)。若候選 Web Services 只有一個，則選擇該 Web Services 來支援其可支 援的所有工作任務。若候選 Web Services 不只一個，則逐步遞增基數，將考慮基 數更多的工作任務，根據這些工作任務可支援的 Web Services 集合做交集，來減 少候選 Web Services，如此重複遞增基數以減少候選 Web Services，直到選擇出 最適合的 Next Web Services 來支援，Next Web Services 為下一個被選定的 Web Services。最後再依照這些步驟，不斷的重複，直到所有的工作任務都被分派到 Web Services 予以支援為止。
圖 4.7HGS演算法流程圖
IHGS 演算法
觀察上述兩種演算法，在實驗模擬時，我們發現在候選的 Web Services 數量 比較少的情況，HGS 演算法的效能會比 Greedy 好。HGS 演算法主要是考量每一 個 Web Servcies 被選擇的必要性。即可支援同一個工作任務的 Web Services 愈 少，則代表這些 Web Services 的必要性愈重。根據 HGS 演算法，先分派基數為 1 的工作任務，表示該工作任務只有 1 個 Web Services 可以支援，該 Web Services 必定被選擇，而後再考慮基數為 2 及 2 以上的工作任務。
雖然目前現行的 Web Servciese 非常多，但大多數皆是支援單一功能的服 務，可支援多功能的 Web Services 仍為少數，因此，考慮到侯選 Web Servcies 數量少的因素，本篇論文考慮 Web Services 被選擇的必要性，改進 HGS 的演算 法，提出新的 IHGS(Improve HGS)演算法。IHGS 一開始如同 HGS 演算法一樣，
先分派基數為 1 的工作任務。再從可支援的工作任務數比較少的 Web Services 開始考慮，若該 Web Services 可支援的工作任務，亦存在其它 Web Services 可以 支援，即基數為 2 以上，則 IHGS 演算法將移除此支援關係，以降低工作任務的 基數。直到工作任務的基數降成 1，再進行分派。不斷的重覆這些步驟，即可找 出解。其流程如下圖 4.8 所示。先計算針對每一個工作任務，計算出可支援該工 作任務的所有 Web Services 的個數，作為考量的基數(Cardinal Number)。第二步 檢查看是否有基數為一的工作任務，若有，則分派所有基數為 1 的工作任務。基 數為 1 表示該工作任務只有一個 Web Services 可以支援，所以必然選擇該 Web Services 來支援。無基數為 1 的工作任務或分派完基數為 1 的工作任務後，我們 進一步去計算剩餘未被選定的 Web Services 之可支援的工作數。選擇可支援工作 數最少的 Web Services，逐一比較該 Web Services 可支援的工作任務，若該工作 任務基數大於 1，則表示該工作任務尚有其它 Web Services 可以支援，因此移除 此 Web Servcies 與該工作任務的支援關係，以降低工作任務的基數。再去計算檢 查是否有基數為 1 的工作任務，再進行分派。最後再依照這些步驟，不斷的重複，
直到所有的工作任務都被分派到 Web Services 予以支援為止。
