(轉)ASP.NET Web 服務如何工作

標籤：

https://msdn.microsoft.com/zh-cn/library/ms996410.aspx發布日期 : 4/1/2004 | 更新日期 : 4/1/2004摘要：瞭解 Microsoft ASP.NET Web 服務方法 (WebMethod) 如何為產生 Web 服務提供一種高效方法。WebMethod 可以將傳統的 Microsoft .NET 方法公開為支援 HTTP、XML、XML 結構描述、SOAP 和 WSDL 的 Web 服務操作。WebMethod (.asmx) 處理常式自動將傳入的 SOAP 訊息調度到相應的方法，並自動將傳入的 XML 元素序列化為相應的 .NET 對象。（20 頁列印頁）Aaron Skonnard DevelopMentor2003 年 5 月適用於：Microsoft? ASP.NET Web 服務方法 SOAP 訊息處理 XML 結構描述 基於 HTTP 的 Web 服務*本頁內容簡介 WebMethod 架構 訊息調度 將 XML 映射到對象 自動產生 WSDL 小結 資源 簡介在 Microsoft? .NET 中，目前有兩種截然不同的方法來實現基於 HTTP 的 Web 服務。第一種同時也是最低級的方法是編寫一個自訂 IHttpHandler 類並將它插入到 .NET HTTP 管道中。這種方法要求您使用 System.Web API 來處理傳入的 HTTP 訊息，使用 System.Xml API 來處理在 HTTP 主體中找到的 SOAP 封裝。編寫自訂處理常式還要求您手動編寫一個精確描述您的實現的 WSDL 文檔。要正確地做好這一切，需要對 XML、XSD、SOAP 和 WSDL 規範有深入的瞭解，但這個先決條件使大多數人望而卻步。實現 Web 服務的一種更高效的方法是使用 Microsoft ASP.NET WebMethod 架構。ASP.NET 為 .asmx 終結點附帶了一個特殊的 IHttpHandler 類（名為 WebServiceHandler），該類提供您所需的可反覆套用的 XML、XSD、SOAP 和 WSDL 功能。由於 WebMethod 架構使您從複雜的基礎 XML 技術中解脫出來，因此您可以將精力迅速集中到手頭的業務問題上。ms996410.howwebmeth_01(zh-cn,MSDN.10).gif圖 1. 靈活性和工作效率之間的折衷在實現技術之間進行選擇就會形成 1 中所示的靈活性和工作效率之間常見的折衷。編寫自訂的 IHttpHandler 會為您提供極大的靈活性，但卻要花大量的時間來編寫、測試和調試代碼。WebMethod 架構使迅速產生和運行 Web 服務變得非常輕鬆，但是您無疑將受到該架構邊界的限制。但是，如果 WebMethod 架構不能完全滿足您的需要，也可以通過添加自己的額外功能來擴充該架構。通常，除非您已經掌握了 XML、XSD、SOAP 和 WSDL，並且願意承擔直接處理它們所帶來的負擔，否則，最好還是使用 WebMethod 架構來滿足您的 Web 服務需要。它提供了大多數 Web 服務終結點所需的基本服務，以及一些使架構更符合您確切需要的有趣的擴充性特點。基於上述假設，本文的其餘部分將討論 WebMethod 的內部工作機制。如果您對 XML 結構描述和 SOAP 不熟悉，則可能需要在繼續閱讀本文之前參閱 Understanding XML Schema 和 Understanding SOAP。返回頁首 WebMethod 架構WebMethod 架構圍繞將 SOAP 訊息映射到 .NET 類上的方法來設計。這通過首先用在 System.Web.Services \命名空間中找到的 [WebMethod] 屬性批註您的方法來完成。例如，下面的 .NET 類包含四種方法，其中的兩種方法用 [WebMethod] 屬性進行批註：using System.Web.Services; public class MathService { [WebMethod] public double Add(double x, double y) { return x + y; } [WebMethod] public double Subtract(double x, double y) { return x - y; } public double Multiply(double x, double y) { return x * y; } public double Divide(double x, double y) { return x / y; } } 要在 WebMethod 架構中使用該類，需要將該類編譯成程式集，然後將它複製到虛擬目錄的 bin 目錄中。在本例中，Add 和 Subtract 方法隨後可被公開為 Web 服務操作，而 Multiply 和 Divide 卻不能（因為它們沒有被標記為 [WebMethod]）。通過 .asmx 終結點將 Add 和 Subtract 公開為 Web 服務操作。為此，要建立一個名為 Math.asmx 且包含以下簡單聲明的文字檔，然後將它放到包含該程式集的同一虛擬目錄中（註：這是放在虛擬目錄本身中，而不是它的 bin 子目錄）：<%@ WebService class="MathService"%>上面的聲明通知 .asmx 處理常式要在哪個類中尋找 WebMethod，該處理常式就會神奇地處理其餘所有事情。例如，假設虛擬目錄的名稱為 ‘math‘，它包含 Math.asmx 以及一個包含該程式集的 bin 子目錄，瀏覽到 http://localhost/math/math.asmx 會導致 .asmx 處理常式產生 2 所示的文檔頁（後面會對此進行詳述）。關於 .asmx 處理常式如何工作有一個很大的變化。.asmx 檔案通常只包含 WebService 聲明，該聲明根據名稱引用 Web 服務類（這與上面顯示的聲明相似）。因此，在本例中，程式集必須已經被編譯和部署到虛擬目錄的 bin 目錄中。對於在 .asmx 檔案中找到的原始碼，.asmx 處理常式還提供Just-In-Time 編譯。例如，下面的檔案（名為 Mathjit.asmx）包含 WebService 聲明以及被引用類的原始碼。<@% WebService class="MathServiceJit" language="C#"%> using System.Web.Services; public class MathServiceJit { [WebMethod] public double Add(double x, double y) { return x + y; } [WebMethod] public double Subtract(double x, double y) { return x - y; } public double Multiply(double x, double y) { return x * y; } public double Divide(double x, double y) { return x / y; } } 當通過 HTTP 首次訪問此檔案時，.asmx 處理常式會編譯原始碼並將程式集部署到正確的位置。請注意，WebService 聲明還必須提供語言，以便 .asmx 處理常式在運行時能夠選擇正確的編譯器。這種方法的明顯缺點是，只有在首次訪問該檔案之後，才會發現編譯錯誤。ms996410.howwebmeth_02(zh-cn,MSDN.10).gif圖 2. MathService 文檔當您在 Visual Studio? .NET 中建立一個 Web 服務項目時，總是使用“雙檔案”技術，即類的源檔案與引用它的 .asmx 檔案是分開的。整合式開發環境 (IDE) 盡量地對檔案進行了隱藏，但是如果您在 Solution Explorer 工具列上單擊 Show All Files，將會注意到該項目中的每個 Web 服務類都有兩個檔案。實際上，Visual Studio .NET 並不支援 .asmx 檔案的文法反白或 IntelliSense?，所以，如果您朝著這個方向設計，則必須依靠自己。對於 Web 項目，Visual Studio .NET 也負責自動建立一個虛擬目錄並將程式集編譯到該虛擬目錄的 bin 目錄中。在詳細討論 .asmx 處理常式如何工作之前，讓我們先簡單討論一下訊息如何從 Internet Information Server (IIS) 傳遞到 .asmx 處理常式。當傳入的 HTTP 訊息到達連接埠 80 時，IIS 使用在 IIS 中繼資料庫中找到的資訊來確定應當使用哪個 ISAPI DLL 來處理訊息。.NET 安裝程式將 .asmx 副檔名映射到 Aspnet_isapi.dll， 3 所示。ms996410.howwebmeth_03(zh-cn,MSDN.10).gif圖 3. .asmx 的 IIS 應用程式對應Aspnet_isapi.dll 是 .NET 架構提供的標準的 ISAPI 副檔名，它只是將 HTTP 要求轉寄到一個名為 Aspnet_wp.exe 的單獨的輔助進程。Aspnet_wp.exe 宿主公用語言運行庫和 .NET HTTP 管道。當訊息進入 .NET HTTP 管道之後，該管道會在設定檔中進行尋找，看對於給定的副檔名應當使用哪個 IHttpHandler 類。如果您在 Machine.config 檔案中進行尋找，則會發現它包含 .asmx 檔案的 httpHandler 映射，如下所示： ... 因此，當訊息進入面向 .asmx 檔案的 .NET HTTP 管道時，該管道會調用 WebServiceHandlerFactory 類，以便執行個體化新的 WebServiceHandler 對象，該對象可用於處理請求（通過調用 IHttpHandlerProcessRequest 方法）。WebServiceHandler 對象隨後開啟物理 .asmx 檔案，以便確定包含 WebMethod 的類的名稱。有關 .NET HTTP 管道如何工作的詳細資料，請查看 HTTP Pipelines:Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET。當 .asmx 處理常式由 .NET HTTP 管道調用之後，它會開始神奇地處理 XML、XSD、SOAP 和 WSDL。由 .asmx 處理常式提供的其餘功能可分成三大類：1) 訊息調度；2) 將 XML 映射到對象；3) 自動產生 WSDL 和文檔。讓我們更詳細地瞭解這些方面。返回頁首 訊息調度當 .asmx 處理常式由 HTTP 管道調用之後，它會通過查看在 .asmx 檔案中發現的 WebService 聲明來確定要檢查哪個 .NET 類。然後，它會查看傳入的 HTTP 訊息中的資訊，以便正確地確定要在被引用類中調用哪種方法。要調用先前樣本中顯示的 Add 操作，傳入的 HTTP 訊息必須具有如下所示的外觀：POST /math/math.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/Add" 33 66 在傳入的 HTTP 訊息中，確實有兩段資訊可用來確定要在該類中調用哪種方法：SOAPAction 頭或請求元素的名稱（例如，soap:Body 元素中元素的名稱）。在本例中，任何一個都指出了發送方想調用的方法的名稱。在預設情況下，.asmx 處理常式使用 SOAPAction 頭的值來執行訊息調度。因此，.asmx 處理常式查看訊息中的 SOAPAction 頭，使用 .NET 反射檢查被引用類中的方法。它只考慮標記了 [WebMethod] 屬性的方法，但是它可以通過查看每種方法的 SOAPAction 值來正確地確定要調用哪種方法。由於我們沒有對類中的方法顯式指定 SOAPAction 值，因此，.asmx 處理常式假設 SOAPAction 值將由 Web 服務的命名空間及其後面的方法名稱組成。而且我們也沒有指定命名空間，因此該處理常式會將 http://tempuri.org 作為預設的命名空間。這樣，Add 方法的預設 SOAPAction 值將是 http://tempuri.org/Add。您可以自訂 Web 服務的命名空間，方法是用 [SoapDocumentMethod] 屬性批註自己的 WebMethod，從而使用 [WebService] 屬性以及正確的 SOAPAction 值來批註自己的類，如下所示：using System.Web.Services; using System.Web.Services.Protocols; [WebService(Namespace="http://example.org/math")] public class MathService { [WebMethod] public double Add(double x, double y) { return x + y; } [WebMethod] [SoapDocumentMethod(Action="urn:math:subtract")] public double Subtract(double x, double y) { return x - y; } ... } 現在，.asmx 處理常式希望 Add 方法的 SOAPAction 值是 http://example.org/math/Add（使用預設試探法），希望 Subtract 方法的 SOAPAction 值是 urn:math:subtract（因為我們將它顯式定義為該值）。例如，下面的 HTTP 要求訊息調用 Subtract 操作：POST /math/math.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "urn:math:subtract" 33 66 如果 .asmx 處理常式未找到與傳入的 HTTP 訊息相匹配的 SOAPAction，則它只是引發一個異常（以後會詳細介紹如何處理異常）。如果您不想依賴 SOAPAction 頭來進行方法調度，則可以用 [SoapDocumentService] 屬性的 RoutingStyle 屬性來批註該類，以便指示 .asmx 處理常式使用請求元素的名稱。如果這樣做的話，可能還應該指出 WebMethod 不需要 SOAPAction 值（通過將它們的值設定為空白字串），如下所示：using System.Web.Services; using System.Web.Services.Protocols; [WebService(Namespace="http://example.org/math")] [SoapDocumentService( RoutingStyle=SoapServiceRoutingStyle.RequestElement)] public class MathService { [WebMethod] [SoapDocumentMethod(Action="")] public double Add(double x, double y) { return x + y; } [WebMethod] [SoapDocumentMethod(Action="")] public double Subtract(double x, double y) { return x - y; } ... } 在本例中，該處理常式甚至不查看 SOAPAction 值，而是使用請求元素的名稱。例如，對於 Add 方法，該處理常式希望請求元素的名稱是 Add（來自 http://example.org/math 命名空間），如下面的 HTTP 要求訊息中所示：POST /math/math.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "" 33 66 因此，當 .asmx 處理常式收到傳入的 HTTP 訊息時，它做的第一件重要事情就是確定如何將該訊息調度到相應的 WebMethod。但是，在能夠實際調用該方法之前，它必須將傳入的 XML 映射到 .NET 對象。返回頁首 將 XML 映射到對象在 WebMehod 處理常式確定了要調用的方法之後，它需要將 XML 訊息還原序列化為可在方法調用過程中提供的 .NET 對象。如同訊息調度一樣，該處理常式通過以下方法來實現上述目標：通過反射來檢查該類，以便確定如何處理傳入的 XML 訊息。XmlSerializer 類在 System.Xml.Serialization 命名空間中自動完成 XML 和對象之間的映射。XmlSerializer 使將任何公用的 .NET 類型映射到 XML 結構描述類型成為可能，在建立了這樣的映射之後，它可以在 .NET 對象和 XML 執行個體文檔之間自動對應（請參閱圖 4）。目前，XmlSerializer 被限制於 XML 結構描述所支援的模型中，因此無法處理當今所有複雜的現代物件模型，例如，複雜的非樹型對象圖、雙重指標等。不過，XmlSerializer 能夠處理開發人員傾向使用的大多數複雜類型。對於上面說明的 Add 樣本，XmlSerializer 會將 x 和 y 元素映射為 .NET 雙精確度值，這些值隨後會在調用 Add 時提供。Add 方法向調用方返回一個雙精確度值，該值隨後將需要重新序列化為 SOAP 響應中的一個 XML 元素。ms996410.howwebmeth_04(zh-cn,MSDN.10).gif圖 4. 將 XML 映射到對象XmlSerializer 還可以自動處理複雜的類型（除了上面描述的限制）。例如，下面的 WebMethod 計算兩個 Point 結構之間的距離：using System; using System.Web.Services; public class Point { public double x; public double y; } [WebService(Namespace="urn:geometry")] public class Geometry { [WebMethod] public double Distance(Point orig, Point dest) { return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) + Math.Pow(orig.y-dest.y, 2)); } } 此操作的 SOAP 請求訊息將包含一個 Distance 元素，該元素中包含兩個子項目，一個叫做 orig，另一個叫做 dest，它們都應當包含 x 和 y 子項目，如下所示： 0 0 3 4 在本例中，SOAP 響應訊息將包含一個 DistanceResponse 元素，該元素包含一個雙精確度類型的 DistanceResult 元素： 5 預設的 XML 映射將方法的名稱用作請求元素的名稱，將參數的名稱用作請求元素的子項目的名稱。每個參數的結構都取決於類型的結構。公用欄位和屬性的名稱只是映射到子項目（在本例中是 Point 中的x 和 y）。在預設情況下，響應元素的名稱是請求元素的名稱後面加上 "Response"。響應元素也包含一個子項目，名稱是請求元素的名稱後面加上 "Result"。您可以通過使用大量的內建映射屬性從標準的 XML 映射中解放出來。例如，可以使用 [XmlType] 屬性來自訂類型的名稱和命名空間。可使用 [XmlElement] 和 [XmlAttribute] 屬性來控制參數或類成員分別映射到元素或屬性的方式。還可以使用 [SoapDocumentMethod] 屬性來控制方法本身如何映射到請求/響應訊息中的元素名稱。例如，使用散佈於下面程式片段中的多種屬性檢查如下版本的 Distance：using System; using System.Web.Services; using System.Web.Services.Protocols; using System.Xml.Serialization; public class Point { [XmlAttribute] public double x; [XmlAttribute] public double y; } [WebService(Namespace="urn:geometry")] public class Geometry { [WebMethod] [SoapDocumentMethod(RequestElementName="CalcDistance", ResponseElementName="CalculatedDistance")] [return: XmlElement("result")] public double Distance( [XmlElement("o")]Point orig, [XmlElement("d")]Point dest) { return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) + Math.Pow(orig.y-dest.y, 2)); } } 這個版本的 Distance 希望傳入具有如下外觀的 SOAP 訊息： 而且，它將產生一個如下所示的 SOAP 響應訊息： 5 .asmx 處理常式使用 SOAP document/literal 樣式來實現和描述上面顯示的預設映射。這意味著該 WSDL 定義將包含用來描述 SOAP 訊息中所使用的請求和響應元素的字面上的 XML 結構描述定義（例如，不使用 SOAP 編碼規則）。.asmx 處理常式還可以使用 SOAP rpc/encoded 樣式。這意味著 SOAP 本文中包含一個 RPC 調用的 XML 表示形式，而且參數都使用 SOAP 編碼規則（例如，不需要 XML 結構描述）進行了序列化。為了實現這個目標，可以使用 [SoapRpcService] 和 [SoapRpcMethod] 屬性，而不使用 [SoapDocumentService] 和 [SoapDocumentMethod] 屬性。有關這些樣式之間的區別的更多資訊，請查看 Understanding SOAP。正如您所看到的一樣，可以完全自訂給定方法映射到 SOAP 訊息的方式。XmlSerializer 提供一個功能強大的序列化引擎，以及許多我們在本文中沒有時間進行討論的功能。有關 XmlSerializer 如何工作的更多資訊，請查看 Moving to .NET and Web Services。在我的每月 MSDN Magazine 的 XML Files 專欄（可在線上封存中查看專欄列表）中，我還介紹了 XmlSerializer 的許多不易察覺的細微差別。除了對參數的還原序列化進行處理以外，.asmx 處理常式還能夠對 SOAP 頭進行還原序列化/序列化。SOAP 頭的處理方法與參數不同，因為它們通常被視為帶外資訊，並未直接關聯到某個特定的方法。因此，SOAP 頭的處理通常是通過偵聽層完成的，從而使得 WebMethod 完全無須對 SOAP 頭進行處理。但是，如果您希望親自處理 WebMethod 中的頭資訊，則必須提供一個從 SoapHeader 派生的 .NET 類，此類代表該頭的 XML 結構描述類型（遵循上面描述的同一映射準則）。然後定義該類型的成員變數，以便讓其充當頭執行個體的預留位置。最後，批註每個需要訪問該頭的 WebMethod，以便指定您想要到達的欄位的名稱。例如，考慮下面的 SOAP 請求，其中包含有一個用於進行身分識別驗證的 UsernameToken 頭： Mary yraM ... 為了使 .asmx 處理常式能夠還原序列化該頭，首先需要定義一個表示隱含的 XML 結構描述類型的 .NET 類（註：如果您實際上已經知道了該頭的 XML 結構描述，則可以使用 xsd.exe /c 來產生該類）。在本例中，相應類的外觀如下所示：[XmlType(Namespace="http://example.org/security")] [XmlRoot(Namespace="http://example.org/security")] public class UsernameToken : SoapHeader { public string username; public string password; } 接著，只需在 WebMethod 類中定義一個用來儲存頭類的執行個體的成員變數，並用 [SoapHeader] 屬性批註 WebMethod，如下所示：using System; using System.Web.Services; using System.Web.Services.Protocols; [WebService(Namespace="urn:geometry")] public class Geometry { public UsernameToken Token; [WebMethod] [SoapHeader("Token")] public double Distance(Point orig, Point dest) { if (!Token.username.Equals(Reverse(Token.password))) throw new Exception("access denied"); return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) + Math.Pow(orig.y-dest.y, 2)); } } 然後，您可以在 WebMethod 中訪問 Token 欄位並提取在該頭中提供的資訊。您也可以使用同樣的方法將頭重新發送到用戶端 — 您只需在 [SoapHeader] 屬性中指定頭的方向。有關在 WebMethod 架構中處理 SOAP 頭的更多資訊，請查看 Digging into SOAP Headers with the .NET Framework。.asmx 處理常式也提供了 .NET 異常的自動序列化。由 .asmx 處理常式捕獲的任何未處理的例外狀況都自動序列化為響應中的 SOAP Fault 元素。例如，在上例中，如果使用者名稱與反轉密碼不匹配，代碼將引發一個 .NET 異常。.asmx 處理常式隨後將捕獲該異常，並將它序列化為 SOAP 響應，如下所示： soap:Server Server was unable to process request. --> access denied 如果您希望對 SOAP Fault 元素進行更多的控制，則還可以顯式引發 SoapException 對象，以便指定所有的 SOAP Fault 元素細節，例如，faultcode、faulstring、faultactor 和 detail 元素。有關更多資訊，請查看 Using SOAP Faults。正如您所看到的一樣，要知曉 WebMethod 如何工作必須瞭解基礎序列化引擎及其各種選項。序列化引擎的好處在於，它隱藏了所有的基礎 XML API 代碼，而在自訂處理常式中，您通常必須編寫這些代碼。儘管多數開發人員發現這很好，但是，有一些開發人員卻認為它是一個缺陷，因為他們仍希望親自處理 WebMethod 實現中的原始 SOAP 訊息。有關如何?這種混合方法的更多詳細資料，請查看 Accessing Raw SOAP Messages in ASP.NET Web Services。返回頁首 自動產生 WSDL在您寫好並部署了 WebMethod 之後，用戶端需要明確知道為了與它成功通訊而必須使 SOAP 訊息具有什麼樣的外觀。提供 Web 服務說明的標準方法是通過 WSDL（以及嵌入的 XSD 定義）進行的。為了協助適應這種情況，.asmx 處理常式自動產生可讀的文檔頁，以及能準確反映 WebMethod 介面的 WSDL 定義。如果您對 WebMethod 應用了許多映射屬性，則它們都會反映在產生的文檔中。如果您瀏覽 .asmx 檔案，將會看到一個 2 所示的可供人工讀取的文檔頁。此文檔頁是由一個名為 DefaultWsdlHelpGenerator.aspx（位於 C:\windows\Microsoft.NET\Framework\ v1.0.3705\config）的 .aspx 頁產生的。如果您開啟這個檔案，將會發現這僅僅是一個標準的 ASP.NET 頁，該頁使用 .NET 反射產生文檔。此功能允許您的文檔總是與代碼保持同步。您只需修改此檔案即可自訂所產生的文檔。還可以通過在 Web.config 檔案中指定一個不同的文檔檔案來避免在虛擬目錄中產生文檔： ... 如果用戶端對 .asmx 終結點發出 GET 請求，而且查詢字串中有 “?wsdl”，那麼，.asmx 處理常式會產生 WSDL 定義，而不產生可供人工讀取的文檔。用戶端可以使用 WSDL 定義來組建代理程式類，這些類可自動瞭解如何與 Web 服務通訊（例如，使用 .NET 中的 Wsdl.exe）。要自訂 WSDL 產生過程，可以編寫一個 SoapExtensionReflector 類，並在 Web.config 檔案中向 WebMethod 架構註冊該類。然後，當 .asmx 處理常式產生 WSDL 定義時，它將調用反射器類，並使您有機會自訂向用戶端提供的最終定義。有關如何編寫 SoapExtensionReflector 類的更多資訊，請查看 SoapExtensionReflectors in ASP.NET Web Services。您還可以使用兩種不同的方法來完全跳過 WSDL 產生過程。第一種方法是，在虛擬目錄中提供一個可供用戶端訪問的靜態 WSDL 文檔，然後通過將文檔產生器從 Web.config 檔案中刪除來禁用它，如下所示： ... 另一種自動化程度較之稍高的方法是，使用 [WebServicesBinding] 屬性來指定由 WebMethod 類實現的靜態 WSDL 文檔在虛擬目錄中的位置。您還必須使用 [SoapDocumentMethod] 屬性為每個 WebMethod 實現的 WSDL 綁定指定名稱。這樣做之後，WSDL 的自動產生過程將匯入靜態 WSDL 檔案，並在它周圍封裝一個新的服務說明。有關此方法的更多資訊，請查看標題為 Place XML Message Design Ahead of Schema Planning to Improve Web Service Interoperability 的文章。目前，因為仍沒有太多可用的 WSDL 編輯器，所以手工編寫 WSDL 是極其困難的。因此，文檔/WSDL 的自動產生是 WebMethod 架構中很有價值的一部分，沒有它，許多開發人員的日子會很難過。返回頁首 小結ASP.NET WebMethod 架構為產生 Web 服務提供了一種高效的方法。WebMethod 架構使得傳統的 .NET 方法公開為支援 HTTP、XML、XML 結構描述、SOAP 和 WSDL 的 Web 服務操作。WebMethod (.asmx) 處理常式自動確定如何將傳入的 SOAP 訊息調度到相應的方法，以及何時將傳入的 XML 元素自動序列化為相應的 .NET 對象。而且，為了簡化與用戶端的整合，.asmx 處理常式還為產生人可讀取的 (HTML) 和機器可讀取的 (WSDL) 文檔提供自動支援。儘管與自訂的 IHttpHandler 相比，WebMethod 架構稍微有些限制，但是它還是提供了一個功能強大的擴充性模型，即所謂的 SOAP 延伸模組架構。SOAP 延伸模組允許您引入我們上面沒有討論到的額外功能來滿足您的具體需要。例如，Microsoft 發布了 Web Services Enhancements 1.0 for Microsoft .NET (WSE)，WSE 只提供一個 SoapExtension 類，該類為 WebMethod 架構引入了對幾個 GXA 規範的支援。有關編寫 SOAP 延伸模組名的更多資訊，請查看 Fun with SOAP Extensions。返回頁首 資源Accessing Raw SOAP Messages in ASP.NET Web Services（Tim Ewald）。Digging into SOAP Headers with the .NET Framework（Matt Powell）。Fun with SOAP Extensions（Keith Ballinger）。HTTP Pipelines:Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET（Tim Ewald 和 Keith Brown）。Moving to .NET and Web Services（Don Box）。Place XML Message Design Ahead of Schema Planning to Improve Web Service Interoperability（Yasser Shohoud）。SoapExtensionReflectors in ASP.NET Web Services（Matt Powell）。Understanding SOAP（Aaron Skonnard）。Using SOAP Faults（Scott Seeley）。Understanding XML Schema（作者是 Aaron Skonnard）。MSDN Magazine 中的 XML Files 專欄索引（Aaron Skonnard）。

(轉)ASP.NET Web 服務如何工作