为了使 .asmx 句柄有可能反串行化 SOAP 头，首先你需要定义一个 .NET 类，它代表了暗含的 XML Schema 类。在此例中相应的类如下：
[XmlType(Namespace="http://example.org/security")]
[XmlRoot(Namespace="http://example.org/security")]
public class UsernameToken : SoapHeader {
public string username;
public string password;
}
然后你需要在 WebMethod 类中定义一个成员变量来控制一个头类的实例，同样要为 WebMethods 标记 [SoapHeader] 属性。见如下：
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 域，并提取 SOAP 头提供的信息。你也可以使用同样的技术将头信息送回客户端——你需要在 [SoapHeader] 属性声明中指定头的方向。
.asmx 句柄也提供了 .NET 异常的自动串行化。任何被 .asmx 句柄劫获的未处理的异常都会被自动串行化为应答消息中的 SOAP Fault 元素。比如，在前面的例子中，假如用户名与反转的口令不匹配，我们的代码将会抛出一个 .NET 异常。 .asmx 句柄劫获这个异常，将它串行化为下面的 SOAP 应答：
1<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
2
3
4 <soap:body>
5
6
7 <soap:fault>
8
9
10 <faultcode>soap:Server</faultcode>
11
12
13 <faultstring>Server was unable to process request. --> access denied</faultstring>
14
15
16 <detail></detail>
17
18
19 </soap:fault>
20
21
22 </soap:body>
23</soap:envelope>
如果你想更多的控制 SOAP Fault 元素，也可以通过指定所有 SOAP Fault 元素细节来明确抛出一个 SOAP 异常对象。比如： faultcode, faulstring, faultactor, detail 元素。
领会 WebMethods 如何工作需要理解根本的串行化引擎和它的各种选项。串行化引擎的好处就是它隐藏了定制句柄中底层的 XML API 代码。然而尽管许多开发人员认为这样很好，一些人也认为这也是它的缺陷，因为他们想亲手来处理 WebMethod 中未经加工的 SOAP 消息。
自动生成 WSDL 文档
写好并部署了一个 WebMethod 后，客户需要明确知道和它成功通信 SOAP 消息应该是个什么样子。提供 Web 服务描述的标准方法是通过 WSDL （和嵌入的 XSD 定义）。 .asmx 句柄自动的生成了人性化的可读文档和 WSDL 定义，它准确的反映了 WebMethod 接口。如果在你的 WebMethods 中应用了一些映射属性，它们将都被反映在生成的文档中。
假如你浏览这个 .asmx 文件，你将看到一个人性化的可读文档页面就像图 2 中显示的那样。这个文档页是由 DefaultWsdlHelpGenerator.aspx ( 在 C:\windows\Microsoft.NET\Framework\v1.0.3705\config 中 ) 生成的。打开这个文件你会看到它就是一个标准的 ASP.NET 页面，它使用 .NET reflection 生成那个文档。这个特点使文档一直与代码同步，可以通过简单的修改这个文件来定制你的生成文档。
也可以在 Web.config 文件中指定一个不同的文档文件来绕过基于虚拟目录文档生成器：
1<configuration>
2
3
4 <system.web>
5
6
7 <webservices>
8
9
10 <wsdlhelpgenerator href="MyDocumentation.aspx"></wsdlhelpgenerator>
11
12
13 </webservices>
14
15
16 ...
17
18如果客户端发出请求 .asmx 终点，且请求字符串后加“？ wsdl ”， .asmx 句柄将生成一个 WSDL 定义而不是一个人性化的可读文档。客户端可以使用 WSDL 定义生成代理类，它自动的知道怎样和 Web 服务通信。
19
20要定制 WSDL 生成过程，你可以写一个 ** SoapExtensionReflector ** 类并在你的 Web.config 文件中注册到 WebMethods 框架。然后当 .asmx 句柄生成 WSDL 定义时，它将会调用你的反映类（ reflector ）使你有机会定制提供给用户的最后定义。
21
22同样你也可以采用两种技术来绕过 WSDL 生成过程。首先，可以在你的虚拟目录下提供一个静态的 WSDL 文档供客户访问，然后从 Web.config 文件中除去文档生成器（如下所示）。
23
24
25 <configuration>
26
27
28 <system.web>
29
30
31 <webservices>
32
33
34 <protocols>
35
36
37 <remove name="Documentation"></remove>
38
39
40 </protocols>
41
42
43 ...
44
45另外一个比较自动化的技术是使用 [WebServiceBinding] 属性来指定 WebMethod 类实现的静态 WSDL 文档在虚拟目录中的位置，也要用 [SoapDocumentMethod] 属性为每一个实现的 WebMethod 指定 WSDL 绑定的名字。这样做以后，自动 WSDL 生成过程将会导入你的静态 WSDL 文件，生成一个新的服务描述。
46
47手工编写 WSDL 是极端困难的，因为现在没有很多 WSDL 编辑器。因此自动文档 /WSDL 生成是 WebMethod 框架中有价值的一部分。没有它，许多开发者的日子会很难过的。
48
49### 总结
50
51ASP.NET WebMethods 框架为创建 WEB 服务提供了高效的方法。 WebMethods 使得传统的 .NET 方法能够成为支持 HTTP 、 XML 、 XML Schema 和 WSDL 的 Web 服务操作。 WebMethod （ .asmx ）句柄自动决定怎样将到来的 SOAP 请求消息分派到适当的方法，然后又将请求消息中的 XML 元素串行化为相应的 .NET 对象。为简化集成客户端， .asmx 句柄也支持可读文档和 WSDL 的生成。
52
53和自己定制的 IhttpHandlers 相比，尽管 WebMethods 框架有点受限，它还是提供了称为 SOAP 扩展框架的强大扩展模型。 SOAP 扩展允许你引入我们上面没有讨论到的额外功能来满足你的具体需要。比如，微软发布了 Web Serivices Enhancements1.0 ，它提供了 SoapExtension 类，为 WebMethods 框架引入了几个 GXA 规范的支持。
54
55ASD 全球范围内寻找能够应您的需求供应服务或产品的企业，发布您所能提供的服务或产品以供其他 DDFDFDFDFDFD 商业实体来发现，这是全球商家的期望。
56
57为满足这一商业需求，技术领域和商业领域的领导者们启动了 UDDI 计划，通过紧密地协作，开发和制订 UDDI 规范，并部署 UDDI 服务。 UDDI(Universal Description, Discovery and Integration), 统一描述、发现和集成协议，是开放的、基于 Internet 的新一代电子商务技术标准。</webservices></system.web></configuration></system.web></configuration>