Web 服务协议已经从支持带有简单参数的非常简单的请求，发展到对现代的面向对象语言的完整支持。 XML-RPC 看来是 Web 服务的早期形式之一，仅仅支持简单类型 ―― 字符串、整数、布尔值等等。SOAP 向前迈出了一步，有了用于对象的编码规则。最近的发展 ―― 在二进制数据方面的改进 ―― 来自带附件的 SOAP。

　　带附件的 SOAP 最初是作为 SOAP 1.1 的扩展提出的，得到了主流 SOAP 工具箱的支持。尽管 W3C 正式发布的 SOAP 1.2 还不支持附件，但是正努力实现在不远的将来(理想情况下)把它包含进来。

　　Web 服务与二进制数据

　　我毫不怀疑 XML 在应用程序集成中取得的成功，源自于对文本性编码的依赖(与二进制协议相对而言，如 CORBA ——一种面向对象的 RPC 协议，RMI ―― Java 专用的 RPC 标准)。优先选择文本性编码有几种原因，但最重要的可能是因为它容易调试，而且如果必要的话容易完成专门的实现。

　　对文本性编码的依赖仍然有不利的一面，XML 对引入二进制数据没有提供有效的解决方案。按照 W3C XML Schema 规范，二进制数据应该采用 base 64 或者十六进制编码。不幸的是，base 64 编码的数据比未编码的数据大 50%，而十六进制编码的数据是原来数据的两倍长。对于小段的二进制数据这种代价还可以接受，但对于较大的数据集显然是个问题。

　　二进制数据在许多应用程序中都很有用。比如：

　　1：安全应用程序需要密码、散列、证书以及加密数据本身。

　　2：多媒体应用程序处理图片、音乐和视频。

　　3：在一些应用程序中，数据的 XML 表示被认为效率太低，比如 CAD/CAM。

　　4：XML之前的成千上万种文件格式：字处理、电子表格、字体、向量图形、系谱等等。

　　尽管为这些文件格式创建 XML 版本是可能的(如用于向量图形的 SVG)，但二进制数据已经存在了很长时间并且可能仍然非常普及。

　　最后还有 XML 自身的问题。在一个 XML 文档中包括另一个 XML 文档不是很简单的事(语法正确的解决方法依赖于 CDATA 节和字符转义)。

　　为了解决这些应用程序的需要，Web 服务必须有效地支持二进制数据。提出的解决方案是带有附件的 SOAP，该协议的核心是从 XML 有效负载中去掉二进制信息将其直接作为 multipart/related MIME 内容放在 HTTP 请求中。

　　在设计使用二进制数据的 Web 服务时，可以选的方法有：

　　1：如果数据集很小，可以考虑在 XML 载荷中使用 base 64 编码，对于小的数据集这样做的代价不构成问题。

　　2：如果数据集很大，使用附件是唯一可行的选择。

　　清单 1 是一个带有 base 64 编码参数的 SOAP 请求。注意其中的 address 元素。清单 1. base 64 编码的参数

< p xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">< p>　　<>　　实现附件

 1/2    1 2 下一页 尾页