理解Web Services附件

使用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的类型感知编码中进行无形的分层。