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

<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+aereeOgdLkt4gCnNOEFECL8CtrJtY/taPM4A+k/ 

4E1JPnBgtCRrGWWpVkO0UqRXahz2XbShrDQnzgDwaHDf/ 

fHDXfZgpFwOgPF1IG88KQZO0JncSYKIp5I8OPYTeqD0yVhB8QSt9sWw59yzLHvU65UKoYfXA7RvOqZkJGtV6wZAgGcA= 

= 

                    </OrderByte> 

                <OrderNumber xmlns="http://wintellect.com/Order"> 

                        12345 

                    </OrderNumber> 

                </Order> 

            </SubmitOrder> 

        </s:Body> 

</s:Envelope>

// start of a boundary in the multipart message多部分消息的分界线 

--uuid:+id=1 

Content-ID: <http://wintellect.com/0> 

Content-Transfer-Encoding: 8bit 

// set the content type to xop+xml，设置内容类型xop+xml 

Content-Type: application/xop+xml;charset=utf8; type="application/soap+xml" 

<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"> 

                     // add a reference to another message part 

                    <xop:Include href=cid:http://wintellect.com/1/12345 

                     xmlns:xop="http://www.w3.org/2004/08/xop/include"/> 

                </OrderByte> 

                <OrderNumber xmlns="http://wintellect.com/Order"> 

                    12345 

             </OrderNumber> 

            </order> 

        </SubmitOrder> 

</s:Body> 

</s:Envelope> 

// end of the boundary in the first message part第一部分的内容结束边界 

--uuid:+id=1 

// add the binary data as an octect stream增加二进制数据为八位字节流 

Content-ID: <http://wintellect.com/1/12345> 

Content-Transfer-Encoding: binary 

Content-Type: application/octet-stream 

// raw binary data here这里是原始二进制数据 

　 　MTOM 编码规范规定一个 MTOM 消息能够包涵二进制数据在 base64 编码的字符里，后者二进制流在额外的消息部分里。它也表示一个基于 base64 编码的二进制数据的代表在处理的时候必须可用。换句话说，额外的消息部分可以为消息传输创建，但是内联的 base64 数据必须对一些操作如：应用数字签名临时可用。当消息处于内联的基于 base64 编码的状态，基于 XML 编码的安全机制可以被应用到 SOAP 消息里。安全机制应用结束，消息可以被序列化为多部分消息。当接受者接受消息的时候，这个消息可以被 XML 安全规范机制强制根据一些列规则进行验证。

　　非常有意思地看到，当大量二进制消息是基于 base64 编码或者二进制流编码在额外的消息部分的时候， WCF MTOM 编码器能够正确地选择序列化。 WCF 编码器使用二进制数据大小作为选择的依据。在之前的消息里， OrderBytes 元素大约 800k 。如果我们减少 OrderBytes 的大小到 128k ，在检查一下消息格式，我们可以看到：

　 这个例子里， WCF 编码器序列化二进制元素为基于 base64 编码的 string 。这个优化是相当符合 MTOM 规范。

选择恰当的编码

　　选择消息编码器强迫你去考虑当前和未来的消息使用问题。大部分来说，应用互操作性和消息里的数据类型会决定我们的选择。性能，在决定那个编码器是最适合我们系统的时候，也会考虑进来。表 2-1 基于消息类型和那种系统可以可以发送和接受消息列举了编码情况。

表  2-1: 消息编码器排列和场景
消息类型	Binary	Text	MTOM
Text 内容 ,  只与 WCF  交互	1	2	3
Text 内容 ,  与现代非 WCF 系统交互	N/A	1	2
Text 内容 ,  与旧的非 WCF systems  交互	N/A	1	N/A
大二进制内容 ,  只与 WCF  交互	1	3	2
大二进制内容 ,  与现代非 WCF 系统交互	N/A	2	1
大二进制内容 , ,  与旧的非 WCF systems  交互	N/A	1	N/A
小二进制内容 ,  只与 WCF  交互	1	2	3
小二进制内容 ,  与现代非 WCF 系统交互	N/A	1	2
小二进制内容 , ,  与旧的非 WCF systems  交互	N/A	1	N/A

不应该惊讶，二进制编码器是 WCF 与其它 WCF 系统交互最高效的编码器。我们也许吃惊的是这个事实，在端到端的情况下， MTOM 消息编码是比文本编码器效率还低。互操作性和二进制数据大小是你选择 MTOM 和文本编码器的因素。绝大多数情况， MTOM 编码消息只能发送给 MTOM 编码器的系统。写本书的时候， MTOM 是一个很新的规范，所以只有现代系统可以高效地处理 MTOM 消息。从性能的角度来看， MTOM 编码器只有当包装到消息里的二进制数据很大的时候才有意义。 MTOM 不应该用在不包括二进制数据的消息里，因为 MTOM 的性能此时比文本编码器效率更低。因此，独立测试一个在产品环境里使用的消息非常重要。

　　 幸运的是，我们可以在第 4 章： WCF 101 里看到， WCF 就是这些编码选择都不需要大的改变应用程序的方式来设计的。事实上，这使得一个服务可以与多种不同的消息编码交互成为可能。举例来说，一个服务可以与两个二进制编码和文本编码的消息交互。这个场景的好处在于当与别的 WCF 参与者通信的时候，服务可以快速执行，并且可以与别的平台通信，比如 JAVA 。