使用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:[email protected]</Picture> </Person> </soap:Body> </soap:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <[email protected]> ...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:[email protected]"/></Picture> </Person> </soap:Body> </soap:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <[email protected]> ...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的類型感知編碼中進行無形的分層。