什么是 XML Web Service 2008-09-10 11:33

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 的發展，還將進一步介紹滿足上述需要以及其他需要的規范。 不夸張地說，XML正在接管這個世界，正在成為今天一切Web服務和大多數SOA的基礎。XML本身并非一種技術，而是程序設計語言，可支持開發者為Web信息設計自己的標簽。如此一來，Web信息便可被XML應用共享。 目前，我們已看到了XML流域的洶涌波濤： ● 微軟發布了其Office的下一個版本，代碼名稱為Office 12，XML將成為其固有的文件格式。所有.ppt、.doc.xls后綴的文件都將消失。這些“缺省的”XML文件格式可作為WordprocessingML和SpreadsheetML的擴展格式，可以和Office 2000以上版本的二進制文件互操作。 ● 英特爾收購了Sarvega，這是XML交換的一個早期支持者。Sarvega 為了能夠有效地處理、加速、安全維護XML流量而開發出了自己的操作系統。這次收購將讓英特爾的產品線繼承Sarvega處理XML流量的優勢。 ● 思科于今年6月發布了AON(面向應用網絡)平臺。AON是一個真正的應用交換平臺，不僅可支持XML，而且可支持非XML的網絡應用，如數據庫應用、語音、視頻、文件共享和及時消息等。 ● 一些企業，如Datapower和Reactivity以他們的XML設備、網絡及軟件產品繼續在為XML加油。我們看到XML產品從服務器、刀片到軟件已應有盡有。 業界一直在談論應用交換是XML交換的自然進展，應用交換最終會被路由器廠商吞吃掉，然而實際情況卻是路由器廠商在其系統中增加了XML交換，英特爾開發了XML加速和安全軟件，微軟在把一些文檔轉換成XML格式，換句話說XML交換已經出現，應引起大家注意。 XML的問題是要找出誰在這個市場上。看看上述實例，你會看到有WAN廠商、軟件商和芯片制造商都在同一個方向上努力。 那么，企業應如何做呢?軟件和應用方面的變化還沒有什么，但網絡方面的變化的確應該引起關注。需要對XML交換的影響，如加速和安全等進行評估。在企業中，XML文件已超出了部門的范圍，財務部門開始執行政府的XML格式規范，甚至連銷售部門也開始與合作伙伴以及渠道商玩起了XML模板。這些線索表明企業必須要及早地研究相應的對策了。 企業需要做出許多體系架構上的決策，比如是否需要采用通用服務器及其軟件(現在也包括了英特爾)、服務器應用(Sarvega)、高端應用服務器(IBM、BEA)、專用芯片和嵌入式子系統(DataPower、Tarari)、網絡設備(思科、DataPower)，甚至外包。 趕緊考察一下SOA吧。現在就與最流行的技術接觸，了解清楚你的企業中哪里是XML的弱點，準備讓你的企業與XML共同成長。 資料引用:http://www.knowsky.com/347709.html

轉載于:https://blog.51cto.com/youxue/345335

總結

以上是生活随笔為你收集整理的什么是 XML Web Service的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。