WCF ——从绑定元素认识系统预定义绑定 转载 & NetTcpBinding & 信道工厂（Channel Factory）（转发）
WCF中的Binding模型之六（完结篇）：从绑定元素认识系统预定义绑定
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟... ...
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟。
四、NetTcpBinding
到此为止，我们一共介绍了三种类型的绑定。从对于传输协议的支持来看，它们都就是基于HTTP或者HTTPS的绑定；从对标准的支持看来，BasicHttpBinding提供对WS-BP 1.1的支持，WsHttpBinding和WsDualHttpBinding则对WS-*新的协议提供很好的支持，比如WS-Transactions、WS-Reliable Messaging、WS-Security等等；从消息编码的角度来看，它们均支持基于纯文本的消息编码和MTOM编码。这些属性都决定了这三种绑定具有较好的互操作性，也就是说，对于此三种绑定的应用并不限于对于基于.NET平台应用的交互，如果通过这些绑定寄宿我们的服务，其他平台的客户端可以调用我们的服务，同理我们也可以利用基于这些绑定的客户端访问其他非.NET平台的Web服务，只要对方支持相应的标准。
接下来我们要介绍的另外三种绑定，相比之下就不具有如此好的互操作性，它们只能应用于单纯的WCF客户端和服务之间的交互。它们基于不同的传输协议，我们先来介绍基于TCP传输协议的NetTcpBinding。
我们照例采用列出绑定元素列表的方式分析绑定的特性，我们先通过下面的代码看看一个采用默认构造函数创建的NetTcpBinding对象会包含哪些绑丁元素。
析一个NetTcpBinding对象在默认的情况下具有哪些特性：TcpTransportBindingElement表明采用TCP作为传输协议；WindowsStreamSecurityBindingElement提供基于Windows凭证的传输安全；BinaryMessageEncodingBindingElement实现基于二进制的消息编码；TransactionFlowBindingElement则提供对事务流转的支持。
除了WindowsStreamSecurityBindingElement，相信有了前面的介绍，读者不会感到陌生。在这里我们来简单讨论一下WindowsStreamSecurityBindingElement。WindowsStreamSecurityBindingElement继承自System.ServiceModel.Channels.StreamUpgradeBindingElement，StreamUpgradeBindingElement是一种特殊的绑定元素。前面我们讲了，绑定元素的使命在于对相应信道的创建，而StreamUpgradeBindingElement的特别之处在于它并会参与信道的创建。StreamUpgradeBindingElement一般应用于基于流的传输（Stream Oriented Transport），比如TCP、命名管道等等。它一般位于TransportBindingElement之上，在传输层基础上提供进一步的升级处理（Transport Upgrade），比如安全加密、压缩等等。WindowsStreamSecurityBindingElement在这里的提供基于Windows客户端凭证的传输安全，与之相对的，还有一个System.ServiceModel.Channels.SslStreamSecurityBindingElement，提供基于SSL的传输安全。如果我们将绑定的客户端凭证的类型改成Certificate或者None，SslStreamSecurityBindingElement将会被采用：
实际上，如果采用消息安全模式，SymmetricSecurityBindingElement将会添加进来实现基于消息级别的签名、加密安全措施。这也可以从下面的输出结果看出来：
除了单纯的传输安全模式和消息模式之外，NetTcpBinding还支持一种混合的安全模式，该模式的SecurityMode枚举值表示为：SecurityMode.TransportWithMessageCredential。该模式通过传输安全保障数据的一致性和保密性，通过消息安全提供身份验证。关于不同种类的安全模式，将在“安全”一章中进行详细讲解。SslStreamSecurityBindingElement和TransportSecurityBindingElement一起提供该模式的安全
和WsHttpBinding一样，NetTcpBinding也提供对可靠会话的支持，以保障数据包或者消息的可靠、有序传递。不过与WsHttpBinding的实现机制不同的是，基于NetTcpBinding是采用TCP协议固有的可靠传输机制，比如消息确认机制、重发机制等等。下面的代码，通过ReliableSession.Enabled属性让绑定实现对可靠会话的支持：
和WsHttpBinding一样，通过ReliableSessionBindingElement实现对可靠会话的支持：
由于NetTcpBinding采用TCP作为传输协议，所以它一般只应用于Intranet中；由于采用二进制的消息编码方式，在性能上较之基于文本的编码会有较大的提高；此外，由于和HTTP协议不同，TCP本身就是一个基于双工通信的协议，所以和WsDualBinding一样可以用于基于双工消息交换模式的WCF应用中。
从整个基础构架的层次结构上讲，WCF可以分成两个部分：服务模型层（Service Mode Layer）和信道层（Channel Layer）。服务模型层建立在信道层之上，提供了一个统一的、可扩展的编程模型。信道层则通过绑定（Binding）建创的信道栈为消息通信提供了一个传输、处理的通道。
从整个基础构架的层次结构上讲，WCF可以分成两个部分：服务模型层（Service Mode Layer）和信道层（Channel Layer）。服务模型层建立在信道层之上，提供了一个统一的、可扩展的编程模型。信道层则通过绑定（Binding）建创的信道栈为消息通信提供了一个传输、处理的通道。
[第1篇] Binding模型简介
对于一个分布式应用的开发与设计来说，通信问题是不得不考虑，同时也是最为复杂、最难实现的问题。在过去的若干年中, 微软先后推出了一系列广受欢迎的通信技术, 比如DCOM、Enterprise Service、.NET Remoting、XML Web Service、MSMQ等等。这些技术提供了各自的编程模型，是开发人员从繁琐的完全基于通信的编程中解脱出来，使之仅仅需要关注具体的业务逻辑。 WCF是所有的这些通信技术集大成者，它充分地整合了所有这些使用于不同领域、不同场景的通信技术，提供了一个统一的编程模型。
无论从功能上讲，还是从WCF的整个基础构架的层次结构上讲，WCF可以分成两个不部分：编程模型和通信实现。编程模型通过WCF服务模型层（service mode layer）提供，而信道层 (channel layer) 则提供了具体的通信的实现。服务模型层建立在信道层之上，对于一般的WCF开发人员来讲，他们仅仅会接触到服务模型层，信道层则是被屏蔽掉的。而绑定是整个信道层的缔造者。
[第2篇] 信道与信道栈（Channel and Channel Stack）
WCF采用基于消息交换的通信方式，而绑定则实现了所有的通信细节。绑定通过创建信道栈实现了消息的编码与传输，以及对WS-*协议的实现。WCF绑定模型涉及多种类型的组件，比如信道、信道监听器、信道工厂等等。从功能上讲，这些对象都是为通信服务的，我们可以把它们称为通信对象（Communication Object）。对于这些通信对象来说，在通信不同的阶段，它们往往具有不同的状态；从整个通信的生命周期来看，在不同阶段过渡的过程中，它们具有一些相似的状态转换方式……
[第3篇] 信道监听器（Channel Listener）
信道管理器是信道的创建者，一般来说信道栈的中每个信道对应着一个信道管理器。基于不同的消息处理的功能，将我们需要将相应的信道按照一定的顺序能组织起来构成一个信道栈，由于信道本身是由信道管理器创建的，所以信道对应的信道管理器也构成一个信道管理器栈，栈中信道管理器的顺序决定由它所创建信道的顺序。
对于WCF的信道层来说，信道管理器在服务端和客户端扮演着不同的角色，服务端的信道管理器在于监听来自客户端的请求，而客户端的信道仅仅是单纯的创建用于消息发送的信道。因此，客户端的消息管理器又称为信道监听器（Channel Listener），客户端的信道管理器则成为信道工厂（channel factory）。 在WCF中，所有的信道管理器，不管是位于服务端的信道监听器还是客户端的信道工厂，都继承自一个基类： .ChannelManagerBase。
其实我们完全可以把一个WCF应用开成是一个普通的基于监听-请求模式的网络应用，服务端将监听器绑定到一个或一组URI上进行网络监听，一旦成功监听到来自客户端的请求，则接收、处理该请求，如需回复则发送回复回客户端。在整个过程中，监听器处于核心的地位，而WCF中的信道监听器就起着这样的作用。
[第4篇] 信道工厂（Channel Factory）
由于信道管理器在客户端和服务端所起的不同作用，分为信道监听器和信道工厂。和服务端的信道监听其相比，处于客户端的信道工厂显得简单。从名称就可以看得出来，信道工厂的作用就是单纯的创建用于消息发送的信道。
[第5篇] 绑定元素（Binding Element）
在上面的内容中，先后介绍了信道、信道管理器、信道监听器和信道工厂。从对象的创建来讲，信道管理器是信道的创建者。说的再具体点，客户端的信道通过信道工厂创建，服务端的信道通过信道监听器创建。但是信道工厂和信道监听器又是如果被创建出来的呢？
我们在一开始就已经说过，作为终结点三要素的绑定对象实现了所有的通信细节，并且通过创建信道栈实现了消息的传递。从这一点来说，绑定对象无疑是信道层所有通信对象的最终缔造者，所以信道工厂和信道监听器最终的创建都是靠绑定对象实现的。关于这个创建过程又和另一个重要的对象密切相关，那就是绑定元素。
绑定元素，顾名思义就是构成一个绑定对象的元素。绑定对象最根本的目的就是创建信道栈，借此实现对消息的传输、编码和基于消息交换的其他功能，比如安全、可靠传输、事务流转等等。组成信道栈的单个信道对象基于对某项单一功能的实现，在不同环境中，我们需要根据具体的需要创建相应的信道，并根据一定的顺序把这些信道组成一个完整的信道栈。对于绑定对象来说，如何实现这种灵活、自由的信道常创建方式，这得益于基于绑定元素的设计模式。
[第6篇] 从绑定元素认识系统预定义绑定
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟。
作者：Artech
-----------------------------------
《WCF的绑定模型》博文系列汇总[共6篇]
https://blog.51cto.com/u_15061935/4757296
-----------------------------------
WCF中的Binding模型之六（完结篇）：从绑定元素认识系统预定义绑定
https://blog.51cto.com/u_15076215/4759121
艾伟：[WCF的Binding模型]之四：信道工厂（Channel Factory）
由于信道管理器在客户端和服务端所起的不同作用，分为信道监听器和信道工厂。和服务端的信道监听其相比，处于客户端的信道工厂显得简单。从名称就可以看得出来，信道工厂的作用就是单纯的创建用于消息发送的信道。我们先来看看与信道工厂相关的一些接口和基类的定义
一、信道工厂相关的接口和基类
对于信道监听器，WCF定义了两个接口：IChannelListener和IChnnelListener。与之相对地，WCF也为信道工厂定义了两个接口：IChannelFactory和IChannelFactory
由于信道工厂的目的就是单纯的创建信道，所以IChannelFactory和IChannelFactory的定义显得格外简洁。两个重载的CreateChannel方法通过目的终结点的地址（to），以及在手工寻址下不同于目的终结点地址的另一个地址，该地址是消息实际会被发送的地址（via）。关于To和Via可以参考第二章关于物理地址和逻辑地址的部分。
除了上面的两个接口之外，WCF还定义分别是实现了它们的两个抽象基类：ChannelFactoryBase和ChannelFactoryBase。ChannelFactoryBase继承自所有信道管理器的基类：CnannelManagerBase，而ChannelManagerBase又继承自CommunicationObject，实现ICommunicationObject接口定义的基本的状态属性和状态转换功能。并且实现了接口IChannelFactory和ICommunicationObject。而ChannelFactoryBase继承自CnannelManagerBase，并且实现了接口：IChannelFactory, IChannelFactory和ICommunicationObject。一般地，范型类型TChannel为基于相应channel shape下客户端信道类型，比如IOutputChannel、IRequestChannel和IDuplexChannel。ChannelFactoryBase和ChannelFactoryBase的简单定义如下：
-----------------------------------
下面的类图简明直观的表述了WCF中关于信道工厂的体系结构。
二、案例演示：如何自定义信道工厂
在上一个案例中，我们创建了一个自定义的信道监听器：SimpleReplyChannelListner。该信道监听器用于在请求-回复消息交换模式下进行请求的监听。在本案例中，我们来创建与之相对的信道工厂：SimpleChannelFactory，用于请求-回复消息交换模式下进行用于请求发送信道的创建。由于SimpleChannelFactory的实现相对简单，将所有代码一并附上。
SimpleChannelFactory直接继承自抽象基类SimpleChannelFactoryBase。字段成员_innerChannelFactory表示信道工厂栈中后一个信道工厂对象，该成员在构造函数中通过传入的BindingContext对象的BuildInnerChannelFactory方法创建。OnCreateChannel是核心大方法，实现了真正的信道创建过程，在这里我们创建了我们自定义的信道：SimpleRequestChannel.。构建SimpleRequestChannel. 的InnerChannel通过_innerChannelFactory的CreateChannel方法创建。对于其他的方法（OnOpen、OnBeginOpen和OnEndOpen），我们仅仅通过PrintHelper输出当前的方法名称，并调用_innerChannelFactory相应的方法。
艾伟：[WCF的Binding模型]之四：信道工厂（Channel Factory）
https://blog.51cto.com/u_15127691/4001086
