《WCF技术内幕》翻译33:第2部分_第6章_通道:通道形状

  1. 云栖社区>
  2. 博客>
  3. 正文

《WCF技术内幕》翻译33:第2部分_第6章_通道:通道形状

技术小胖子 2017-11-07 18:32:00 浏览596
展开阅读全文
Chapter 6: Channels
6章:通道(Channel
Overview
概述
Channels in Perspective
正确认识Channel
The Channel State Machine
通道状态机
Introduction to Channel Shape
通道形状
Channel Interfaces and Base Types
通道接口和基本类型
Channel Flavors
通道功能
Creating a Custom Channel
自定义通道
Summary
本章小结
通道形状介绍
通道形状是我们对通道进行分类的重要依据之一。概念上,一个通道形状对应于一个或多个消息交换模式(MEPs),第3章“消息交换模式、拓扑与编排”里曾经讨论过这个概念。为了说明问题,考虑一下发送者和接收者使用请求/应答模式来交换消息的情况。在请求/应答模式里,发送者发送消息给接收者,接收者回复消息给发送者,请求消息和应答消息之间的关系是固定的。因为通道是发送者和接收者交换消息的物理途径,发送者和接收者必须建立它们自己的通道。当发送者和接收者通过请求/应答模式来交换消息的时候,发送者和接收者必须理解请求/应答模式的规则。在结构上来说,这意味着发送者上的通道要定义发送消息和接收消息的成员。此外,发送者和接收者需要定义关联请求消息和应答消息的成员。
咋一看,发送者和接收者有着相同的角色。例如,发送者和接收者都可以发送和接收消息。逻辑上的区别就是发送和接收消息过程中的顺序不同。这意味着发送者和接收者上的通道会略有不同。这些不同点体现在发送者和接收者通道里定义的成员上。通道形状是我们命名和划分这些不同点的方式。因为.NET接口是鉴别.NET类型成员的天然方式,所以它们也是区别通道形状的最佳方式。
WCF类型系统定义了几个描述不同通道形状的接口,这些接口与第三章里讲述的消息交换模式一一对应。图6-2列举了消息交换模式(MEP)、发送者和接受之间的对应关系。这些接口都定义在System.ServiceModel.Channels命名空间下。
图6-2消息交换模式(MEP)与通道形状的关系
MEP
Sender
Receiver
数据报
IOutputChannel
IInputChannel
请求/应答
IRequestChannel
IReplyChannel
双工
IDuplexChannel
IDuplexChannel
P2P
IDuplexChannel
IDuplexChannel
 
注意,这里报文和请求/应答模式的接口是不同的。对于报文MEP,发送者发送一个消息,但是不能接收消息,而请求/应答模式是可以的。记住,IOutputChannel 定义了一个名为Send的方法,而IInputChannel定义了一个名为Receive的方法。
这里还需要解释一下表6-2里的双工MEP。记住双工MEP里,发送者和接收者都可以发送和接受消息。在成员级别上,两者都可以定义一个名为一个名为Send和一个名为Receive的方法。
实际上,消息程序需要把多个消息关联到一起。例如,一个交易系统(发送者)也许要发送关于一个交易订单或者产品的多个消息到财务系统(接收者)。这个关联的逻辑边界就是会话(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接口。下面代码展示了这些接口里的成员:
InBlock.gifpublic interface ISession { 
InBlock.gif 
InBlock.gif String Id { get; } 
InBlock.gif 
InBlock.gif
InBlock.gif 
InBlock.gifpublic interface ISessionChannel<T> where T: ISession { 
InBlock.gif 
InBlock.gif T Session { get; } 
InBlock.gif 
InBlock.gif}
如代码所示,接口暴露了一个名为Id的成员,这个成员表示一个会话标识符。在WCF里,实现了ISessionChannel<T>接口的通道类型被称为会话通道。为了连贯性考虑,WCF里把会话作为通道形状的一个变量考虑。换句话说,IDuplexChannel接口包含一个名为IDuplexSessionChannel的变量。从通道形状的角度来看,IDuplexSessionChannel与IDuplexChannel的通道形状不同,尽管它们都能够实现双工通信。两者真正的区别在于IDuplexSessionChannel实现了ISessionChannel<T>接口。表6-3列举了WCF类型系统里的会话通道形状.
6-3消息交换模式(MEP)与会话通道形状的关系
MEP
Sender
Receiver
数据报
IOutputSessionChannel
IInputSessionChannel
请求/应答
IRequestSessionChannel
IReplySessionChannel
双工
IDuplexSessionChannel
IDuplexSessionChannel
P2P
IDuplexSessionChannel
IDuplexSessionChannel
 
备注:与上一节里介绍的“通道状态机”相反,这里只有通道才会实现通道形状接口,并且需要一个表示通道形状接口的引用。
【老徐备注】

1.三种 MEP:

  • 数据报(IInputChannel  IOutputChannel
    使用数据报 MEP 时,客户端使用“启动后不管”的交换形式发送消息。“启动后不管”交换形式是一种要求对成功传递做带外确认的交换形式。消息在传输过程中可能会丢失,而永远不能到达服务。如果在客户端成功完成发送操作,这并不保证远程终结点已经收到消息。数据报是消息传递的基本构造块,因为您可以在它上面构建自己的协议,包括可靠的协议和安全的协议。客户端数据报通道实现 IOutputChannel 接口,而服务数据报通道实现 IInputChannel 接口。
  • 请求-响应(IRequestChannel  IReplyChannel
    在此 MEP 中会发送一个消息并收到一个答复。此模式由请求-响应对组成。请求-响应调用的示例是远程过程调用 (RPC) 和浏览器的 GET 请求。此模式也称为半双工。在此 MEP 中,客户端通道实现 IRequestChannel,而服务通道实现 IReplyChannel。
  • 双工 (IDuplexChannel)
    双工 MEP 允许客户端发送任意数量的消息,并且这些消息可以以任何顺序接收。双工 MEP 就像电话通话,所说的每一个字都是一条消息。由于在这种 MEP 下双方都能发送和接收,由客户端和服务通道实现的接口是 IDuplexChannel。
http://msdn.microsoft.com/zh-cn/library/aa751829.aspx



 本文转自 frankxulei 51CTO博客,原文链接:http://blog.51cto.com/frankxulei/318569,如需转载请自行联系原作者


网友评论

登录后评论
0/500
评论
技术小胖子
+ 关注