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 服務（英文）主頁。
SOAPSoap 是 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 的成長，還將進一步推選 滿足上述須要以及其他須要的規范。