《WCF技术内幕》翻译9:第1部分_第2章_面向服务:消息编码

消息编码

随着时间的流逝,也许我们会条件反射式地认为XML(SOAP)是一个结构文本 。毕竟,文本是人可读的,每个计算机系统也可以处理文本。基于文本的XML的 普遍共性与我们的与其它系统交互的想法产生了共鸣。可以容易的解释的基于文 本的XML本质上会体积变大。可以理解使用XML会带来性能损失。就像要花费点精 力把信装到信封里一样,它需要一些处理时间与XML交互。某些情况下,基于文 本的XML数据大小限制了它的应用,特别是当我们要通过网络发送一个XML消息的 时候。

此外,如果我们限制自己使用基于文本的XML,那么我们怎么才能在XML文档 里发送二进制数据(像音乐或者视频)?如果你已经阅读了标准的XMLSchema数 据类型,你会发现2个二进制数据类型:: xs:base64Binary 和xs:hexBinary。 本质上说,两个数据类型都代表一组有序的8位字节。使用这些XML数据类型或许 可以解决一些嵌入二进制数据到文档中的问题,但是事实上,这已经使得性能问 题更加糟糕。众所周知的问题就是,base64编码会增加数据30%的大小。这个情 况对于xs:hexBinary更坏,因为它会增加位原来的2倍大小。两个数据都是基于 UTF-8编码的假设。如果我们采用UTF-16编码,这些倍数因子都会翻倍增加。

XML 信息集( XML Infoset)

为了找到性能的瓶颈的答案,我们详细来看一下XML文档的结构。如果我们看 一下规范,XML是一个精确的撰写结构化数据的语法(定义在 http://www.w3.org/TR/REC-xml/)。它要求定义格式良好的XML文档必须包涵一 个开始和结束元素、一个根节点等等。奇怪的是,XML规范发布以后,激起了抽 象定义XML文档的需求。XML信息集(定义在http://www.w3.org/TR/xml- infoset/)提供了这个抽象定义。

实际上,XML信息集定义是项目之间的关系,不定义任何具体的语法,我们能 够解释许多不同的消息编码,包括一些比文本更高校的编码格式,而不需要修改 我们的程序。

SOAP和XML信息集

记得SOAP是建立在XML之上的。这个产生一个问题:到底SOAP消息是建立在早 期的XML语法上还是XML信息集上呢?答案是2者都有。2个SOAP规范并存:SOAP 1.1 和SOAP 1.2。SOAP1.1建立在旧的XML语法上,SOAP1.2建立在XML 信息集上 。有这么一个事实,就可以猜想SOAP1.2建立的消息SOAP1.1的解析器可能无法阅 读。WCF是建立在SOAP1.2(XML信息集上),但是它可以同时处理SOAP 1.1 和 SOAP 1.2的消息。

WCF可以用来和定制与其它实际的消息编码一起工作,只要消息是遵照 SOAP1.1或者SOAP1.2的(它可以和不是SOAP消息一起工作)。如你将会在接下来 的章节里看到的一样,WCF是一个可灵活接入和组合的架构。所以自定义编码器 可以轻易地安装到WCF的管道上。当一个新的编码器开发完毕,微软或者第三方 都可以在消息堆栈里创建和插入它。我将会在第6章:《通道》里详细介绍消息 编码器。现在我们来看一下WCF里的编码器。在写本书的时候,WCF提供了三个编 码器:文本(text)、(二进制)binary、 消息传输优化机制(Message Transmission Optimization Mechanism ,MTOM)。

文本编码器

和你从它的名字里猜到的一样,文本编辑器的输出结果是基于文本编码的消 息。每个明白Unicode文本的系统都可以阅读和处理这个编码器传递来的消息, 在与别的非WCF系统互操作时,这个是一个很帮的选择。二进制数据通过 xs:base64Binary扩展样式定义(XSD)数据类型可以包涵到基于文本的消息里。 这是一个使用WCF文本编码器编码过的消息(为了清晰,移除了一部分元素)。

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap- envelope">
     <s:Header></s:Header>
     <s:Body>
       <SubmitOrder xmlns="http://wintellect.com/OrderProcess">
         <Order xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
         <OrderByte xmlns="http://wintellect.com/Order">
mktjxwyxKr/9oW/jO48IhUwrZvNOdyuuquZEAIcy08aa+HXkT3dNmvE/
+zI96Q91a9Zb17HtrCIgtBwmbSk4ys2pSEMaIzXV3cwCD3z4ccDWzpWx1/
wUrEtSxJtaJi3HBzBlk6DMW0eghvnl652lKEJcUJ6Uh/LRlZz3x1+aereeOgdLkt4gCnNO EFECL8CtrJtY/taPM4A+k/
4E1JPnBgtCRrGWWpVkO0UqRXahz2XbShrDQnzgDwaHDf/
fHDXfZgpFwOgPF1IG88KQZO0JncSYKIp5I8OPYTeqD0yVhB8QSt9sWw59yzLHvU65UKoYf XA7RvOqZkJGtV6wZAgGcA=
=
           </OrderByte>
         <OrderNumber xmlns="http://wintellect.com/Order">
             12345
           </OrderNumber>
         </Order>
       </SubmitOrder>
     </s:Body>
  </s:Envelope>

时间: 2024-08-02 19:52:47

《WCF技术内幕》翻译9:第1部分_第2章_面向服务:消息编码的相关文章

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技术内幕》翻译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技术内幕》翻译1:《WCF技术内幕》目录和作者简介

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

《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技术内幕》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技术内幕》21:第2部分_第5章_消息:WCF XML Stack 和 XmlDictionary

WCF XML Stack Microsoft .NET Framework为了多种用途的XML处理定义了一个丰富的类型集 合.作为一个消息平台,WCF比其他.NET应用需要的正常功能还要多.例如,你 在第2章:"面向服务"里看到的一样,WCF能够产生.发送.接受.处理二进制 或者MTOM编码的XML消息.因为.NET Framework没有提供这些功能,WCF API自己 定义类型来实现这些功能,我们可以使用这些类型与Message类型直接交互.换 句话说,WCF API 定义的类型