使用XML來(lái)傳遞消息會(huì)給您的應(yīng)用程序帶來(lái)許多好處：通過(guò)它您可以利用大量的API、跨平臺(tái)支持、以及用來(lái)描述和操縱XML（例如Xquery，XSLT，XPath和XML Schema）的通用工具。你不想關(guān)心的許多細(xì)節(jié)問(wèn)題也可以由XML來(lái)處理——比如行結(jié)束、字符編碼、結(jié)構(gòu)化數(shù)據(jù)和分界——這使您只需將精力集中于您的應(yīng)用程序。由于上述所有的原因，能使用XML是非常好的。
盡管用XML來(lái)傳遞消息存在巨大優(yōu)勢(shì)，但是其缺點(diǎn)是性能問(wèn)題：由于XML的設(shè)計(jì)方式，有些數(shù)據(jù)類(lèi)型不能很好的與XML集成。由于XML是基于文本的形式，最顯著的是二進(jìn)制數(shù)據(jù)（即不能被表示為Unicode字符集的任何東西）。
開(kāi)發(fā)人員要做什么呢？
使用URL引用
最容易的解決辦法就是在你的XML中不包括這樣的數(shù)據(jù)，而是像HTML中使用URL那樣在Web上引用它。例如，如果你的應(yīng)用程序的消息需要包含一個(gè)人的JPEG圖片，那么帶有嵌入式鏈接的XML可能如下所示：
|
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap="...">
<soap:Body>
<Person name="bob">
<Picture>http://www.example.com/people/bob.jpg</Picture>
</Person>
</soap:Body>
</soap:Envelope> |
如果數(shù)據(jù)是長(zhǎng)時(shí)間穩(wěn)定且對(duì)消息的接收者而言是可用的，這種方式能夠發(fā)揮很好的作用。然而，如果數(shù)據(jù)是短暫的，或者數(shù)據(jù)的接收者沒(méi)有連接到Web，這就不是一個(gè)好的解決辦法。為了處理這些情況，數(shù)據(jù)必須隨著消息進(jìn)行傳送。
使用編碼
把二進(jìn)制的數(shù)據(jù)放入一條基于XML的消息的最簡(jiǎn)單的方法，就是使用類(lèi)似Base64的方式對(duì)其進(jìn)行編碼，把它轉(zhuǎn)變成對(duì)XML 安全的一串字符（以及7位的MIME傳輸，XML最初就是針對(duì)它設(shè)計(jì)的）。使用Base64編碼，我們的圖片XML 可能如下所示：
|
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap="...">
<soap:Body>
<Person name="bob">
<Picture>Li4uYmluYXJ5IGpwZWcgaW1hZ2UuLi4=</Picture>
</Person>
</soap:Body>
</soap:Envelope> |
XML Schema定義了一種base64Binary類(lèi)型，這是一種足夠通用的方法，使您能夠照此識(shí)別已編碼的二進(jìn)制內(nèi)容（它也定義一種hexBinary類(lèi)型，這是一個(gè)可選的編碼模式，但還不是很流行）。
這種編碼的不利方面是它的低效率；因?yàn)閿?shù)據(jù)的二進(jìn)位形式使用有限范圍的字符集來(lái)表示豐富的數(shù)據(jù)流，它通常比base64形式更簡(jiǎn)潔。通常，對(duì)于給定的數(shù)據(jù)流，base64編碼會(huì)引入33%的冗余尺寸，從而使XML消息更大。
另外，對(duì)二進(jìn)制數(shù)據(jù)進(jìn)行編碼和解碼會(huì)造成相當(dāng)大的處理開(kāi)銷(xiāo)，這反過(guò)來(lái)會(huì)影響使用它的應(yīng)用程序的可擴(kuò)展性和性能。
使用帶附件的SOAP消息
這些問(wèn)題促成了帶附件的SOAP消息（SOAP Messages with Attachments (SwA)）的開(kāi)發(fā)。帶附件的SOAP消息是一種特定于Web Services的技術(shù)，它使用MIME Multipart/Related數(shù)據(jù)包來(lái)隨XML消息發(fā)送二進(jìn)制數(shù)據(jù)和其它附件，從而避免了編碼的開(kāi)銷(xiāo)。用于我們的圖片的一個(gè)簡(jiǎn)化的SwA消息可能如下所示：
|
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap="...">
<soap:Body>
<Person name="bob">
<Picture>cid:bob@pictures.example.com</Picture>
</Person>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <bob@pictures.example.com>
...binary JPEG image...
--MIME_boundary-- |
我們可以看到，圖像數(shù)據(jù)在一個(gè)MIME附件中。它是從帶有一個(gè)cid（URL）的SOAP消息而被引用的，這個(gè)URI使用Content-ID MIME頭的值來(lái)找到正確的附件。
這樣避免了編碼的開(kāi)銷(xiāo)和冗余，但是也帶來(lái)了一些新的問(wèn)題。XML和Web Services的大部分價(jià)值在于使用generic XML工具來(lái)處理內(nèi)容的能力——像XPat、XQuery、XSLT、XML 加密和數(shù)字簽名以及XML schema一樣。這些工具不處理非XML的內(nèi)容；如果您想要對(duì)這些內(nèi)容進(jìn)行查詢(xún)、轉(zhuǎn)換、加密、簽名或者描述，您就需要使用一種不同的機(jī)制，甚至建立一種新的機(jī)制。
此外，由于SwA還存在相當(dāng)多的互操作性問(wèn)題，以致于WS-I一直致力于研究（在寫(xiě)作本文時(shí)）適合它們的特定的互操作性配置文件。
實(shí)際上，帶有附件的SOAP消息引進(jìn)了一種新的消息數(shù)據(jù)模型，因此，它不再是基于XML的消息傳遞了。在2003年的早期，BEA公司和Microsoft公司就開(kāi)始關(guān)注并撰寫(xiě)關(guān)于這個(gè)問(wèn)題的白皮書(shū)，并且開(kāi)始探索其他可能的選擇。
MTOM和XOP的引入
在找出與SwA相關(guān)的那些問(wèn)題之后，我們開(kāi)始研究制訂一個(gè)具體的解決方案。這項(xiàng)工作從Proposed Addendum to SOAP Messages with Attachments（PASWA）開(kāi)始，并且W3C 的XML協(xié)議組（該組提出了SOAP 1.2）一直將它作為Message Transmission Optimization Mechanism（MTOM）和XML-binary Optimized Packaging（XOP）的規(guī)范加以研究。
上述內(nèi)容背后的思想很簡(jiǎn)單。 XOP是XML的可選序列化方法，使您能夠?qū)⑷魏?/SPAN>XML文檔表示為XOP數(shù)據(jù)包。在XOP數(shù)據(jù)包里，任何被命名為base64字符串的事物都作為附件進(jìn)行編碼，其方法與SwA的方法非常相似。不過(guò)，數(shù)據(jù)和附件之間的鏈接不同：它不是依靠應(yīng)用程序進(jìn)行處理，而是由該格式自行處理。
例如，當(dāng)我們圖片文檔在作為一個(gè)XOP數(shù)據(jù)包而被序列化時(shí)，可能如下所示：
|
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap="..."
xmlns:xbinc="...">
<soap:Body>
<Person name="bob">
<Picture><xbinc:Include
href="cid:bob@pictures.example.com"/></Picture>
</Person>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <bob@pictures.example.com>
...binary JPEG image...
--MIME_boundary-- |
從XML觀點(diǎn)來(lái)看，該文檔與上面的base64版本同構(gòu)；也就是說(shuō)，其中任何一種都可以編碼為另外一種，而不會(huì)造成信息的丟失。與SwA不同，XOP使用xbinc:Include元素顯式地將內(nèi)容與正確的附件關(guān)聯(lián)起來(lái)，并避免了SwA中存在的許多歧義性。它也保持XML 消息的數(shù)據(jù)模型；因?yàn)樗皇?/SPAN>XML的一種可選編碼，實(shí)際上，可以將附件中的二進(jìn)制內(nèi)容視為XML自身中的base64編碼的數(shù)據(jù)。
XOP是一個(gè)通用的機(jī)制；我們能用它來(lái)序列化任何種類(lèi)的XML。在SOAP中，MTOM使XOP串行化和反串行化成為可能，這是HTTP綁定的擴(kuò)展。隨著其他綁定被定義出來(lái)，它們也將包含XOP支持。
從API角度來(lái)看，XOP隱含著一些有趣的內(nèi)容。如果一個(gè)XML棧能夠理解XOP編碼，那么您的應(yīng)用程序就根本不需要改變；例如，當(dāng)它需要訪問(wèn)圖片時(shí)，它仍然能夠?qū)⑺@得內(nèi)容的字符值看作base64編碼字符串。如果XOP正在使用中，那么該實(shí)現(xiàn)可以即刻自動(dòng)將其編碼。
這就能夠?qū)?/SPAN>XOP透明地逐步部署到應(yīng)用程序中，但是并不能產(chǎn)生期望的性能收益。為了產(chǎn)生期望的性能收益，應(yīng)用程序需要通過(guò)使棧顯式地為它執(zhí)行base64編碼和解碼來(lái)訪問(wèn)二進(jìn)制內(nèi)容的值空間，而不是詞法空間。
實(shí)際上，這相當(dāng)容易做到。為了兼容XOP，需要用一種簡(jiǎn)單方法來(lái)擴(kuò)展XML API，從而訪問(wèn)值空間。例如，SAX定義了characters()方法來(lái)處理字符數(shù)據(jù)，包括我們的圖片元素。通過(guò)定義一種新方法——例如binary() 方法，自動(dòng)地對(duì)base64編碼的內(nèi)容進(jìn)行合適的解碼， 或者當(dāng)xbinc:Include 存在時(shí)，取消對(duì)附件的引用。應(yīng)用程序可以更容易地實(shí)現(xiàn)由XOP提供的收益。
當(dāng)我們考慮類(lèi)型感知API，（像XML beans）時(shí)，事情變得更有意思了。因?yàn)樗峁┝嗽L問(wèn)XML 內(nèi)容的詞法空間和值空間的方法，所以有可能在類(lèi)似XOP的類(lèi)型感知編碼中進(jìn)行無(wú)形的分層。
建議
在寫(xiě)作本文時(shí)，W3C仍然在開(kāi)發(fā)XOP和MTOM，但是它們進(jìn)展迅速，并且擁有來(lái)自Web服務(wù)行業(yè)的各個(gè)巨頭的充分支持。因此，我們預(yù)計(jì)XOP和MTOM將成為主流的Web Services附件機(jī)制。
另外，XML API——包括DOM，SAX，StAX和XML beans——將需要進(jìn)行修改，以實(shí)現(xiàn)由XOP帶來(lái)的好處。由于XOP得到Web Services領(lǐng)域的一致認(rèn)同及其簡(jiǎn)潔性，我們期望這種修改會(huì)迅速實(shí)現(xiàn)。
同時(shí)，最好的選擇是使用一個(gè)URI引用和編碼；對(duì)于某些應(yīng)用程序類(lèi)型而言，URI引用總是有用的，并且編碼與XOP的透明兼容性意味著，當(dāng)XOP得到更廣泛的采用時(shí)，很容易進(jìn)行升級(jí)。