为了使.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应答：
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>Server was unable to process request. --> access denied</faultstring> <detail /> </soap:Fault> </soap:Body></soap:Envelope>
如果你想更多的控制SOAP Fault元素，也可以通过指定所有SOAP Fault元素细节来明确抛出一个SOAP异常对象。比如：faultcode, faulstring, faultactor, detail元素。
领会WebMethods如何工作需要理解根本的串行化引擎和它的各种选项。串行化引擎的好处就是它隐藏了定制句柄中底层的XML API代码。然而尽管许多开发人员认为这样很好，一些人也认为这也是它的缺陷，因为他们想亲手来处理WebMethod中未经加工的SOAP消息。
写好并部署了一个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文件中指定一个不同的文档文件来绕过基于虚拟目录文档生成器：
<configuration> <system.web> <webServices> <wsdlHelpGenerator href="MyDocumentation.aspx"/> </webServices> ...
如果客户端发出请求.asmx终点，且请求字符串后加“？wsdl”，.asmx句柄将生成一个WSDL定义而不是一个人性化的可读文档。客户端可以使用WSDL定义生成代理类，它自动的知道怎样和Web服务通信。
要定制WSDL生成过程，你可以写一个SoapExtensionReflector类并在你的Web.config文件中注册到WebMethods框架。然后当.asmx句柄生成WSDL定义时，它将会调用你的反映类（reflector）使你有机会定制提供给用户的最后定义。
同样你也可以采用两种技术来绕过WSDL生成过程。首先，可以在你的虚拟目录下提供一个静态的WSDL文档供客户访问，然后从Web.config文件中除去文档生成器（如下所示）。
<configuration> <system.web> <webServices> <protocols> <remove name="Documentation"/> </protocols> ...
另外一个比较自动化的技术是使用[WebServiceBinding]属性来指定WebMethod类实现的静态WSDL文档在虚拟目录中的位置，也要用[SoapDocumentMethod]属性为每一个实现的WebMethod指定WSDL绑定的名字。这样做以后，自动WSDL生成过程将会导入你的静态WSDL文件，生成一个新的服务描述。
手工编写WSDL是极端困难的，因为现在没有很多WSDL编辑器。因此自动文档/WSDL生成是WebMethod框架中有价值的一部分。没有它，许多开发者的日子会很难过的。
ASP.NET WebMethods框架为创建WEB服务提供了高效的方法。WebMethods使得传统的.NET方法能够成为支持HTTP、XML、XML Schema和WSDL的Web服务操作。WebMethod（.asmx）句柄自动决定怎样将到来的SOAP请求消息分派到适当的方法，然后又将请求消息中的XML元素串行化为相应的.NET对象。为简化集成客户端，.asmx句柄也支持可读文档和WSDL的生成。
和自己定制的IhttpHandlers相比，尽管WebMethods框架有点受限，它还是提供了称为SOAP扩展框架的强大扩展模型。SOAP扩展允许你引入我们上面没有讨论到的额外功能来满足你的具体需要。比如，微软发布了Web Serivices Enhancements1.0，它提供了SoapExtension类，为WebMethods框架引入了几个GXA规范的支持。
ASD全球范围内寻找能够应您的需求供应服务或产品的企业，发布您所能提供的服务或产品以供其他DDFDFDFDFDFD商业实体来发现，这是全球商家的期望。
为满足这一商业需求，技术领域和商业领域的领导者们启动了UDDI计划，通过紧密地协作，开发和制订UDDI规范，并部署UDDI服务。UDDI(Universal Description, Discovery and Integration), 统一描述、发现和集成协议，是开放的、基于Internet的新一代电子商务技术标准。
本文地址：http://com.8s8s.com/it/it45550.htm