WCF开发插件的应用在一定程度上大大提高了开发人员的开发效率，尤其是在通信方面的操作，提供了一个简单的操作方法。在这里我们将会针对WCF通道形状的相关内容，为大家详细讲解这方面的知识。#t#
WCF通道形状是我们对通道进行分类的重要依据之一。概念上，一个通道形状对应于一个或多个消息交换模式（MEPs）。为了说明问题，考虑一下发送者和接收者使用请求/应答模式来交换消息的情况。在请求/应答模式里，发送者发送消息给接收者，接收者回复消息给发送者，请求消息和应答消息之间的关系是固定的。因为通道是发送者和接收者交换消息的物理途径，发送者和接收者必须建立它们自己的通道。当发送者和接收者通过请求/应答模式来交换消息的时候，发送者和接收者必须理解请求/应答模式的规则。在结构上来说，这意味着发送者上的通道要定义发送消息和接收消息的成员。此外，发送者和接收者需要定义关联请求消息和应答消息的成员。
咋一看，发送者和接收者有着相同的角色。例如，发送者和接收者都可以发送和接收消息。逻辑上的区别就是发送和接收消息过程中的顺序不同。这意味着发送者和接收者上的通道会略有不同。这些不同点体现在发送者和接收者通道里定义的成员上。WCF通道形状是我们命名和划分这些不同点的方式。因为.NET接口是鉴别.NET类型成员的天然方式，所以它们也是区别通道形状的最佳方式。
WCF类型系统定义了几个描述不同WCF通道形状的接口，这些接口与消息交换模式一一对应。消息交换模式（MEP）、发送者和接受之间的对应关系。这些接口都定义在System.ServiceModel.Channels命名空间下。
实际上，消息程序需要把多个消息关联到一起。例如，一个交易系统（发送者）也许要发送关于一个交易订单或者产品的多个消息到财务系统（接收者）。这个关联的逻辑边界就是会话（session）。当第一次考虑这些会话的时候，很容易理解为接收者会根据发送者来关联这些消息。这样一来，很自然地就会猜想，同时处理5个发送者请求的接收者将会把消息关联到一个特定的发送者上，正像ASP.NET程序处理来自于多个浏览器的请求消息一样。在WCF应用程序里，这些耦合过于紧密以至于不能满足过多的消息需求。例如，一个交易系统（发送者）或许发送多个订单有关的消息，财务系统（接收者）也许要根据需订单实例而不是交易系统（发送者）来关联这些消息。
WCF会话是一个通道级别的构造。因为这个概念也就是为了关联消息，每个通道都自己关联消息的方式。例如，TCP/IP通道能够根据接收消息的socket来关联同一个会话里的消息。与之相对的是，实现了WS-ReliableMessaging规范的通道，可以在消息头里使用ID属性来关联同一个会话里的消息，所以，这也就不需要依赖具体的socket或者传输结构了，就可以实现同一个会话里消息的关联。
所有支持会话的通道的一个共同特性就是它们可以拥有自己的标识符，WCF基础结构里的不同模块都可以使用这个标识符来关联消息。概念上看，通道需要实现System.ServiceModel.Channels.ISessionChannel<T>接口来会支持会话。ISessionChannel<T>的泛型参数必须实现System.ServiceModel.Channels.ISession接口。下面代码展示了这些接口里的成员：
- public interface ISession {
- String Id { get; }
- }
- public interface ISessionChannel<T> where T: ISession {
- T Session { get; }
- }
如代码所示，接口暴露了一个名为Id的成员，这个成员表示一个会话标识符。在WCF里，实现了ISessionChannel<T>接口的通道类型被称为会话通道。为了连贯性考虑，WCF里把会话作为通道形状的一个变量考虑。换句话说，IDuplexChannel接口包含一个名为IDuplexSessionChannel的变量。从WCF通道形状的角度来看，IDuplexSessionChannel与IDuplexChannel的通道形状不同，尽管它们都能够实现双工通信。两者真正的区别在于IDuplexSessionChannel实现了ISessionChannel<T>接口。表6-3列举了WCF类型系统里的会话通道形状.
