ASMX2.0、WSE3.0和WCF问题解答(二)

　Microsoft® .NET Framework 2.0 版通过几个有趣但可能令人困惑的方式重塑了 Web 服务的前景。因此，本月我打算解答一些与 ASP.NET Web Services (ASMX) 2.0、Web Services Enhancements (WSE) 3.0 和 Windows® Communication Foundation (WCF)(WinFX® 的一部分)有关的最常见问题。（查看本文第一部分）

　　问:何时应该将 WSE 与 ASMX 结合使用，何时应该单独使用 ASMX?我希望将这个问题弄得更清楚些。

　　答:ASMX 2.0 支持 WS-I Basic Profile 1.1 和 SOAP 1.2。这意味着，它支持 XML 1.0、XML 架构定义 (XSD)、Web 服务描述语言 (WSDL)、SOAP 1.1、SOAP 1.2 以及编译时的基本配置文件一致性验证。WSE 3.0 通过提供对某些更高级的 WS-* 协议的支持，来补充 ASMX 2.0 的功能。目前，当您需要使用以下一个或多个功能来增强 ASMX 服务时，通常会使用 WSE 3.0:

• 　　•基于消息的安全性 (WS-Security)
• 　　•高效的二进制数据传输 (MTOM)
• 　　•可选的宿主环境
• 　　•自定义声明性策略管道

　　基于消息的安全性和 MTOM 是人们在 ASMX 项目中启用 WSE 的两个主要原因。还有一个好消息是，您不必修改服务逻辑就可以这样做。WSE 3.0 通过 ASMX 提供的扩展点来利用 ASMX。这使您能够利用各种 WSE 3.0 功能，而不必学习新的编程模型 — 您需要做的就是运行 WSE 设置工具并选择所需的选项。

　　在 ASMX 项目中启用 WSE 3.0 的另一个原因是，要利用它的策略管道扩展性模型。WSE 使您能够插入对进入和离开终结点的 SOAP 消息执行预处理和后续处理的筛选器。该扩展点比 ASMX SOAPExtension 框架更易于使用，因为它提供的功能可以创建能够与 WSE 提供的现有声明性安全策略相结合的自定义声明性策略。您决定“启用”WSE 可能只是为了具有该扩展选项，或者至少是为了使用改进的 SOAP 消息诊断跟踪功能。

　　有了 WSE 2.0，大多数开发人员在需要进行自定义宿主时就抛弃了 ASMX。现在，WSE 3.0 使您能够执行 ASMX 类型的自定义宿主，这就更没有问题了。导致您单独使用 WSE 消息处理 API 的主要情况是，需要实现可选的消息交换模式，例如，双工通信、多播或发布/订阅情况。消息处理类 SOAPSender 和 SOAPReceiver 使您能够实现任何类型的高级消息处理模式。问:当我在 Web 站点中启用 WSE 3.0 后，在配置文件中再也看不到 WSE SOAPExtension 了。相反，我看到了一个 SOAPServerProtocolFactory。那是什么?

　　答:默认情况下，可以使用几个不同的服务器协议调用 ASMX 终结点，包括 HTTPSOAP、HTTPSOAP12、HTTPGet、HTTPPost、HTTPPostLocalhost 和 Documentation。您可以在 Web.config 中启用或禁用其中任何一个协议。.NET Framework 2.0 中的默认 ASMX 配置如下所示:

<WebServices>    <protocols>       <clear />       <add name="HTTPSOAP12" />       <add name="HTTPSOAP" />       <add name="HTTPPostLocalhost" />       <add name="Documentation" />    </protocols>    ... </WebServices>

　　每个协议都期望不同类型的 HTTP 消息，并实现不同的 ASMX 调用协议。例如，对于 HTTPSOAP，传入的 HTTP 有效负载将始终包含 ，而对于 HTTPGet，数据在查询字符串中传入且 HTTP 有效负载为空。前者在响应中返回 SOAP 信封，而后者只返回纯 XML。

　　为了处理这些差异，ASMX 处理程序 (System.Web.Services.Protocols.WebServiceHandler) 使用名为 ServerProtocol 的类来处理传入的消息。还有几个派生自 ServerProtocol 的类，包括 SOAPServerProtocol 和 HTTPGetServerProtocol。这些类将映射到配置文件中的不同协议。ASMX 处理程序会检查传入的 HTTP 消息，并选择合适的 ServerProtocol 类型。从那时起，ServerProtocol 实例就开始管理调用操作的过程。在调用过程中，SOAPExtension 框架就是它管理的内容之一。

　　SOAPExtension 框架是一个扩展点，以便开发人员在 ASMX 处理程序和目标 WebMethod 之间插入代码。实际上，它提供了一种用于转换传入消息流和传出消息流的机制。如果您需要修改 SOAPExtension 中的消息，则必须提供一个将传递到链中下一个扩展的新流(在一开始即与 SOAPExtension.ChainStream 绑定在一起)。因此，将重复以下过程:SOAPExtension 接收流，进行分析，执行它的任务，然后写入下一个 SOAPExtension 将读取的流。

　　WSE 2.0 完全作为 SOAPExtension 而实现的。在该级别实现 WSE 的一个问题是，它会在流级别导致大量的序列化/反序列化系统开销。移到 WSE 3.0，WSE 小组希望通过将抽象层上移并编写自己的 SOAPServerProtocol 实现来优化他们的 SOAP 处理模型。因此，他们询问 ASMX 小组是否能够通过 ASMX 2.0 中的配置来替换默认的 SOAPServerProtocol。ASMX 开发人员提供一个名为 的新配置元素，任何人都可以使用它来提供自己的实现(虽然我们不鼓励这么做)。ASMX 处理程序会读取该类型，并用它来创建相应 SOAPServerProtocol 类型的实例以处理新的请求。WSE 3.0 将使用该挂钩，并使用 Microsoft.Web.Services3.WSEProtocol 来替换默认的 SOAPServerProtocol 类。

　　WSEProtocol 可以在同一个类中管理 SOAPExtension 机制和 WSE 管道，从而减少了一些流摩擦。WSE 3.0 仍然使用 SOAPExtension(名为 WSEProtocolExtension)，但它从来不在配置文件中出现，这是因为 WSEProtocol 在启动时动态插入它(以确保它始终存在)。WSEProtocolExtension 只负责识别和分析 MTOM 和 XML 1.0 流;其他事情均由 WSEProtocol 实现来完成。

　　因此，简单说， 是 WSE 3.0 将自身融入 ASMX 2.0 的方式。WSE 3.0 仍然使用 SOAPExtension，在该版本中，它只是不在执行任务的决策地。　问:如果在我自己的应用程序中承载 ASMX 类，会对 HTTPContext.Current 造成什么影响?SOAPExtension 又如何呢?

　　答:遗憾的是，ASMX 设计与 ASP.NET 紧密地耦合在一起。例如，当 Visual Studio® 创建新的 ASMX 类时，在默认情况下会从 System.Web.Services.WebService 派生。这会通过新的 ASMX 类上的属性来公开各种 System.Web.HTTPContext 属性，从而鼓励它们在 WebMethod 中的使用。某些开发人员还习惯于通过 HTTPContext.Current 显式使用 HTTP 上下文。

　　当您使用 WSE 3.0 中的 SOAPReceivers 承载一个 ASMX 类时，这种类型的代码就不再工作了。本例，您的代码在 IIS 和 ASP.NET HTTP 管道之外执行。HTTPContext.Current 将始终为空，因此这可能要求您修改现有的 WebMethod 逻辑。通常，如果您打算在 ASP.NET 之外的宿主环境中重用该类型，则应该避免在 WebMethod 代码中依赖 HTTP 管道中的任何内容。

　　此外，在使用 SOAPReceivers 作为宿主时，就不能再依赖 HTTPModule 或 SOAPExtension 为您执行任务了。因为现在您在 ASMX 处理程序之外执行，所以这些媒介将不再起作用。

　　问:我在 WSE 3.0 设置工具中找不到 Filters 选项卡。如何访问它呢?

　　答:Filters 选项卡不再位于 WSE 3.0 设置工具中，因为 元素已经从 WSE 3.0 配置部分中移除了。在 WSE 2.0 中，您使用 元素来定义通过筛选器构建管道的方式。默认情况下包含的一个筛选器是策略筛选器。策略筛选器查看另一个配置文件(策略文件)，以便根据其断言(类似于筛选器)来决定如何处理传入和传出的消息。

　　在 WSE 3.0 中，这两个概念已统一。因此，现在的策略由断言组成，并且每个断言都会在管道中插入 WSE 筛选器。您将断言放到策略中，以控制筛选器管道在运行时如何构建和组织。因此，如果您希望在管道中插入自定义筛选器，则应该编写筛选器类，编写使用新筛选器的策略断言类，在策略中使用断言类，然后将该策略应用于服务。在 WSE 3.0 中，正是策略框架驱动着管道，因此就不再需要部分。　问:WSE 3.0 支持哪些传输?编写自定义传输很难吗?

　　答:WSE 3.0 支持 HTTP 和 TCP。WSE 提供一个自定义传输框架，以允许第三方插入自己的传输实现。自从 WSE 2.0 发布以后，一些开发人员提供了示例 WSE 传输来演示如何完成此操作。其中一个可用于 Microsoft 消息队列服务器 (MSMQ)、SMTP和 UDP。所有这些传输均针对 WSE 2.0 编写，但是将它们移植到 WSE 3.0 也没什么问题。

　　以下代码提供一个使用 SMTP 传输在控制台应用程序中宿主服务的示例:

SOAPReceivers.Add(new Uri("SOAP.SMTP://test@skonnard.com"),     typeof(ExpenseReportService)); Console.ReadLine();

　　然后，在客户端，您只需在调用方法前指定 SMTP 地址即可，如下所示:

ExpenseReportServiceWSE svc = new ExpenseReportServiceWSE(); svc.Url = "SOAP.SMTP://test@skonnard.com"; svc.Submit(report);

　　现在，客户端将向 test@skonnard.com 电子邮件地址发送消息，接收器将从同一个地址接收消息。该示例中比较有趣的是，客户端和接收器不再需要同时运行。请注意，在使用自定义传输时，开发人员体验不会受到影响。您必须做的一件事是，通过将 映射添加到 WSE 配置部分来告诉 WSE 如何处理“SOAP.SMTP”协议方案，如下所示:

<Microsoft.Web.services3>   <messaging>     <transports>       <add scheme="SOAP.SMTP" type="SOAPSMTPTransport,SOAPSMTP"/>     </transports>   </messaging>   ... </Microsoft.Web.services3>

　　该元素将协议方案映射到一个从 ISOAPTransport 派生的类。当调用 SOAPReceivers.Add 时，它会从配置部分查找映射到指定协议方案的类型。然后，它会实例化指定的类型，并使用 ISOAPTransport 方法生成输入和输出通讯信道。客户端也会发生同样的操作。这些信道会对其余 API 隐藏所有传输实现的细节。

　　因此，编写自定义 WSE 传输需要实现三个类:一个用于建模传输 (ISOAPTransport)，另外两个用于建模输入/输出信道(ISOAPInputChannel 和 ISOAPOutputChannel)。传输可提供信道并管理所有信道共享的资源，而信道主要用于通过传输发送/接收消息。这里，您处理的是低级别传输细节，因此有点困难。了解其工作方式的最佳方法是，演练我在前面提到的现有 WSE 传输示例。