XML Web Service 是在Internet 上進行分散式運算的基本建構塊。開放的標準以及對使用者和應用程式之間的通訊和協作的關注產生了這樣一種環境，在這種環境下，XML Web Service 成為應用程式整合的平台。應用程式是透過使用多個不同來源的XML Web Service 建構而成的，這些服務相互協同工作，而不管它們位於何處或如何實現。
有多少個建置XML Web Service 的公司，就可能有多少種XML Web Service 定義。不過幾乎所有定義都有以下共同點：
XML Web Service 透過標準的Web 協定向Web 使用者提供有用的功能。多數情況下使用SOAP 協定。
XML Web Service 可以非常詳細地說明其介面，這使用戶能夠建立客戶端應用程式與它們進行通訊。這種說明通常包含在稱為Web 服務說明語言(WSDL) 文件的XML 文件中。
XML Web Service 已註冊，以便潛在用戶能夠輕易地找到這些服務，這是透過通用發現、說明和整合(UDDI) 來完成的。
本文將介紹這三種技術，但首先需要解釋為什麼要關注XML Web Service。
XML Web Service 體系結構的主要優點之一是：允許在不同平台上、以不同語言編寫的各種程式以基於標準的方式相互通訊。對這一行業有所了解的用戶可能馬上會說：「等一等，CORBA 和之前的DCE 不是都做過相同的承諾嗎？這和它們有什麼區別？」最重要的區別在於：SOAP 比以前的方法要簡單得多，因此要實現與標準相容的SOAP，障礙也要少得多。 Paul Kulchenko 在http://www.soapware.org/directory/4/implementations （英文）提供了一個SOAP 實作方案的清單。上次統計時，該清單已經包含了79 項。正如您所預料，多數大的軟體公司都提供SOAP 實現方案，但也有許多實現方案是由個別開發人員創建和維護的。相對先前的方案而言，XML Web Service 的另一個優點是使用標準的Web 協定- XML、HTTP 和TCP/IP。許多公司都已經建立了Web 基礎架構，同時它們的員工在維修方面也都具備相應的知識和經驗。因此，引入XML Web Service 與引入先前的技術相比，其成本要低得多。
我們將XML Web Service 定義為：透過SOAP 在Web 上提供的軟體服務，使用WSDL 檔案進行說明，並透過UDDI 進行註冊。那麼，您也許要問：「使用XML Web Service 能夠做什麼？」最初的XML Web Service 通常是可以方便地併入應用程式的資訊來源，如股票價格、天氣預報、體育成績等等。我們很容易想到，可以建立一整類應用程式以分析和匯總所關心的信息，並以各種方式提供這些資訊；例如，您可以使用Microsoft® Excel 電子表格來匯總所有的財務資訊- 股票、401K 、銀行存款、貸款等等。如果能夠透過XML Web Service 取得這些訊息，Excel 就可以不斷地對其進行更新。這些資訊中有些是免費的，有些則可能需要訂閱才能獲得相應服務。大部分這種資訊現在已經可以在Web 上找到了，但是XML Web Service 可以讓程式存取更簡單，也更可靠。
以XML Web Service 方式提供現有應用程序，可以建立新的、更強大的應用程序，並利用XML Web Service 作為構造塊。例如，用戶可以開發一個採購應用程序，以自動獲取來自不同供應商的價格信息，從而使用戶可以選擇供應商，提交訂單，然後跟踪貨物的運輸，直至收到貨物。而供應商的應用程式除了在Web 上提供服務外，還可以使用XML Web Service 檢查客戶的信用、收取貨款，並與貨運公司辦理貨運手續。
未來，某些最有趣的XML Web Service 所支援的應用程式還可以利用Web 完成目前無法完成的任務。例如，日曆服務就是Microsoft .NET My Services（英文）專案即將支援的服務之一。如果您的牙醫和機械師透過這XML Web Service 提供其日程安排，您就可以透過網路與他們安排約會；如果您願意，他們也可以直接在您的日曆上約定清潔和日常保養的日期。不難想像，只要能夠對Web 進行編程，您就可以創建數以百計的應用程式。
有關XML Web Service 及其可以建立的應用程式的詳細信息，請參閱MSDN Web 服務（英文）主頁。
SOAP
Soap 是XML Web Service 的通訊協定。當把SOAP 描述為一種通訊協定時，多數人都會想到DCOM 或CORBA，並且會問「SOAP 如何啟動物件？」或「SOAP 使用什麼樣的命名服務？」等問題。雖然SOAP 實作方案可能會包含上述內容，但SOAP 標準並未對其進行規定。 SOAP 一種規範，用來定義訊息的XML 格式- 這是規範中所必需的部分。包含在一對SOAP 元素中的、結構正確的XML 區段就是SOAP 訊息。這是不是很簡單？
SOAP 規範的其他部分介紹如何將程式資料表示為XML，以及如何使用SOAP 進行遠端過程呼叫(RPC)。這些可選的規範部分用於實現RPC 形式的應用程序，其中客戶端將發出一條SOAP 訊息（包含可調用函數，以及要傳送到該函數的參數），然後伺服器將返回包含函數執行結果的訊息。目前，多數SOAP 實作方案都支援RPC 應用程序，這是因為習慣於開發COM 或CORBA 應用程式的程式設計人員熟悉RPC 形式。 SOAP 也支援文件形式的應用程序，在這類應用程式中，SOAP 訊息只是XML 文件的包裝。文件形式的SOAP 應用程式非常靈活，許多新的XML Web Service 都利用這項特點來建立使用RPC 難以實現的服務。
SOAP 規範的最後一個可選部分定義了包含SOAP 訊息的HTTP 訊息的樣式。此HTTP 結合非常重要，因為幾乎所有目前的OS（以及許多先前的OS）都支援HTTP。 HTTP 綁定雖然是可選的，但幾乎所有SOAP 實作方案都支援HTTP 綁定，因為它是SOAP 的唯一標準協定。由於這一原因，人們通常誤認為SOAP 必須使用HTTP。其實，有些實作方案也支援MSMQ、MQ 系列、SMTP 或TCP/IP 傳輸，但由於HTTP 非常普遍，幾乎所有目前的XML Web Service 都使用它。由於HTTP 是Web 的核心協議，因此大多數組織的網路基礎結構都支援HTTP，並且員工已經了解如何對其進行管理。如今，已經建立了用於HTTP 的安全保護、監視和負載平衡的基礎結構。
開始使用SOAP 時，最容易混淆的是SOAP 規範及其許多實作方案之間的差異。多數使用SOAP 的使用者並不會直接編寫SOAP 訊息，而是使用SOAP 工具包來建立和分析SOAP 訊息。這些工具包通常將函數呼叫從某種語言轉換為SOAP 訊息。例如，Microsoft SOAP Toolkit 2.0 將COM 函數呼叫轉換為SOAP，而Apache Toolkit 將JAVA 函數呼叫轉換為SOAP。函數呼叫的類型和支援的參數的資料類型隨每個SOAP 實作方案的不同而不同，因此適用於一個工具包的函數可能並不適用於另一個工具包。這並不是SOAP 的限制，而是所使用的特定實現方案的限制。
到目前為止，SOAP 最引人注目的特徵是它可以在許多不同的軟體和硬體平台上實現。這意味著SOAP 可用於連結企業內部和外部的不同系統。過去曾試過多種方法以提出一個可用於系統整合的通用通訊協議，但它們都沒有像SOAP 一樣獲得廣泛的認可。為什麼呢？因為與許多早期的協議相比，SOAP 更小巧，而且更容易實現。例如，DCE 和CORBA 的實作需要數年時間，所以只發布了很少幾個實作方案。而SOAP 可以利用現有的XML 分析器和HTTP 函式庫完成大部分艱苦的工作，因此SOAP 實作方案在數月內便可完成。這就是為什麼現在已經有70 多個SOAP 實作方案的原因。當然，SOAP 並不具備DCE 或CORBA 的全部功能，雖然功能減少了，但由於其複雜程度大大降低了，因此SOAP 更易於應用。
HTTP 的普及性和SOAP 的簡單性使您幾乎可以從任何環境中呼叫它們，因此成為XML Web Service 的理想基礎。有關SOAP 的詳細信息，請參閱MSDN SOAP（英文）主頁。
安全性如何？
通常，剛接觸SOAP 的使用者提出的第一個問題就是SOAP 如何解決安全性問題。在其早期開發階段，SOAP 被視為基於HTTP 的協議，所以認為HTTP 的安全性對於SOAP 已經足夠了。畢竟目前有數以千計的Web 應用程式都在使用HTTP 安全性，所以這對SOAP 確實已經足夠。因此，目前的SOAP 標準假定安全性屬於傳輸問題，而並非以安全性問題處理。
當SOAP 擴展至更為通用的協議，並運行於眾多傳輸之上時，安全性問題就變得突出了。例如，HTTP 提供若干種方法對進行SOAP 呼叫的使用者進行身份驗證，但是當訊息從HTTP 路由到SMTP 傳輸時，如何傳播該身份識別呢？ SOAP 是作為構造塊協定進行設計的，所以幸運的是，已經有了相應的規範以基於SOAP 為Web 服務提供額外的安全保護功能。 WS-Security 規範（英文）定義了一套完整的加密系統，而WS-License 規範（英文）定義了相應的技術，以保證呼叫者的身份標識，並確保只有授權使用者才可以使用Web 服務。
WSDL
WSDL (Web Services Description Language) 表示Web 服務說明語言。在本文中，我們可以認為WSDL 文件是一個XML 文檔，用於說明一組SOAP 訊息以及如何交換這些訊息。換句話說，WSDL 對於SOAP 的作用就像IDL 對於CORBA 或COM 的作用。由於WSDL 是XML 文檔，因此很容易進行閱讀和編輯；但大多數情況下，它是由軟體產生和使用。
若要查看WSDL 的值，可以假設您要呼叫由您的一位業務夥伴提供的SOAP 方法。您可以要求對方提供一些SOAP 訊息範例，然後編寫您的應用程式以產生並使用與範例類似的訊息，但這樣很容易出錯。例如，您可能會看到一個2837 的客戶ID，並假設它為整數，而實際上它是一個字串。 WSDL 透過明確的表示法指定請求訊息必須包含的內容以及回應訊息的樣式。
WSDL 檔案用於說明訊息格式的表示法以XML 架構標準為基礎，這意味著它與程式語言無關，而且以標準為基礎，因此適用於說明可從不同平台、以不同程式語言存取的XML Web Service接口。除說明訊息內容外，WSDL 還定義了服務的位置，以及使用什麼通訊協定與服務進行通訊。也就是說，WSDL 檔案定義了編寫使用XML Web Service 的程式所需的全部內容。有幾種工具可以讀取WSDL 文件，並產生與XML Web Service 通訊所需的程式碼。其中一些最強大的工具可在Microsoft Visual Studio® .NET 中找到。
目前，許多SOAP 工具包都包含從現有程式介面產生WSDL 檔案的工具，但卻幾乎沒有直接用於編寫WSDL 的工具，而且WSDL 的工具支援也很不完整。但不久就會出現編寫WSDL 檔案的工具，接著還會有產生代理和存根的工具（與COM IDL 工具很相似），這些工具將成為多數SOAP 實作方案的一部分。到那時，WSDL 將成為建立XML Web Service 的SOAP 介面的首選方法。
這裡有一個非常好的WSDL 說明（英文），您也可以在http://www.w3.org/TR/wsdl （英文）找到WSDL 規格。
UDDI
通用發現、說明和整合(UDDI) 是Web 服務的黃頁。與傳統黃頁一樣，您可以搜尋提供所需服務的公司，閱讀以了解所提供的服務，然後與某人聯繫以獲得更多資訊。當然，您也可以提供Web 服務而不在UDDI 中註冊，就像在地下室開展業務，依靠的是口頭吆喝；但是如果您希望拓展市場，則需要UDDI 以便能被客戶發現。
UDDI 目錄條目是介紹所提供的業務和服務的XML 檔案。 UDDI 目錄條目包括三個部分。 「白頁」介紹提供服務的公司：名稱、地址、聯絡方式等等；「黃頁」包括基於標準分類法（例如North American Industry Classification System 和Standard Industrial Classification）的行業類別；「綠頁」詳細介紹了存取服務的接口，以便使用者能夠編寫應用程式以使用Web 服務。服務的定義是透過一個稱為類型模型（或tModel）的UDDI 文件來完成的。多數情況下，tModel 包含一個WSDL 文件，用於說明存取XML Web Service 的SOAP 接口，但是tModel 非常靈活，可以說明幾乎所有類型的服務。
UDDI 目錄還包含若干種方法，可用於搜尋建立您的應用程式所需的服務。例如，您可以搜尋特定地理位置的服務提供者或搜尋特定的業務類型。之後，UDDI 目錄將提供資訊、聯絡方式、連結和技術數據，以便您確定能滿足需要的服務。
UDDI 可讓您尋找提供所需的Web 服務的公司。如果您已經知道要與誰進行業務合作，但尚不了解它還能提供哪些服務，這時該如何處理呢？ WS-Inspection 規範（英文）可讓您瀏覽特定伺服器上提供的XML Web Service 的集合，從中尋找所需的服務。
有關UDDI 的詳細信息，請訪問http://www.uddi.org/about.html （英文）。
其他內容
到現在為止，我們已經討論瞭如何與XML Web Service 通訊(SOAP)，XML Web Service 是如何進行說明的(WSDL)，以及如何尋找XML Web Service (UDDI)。這些內容構成了一套基本規範，為應用程式的整合和聚合提供了基礎。根據這些基本規範，公司可以建立實際的解決方案，並從中獲益。
為實作XML Web Service，我們已經做了許多工作，但仍有大量工作需要完成。今天，人們已經使用XML Web Service 取得了成功，但對於開發人員來說，仍有許多環節需要改進。例如，安全性、營運管理、事務處理以及可靠的訊息傳遞等。 Global XML Web Services Architecture 將透過以下方式協助XML Web Service 進入下一個發展階段：提供一個一致的通用模型，以模組化和可擴充的方式為XML Web Service 新增新的進階功能。
上述的安全模組（WS-Security [英文] 和WS-License [英文]）就是Global Web Services Architecture 規範的一部分。營運管理的需求（例如在多個伺服器之間路由訊息，以及動態配置這些伺服器以便進行處理）也是Global Web Services Architecture 的一部分，它們是透過WS-Routing 規範（英文）和WS-Referral 規範（英文）來實現的。隨著Global Web Services Architecture 的發展，也將進一步介紹符合上述需求以及其他需求的規格。