使用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 ?>

         <soap:Envelope /xml

         –MIME_boundary

         Content-Type: text/xml; charset=UTF-8

         Content-Transfer-Encoding: 8bit

         <?xml version=’1.0′ ?>

         <soap:Envelope /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得到更广泛的采用时，很容易进行升级。