Web Services 入門

我發現技術教程的特色每每是，用更多的名詞來解釋一個名詞，以致於讓徹底陌生的初學者一個名詞也弄不懂。最近想學習一下 Web Services，上網看了許多文章，仍是感受雲裏霧裏，就沒有一篇能徹底用通俗的語言來解釋明白。直到我發現下面這篇相對淺顯的文章。謝謝做者的文章！

原帖請見：http://sun.cis.scu.edu.tw/~nms9115/articles/delphi/WebServices/WebServices1.htm

 

什麼是 Web Services？

平臺中立的網路服務

Web Services 是一種平臺中立的網路服務，應用程式能夠透過 URL 指定存取 internet 上任何一臺電腦提供的服務，無論對方的電腦是什麼做業平臺或應用程式的類型，雙方只要遵循標準的協定就能夠溝通。

分散式應用程式的基石（building blocks）

基於其平臺中立的特性，軟體開發人員能夠將設計好的 Web Services 公佈在 internet 上供其餘應用程式使用，其餘的開發人員則能夠重複使用這些現有的服務來建構分散式應用程式，而無須花時間從新設計相同功能的軟體元件。

Web Services 使得「軟體即服務」的觀念更容易落實，同時也意味著分散式架構所涵蓋的範圍將更廣。

為什麼要有 Web Services？

前面已經大略點出，Web Services 基於其平臺中立以及 internet 無遠弗屆的特性，將可提升軟體元件的重複使用率，這是它的好處之一，除此以外，我們還能夠從企業的需求以及技術面兩種角度來探討為什麼須要 Web Services。

企業的需求

早期企業對企業之間的資料交換是以 EDI（Electronic Data Interchange，電子資料交換）達成，但由於 EDI 多為昂貴的專屬系統，使用特定的協定與資料格式，所以維護成本較高，擴充也不容易。隨著網際網路的興盛，具備高度開放性的架構、協定、及資料格式便大受歡迎，例如：TCP/IP，HTML，XML....等，並且促成了一波企業對客戶（B2C），企業對企業（B2B）的電子商務熱潮。而在 B2B 方面則逐漸造成了電子交易市集（eMarketplace）的商務模式，此模式由第三方提供一個交易場所（網站），讓各商家在此地進行交易，資料輸入仍以人工做業為主，以目前各行業競爭之激烈，速度可說是勝負的關鍵，若是能夠將人工輸入資料的方式改爲電腦之間自動交換資料就能夠大幅縮短企業間溝通及資料交換的時間，進而提昇企業的競爭力與反應速度。集各項公開標準於一身的 Web Services 正好符合這個需求。

由此觀之，也能看出 Web Services 的另外一項特點：把以往使用者與應用程式的互動的情景，轉變成應用程式與應用程式之間的互動。

現有技術的不足

若以技術的角度來看為什麼須要 Web Services，能夠先看看現有的分散式架構有何不足。目前大多數的分散式應用系統都是以遠端程序呼叫（Remote Procedure Call，RPC）的方式存取另外一臺電腦上的服務，例如：Microsoft 的 Distributed Component Object Model（DCOM），Sun 的 Remote Method Invocation（RMI），OMG 的 Common Object Request Broker Architecture（CORBA） 等，這些以 RPC 為基礎的分散式架構提供了開發人員熟悉的程式撰寫方式（函數呼叫）以及位置透明化（location transparency）的優點，可是它有如下缺點：

• 緊密耦合。用戶端與伺服器程式之間要規定詳細的呼叫方式，並且用戶端得事先知道如何存取這些服務的相關細節（例如函式有哪些參數及其型態），伺服器這邊稍有改變可能就會令用戶端無法執行。
• 只能同步執行（synchronous calls）。用戶端呼叫伺服器的某個程序時，必須等該程序執行完畢之後才能繼續其餘動做，期間使用者能作的只有等待。儘管可使用多執行緒的技巧來解決，但卻增長了程式的複雜度，程式也比較難撰寫。

當應用程式須要以非同步的方式執行工做時，便衍生出另外一種所謂的訊息導向的架構，例如：Microsoft 的 MSMQ，IBM 的 MQSeries 等。有別於 RPC 的程序呼叫方式，這種架構使用非同步訊息傳遞的機制，訊息送出後用戶端即可以繼續執行其餘工做，訊息保證會送達目的地，至於何時送達則不確定，這是它最大的特點，而其缺點為：

• 先收到的訊息先處理（佇列），無法提供特定工做流程（workflow）的執行順序。
• 程式設計師必須處理訊息封包的包裝、解讀與驗證，是一項不輕的負擔。
• 各家廠商提供的解決方案彼此不相容。

不論是 RPC 還是訊息導向的架構，它們都有一個共同的缺點，就是會跟特定的做業環境或軟體綁在一塊兒，並且各種產品使用不一樣的傳輸協定或資料格式，使得彼此不能相互溝通。另外，DCOM、RMI、CORBA 等二進位協定一般會被防火牆擋在外面，使外界無法直接存取企業內部的資訊服務，若要讓它們能夠穿過防火牆，網管人員就必須在牆上打洞，如此勢必引發網路安全的問題，這也是現有的分散式架構中一個比較讓人頭痛的地方。

為瞭解決這些問題，Web Services 便應運而生。它具備如下特點：

• 寬鬆的（loosely-coupled）分散式架構。
• 平臺中立，與實做（開發工具、程式語言）無關。
• 無狀態（stateless）。
• 提供同步與非同步的程序呼叫。
• 容易穿越防火牆。

但並不是說 Web Services 就能夠徹底取代傳統的分散式技術，只能說各有其適用的時機吧，在評估要使用哪一種技術來開發應用程式時，除了瞭解技術自己的優缺點，也要確實瞭解應用程式的需求及環境的限制，纔不會發生以尖端科技製造無用軟體的情形。

Web Services 是如何運做的？

Web Services 要能運做，首先必須解決的問題是：

1. 應用程式如何透過 internet 遂行遠端程序呼叫，並且不用知道對方的做業環境及應用程式型態？
2. 用戶端程式如何知道怎樣使用某個 Web Service？或者說，如何得知該服務的介面（提供哪些方法呼叫）？
3. 當應用程式須要某種特定的功能時，怎麼知道網路上已經有人提供這類功能的 Web Services？到哪裡找到這些 Web Services？

第一個問題的答案是須要一個標準的訊息格式以即可以順利在各平臺之間傳遞。第二個問題則須要一個描述 Web Services 的文件，用戶端能夠透過解讀這個文件來瞭解如何使用它。第三個問題能夠透過一個描述的答案則是要有一個類似目錄服務的機制，提供外界查詢現有的 Web Services。

Web Services 有三個重要的元素能夠解決上述問題，它們是：

• SOAP - 傳遞訊息的格式
• WSDL - 描述服務的內容
• SOAP Discovery - 尋找有哪些服務

也有人稱它們為 Web Services 三劍客，如下再個別進一步地說明。

SOAP

前面屢次說起 Web Services 是平臺中立的，這不僅指做業系統，連網站伺服器的品牌、應用程式的類型都沒有特別限定，例如用戶端的做業環境是 Windows 2000 + IIS，而執行 Web Services 的做業環境是 Linux + Apache。要符合這些條件，就必定要有一套標準的協定才行，這個標準協定就是 Simple Object Access Protocol（SOAP）。

SOAP 是架構在 HTTP 之上的物件存取協定，也就是說透過 HTTP 來傳遞訊息，而訊息的內容則是以 XML 格式來描述。當用戶端程式須要呼叫一個遠端物件的方法時，能夠把這項要求封裝成 SOAP 呼叫傳遞給遠端的 Web Services，當 Web Services 收到了用戶端的請求便去執行其指定的方法，並且在執行完畢之後傳回結果。所以也能夠說 SOAP 就是 internet 上面的 RPC。

相較於傳統的 RPC，SOAP 不可是個被業界所支援的公開標準，還具備容易穿透防火牆的優點，使遠端程序呼叫得以順利跨越不一樣的網域。SOAP 之能夠順利穿透防火牆，是由於其搭載的純文字訊息是透過 HTTP 協定來傳輸，而大部分的企業網路的防火牆都會開放 HTTP 使用的 80 埠的緣故。

WSDL

當你在網路上找到一個 Web Service，你如何知道要怎樣使用它？它提供了什麼服務？有哪些方法能夠呼叫？要傳遞哪些參數？這些問題的答案就是 WSDL（Web Service Description Language）。

WSDL 是一份以 XML 撰寫的文件，附檔名就是 .WSDL，其主要的用途是「描述 Web Services」，也就是讓用戶端知道如何使用 Web Services。WSDL 的文件內容也有一個共同的標準，以便與各種用戶端應用程式相互整合，此標準是由 IBM 與 Microsoft 共同研擬。

若是你瞭解 COM 的話，WSDL 的做用就等同於 COM 的 IDL（Interface Difinition Language）或 type library。

Web Service Discovery（又稱為 Disco）

WSDL 是在你已經確定要使用某個 Web Service 並且知道其網址的情形下才有用，萬一你不知道哪裡有你須要的 Web Services 怎麼辦？例如，你的應用程式現在要加入一項功能，能夠讓使用者輸入特定關鍵字找尋相關的 MP3 檔案的下載網址，這時候你要去哪裡找這類 Web Services？

Disco 的用途就在這裡，就像電話簿和搜尋引擎網站一樣，提供資訊分類以及尋找的服務，讓你能夠方便快速地找到你須要的 Web Services。

其運做原理是，當開發人員將一個 Web Service 設計完成之後，能夠將它登錄到一個集中的地方，其餘人就能夠向這個集中地查詢找到須要的服務。這個登錄－查詢的機制只要就是依靠 UDDI（Universal Description, Discovery and Integration）來達成。

Web Services 的架構

將 XML，SOAP，WSDL，UDDI 這些核心元素組合起來，就能夠造成一個 Web Services 架構，架構中包含了三種主要的角色，分別是 Web Services 的提供者（provider），消費者（consumer），與介於兩者之間的中介者（broker），參考下圖：

其運做流程以下：

1. 服務提供者開發 Web Services。
2. 服務提供者將 Web Services 佈署至伺服器環境，並且向服務中介者登錄其相關資訊至 UDDI 註冊資料庫中。
3. 服務的消費者到 UDDI 註冊資料庫中搜尋所需的服務。
4. 服務的消費者在取得 Web Services 的相關資訊後就可使用該服務。

可能面臨的挑戰

面對一項新的技術，在瞭解它的優點及學習如何應用該項技術的同時，也必須注意可能伴隨該項技術而來的問題，以避免將技術用錯了地方或者太晚發現決策的錯誤。所以這裡摘要地列出一些應用 Web Services 時可能遭遇的挑戰以玆參考，內容摘自 Graham Glass 的文章「The Web services (r)evolution, Part 1」。

可靠性

若是本來提供 Web Services 的伺服器掛掉了，用戶端該如何應變？是否可能以其餘廠商提供的 Web Services 暫時替代？這個替代品的功能和使用方式是否跟本來的 Web Services 徹底相同？

安全性

在網路上傳遞敏感資料時須要將資料加密處理，HTTP 配合 SSL 能夠提供基礎的安全防護，可是對一些須要對個人身分進行驗證與授權的場合就不夠用了，此時 Web Services 要作到什麼程度纔算安全？是否須要在每個方法呼叫中傳遞及驗證使用者的身分？效率與安全的平衡點在哪裡？

交易處理

以往的分散式應用程式使用兩段式交付（two-phase commit）的方式完成分散式交易，這種方式在企業內部網路的環境下處理短時間的交易沒有什麼問題，可是若是拿到網際網路的開放環境下就窒礙難行了，因為一個交易啟動之後，也許要經過數天之後交易才完成，啟動交易的做業是否要一直等待直到全部參與交易的做業都成功後才確認完成整個交易？實際上不可能這樣作。所以 Web Services 在分散式交易的處理上目前仍有待努力，目前 Microsoft 提出了補償交易的方案（XLANG），而 W3C 則還沒有針對此問題制定相關的標準。

經營模式

你的 Web Services 要如何收費？收取年費還是用多少算多少？你如何預防用戶將帳號密碼告訴其餘人以共享存取你的 Web Services？

除錯

由於每個用戶端所執行的做業系統及環境可能不一樣，所以如何確保你的 Web Services 能夠適用各種用戶端的環境也是可能碰到的問題，當用戶端向你回報錯誤訊息的時候，你是否能在限定的時間內解決問題？須要模擬用戶的做業環境嗎？