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

通道形状介绍

通道形状是我们对通道进行分类的重要依据之一。概念上,一个通道形状对 应于一个或多个消息交换模式(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接口。下面代码展示了这些接口里的 成员:

public interface ISession {
  String Id { get; }
}
public interface ISessionChannel<T> where T: ISession  {
  T Session { get; }
}

时间: 2024-11-08 21:19:22

《WCF技术内幕》33:第2部分_第6章_通道:通道形状的相关文章

《WCF技术内幕》翻译15:第1部分_第3章_消息交换模式、拓扑与编排:消息拓扑

<WCF技术内幕>翻译15:第1部分_第3章_消息交换模式.拓扑与编排:消息拓扑.消息编排和本章小结 消息拓扑 消息拓扑描述的是在一个或多个发送者和接受者之间消息如何发送的.消息拓扑可以描述简单的应用-应用的连接关系,但是它同样可以描述复杂的应用-企业的连接.在后续文章里,面向服务的应用的作用会显现出来.概括地说,这些可能存在的拓扑结构比面向组件的应用系统能够涉及到的情况会更加多.更加复杂. 某种层次上,一个消息拓扑是一个或者多个消息交换模式(MEP)的组合.实际上可能存在有无数种拓扑结构,但

《WCF技术内幕》翻译14:第1部分_第3章_消息交换模式、拓扑与编排…

<WCF技术内幕>翻译14:第1部分_第3章_消息交换模式.拓扑与编排:消息交换模式(MEP) 第3章:消息交换模式.拓扑和编排 当设计消息应用系统的时候,有必要考虑一下消息是怎样在发送者.中介者 和接受者(前面章节介绍了这些消息参与者)流转的.系统中消息交换可能性的 波动的值可以被不同程度地详细描述.这些不同级别的细节就是总所周知的消息 交换模式(MEPS).消息拓扑和消息编排[老徐备注1].当从总体来看时,这 三个级别的细节让我们抽象地描述任何消息场景.本章会详细剖析消息交换模式 (MEP

《WCF技术内幕》翻译6:第1部分_第2章_面向服务:概述、快速定义…

<WCF技术内幕>翻译6:第1部分_第2章_面向服务:概述.快速定义面向服务.理解消息 概述 互联网上充斥着面向服务(SO)的对话,大部分会话都是抽象地描述为面向 服务.这一章我们会一些不同的方法.下面一些章页,我们会站在需求的角度看 一下面向服务.更具体地说,我们将看一下一般的消息应用和需要什么才能使他 们运转.通过这个过程,我们将发掘几个理解面向服务必需的几个概念.本章的 最后几段会给出面向服务的比较正式的定义,并且会讨论一下为什么当今世界里 面向服务对于分布式计算意义重大. 如果你问10

WCF技术内幕

<WCF技术内幕>39:第2部分_第7章_通道管理器:通道工厂和本章 <WCF技术内幕>38:第2部分_第7章_通道管理器:通道侦听器 <WCF技术内幕>37:第2部分_第7章_通道管理器:概述和通道管理 <WCF技术内幕>36:第2部分_第6章_通道:创建自定义通道和本章 <WCF技术内幕>35:第2部分_第6章_通道:通道功能 <WCF技术内幕>34:第2部分_第6章_通道:通道接口和基本类型 <WCF技术内幕>33:

《WCF技术内幕》26

<WCF技术内幕>26:第2部分_第5章_消息:Buffered vs Streamed.序列化和反序列化消息 Buffered vs. Streamed消息 当我们在终结点之间流动的消息时,我们会本能地想到缓存.换个方式来说 ,我们假设程序接收到一个Message时,它已经知道整个Message.这种方式称作 缓存模式(buffering).与之相对的就是流处理模式(streaming),并且有2种 流处理模式(streaming).第一种是推模型(push model),发送者按照自己 的

《WCF技术内幕》23

<WCF技术内幕>23:第2部分_第5章_消息:XmlDictionaryReader和回到Message XmlDictionaryReader类型 XmlDictionaryReader抽象类型继承自System.Xml.XmlReader,因此继承了很 多XmlReader的特性.和XmlReader 一样,XmlDictionaryReader定义了几个工厂 方法,他们返回的是XmlDictionaryReader的子类型的实例.更确切地说, XmlDictionaryReader包装

《WCF技术内幕》翻译2:《WCF技术内幕》绪论

总述 服务是现代软件架构的一个主要部分,WCF是构建基于Microsoft Windows系 统的服务程序平台.WCF编写的服务可以与其它供应商的服务交互(例如, IBM, BEA, and Novell),WCF为行业标准的演化提供了足够的空间.对于传输,WCF 支持TCP/IP.HTTP. Microsoft消息队列 (MSMQ).命名管道.WCF同样支持一系 列WS-*规范(读作WS-星)协议,比如WS-Addressing, WS-ReliableMessaging (WS-RM), W

《WCF技术内幕》翻译1:《WCF技术内幕》目录和作者简介

翻译序言: 我现在推荐一本很好的WCF学习书籍:<Inside Microsoft Windows Communication Foundation>.Justin Smith先生所著.2007年出版至今,在亚 马逊网站上评价也比较高.综合评价4星半.是一本不错的深入学习WCF的书籍. 我在搜索了很久以后,发现这本书目前还没有中文译本.随计划翻译.分享给国 内的WCF技术爱好者.翻译工作对我个人也是一次新的尝试,希望这本书的翻译 能给大家的学习带来帮助.另外如有技术问题或翻译不当,都可以留言交

ArcGIS for Desktop入门教程_第四章_入门案例分析 - ArcGIS知乎-新一代ArcGIS问答社区

原文:ArcGIS for Desktop入门教程_第四章_入门案例分析 - ArcGIS知乎-新一代ArcGIS问答社区 1 入门案例分析 在第一章里,我们已经对ArcGIS系列软件的体系结构有了一个全面的了解,接下来在本章中,将通过一个案例来熟悉ArcGIS for Desktop的使用,从解决问题的过程中,逐渐适应ArcGIS桌面的界面和操作方式. 本章的练习数据是一个住宅小区的简单平面示意图,需要在已有的基础上把楼房的轮廓补充完整,并加以整饰,完成一幅地图. 1.1 打开地图文档并浏览

ArcGIS for Desktop入门教程_第六章_用ArcMap制作地图 - ArcGIS知乎-新一代ArcGIS问答社区

原文:ArcGIS for Desktop入门教程_第六章_用ArcMap制作地图 - ArcGIS知乎-新一代ArcGIS问答社区 1 用ArcMap制作地图 作为ArcGIS for Desktop的组成部分之一,ArcMap用于数据的浏览.编辑.显示.查询.地图排版等.ArcMap和ArcCatalog一起构成了完整的数据处理与管理分析的功能.在前一章中已经介绍了ArcCatalog的使用,本章中将介绍ArcMap的使用.本章的例子依然使用第4章里的小区平面图示例,但是将从原理的角度做更加