《WCF技术内幕》30:第2部分_第5章_消息:复制消息、消息清理和本章小结

复制消息

有时候需要从现有的一个消息实例创建一个缓存模式的消息拷贝。Message类 型定义了实现此目的的实例方法:

public MessageBuffer CreateBufferedCopy(Int32  maxBufferSize) { ... }

创建Message的拷贝还是相当简单的,但是这会带来消息内部状态的改变。如 果使用不当,这个状态改变会给我们要复制的消息对象带来一些问题。当调用 CreateBufferedCopy方法时,新消息的state属性必须是MessageState.Created 。如果设置为其它状态,此方法就会抛出一个InvalidOperationException异常 。直到CreateBufferedCopy返回结果,原调用实例的状态才会变为 MessageState.Copied。如果此方法调用成功,则会返回一个 System.ServiceModel. Channels.MessageBuffer类型的实例。MessageBuffer定 义了一个实例方法CreateMessage,它会返回一个Message类型实例。这个实例的 状态会是Message.Created。下面代码演示了如何复制一个消息:

Message msg = Message.CreateMessage (MessageVersion.Default,"urn:SomeAction","Something in the body");

Console.WriteLine("Starting Message state: {0}\n",  msg.State);
Console.WriteLine("Message:\n{0}\n", msg.ToString());

MessageBuffer buffer = msg.CreateBufferedCopy (Int32.MaxValue);
Console.WriteLine("Message state after copy: {0}\n",  msg.State);
Message msgNew = buffer.CreateMessage();
Console.WriteLine("New Message State: {0}\n",msgNew.State);
Console.WriteLine("New Message:\n{0}\n", msgNew.ToString ());

运行代码,输入结果如下:

Starting Message state: Created

Message:

<s:Envelope  xmlns:a="http://www.w3.org/2005/08/addressing"
  xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
     <a:Action  s:mustUnderstand="1">urn:SomeAction</a:Action>
  </s:Header>
  <s:Body>
     <string  xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
       Something in the body</string>
  </s:Body>
</s:Envelope>

时间: 2024-09-15 04:22:15

《WCF技术内幕》30:第2部分_第5章_消息:复制消息、消息清理和本章小结的相关文章

《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技术爱好者.翻译工作对我个人也是一次新的尝试,希望这本书的翻译 能给大家的学习带来帮助.另外如有技术问题或翻译不当,都可以留言交

《WCF技术内幕》20:第2部分_第5章_消息:Message类型介绍

第5章:消息 System.ServiceModel.Channels.Message抽象类型是Microsoft Windows Communication Foundation (WCF)里通信的基本单位.尽管Message类型使用在 WCF 程序里,但是WCF的开发人员却不需要直接接触Message.因此,可以不与任 何Message的实例交互就能写出一个功能丰富的WCF程序.但是,虽然你的代码没 有直接与Message对象交互,记住WCF基础结构也在背后忙于创建.发送.接受或 者其它处理

《WCF技术内幕》翻译8:第1部分_第2章_面向服务:消息剖析、消息传输

消息剖析 小时候,我们学习到邮票应该贴在信封的右上角,地址应该写在中间.如果 我们愿意,可以增加一个回复地址在信封的左上角.所有被处理的信件必须遵守 这个基本的结构.如果格式不对,或者地址不清晰,或者地址不合法,邮政服务 会认为这个邮件无效,并且无法投递.如果我们幸运的话,邮件会被退回(如果 写地址的话).可以想象没写地址有多混乱.如果发送者可以允许乱放邮票或者 地址,邮政服务需要查遍整个信封来确定邮票和地址.很可能,为了完成新加投 递任务,每次可能要增加远多于2美分的邮资.实际上,邮局定义的信