ASP.NET Web Service如何工作（1）
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的类名。
