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

《WCF技术内幕》翻译8：第1部分_第2章_面向服务:消息剖析、消息传输2011-05-28 博客园译:Frank Xu Lei消息剖析

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

与邮寄信件的例子相反，SO消息不需要在遵守结构模式。像邮寄信件的例子，一个定义好的信封格式改进提高工作效率，可靠性和系统的功能。记住消息应用系统概念不是新的。起源于各种各样不同厂商的消息已经经历过了几十年来应用的发展。没有标准的结构，各个厂商偶读可以开发自己的消息架构，结果就是这些千差万别的消息架构不能够用来进行系统间的互操作。

如果我们看一下FedEx, UPS, 和DHL这些公司，我们可以看到一个相似的模式。每个组织已经定义好的他们自己的地址格式和打包规范。很难看到一个贴着 UPS标签的过夜包裹在FedEx 公司里投递。技术角度来说是可行的，但是商业压力和效率阻碍了这些公司于另外一个公司的地址格式和包装标准通用。

用相同的概念检验一个可收购企业的计算系统并不苦难。总体来说，厂商不希望自己的应用系统可以与其他的系统交互。他们有足够的时间让自己的系统与单个设备通信，单独与其它系统互操作。过去，客户希望，在一定程度上，用一个厂商的工具集解决他们所有的企业需求。客户面对的选择是“谁能卖给我这样的完整包裹？”而不是“那个产品最适合我的每个需求？”。随着社会发展，一站式销售很难满足潜在的客户。结果，软件厂商不得不坐到一起来开会，来制定一些列公共消息规范和标准，让他们的应用系统产生的消息遵守这些规范。为了这些标准的简历和通过，已经花费的很多年时间，但是最终这些标准诞生，并且我们可以希望这些标准日益完善。

有许多关于消息标准的文章，在阅读本书的时候我们可以多次提到这些标准。这些规范是，不论哪种形式，许多都是基于SOAP，并且每个规范的作用不同。出于学习上的好奇心，完全的SOAP消息规范可以在这里查看： http://www.w3.org/TR/soap12-part1/。由于SOAP的灵活性，现在SO消息的消息都是SOAP消息。SOAP，它的核心，是一个基于XML的消息结构。SOAP定义了3个主要的可以定义任意XML消息的XML元素：信封，消息主体和消息头。这里是个简单的SOAP消息的例子:

<？xml version="1.0" ？>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap- envelope">
<env:Header>

      </env:Header>
  <env:Body>

  </env:Body>
</env:Envelope>

因为WCF一个为了与其它系统互操作的SO平台，它发送、接受和处理SOAP消息。正像你将会再第4章：“WCF101”里看到的一样，我们可以认为WCF是一个可以用无数行为来创建、发送和解析消息的工具包。目前，我们可以弄清楚所有的 SOAP消息的共同点。

消息信封

正如名字的含义一样，消息信封包装消息体和消息头。所有的SOAP消息都有一个消息信封作为根元素。消息信封经常被用来定义不同的贯穿消息的命名空间（和前缀）。这令人对SOAP消息非常兴奋。