Web Services Enhancements 管道技术内幕

　　在上例中，TimestampOutputFilter 向消息添加一个时间戳标头，TraceOutputFilter 将消息写入跟踪文件。问题是向跟踪文件写入的消息是否包括时间戳标头？答案是肯定的。乍看起来这似乎违反常理。SoapOutputFilterCollection.Add 方法将过滤器附加到集合的末尾，因此 TraceOutputFilter 比 TimestampOutputFilter 早出现，这意味着在添加时间戳之前，消息就已经被写入跟踪文件中。然而，结果却是输出过滤器逆序执行，也就是说，集合中最后的输出过滤器最先处理消息。我给大家解释一下原因。

　　考虑两个会变更输出消息内容的过滤器 TimetampOutputFilter 和 SecurityOutputFilter。如果 TimetampOutputFilter 要向出站消息添加时间戳标头，就需要在 SecurityOutputFilter 加密消息之前进行。因此，输出过滤器处理的顺序非常重要。而且，当输入消息到达时，SecurityInputFilter 必须先解密消息，然后 TimestampInputFilter 才能检查消息是否过期。因此，输入过滤器处理的顺序也很重要，一般需要反转相应输出过滤器的顺序。

　　Pipeline 类考虑了这种情形，下面是它的工作原理。过滤器集合中的第一个过滤器最“接近线路”，最后一个过滤器最“接近代码”。对于输出过滤器和输入过滤器来说都是这样。输入过滤器始终按它们出现在集合中的顺序进行处理，而输出过滤器始终按相反的顺序进行处理。所有这些都封装在 ProcessInputMessage 和 ProcessOutputMessage 方法中。图 2 说明了这种体系结构。

图 2：Pipeline 类中的过滤器处理顺序

　　Pipeline 类有充分的理由采用这种工作方式。如果输入和输出过滤器集合以相同的顺序移动的话，您就必须在代码中手动反转一组过滤器的顺序。通过在 ProcessOutputMessage 中使用逆序处理，Pipeline 类就将您从其中解放出来。您可以“按照相同的顺序”向各自的集合中添加“对应的”输入和输出过滤器，而把其余的工作留给 Pipeline 去做。

　　在大多数应用程序中，您很可能希望 Pipeline 对象使用相同的输入和输出过滤器。为此，WSE 支持默认 Pipeline 配置。Microsoft.Web.Services.Configuration.WebServicesConfiguration 类提供了一个静态 FilterConfiguration 属性，它维护了一对过滤器集合，分别通过 InputFilters 和 OutputFilters 属性来提供。当使用默认构造函数来实例化 Pipeline 类时，对默认过滤器的引用被复制到新对象的过滤器集合中。您可以针对每个 AppDomain 来修改默认的 Pipeline 配置。

　　使用内置 WSE 过滤器来预先配置默认的输入和输出过滤器集合。表 2 显示了这些配置。

　　表 2：预先配置的默认 Pipeline 配置

　　请注意，索引较小的过滤器更“接近线路”，而索引较大的过滤器更“接近代码”。如果在 WSE 中启用跟踪功能，则 TraceInputFilter 和 TraceOutputFilter 将被插入到默认过滤器集合的最前面，即 0 位置。这样做很有意义，因为跟踪过滤器的目标就是记录消息出入线路的情况。

　　如果您愿意，可以修改 AppDomain 的默认过滤器集合。例如，如果您希望应用程序使用 WS-Security 而不是 WS-Routing 和 WS-Referral，则可以删除路由和参照过滤器。一般来说，删除不需要的过滤器可以减少必须检查每个 SOAP 消息的对象数，进而提高应用程序的性能。

　　以下方法说明如何从默认的输入和输出过滤器中删除路由和参照标头。

　　值得注意的是，修改默认过滤器集合对现有的 Pipeline 对象没有影响。只有在更改默认集合后创建的新 Pipeline 对象才会受到此修改的影响。例如，在以下代码中，两个 Pipeline 对象使用不同的过滤器。

　　如果您结合使用 WSE 和 ASP.NET Web 服务，可以使用 Global.asax 文件来修改服务在应用程序启动时的默认过滤器集合。下面是一个示例：