<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Chapter 6: Channels</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">第6章:通道(Channel)</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Overview</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">概述</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Channels in Perspective</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">正确认识Channel</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">The Channel State Machine</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道状态机</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Introduction to Channel Shape</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道形状</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Channel Interfaces and Base Types</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道接口和基本类型</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Channel Flavors</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">通道功能</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Creating a Custom Channel</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">自定义通道</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">Summary</a>
<a href="http://frankxulei.blog.51cto.com/1596834/318569" target="_blank">本章小结</a>
通道形状是我们对通道进行分类的重要依据之一。概念上,一个通道形状对应于一个或多个消息交换模式(MEPs),第3章“消息交换模式、拓扑与编排”里曾经讨论过这个概念。为了说明问题,考虑一下发送者和接收者使用请求/应答模式来交换消息的情况。在请求/应答模式里,发送者发送消息给接收者,接收者回复消息给发送者,请求消息和应答消息之间的关系是固定的。因为通道是发送者和接收者交换消息的物理途径,发送者和接收者必须建立它们自己的通道。当发送者和接收者通过请求/应答模式来交换消息的时候,发送者和接收者必须理解请求/应答模式的规则。在结构上来说,这意味着发送者上的通道要定义发送消息和接收消息的成员。此外,发送者和接收者需要定义关联请求消息和应答消息的成员。
咋一看,发送者和接收者有着相同的角色。例如,发送者和接收者都可以发送和接收消息。逻辑上的区别就是发送和接收消息过程中的顺序不同。这意味着发送者和接收者上的通道会略有不同。这些不同点体现在发送者和接收者通道里定义的成员上。通道形状是我们命名和划分这些不同点的方式。因为.NET接口是鉴别.NET类型成员的天然方式,所以它们也是区别通道形状的最佳方式。
WCF类型系统定义了几个描述不同通道形状的接口,这些接口与第三章里讲述的消息交换模式一一对应。图6-2列举了消息交换模式(MEP)、发送者和接受之间的对应关系。这些接口都定义在System.ServiceModel.Channels命名空间下。
图6-2消息交换模式(MEP)与通道形状的关系
MEP
Sender
Receiver
数据报
IOutputChannel
IInputChannel
请求/应答
IRequestChannel
IReplyChannel
双工
IDuplexChannel
P2P
这里还需要解释一下表6-2里的双工MEP。记住双工MEP里,发送者和接收者都可以发送和接受消息。在成员级别上,两者都可以定义一个名为一个名为Send和一个名为Receive的方法。
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的变量。从通道形状的角度来看,IDuplexSessionChannel与IDuplexChannel的通道形状不同,尽管它们都能够实现双工通信。两者真正的区别在于IDuplexSessionChannel实现了ISessionChannel<T>接口。表6-3列举了WCF类型系统里的会话通道形状.
图6-3消息交换模式(MEP)与会话通道形状的关系
IOutputSessionChannel
IInputSessionChannel
IRequestSessionChannel
IReplySessionChannel
IDuplexSessionChannel
<a></a>
备注:与上一节里介绍的“通道状态机”相反,这里只有通道才会实现通道形状接口,并且需要一个表示通道形状接口的引用。
【老徐备注】
使用数据报 MEP 时,客户端使用“启动后不管”的交换形式发送消息。“启动后不管”交换形式是一种要求对成功传递做带外确认的交换形式。消息在传输过程中可能会丢失,而永远不能到达服务。如果在客户端成功完成发送操作,这并不保证远程终结点已经收到消息。数据报是消息传递的基本构造块,因为您可以在它上面构建自己的协议,包括可靠的协议和安全的协议。客户端数据报通道实现 IOutputChannel 接口,而服务数据报通道实现 IInputChannel 接口。
在此 MEP 中会发送一个消息并收到一个答复。此模式由请求-响应对组成。请求-响应调用的示例是远程过程调用 (RPC) 和浏览器的 GET 请求。此模式也称为半双工。在此 MEP 中,客户端通道实现 IRequestChannel,而服务通道实现 IReplyChannel。
双工 MEP 允许客户端发送任意数量的消息,并且这些消息可以以任何顺序接收。双工 MEP 就像电话通话,所说的每一个字都是一条消息。由于在这种 MEP 下双方都能发送和接收,由客户端和服务通道实现的接口是 IDuplexChannel。
http://msdn.microsoft.com/zh-cn/library/aa751829.aspx
本文转自 frankxulei 51CTO博客,原文链接:http://blog.51cto.com/frankxulei/318569,如需转载请自行联系原作者