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