- 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），參考下圖：
其運作流程如下：
- 服務提供者開發 Web Services。
- 服務提供者將 Web Services 佈署至伺服器環境，並且向服務中介者登錄其相關資訊至 UDDI 註冊資料庫中。
- 服務的消費者到 UDDI 註冊資料庫中搜尋所需的服務。
- 服務的消費者在取得 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 可以適用各種用戶端的環境也是可能碰到的問題，當用戶端向你回報錯誤訊息的時候，你是否能在限定的時間內解決問題？需要模擬用戶的作業環境嗎？
牛刀小試
在了解一些基礎概念之後，讓我們來試著練習撰寫一個簡單的範例程式。以往介紹分散式應用程式的撰寫步驟時，通常會先建立伺服器端的程式，然後再建立用戶端程式，這是因為用戶端所需的特定功能往往都沒有現成的，而必須自行撰寫的緣故。所幸 internet 上面已經有不少現成的 Web Services，我們便可以先學習撰寫難度較低的用戶端程式，知道如何使用之後再學習如何撰寫 Web Services。
首先選定要使用的 Web Service，http://www.xmethods.com 上面有不少現成的，我打算用一個叫做 Email Address Verifier 的 Web Service 來做示範，它提供了驗證 MSN、Hotmail、以及 Yahoo 等免費的電子郵件信箱是否有效的服務。這個 Web Service 是以 VisualStudio.NET 開發出來的，這裡我分別以 Delphi 6 和 VisualStudio.NET 7 英文版來說明開發 Web Service 用戶端程式的步驟，您可以看看兩種工具的程式撰寫方式有何異同。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
