《WCF后续之旅》博文系列总结[共17篇]

《我的WCF之旅》系列自开篇以来，得到了园子里很多朋友的厚爱，并荣登了博客园2007年度系列博文Top 10。由于工作原因，沉寂了一阵，两个月前开始WCF新的旅程。如果说《我的WCF之旅》主要是对WCF基本原理概括性介绍，而对于这个新的系列，我将和大家分享我对WCF的一些实现机制、设计原理的理解，以及我在实际的项目开发中的一些实践经验（比如在后续的一些文章中，我将介绍通过WCF Extension实现一些在真正的分布式项目开发中很有现实意义的功能）。

[第1篇] WCF是如何通过Binding进行通信的

Windows Communication Foundation，顾名思义，就是一个在Windows平台下进行如何进行Communication的基础构造（Infrastructure）。由于WCF的核心还是Communication，这个新的系列就先来讨论WCF如何进行Communication的。通过本篇文章，你将对WCF的通信机制有一个总体的认识，了解到一些和通信相关的概念， 比如：Communication、Channel、Channel Listener、Channel Factory、BindingElement，Channel  Shape等等。

我们已经很清楚了，WCF的通信是通过Endpoint来完成的：Service Provider将WCF service通过Endpoint暴露出来供Service consumer调用，而Service consumer通过与之相匹配的Endpoint来调用service。"Endpoint=ABC”，大家一定也牢记于心。就Endpoint包含的这3个元素而言，Address解决了寻址的问题，代表如何定位和标识对应的Endpoint，而Contract在对Service提供的功能、操作（Service Contract）以及数据（Data contract、Message contract和Fault contract）的抽象表示。而真正实现了通信功能的则是Binding。

[第2篇] 如何对Channel Layer进行扩展——创建自定义Channel

在上一篇文章中，我们通过一个直接借助BasicHttpBinding对象实现Client和Server端进行通信的例子，对WCF channel layer进行了一个大致上的介绍。由此引出了一些列通信相关的概念和对象，比如Channel，Output channel， Input channel，Request channel, Reply Channel，Duplex channel， Channel Shape，Channel manager，Channel factory, Channel listener, Binding element 等。通过这些元素，我们很容易地实现对WCF channel layer进行扩展。

对channel layer进行扩展一般适用于当你的需求通过现有的Binding，或者channel不能实现，而需要自定义一些channel来实现你所需的功能。不如现在的WCF系统定义的Channel中没有实现对Message body的压缩功能。你可以就需要将此功能定义到一个custom channel中，然后将其注入到channel stack中。一般来说，仅仅创建custom channel是不够的，因为在runtime， channel是通过Channel manager进行创建的，所以你需要创建对应的Channel factory（如何对发送方进行扩展）或者Channel listener（如果对接受方进行扩展）。而Channel factory和channel listener最终又是通过Binding element进行创建的，所以你还需要创建相应的Binding element。（Binding element=〉Channel factory&Channel listener=>Channel）

在本章节中，我们将继续讨论WCF channel layer。我们将通过如何创建和应用custom channel来介绍channel layer一些知识。

[第3篇] WCF Service Mode Layer 的中枢—Dispatcher

由于应用WCF的是一个分布式环境，按照所处的环境的不同，可以将 ServiceMode分成client端的ServiceMode和service端的ServiceMode。就其实现的复杂度而言，service 端的ServiceMode要比client端的复杂很多。对于Service端来讲，WCF的ServiceMode需要解决的是:

• 如何根据不同的listening URI创建ChannelListener并进行监听；
• 当request抵达，如何创建适合的Channel接收request message；
• 如何将Message分发到对应的Endpoint进行处理；
• 如何进一步将Message分发到对应的service instance；
• 以及如何进一步地分发的具体的service instance的匹配的method call。

由于“分发（Dispatch）”是其根本的功能和任务，所以Dispatcher是整个Service端ServiceMode的核心。正如标题所述，Dispatcher是整个WCF service mode layer的中枢，本篇文章讲着重围绕着Dispatcher来展开介绍。

[第4篇] WCF Extension Point 概览

在本系列的每篇文章中，我多次提到WCF是一个极具可扩展性的分布是消息通信框架。为了让读者对WCF Extension有一个总体的的认识，在这里我会简单列举了我们经常使用的绝大部分的扩展点，以及通过这些扩展点能够解决实现项目开发中的那些问题。

有一点需要特别提醒的是：对WCF extensions的灵活应用依赖于你对channel layer和service mode dispatching system的深入理解。所以，如果你对channel layer不甚了解，可以参阅本系列的第一个部分(WCF是如何通过Binding进行通信的)和第二部分(如何对Channel Layer进行扩展——创建自定义Channel)， 若是想了解更多关于dispatching system的细节，可以参考本系列的第三部分(WCF Service Mode Layer 的中枢—Dispatcher)。

现在，我们按照在上一篇文章的Dispatching的执行流程，来介绍dispatching system中可以用于对WCF进行扩展的对象，已经这个可扩展对象具体解决的问题和扩展的方式。为了利于读者理解这些可扩展对象具体被使用在 Dispatching整个的生命周期的哪个阶段，我们在标注Step 1、Step 2…字样，读者可以在上一篇文章中查阅对应的步骤在执行怎样的功能。

在上一篇文章中, 我列出了WCF一系列的可扩展对象和元素，并简单介绍了他们各自的功能、适合的场景和具体解决的问题。从本篇开始我将通过一个个具体的例子来介绍如何利用这些扩展点对WCF进行扩展，从而解决一些我们在实现的项目开发中可能出现的问题。

今天，我们将讨论如何通过WCF extension实现多语言、本地化的功能。我们模拟这样的一个场景：我们现在有一个支持多语言的项目，假设通过支持英文（en-US）和简体中文（zh-CN）。我们需要创建一个service为整个系统提供message。对于这个message service，简单起见，我们将基于不同的culture的message存储于不同的Resource文件中，客户端通过访问service来获取基于它自己本地culture的message。比如，如果某一个客户端当前的 culture是en-US，那么会得到英文的message，如果是zh-CN将会得到简体中文的message。

我们很多人会说，在获取message的时候将client端本地的culture作为API的参数传递到 service端，service再根据相应的culture从对应的resource文件中获取message不就可以了吗？这样做不是不可以，但是不过优雅。从业务逻辑和非业务逻辑的分离来讲是不是一个好的解决方案，因为从某种意义上讲，culture信息是业务无关的，不适合作为API的一部分，API应该只和具体的业务逻辑相关联。

今天给出的解决方式基于这样的实现原理：在Client端，当调用我们的message service的时候，当前culture被自动放到message header里传到service端；在service端，该culture 信息自动地被取出，并将service端的当前线程的UI culture设置成该值，那么service只需要根据当前线程的culture去取message就可以了。此外考虑到我们改变线程culture可能带来的不可预知的影响，在方法执行完毕将culture重置。

在这里我们先来实现service端的功能：如何从message header中取出culture，并设置当前线程culture。至于Client端的实现，我们将在另一个场景中进行单独介绍。

如何看过前一篇文章的朋友，也许会记得，在列出的8大dispatching system可扩展对象中，有一个对象很适合我们今天的多语言的场景：CallContextInitializer。顾名思义，CallContext 表示基于当前线程的关于Call stack的上下文信息，这样的信息本存放在TLS（Thread Local Storage）中。CallContextInitializer就是用于去初始化这些context的。实际上，除了call context的初始化工作之外，CallContextInitializer还可以用于call context的清理工作。

在上一篇文章中，我们讨论了如何通过CallContextInitializer实现Localization的例子，具体的做法是将client端的culture通过SOAP header传到service端，然后通过自定义的CallContextInitializer设置当前方法执行的线程culture。在 client端，当前culture信息是通过OperationContext.Current.OutgoingMessageHeaders手工至于SOAP Header中的。实际上，我们可以通过基于WCF的另一个可扩展对象来实现这段逻辑，这个可扩展对象就是MessageInspector。我们今天来讨论MessageInspector应用的另外一个场景：如何通过MessageInspector来传递Context信息。

[第7篇]通过WCF Extension实现和Enterprise Library Unity Container的集成

松耦合、高内聚是我们进行设计的永恒的目标，如何实现这样的目标呢？我们有很多实现的方式和方法，不管这些方式和方法在表现形式上有什么不同，他们的思想都可以表示为：根据稳定性进行关注点的分离或者分解，交互双方依赖于一个稳定的契约，而降低对对方非稳定性因素的依赖。从抽象和稳定性的关系来讲，抽象的程度和稳定程度成正相关关系。由此才有了我们面向抽象编程的说法，所以“只有依赖于不变，才能应万变”。

然后，对于面向对象的思想来讲，我们的功能通过一个个具体的对象来承载。对象是具体的，不是抽象的；创建对象是必然的；对象的创建从某种程度上即使对面向抽象的违背。所以模块之间的耦合度在很大程度上是由于对象创建的方式决定的，而在对象创建过程实现解耦是实现我们“ 松耦合、高内聚”目标的一个重要途径。对于这一点，我们可以看看我们常用的设计模式中有多少是用于解决如何合理进行对象创建的就可以知道了。 Enterprise Library推出的新的Application Block：Unity Application Block为我们提供了一个很好的、可扩展的框架，帮助我们合理、有效的创建对象，并解决创建对象中的依赖。而通过WCF一个简单的扩展对象，就可以很容易地实现和Unity的集成。

在上一篇文章中，我们通过自定义InstanceProvider实现了WCF和微软Enterprise Library Unity Application Block的集成， 今天我们已相同的方式实现WCF与Enterprise Library的另一个Application Block的集成：Policy Injection Application Block (PIAB)。

PIAB，通过Method Interception的机制实现了AOP(Aspect Oriented Programing)。按照PIAB的编程方式，我们将非业务逻辑，比如Caching、Authorization、Transaction Enlist、Auditing、ExceptionHandling扽等等，定义在一个个的CallHandler，这些CallHandler通过Attribute或者Configuration的方式应用到目标方法上。关于 PIAB的详细介绍，我们参考我的PIAB系列（http://www.cnblogs.com/artech/archive/2008/01/29/1057379.html）。

由于PIAB特殊的实现机制(PIAB实现原理), 我们需要通过PIAB的PolicyInjector来创建新的对象或者包装现有的目标对象。只有调用这种能够方式的对象，应用在上面的 CallHandler才能被执行。所以WCF和PIAB的核心问题就是如何通过PIAB PolicyInjector来创建新的Service Instance，或者包装已经生成的service instance。在上面一篇文章中，我们通过Unity Container重新定义了InstanceProvider，我们今天的实现方案也是通过自定义InstanceProvider的方式来实现，不是我们需需要通过PolicyInjector来进行对象的创建。

我们都知道，WCF支持Duplex的消息交换模式，它允许在service的执行过程中实现对client的回调。 WCF这种双向通信的方式是我们可以以Event Broker或者订阅/发布的方式来定义和调用WCF Service。今天我们就给大家一个具体的例子：通过WCF的duplex communication方式现在Session管理。

[第10篇]通过WCF Extension实现以对象池的方式创建Service Instance

我们知道WCF有3种典型的对service instance进行实例化的方式，他们分别与WCF的三种InstanceContextMode相匹配，他们分别是 PerCall，PerSession和Single。PerCall为每次service invocation创建一个新的service instance; 而PerSession则让一个service instance处理来自通过各Session（一般是同一个proxy对象）的调用请求；而Single则是用同一个service instance来处理所有的调用请求。SOA的一个原则是创建无状态的service（stateless service），PerCall应该是我们经常使用的实例化方式，尽管PerSession是默认的InstanceContextMode。

但是对于PerCall这种实例化方式来说，为每次service请求都创建新的service instance，有时候显得有点极端，频繁的对象创建会对系统的性能造成一定的影响。我们能够以池的机制（Pooling）进行对象的获取和创建呢：当 service调用请求抵达service端，先试图从池中获取一个没有被使用的service instance，如何找到，直接获取该对象；否则创建新的对象。当service instance对象执行完毕，将对象释放到池中以供下次service 调用使用。

对于一般的多线程操作，比如异步地进行基于文件系统的IO操作；异步地调用Web Service；或者是异步地进行数据库访问等等，是和具体的线程无关的。也就是说，对于这些操作，任意创建一个新的线程来执行都是等效的。但是有些情况下，有些操作却只能在固定的线程下执行。比如，在GUI应用下，对控件的访问就需要在创建该控件的线程下执行；或者我们在某个固定的线程中通过 TLS（Thread Local Storage）设置了一些Context信息，供具体的操作使用，我们把操作和某个固定的线程的依赖称为线程关联性（Thread Affinity）。在这种情况下，我们的异步操作就需要被Marshal到固定的线程执行。在WCF并发或者Callback的情况下也具有这样的基于线程关联性的问题。

[第12篇] 线程关联性（Thread Affinity）对WCF并发访问的影响

在本系列的上一篇文章中, 我们重点讨论了线程关联性对service和callback的操作执行的影响:在service host的时候，可以设置当前线程的SynchronizationContext，那么在默认情况下，service操作的执行将在该 SynchronizationContext下执行（也就将service操作包装成delegate传入 SynchronizationContext的Send或者Post方法）；同理，对于Duplex同行方式来讲，在client调用service之前，如果设置了当前线程的SynchronizationContext，callback操作也将自动在该 SynchronizationContext下执行。

对于Windows Form Application来讲，由于UI Control的操作执行只能在control被创建的线程中被操作，所以一这样的方式实现了自己的 SynchronizationContext（WindowsFormsSynchronizationContext）：将所有的操作Marshal 到UI线程中。正因为如此，当我们通过Windows Form Application进行WCF service的host的时候，将会对service的并发执行带来非常大的影响。

详细讲，由于WindowsFormsSynchronizationContext的Post或者Send方法，会将目标方法的执行传到UI主线程，所以可以说，所有的service操作都在同一个线程下执行，如果有多个client的请求同时抵达，他们并不能像我们希望的那样并发的执行，而只能逐个以串行的方式执行。(Source Code从这里下载)

[第13篇] WCF后续之旅(13): 创建一个简单的WCF SOAP Message拦截、转发工具

WCF是.NET平台下实现SOA的一种手段，SOA的一个重要的特征就基于Message的通信方式。从 Messaging的角度讲，WCF可以看成是对Message进行发送、传递、接收、基础的工具。对于一个消息交换的过程，很多人只会关注 message的最初的发送端和最终的接收端。实际上在很多情况下，在两者之间还存在很多的中间结点（Intermediary），这些中间结点在可能在 实际的应用中发挥中重要的作用。比如，我们可以创建路由器（Router）进行消息的转发，甚至是Load Balance；可以创建一个消息拦截器（Interceptor）获取request或者response message，并进行Audit、Logging和Instrumentation。今天我们就我们的目光转向这些充当着中间人角色的 Intermediary上面来。

在本篇文章中，我们将会创建一个message的拦截和转发工具（message interceptor）。它将被置于WCF调用的client和service之间，拦截并转发从client到service的request message，以及service到client的response message，并将request message和response message显示到一个可视化的界面上。我们将讨论这个message interceptor若干种不同的实现方式。

[第14篇]WCF后续之旅（14）：TCP端口共享

在基于TCP/IP协议簇的对等网络通信下，相互通信的应用程序运行各自的进程中，出于应用层的进程将数据局封装成数据报，并通过传输层的TCP或者UDP进行网络通信。而TCP和UPD则通过一个16bit的端口来识别不同的应用程序。

对 于一些常用网络服务，他们都有一个知名的端口好与之匹配。比如，FTP服务是用的TCP端口为21；Telnet服务的TCP端口为23等等。而对于客户 端通常对所使用的端口并不关心，只需要保证端口在本机是唯一的就可以了，这样的端口又成为临时端口，临时端口一般在1024到5000之间。

一般来讲，在某一个时刻，一个端口只能供一个应用程序使用。对于WCF来说，当我们通过一个托管的应用程序对某个服务进行寄宿的时候，一个端口被该应用程序独占使用。如何多个寄宿进行使用相同的端口。

[第15篇] WCF后续之旅(15): 逻辑地址和物理地址

在WCF中，每个终结点都包含两个不同的地址——逻辑地址和物理地址。逻辑地址就是终结点Address属性表示的地址。至于物理地址，对于消息发送放来讲，就是消息被真正发送的目的地址；而对于消息的接收放来讲，就是监听器真正监听的地址。

[第16篇]WCF后续之旅(16): 消息是如何分发到Endpoint的--消息筛选(Message Filter)

在介绍终结点的ListenUriMode时，我们提到了两个特殊的对象ChannelDispatcher和ChannelListener。这两个对象在整个WCF的消息分发系统中具有重要的地位，在这节里，我们对WCF的整个消息分发过程作一个简单的介绍。

[第17篇]WCF后续之旅（17）：通过tcpTracer进行消息的路由

对于希望对WCF的消息交换有一个深层次了解的读者来说，tcpTracer绝对是一个不可多得好工具。我们将tcpTracer置于服务和服务代理之间，tcpTracer会帮助我们接获、显示和转发流经他的消息。

从 本质上讲，tcpTracer是一个路由器。当启动的时候，我们需要设置两个端口:原端口（source port）和目的端口（destination port），然后tcpTracer就会在原端口进行网络监听。一旦请求抵达，他会截获整个请求的消息，并将整个消息显示到消息面板上。随后， tcpTracer会将该消息原封不动地转发给目的端口。在另一方面，从目的端口发送给原端口的消息，也同样被tcpTracer截获、显示和转发。