MTOM是W3C消息传输优化机制,一种有效地发送和接收二进制数据的Web服务方法。
总体上,它是如何工作的呢?
一切都始于SOAP是XML这个事实。当您发送除文本以外的任何内容时,例如图像-它必须转换为XML处理器可以理解的数据类型。
如果没有MTOM,您的图像将被转换为base64Binary并放置在SOAP信封的中心位置。这种转换过程使数据变得臃肿。
<tns:data>一个非常长的base64Binary字符串</tns:data>
这里是一个简单的说明:
使用MTOM,图像将作为MIME附件以其原始数据类型(即jpg、png或gif)发送,位于信封之外。当然,它仍然以二进制数据传输,但这次没有与XML相关的转换,从而避免了计算开销。 XOP则会给出外部化图像的位置。
<soap:Envelope>
<soap:Body>
<tns:data>
<xop:include href="SomeUniqueID-ThatLeadsToTheImage"/>
</tns:data>
</soap:Body>
</soap:Envelope>
内容标识: "SomeUniqueID"
内容类型: image/png这里是图像二进制数据
在其他答案没有提到的几个因素中,有人可能会想为什么MTOM不作为默认方式使用,因为它比文本消息编码(Base64)更快。这是因为MTOM并不总是更快。只有在传输大型消息时才应该使用MTOM,因为它会增加开销。对于小尺寸的消息,MTOM的性能将会比文本消息编码(Base64)更差。
如果用于大型消息,MTOM比Base64更快,因为它使用原始二进制进行数据传输。要理解这一点,就应该了解Base64的工作原理。
Base64使用6位(log2(64))来表示1个字符,这意味着Base64使用4个字符来表示24位(3字节)。因此,如果消息大小为n个字节,则Base64将使用4 *(n / 3)个字节来表示数据,这意味着它将比MTOM慢1/3。
Content-ID: "SomeUniqueID"
,可以使用<xop:include href="cid:SomeUniqueID" />
(其中cid
指的是另一个消息部分的Content-ID
标头),而这种 HTTP 请求的Content-Type
标头看起来类似于Content-Type: multipart/related; type="application/xop+xml"; start="root-Content-ID"; start-info="text/xml"; boundary="my-multipart-boundary"
。 - gknicker