ASP.NET建立Web服務之XML基礎結構

asp.net|web|web服務|xml|建立 　　為了在網路多樣性方面取得成功，XML Web服務必須不關心所選擇的作業系統、物件模型和程式語言。而且，XML Web服務為了和其他基於Web的技術一樣被廣泛接受，它們必須：

　　 鬆散耦聯：如果兩個系統中，只有使用的命令能理解前面提到過的自我描述基於文本的訊息，那麼這兩個系統就被認為是鬆散耦聯的。而另一方面，緊密耦聯的系統使用大量的定製的軟體來增強系統間的通訊，並且需要對系統之間瞭解的更多。

　　 無所不在的通訊：現在個人不太可能能夠構造一個作業系統，或者在近期內也不會整合接入網際網路的能力，所以這就要求提供一個無所不在的通訊渠道。同樣，把幾乎任何系統和裝置串連到網際網路的能力將確保這樣的系統和裝置能夠被串連到網際網路的其他的系統或裝置使用。

　　 通用的資料格式：通過採用現有的開放標準而不是專用的閉環式通訊方法，任何系統都能支援能夠理解XML Web服務的相同的開放標準。使用自我描述的基於文本的訊息，XML Web服務和它們的客戶可以共用這些訊息，而不必知道每個底層系統的組成，這將能夠在獨立的完全不同的系統之間通訊。XML Web服務使用XML來實現這個功能。

　　XML Web服務使用一個提供下列功能的基礎結構：一個發現機制,用於定位XML Web服務；一個服務描述，用於定義如何使用這些服務；以及用來通訊的標準串連格式。下列插圖顯示了這個基礎結構的一個執行個體。

XML Web服務基礎結構

基礎結構塊	職能
XML Web服務類別目錄	XML Web服務類別目錄提供一個中央地址，用於定位其他組織提供的XML Web服務。象UDDI登記這樣的XML Web服務類別目錄實現這個職能。XML Web服務的用戶端可以引用XML Web服務類別目錄，也可以不引用XML Web服務類別目錄。
XML Web 服務發現	XML Web服務發現是使用Web服務描述語言（WSDL）定位或發現一個或多個描述特別的XML Web服務的相關文檔。DISCO規格定義了定位服務描述的規則。如果XML Web服務客戶瞭解服務描述的位置，他們可以繞過發現步驟。
XML Web服務描述	為了瞭解如何與一個特定的XML Web服務互動作用，需要提供一個描述來定義XML Web服務支援的互動操作。XML Web服務用戶端在可以使用一個XML Web服務之間必須瞭解如何與它互動。
XML Web服務串連格式	為了能夠進行通用通訊，XML Web服務使用開放串連格式來進行通訊，這些是任何支援最普通的Web標準的系統都能夠理解的協議。SOAP是用於進行XML Web服務通訊的關鍵協議。

　　 XML Web服務類別目錄

　　和使用網際網路上任何其他的資源一樣，XML Web服務類別目錄如果沒有某些尋找方法的話，它是不可能夠找到一個特定的XML Web服務的。XML Web服務類別目錄提供了中央地址，可以讓XML Web服務供應者在其上發布他們提供的XML Web服務的資訊。這樣的目錄甚至可以是XML Web服務本身，可以編程訪問並且提供搜尋結果來響應XML Web服務用戶端的查詢。使用一個XML Web服務類別目錄來定位一個提供XML Web服務作為特定目的的組織，或者判斷一個特定組織提供了什麼XML Web服務，這可能是非常必要的。

　　UDDI（統一描述發現和整合規範）規格定義了一個標準方法來發布和發現XML Web服務的資訊。與UDDI關聯的XML模式定義了四個資訊類型，能讓開發人員使用一個發布的XML Web服務。這些是：商業資訊、服務資訊、綁定資訊和其他用於服務的規範的資訊。

　　作為UDDI工程的核心組件，UDDI Business Registry（業務登記）允許業務編程定位其他組織發布的XML Web服務的資訊。開發人員可以使用UDDI Business Registry來定位發現檔案和服務描述。更多資訊，請看UDDI Web網站（http://uddi.microsoft.com）。

　　XML Web服務發現

　　XML Web服務發現是使用Web服務描述語言WSDL定位或發現一個或多個描述特定的XML Web服務的檔案的操作。它讓XML Web服務用戶端得知一個XML Web服務是否存在並且到哪裡找到這個XML Web服務的描述檔案。

　　一個發布的.disco檔案，是包含串連到其他描述XML Web服務的資源的XML檔案，能夠編程發現一個XML Web服務。下面的代碼給出了一個發現檔案的結構的例子：

＜?xml version="1.0" encoding="utf-8" ?＞ ＜discovery xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.xmlsoap.org/disco/"＞ ＜contractRef ref="http://www.contoso.com/Counter.asmx?wsdl" docRef="http://www.contoso.com/Counter.asmx" xmlns="http://schemas.xmlsoap.org/disco/scl/" /＞ ＜soap address="http://www.contoso.com/Counter.asmx" xmlns:q1="http://tempuri.org/" binding="q1:CounterSoap" xmlns="http://schemas.xmlsoap.org/disco/soap/" /＞ ＜/discovery＞

　　注意：發現文檔是一個元素容器，一般包含到提供用於XML Web服務的發現資訊的資源的連結。如果關聯的是URL，它們假定關聯到發現文檔的位置。

　　然而，一個實現XML Web服務的Web網站不必支援發現。另一個網站可以負責描述這個服務，例如一個XML Web服務類別目錄。沒有一種公用的方法用來探索服務，例如當你建立一個私人使用的服務時。

　　XML Web服務描述

　　XML Web服務基礎結構建立在使用遵循一個公布的服務描述的基於XML的訊息的通訊的基礎上。服務描述是一個使用WSDL語言的XML文法編寫的XML文檔，定義了XML Web服務能理解的XML Web服務訊息格式。服務描述起一個協定的作用，用來定義一個XML Web服務的行為並且指示潛在的客戶如何與之互動。XML Web服務的行為取決於服務定義和支援的訊息類型。這些模式在概念上指示了服務使用者在相應格式的訊息被發送到XML Web服務時可以期待什麼。

　　例如，與遠端程序呼叫（RPC）風格的服務關聯的請求/響應模式將定義哪個SOAP訊息模式用來調用一個特定的方法。這個模式還將定義響應SOAP訊息將遵循的格式。

　　訊息模式的另一個例子表示單方面的互動操作。這個模式在單向通訊發生的時候被使用。在這種情況下，發送方不會從XML Web服務中接收任何訊息，包括故障訊息。 定義SOAP訊息格式的模式可以在內部定義來進行實際的服務描述，它們也可以在外部定義並被匯入服務描述。

　　除了訊息格式的定義和訊息模式以外，服務描述還可選擇性的包含每個XML Web服務進入點的地址。這個地址的格式對應於用於訪問服務的協議，例如URL對應於HTTP或者電子郵件地址對應於SMTP（簡單郵件傳送協議）。

　　更多WSDL規格的資訊，請看W3C Web網站（http://www.w3.org/TR/wsdl）。

　　XML Web服務串連格式

　　象DCOM那樣的二進位協議由一個去掉專有的通訊協定的頂部的方法請求層組成。這樣的協議對建立普遍可用的XML Web服務沒有協助。這麼說並不是說阻止你們在XML Web服務方案中使用這樣的協議，但是使用它們的缺點在於這樣的協議依靠它們的底層系統的特定結構，因此限制了潛在客戶的增加。

　　取而代之，你可以構造XML Web服務來協同一個或多個開放協議一起工作，就象HTTP和SOAP的綜合使用一樣。象你所料想的那樣，基礎結構要求支援不同的協議。

　　XML Web服務不局限於提供遠端程序呼叫訪問。它們還可以被構造來交換結構化的資訊，例如採購訂單和發貨單，並且還可用於自動化和串連內部與外部的業務處理。

　　HTTP-GET和HTTP-POST

　　HTTP-GET和HTTP-POST是使用HTTP的標準協議動詞，用於編碼和傳送變數名/變數值對參數，並且使用相關的請求語義。每個HTTP-GET和HTTP-POST都由一系列HTTP要求標頭組成，這些要求標頭定義了用戶端從伺服器請求了什麼，而響應則是由一系列HTTP應答頭和應答資料群組成，如果請求成功則返回應答。

　　HTTP-GET以使用MIME類型application/x-www-form-urlencoded的urlencoded文本的格式傳遞參數。Urlencoding是一種字元編碼，保證被傳送的參數由遵循規範的文本組成，例如一個空格的編碼是"%20"。附加參數還能被認為是一個查詢字串。

　　與HTTP-GET類似，HTTP-POST參數也是被URL編碼的。然而，變數名/變數值不作為URL的一部分被傳送，而是放在實際的HTTP請求訊息內部被傳送。

　　SOAP簡介

　　SOAP是一個簡單的、重量輕的基於XML的協議，用於交換Web上的結構化的和模式化的資訊。SOAP的總體設計目標是使它保持儘可能的簡單，並且提供最少的功能。這個協議定義了一個不包含應用程式或傳輸語義的訊息架構。因此，這個協議是模組化的並且非常利於擴充。
通過越過標準傳輸協議，SOAP能利用網際網路現有的開放體繫結構，並且能夠被任何支援最基本的網際網路標準的系統所接受。通過越過標準傳輸協議，SOAP能利用網際網路現有的開放體繫結構，並且能夠被任何支援最基本的網際網路標準的系統所接受。你可以看到，基礎結構要求支援一個雖然簡單但是功能強大的遵從SOAP的XML Web服務，因為它基本不向現有的網際網路基礎結構中添加新的內容，然而卻有助於訪問SOAP構造的服務。

　　SOAP協議規範由四個主要的部分組成。第一部分定義了一個強制的可擴充信封（envelope）用於封裝資料。SOAP信封定義了一條SOAP訊息和在SOAP資訊處理器之間交換的基本單元。這是這個規格唯一的強制性的部分。

　　SOAP協議規範的第二部分定義了可選資料編碼規則用於表示應用程式定義的資料類型和直接圖表，以及一個用於序列化非文法資料模型的統一模型。

　　第三部分定義了一個遠端程序呼叫風格（請求/響應）資訊交換的模式。每個SOAP訊息都是單向傳輸。雖然SOAP的根源於RPC，但是它不局限於請求/響應機制。XML Web服務經常聯合SOAP訊息來實現這樣的模式，但是SOAP並不必須使用資訊交換模式，並且規格的這個部分是可選的。

　　這個規格的第四部分定義了SOAP和HTTP之間的綁定。然而，這個部分還是可選的。你可以讓SOAP和任何轉送協議或機制一起協同使用，這些傳送協議能夠傳送SOAP信封，包括SMTP、FTP甚至一個磁碟片。

　　更多SOAP規格的資訊，請看W3C Web網站（http://www.w3.org/TR/soap）。