Scott部落格

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

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

若以技術的角度來看為什麼需要 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）的優點，但是它有以下缺點：

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

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

為了解決這些問題，Web Services 便應運而生。它具有以下特點：

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

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

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

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

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

前面多次提及 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 埠的緣故。

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

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

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

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

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

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

其運作流程如下：

面對一項新的技術，在瞭解它的優點及學習如何應用該項技術的同時，也必須注意可能伴隨該項技術而來的問題，以免將技術用錯了地方或者太晚發現決策的錯誤。因此這裡摘要地列出一些應用 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 可以適用各種用戶端的環境也是可能碰到的問題，當用戶端向你回報錯誤訊息的時候，你是否能在限定的時間內解決問題？需要模擬用戶的作業環境嗎？

轉貼於 原文