文章目錄
- Summary
- Introduction
- WebMethods架構
Summary
ASP.NET Web Service方法(WebMethods)怎樣為建立Web服務提供一種高效的解決方案呢。WebMethods使傳統的Microsoft.NET方法成為Web服務作業,它支援HTTP、XML、XML Schema、SOAP和WSDL。WebMethods(.asmx)控制代碼將到來的SOAP訊息派送給適當的方法,並將到來的XML元素序列化為對應的.NET對象。
Introduction
當今在Microsoft.NET中實現基於HTTP的Web服務有兩種根本不同的方法。第一種也是較低級的一種技術是編寫一個定製的IhttpHandler類並把它嵌入到HTTP管道中。這種方法要求你使用System.web API處理到來的HTTP訊息,用System.Xml API處理HTTP訊息體中的SOAP封裝(envelope)。編寫一個定製的控制代碼同樣也需要你手工編寫WSDL文檔,準確的描述實現過程。做到這一切要求對XML、XSD、SOAP和WSDL規範有深入的瞭解,但這對大多數人來講都是讓人望而卻步的先決條件。
實現Web服務的一種更高效的方法是使用Microsoft ASP.NET的WebMethods架構。ASP.NET為.asmx終節點(叫作WebServiceHandler)裝載了一個專門的IhttpHandler類,它為你的需要提供了XML、XSD、SOAP和WSDL的功能性樣板。因為WebMethod架構使你從底層XML技術的複雜性中解脫出來,可以將精力集中到一些緊要的業務問題。
Figure 1. Tradeoff between flexibility and productivity
選擇一種實現技術涉及到在靈活性和高效性之間的權衡,1所示。一個定製的IhttpHandler有很大的靈活性,但卻要花費大量的時間來編寫、測試和調試代碼。WebMethods架構使構建和運行Web服務變得異常輕鬆,不過很明顯你將被限制在架構的界線裡。不過,如果WebMethods架構不能正確的滿足你的需要,也可通過填加你自己的功能來擴充架構。
總的來講,除非你已經掌握了XML、XSD、SOAP和WSDL並且願意承受直接處理它們的負擔,最好還是使用WebMethods架構來實現你的Web服務需要。它提供了大多數Web服務終點需要的基本服務,還有一些擴充屬性使構架更適合你的具體需要。基於此假設,文章的餘下部分我們將討論WebMethods的內部工作機制。
WebMethods架構
WebMethods架構通過在方法開始處標記[WebMethods]屬性,將SOAP訊息映射到一個.NET類的方法,[WebMethods]可以在System.Web.Service名稱空間中找到。比如下面的.NET類包括四個方法,其中的兩個被標註了[WebMethods]屬性。
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; }}要在WebMethods架構中使用這個類,需要把它編譯成一個assembly並拷貝到虛擬目錄的bin子目錄下。在這個例子中,Add和Subtract方法被作為Web服務作業,而Multiply和Divide卻不能。(因為它們沒有被標記為[WebMethods])
你可以通過一個.asmx終節點來訪問Add和Subtract Web服務作業:建立一個文字檔Math.asmx,它包含下面的簡單聲明,然後把它放到包含assembly的同一個虛擬目錄下(注這裡是虛擬目錄本身,而不是它的bin子目錄)
<%@ WebService class="MathService"%>
這個聲明告訴.asmx控制代碼去哪個類中尋找WebMethods,餘下的就由控制代碼全全處理。比如,假設虛擬目錄叫作“math”,它包含了Math.asmx,它的bin子目錄下包含了assembly,瀏覽http://localhost/math/math.asmx時.asmx控制代碼將產生圖2中的文檔頁。
Figure 2. MathService documentation
關於.asmx控制代碼如何工作有一個主要的變化。.asmx檔案通常只包含了WebService的聲明,根據名字引用相應的Web服務類。因此,在這種情況下,assembly必須已經被編譯並且部署到虛擬目錄的bin子目錄中。.asmx控制代碼也提供了對.asmx檔案原始碼的即時編譯(just-in-time compilation),比如下面的檔案就既包括了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控制代碼編譯源碼並將assembly部署到相應位置。注意WebService聲明必須提供語言以使.asmx控制代碼在運行時能選擇正確的編譯器。這種方法明顯的劣勢就是直到第一次訪問這個檔案的時候你才會發現它的編譯錯誤。
當你在Visual Studio.NET中建立一個新的Web Service項目時,通常使用“雙檔案”技術,即類的源檔案和引用它的.asmx檔案是分開的。IDE會盡量屏蔽這些,如果你在Solution Explorer工具列中點擊Show All Files,你會注意到項目中Web Service類都有兩個檔案。事實上Visual Studio.NET不支援.asmx檔案的syntax highlighting or IntelliSense。對於Web項目,Visual Studio.NET也負責建立一個虛擬目錄,自動地將編譯好的assembly放到虛擬目錄的bin子目錄下。
在我們詳細討論.asmx控制代碼如何工作之前,先來簡單的看一下訊息是怎樣從IIS傳遞到.asmx控制代碼的。當一個HTTP訊息到達80連接埠後,IIS用在IIS 中繼資料庫中找到的資訊決定由哪個ISAPI.DLL來處理訊息。.NET安裝時將.asmx副檔名映射到Aspnet_isapi.dll,3所示。
Figure 3. IIS Application mapping for .asmx
Aspnet_isapi.dll是.NET架構提供的標準的ISAPI副檔名,它只是簡單的將HTTP請求傳遞到一個單獨的工作者進程Aspnet_wp.exe。Aspnet_wp.exe hosts CLR(通用語言運行時)和HTTP管道。訊息一旦進入了HTTP管道,管道就尋找設定檔看哪個IhttpHandler類用來處理給定的副檔名。如果你查看你的machine.config檔案,會看到它包含了一個映射到.asmx檔案的httphandler,如下所示:
<configuration> <system.web> <httpHandlers> <add verb="*" path="*.asmx" type="System.Web.Services.Protocols.WebServiceHandlerFactory,System.Web.Services, Version=1.0.3300.0, Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>當一個訪問.asmx檔案的訊息進入.NET HTTP管道時,管道就會調用WebServiceHandlerFactory類來執行個體化一個新的WebServiceHandler對象,用它來處理請求(通過調用IhttpHandlerProcessRequest方法)。WebServiceHandler對象開啟物理的.asmx檔案來決定包含你的WebMethods的類名。
註:未完,
其餘內容見ASP.NET Web Service如何工作(2)
ASP.NET Web Service如何工作(3)