webServices與Web服務

本篇的內容在MSND中標註已經是一項舊技術，而取而代之的是WCF，

那麼我也放棄吧！可是這個屬於Web服務的範疇，而WCF本質上也是一個Web服務來的，因此對於基礎的東西仍是不變的。那麼此次就着重看看這個Web服務的基礎知識。

首先仍是形式上的列舉一下webServices配置節的內容，儘管它如今沒用了，在WCF當中配置用的是system.serviceModel。

   

webservice的三要素：

SOAP（Simple Object Access Protocol）、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration)之一， soap用來描述傳遞信息的格式， WSDL 用來描述如何訪問具體的接口， uddi用來管理，分發，查詢webService 。具體實現能夠搜索 Web Services簡單實例 ; SOAP 能夠和現存的許多因特網協議和格式結合使用，包括超文本傳輸協議（HTTP），簡單郵件傳輸協議（SMTP），多用途網際郵件擴充協議（MIME）。它還支持從消息系統到遠程過程調用（RPC）等大量的應用程序。SOAP使用基於XML的數據結構和超文本傳輸協議(HTTP)的組合定義了一個標準的方法來使用Internet上各類不一樣操做環境中的分佈式對象。

   

   

XML Web services 是一個能提供特定功能元素（例如應用程序邏輯）的可編程實體，可供使用通用 Internet 標準（例如 XML 和 HTTP）的任意數目的潛在獨立系統訪問。XML Web services 主要依賴普遍接受 XML 及其餘 Internet 標準來建立支持應用程序互操做性的基礎結構，其支持級別解決了之前妨礙這類嘗試的不少問題。

XML Web services 能夠由單個應用程序在內部使用，也能夠經過 Internet 在外部公開以供任意數目的應用程序使用。因爲 XML Web services 可經過標準接口進行訪問，所以 XML Web services 容許多個異構系統做爲單個計算網絡協同工做。

XML Web services 並不追求代碼可移植性的通常功能，而是提供了一種實現數據和系統互操做性的可行解決方案。XML Web services 使用基於 XML 的消息做爲數據通訊的基本方式，以幫助減小組件模型、操做系統和編程語言不一致的系統之間的差異。開發人員能夠在建立應用程序時糅合來自各類來源的 XML Web services，其方式與他們之前在建立分佈式應用程序時使用組件的方式大同小異。

XML Web services 的核心特色之一是，服務的實現和使用之間存在高度的抽象。經過將基於 XML 的消息用做服務的建立和訪問機制，XML Web services 客戶端和 XML Web services 提供程序只要相互知道輸入、輸出和位置，就不用再瞭解任何其餘信息了。

XML Web services 爲分佈式應用程序開發開創了一個新時代。這裏再也不有對象模型衝突，也無需比較編程語言的美觀程度。在使用專有基礎結構緊密耦合系統時，是以犧牲應用程序的互操做性來實現的。XML Web services 在全新的層次上提供互操做性，令這些妨礙效率的對手黯然失色。做爲 Internet 的下一個革命性成果，XML Web services 將成爲連接起全部計算設備的基礎結構。

若想在複雜的網絡中順利執行，XML Web services 必須不受所選用的操做系統、對象模型和編程語言的影響。另外，若想讓 XML Web services 像其餘基於 Web 的技術那樣受到普遍採用，就必須知足下列條件：

• 鬆耦合：若是對兩個系統所施加的惟一要求是瞭解上述基於文本的自述消息，則這兩個系統將被視爲鬆耦合。相反，緊密耦合的系統在進行通訊時會消耗大量的自定義開銷，並須要兩個系統之間加強了解。
• 無所不在的通訊：目前或不久的未來，人們所構建的操做系統通常都可以鏈接到 Internet，從而提供一個無處不在的通訊渠道。所以，若是具有這種幾乎可以將任何系統或設備鏈接到 Internet 的能力，便可確保這類系統和設備可普遍地供任何鏈接到 Internet 的其餘系統或設備使用。
• 通用的數據格式：經過對專用的閉環通訊方法採用現有的開放標準，任何支持相同開放標準的系統都可以瞭解 XML Web services。經過利用 XML Web services 及其客戶端無需知道每一個基礎系統的構成便可共享的自述性文本消息，能夠在獨立系統與其餘系統之間進行通訊。XML Web services 即是使用 XML 來實現此功能。

   

XML Web services 使用的基礎結構提供下列內容：用於查找 XML Web services 的發現機制、用於定義服務用法的服務說明以及通訊所使用的標準連網格式。下面的插圖顯示了這種基礎結構的一個示例。

XML Web services 目錄

   

與 Internet 上的任何其餘資源同樣，要在不使用一些搜索方式的狀況下找到某個特定的 XML Web services 幾乎是不可能的。XML Web services 目錄提供了多箇中心位置，XML Web servicers 提供方能夠在那裏發佈有關他們所提供的 XML Web services 的信息。這類目錄甚至能夠是 XML Web services 自己，能夠經過編程方式來訪問，它們經過響應來自潛在的 XML Web services 客戶端的查詢來提供搜索結果。可能有必要使用 XML Web services 目錄找到爲了某種特定目的而提供 XML Web services 的組織或者肯定某個特定組織所提供的 XML Web services。UDDI（通用描述、發現和集成）規範定義了一種發佈和發現 XML Web services 相關信息的標準方式。與 UDDI 關聯的 XML 架構定義了四種類型的信息，經過這些信息開發人員可使用已發佈的 XML Web services。它們是：業務信息、服務信息、綁定信息和有關服務規範的信息。

XML Web services 發現

XML Web services 發現是指查找（即發現）一個或多個用 Web 服務描述語言 (WSDL) 描述特定 XML Web services 的相關文檔的過程。正是經過發現過程，XML Web services 客戶端才瞭解到存在 XML Web services 以及在何處查找 XML Web services 的說明文檔。

已發佈的 .disco 文件是一個 XML 文檔，其中包含描述 XML Web services 的其餘資源的連接，於是可以實現以編程方式發現 XML Web services。下面演示發現文檔的結構示例：

由上面的發現文檔內容看出有三個URL，其中有兩個是同樣的http://www.contoso.com/Counter.asmx，剩下一個是http://www.contoso.com/Counter.asmx?wsdl，看它的屬性感受是前者是文檔的地址，後者纔是服務的地址，可是根據在我以往使用的配置中發現不帶wsdl的纔是服務地址，並且WSDL正是web service三要素中的web服務描述語言的縮寫，感受後者纔是文檔的地址。

例以下面就是某個WCF服務的WSDL

那麼它不帶WSDL的就是發現地址，感受就是UDDI

   

注意：發現文檔是一個元素容器，其中的元素一般包含一些指向資源的連接 (URL)，這些資源提供 XML Web services 的發現信息。若是 URL 是相對的，則認爲它們相對於發現文檔的位置。

可是，實現 XML Web services 的網站並不須要支持發現。另外一個網站能夠負責描述該服務，例如 XML Web services 目錄。另外，可能不存在查找該服務的公共方式。例如在建立供專門使用的服務時，就會出現這種狀況。

XML Web services 說明

XML Web services 基礎結構所依據的通訊方式是基於 XML 且符合已發佈的服務說明的消息。服務說明是用稱爲 WSDL（Web 服務描述語言）的 XML 語法編寫的 XML 文檔，用於定義 XML Web services 可以識別的消息格式。服務說明的做用就至關於協議，它定義 XML Web services 的行爲，並指示潛在客戶端如何與該服務交互。XML Web services 的行爲由該服務定義和支持的消息模式決定。這些模式從概念上指示，在將格式正確的消息提交給 XML Web services 時，服務使用方能夠指望出現哪些行爲。

例如，與遠程過程調用 (RPC) 樣式服務關聯的請求/響應模式會定義將使用何種 SOAP 消息架構來調用特定的方法。此模式還會定義隨後的響應 SOAP 消息應遵循哪一種格式。

又如，還有一種消息模式表示單向交互。在進行單向通訊時，就會使用這種模式。在這種狀況下，發送方將不會接收到來自 XML Web services 的任何消息，包括錯誤消息。須要注意的是，若是創建單向通訊時使用的協議採用傳統的請求/響應模式，則可能會返回錯誤消息。

定義 SOAP 消息格式的架構能夠在實際服務說明的內部定義，也能夠在外部定義好後再導入到服務說明中。

除了消息格式定義和消息模式外，服務說明還能夠包含與每一個 XML Web services 入口點關聯的地址。此地址的格式應當與用於訪問服務的協議相對應，例如 HTTP 的 URL 或 SMTP 的電子郵件地址。

有關 WSDL 規範，請參見 W3C 網站 (http://www.w3.org/TR/wsdl)。

XML Web services 連網格式

DCOM 等二進制協議包括一個駐留在專有通訊協議之上的方法請求層。這類協議不適合建立通用的 XML Web services。然而，這不會阻止您在 XML Web services 方案中使用這類協議，但使用這類協議的缺點是它們依賴於其基礎系統的特定體系結構，於是限制了潛在客戶端的範圍。

或者，您能夠構造使用一個或更多開放式協議（如 HTTP 和 SOAP 協議的組合）的 XML Web services。支持不一樣的協議所必需的基礎結構各不相同。

XML Web services 不限於提供遠程過程調用 (RPC) 訪問。還能夠生成 XML Web services，用來交換採購訂單和發票等結構化信息，以及用於自動化和鏈接內部及外部業務流程。

HTTP-GET 和 HTTP-POST

HTTP-GET 和 HTTP-POST 是標準協議，它們使用 HTTP（超文本傳輸協議）謂詞對參數進行編碼並將參數做爲名稱/值對傳遞，還使用關聯的請求語義。每一個協議都包括一系列 HTTP 請求標頭，HTTP 請求標頭及其餘一些信息定義客戶端向服務器請求哪些內容，哪一個服務器用一系列 HTTP 響應標頭和所請求的數據進行響應（若是成功）。

HTTP-GET 使用 MIME 類型 application/x-www-form-urlencoded（將追加處處理請求的服務器的 URL 中）以 URL 編碼文本的形式傳遞其參數。URL 編碼是一種字符編碼形式，可確保傳遞的參數中包含一致性文本，例如將空格編碼爲 %20。追加的參數也稱爲查詢字符串。

與 HTTP-GET 相似，HTTP-POST 參數也是 URL 編碼的。可是，名稱/值對是在實際的 HTTP 請求消息內部傳遞的，而不是做爲 URL 的一部分進行傳遞。

SOAP

SOAP 是一種簡單的基於 XML 的輕量協議，用於在 Web 上交換結構化信息和類型信息。SOAP 的整體設計目標是使其儘可能簡單，並提供最低限度的功能。該協議定義一個不包含應用程序或傳輸語義的消息傳遞框架。所以，該協議是模塊化的且高度可擴展。

經過在標準傳輸協議之上傳輸，SOAP 可使用 Internet 的現有開放式體系結構，而且容易被可以支持最基本的 Internet 標準的任意系統所接受。能夠將支持符合 SOAP 的 XML Web services 所必需的基礎結構看做是一種很是簡單且強大的基礎結構，由於它向 Internet 的現有基礎結構添加相對較少的內容，但仍然有助於對用 SOAP 生成的服務進行通用訪問。

SOAP 協議規範包括四個主要部分。第一部分定義用於封裝數據的必需的可擴展信封。SOAP 信封定義 SOAP 消息，是 SOAP 消息處理程序之間的基本交換單位。這是該規範中惟一的一個必需部分。

SOAP 協議規範的第二部分定義了可選的數據編碼規則和一個統一模型，數據編碼規則用來表示應用程序定義的數據和有向圖，統一模型用來序列化非語法數據模型。

第三部分定義 RPC 樣式（請求/響應）消息交換模式。每一個 SOAP 消息都是單向傳輸。雖然 SOAP 的根位於 RPC 中，但它並不侷限於成爲一種請求/響應機制。XML Web services 一般組合 SOAP 消息以實現這類模式，但對於 SOAP 而言消息交換模式並非必需的，而且這一部分規範也是可選的。

規範的第四部分定義 SOAP 與 HTTP 之間的綁定。可是，這部分也是可選的。能夠將 SOAP 與任何能夠傳輸 SOAP 信封的傳輸協議或機制結合使用，其中包括 SMTP、FTP，甚至還包括軟盤。

   

有關 SOAP 規範，請參見 W3C 網站 (http://www.w3.org/TR/ soap)。

使用 SOAP 與 Web 服務方法進行通訊遵循標準格式。此格式的一部分是在 XML 文檔中編碼的數據。XML 文檔包含一個 Envelope 根元素，該元素又由必需的 Body 元素和可選的 Header 元素構成。Body 元素由特定於消息的數據構成。可選的 Header 元素能夠包含不與特定消息直接相關的其餘信息。Header 元素的每一個子元素都被稱爲 SOAP 標頭。

儘管 SOAP 標頭能夠包含與消息相關的數據，但因爲 SOAP 規範並未嚴格定義 SOAP 標頭的內容，所以其中一般包含 Web 服務器內由基礎結構處理的信息。SOAP 標頭的用法示例是在 SOAP 標頭內爲 SOAP 消息提供路由信息。

   

來自 <https://msdn.microsoft.com/zh-cn/library/77hkfhh8.aspx>

   

在以前提供的web服務中看到了某個方法的SOAP內容，以下

看這段就知道該web服務使用的是HTTP協議，請求的時候是用了POST方法，xml格式 utf-8字符編碼，post內容就是那對xml，固然length,string都是一些佔位符，這麼說來或許我也能夠試試本身拼一個HTTP POST請求過去，看可否獲取到對應的內容。這些格式都是有前面的WSDL發現的。.NET Framework內部都把這些操做所有封裝起來，若是要嘗試的話大能夠本身寫個程序從發現WSDL走起（固然.disco文件我如今也沒見到，不知如何獲取並解析），拿到它的WSDL，而後解析成SOAP（或者直接請求得到SOAP？？？），創建起一些代理類，在代理類內部經過HTTP請求把調用代理方法的參數拼裝到HTTP請求中，看可否獲得對應的響應，若是有響應了按照SOAP把結果解析出來，造成代理方法的返回。可是響應及返回這塊也涉及到以前WSDL中說到的消息交互的模式（如單向）。但目前我對WSDL的瞭解不足以實現這個。

   

這是本系列的最後一篇。

   

參考文章

webServices 元素（ASP.NET 設置架構）

來自 <https://msdn.microsoft.com/zh-cn/library/ms228319(VS.85).aspx>

   

<webServices> 元素

來自 <https://msdn.microsoft.com/zh-cn/library/cs8x2624.aspx>

   

   

XML Web services 基礎結構

來自 <https://msdn.microsoft.com/zh-cn/library/sd5s0c6d(v=vs.100).aspx>

   

使用 SOAP 標頭

來自 <https://msdn.microsoft.com/zh-cn/library/77hkfhh8.aspx>