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

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。

中，我们通过一个直接借助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）

• 如何根据不同的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来展开介绍。

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

[第8篇] 通过WCF Extension 实现与MS Enterprise Library Policy Injection Application Block 的集成

[第9篇]通过WCF的双向通信实现Session管理

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

[第11篇]关于并发、回调的线程关联性（Thread Affinity）

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

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若干种不同的实现方式。

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

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

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

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

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

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

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

 

 

作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及着作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

原文链接