Web Service 附件技术的发展及演变.docVIP

Web Service 数据交换协议 Web Service 使用 SOAP 作为其标准的数据交换协议。SOAP 是一个基于 XML 的轻量级协议，用于在无中心、分布式环境中交换结构化的数据，该协议完全独立于具体的系统平台、软件架构和编程语言，提供了一种开放和统一的方式支持应用间的集成和互操作。 SOAP 的设计目标是简单性和扩展性，有助于大量异构程序和平台之间的互操作性，从而使存在的应用程序能够被广泛的用户访问。目前，SOAP 已经成为开放性互联网络应用中标准的数据交换技术。2000 年 W3C 推出了 SOAP1.1 版本，最新的 SOAP1.2 在 2007 年 4 月推出，并成为 W3C 的推荐规范。 SOAP 只是为上层应用提供一个数据的载体，数据的具体语义由上层应用定义。SOAP 报文最外层元素为 Envelope，即 SOAP 信封。Envelope 之下有两个子元素：Header 元素和 Body 元素。其中 Body 元素是 SOAP 报文的主要数据载体，该元素是必需的。用于存放待交换的信息，具体表示为 Body 的子元素；Body 的每个直接子元素称为 Body Block，用于存放具体应用中在逻辑上相关的一组数据；Header 元素是可选的，主要用于扩展机制，Header 的直接子元素称为 Header Block，每个 Header Block 的扩展语义由基于 SOAP 的上层应用来定义，常用的扩展包括安全、事务、消息相关性等。 SOAP 故障 (Fault) 报文是一种特殊的 SOAP 报文，用于在发生故障的场景中运载错误信息。在 SOAP 故障报文中，Body 有且仅有一个名为 Fault 的直接子元素，用于存放和具体故障有关的详细错误信息，包括故障代码、故障原因、发生故障的 SOAP 结点等。图 1 为 SOAP 数据报文和 SOAP Fault 报文示意图。 图 1. SOAP 数据报文和 SOAP Fault 报文? 在 Web Service 的实现中，经常需要在 SOAP 报文中携带各种类型的附件 ( 如图像、文档等 ) 一起传输。例如，在典型的电子商务应用中，客户向商家询问某种商品的详细信息，商家向客户发回 SOAP 格式的回复消息，其中包含有商品的详细说明，商品的图片等供客户参考。这些附件可能是文本文件，XML 片段，二进制文件等等。然而，SOAP 是一种基于 XML 的文本协议，只能使用可见字符组成的文本来表示数据，无法在报文中直接包含其他格式的附件。因此，如何将 SOAP 报文同其他格式的附件组织在一起进行传输便成为一个需要解决的重要问题。 为了对 SOAP 及其他 Web Service 标准进行支持，Java 社区进程组织 (JCP: Java Community Process) 提供并实现了 Java 方面的 Web 服务的原始标准 JAX-RPC1.x (JavaTM APIs for XML based RPC) 和 JAX-WS (JavaTM API for XML-Based Web Services 2.0)。JAX-RPC 最早版本是 JAX-RPC1.0，进过一段时间使用便更新到 JAX-RPC1.1，在 J2EE1.4 中包含 JAX-RPC1.1。JAX-RPC1.1 使用约 1 年后 JCP 再次对其进行更新，考虑到 Web 服务中不单有 RPC Web 服务，还有面向消息的 Web 服务，因而将其更名为更合理的 JAX-WS。目前 JAX-WS2.0 仍在进行当中。JAX-RPC1.1 提供对 SOAP1.1 的支持，JAX-WS2.0 对 SOAP1.1 和 SOAP1.2 进行支持。 Base64 编码的二进制 SOAP 附件 为了简单和通用性，XML 被设计成了以文本的格式来表示数据。使用 SOAP 进行传递的数据首先被序列化，也就是将数据转换成字符串在 XML 文档中传送。在目的地，字符串再被反序列化，即再被转换成表示原来的值的数据类型。把二进制数据放入 SOAP 报文的最简单的方法，就是使用 Base64 编码的方式对其进行编码，以实现数据的序列化和反序列化。 Base64 是一种很常见的编码规范，其作用是将二进制序列转换为可读的 ASCII 字符序列，常用在需用通过文本协议传输二进制数据的情况下，例如 HTTP 和 SMTP 协议。Base64 编码基本原理是把每三个 8bit 的字节转换为四个 6bit 的字节，然后把 6bit 再添两位高位 0，组成四个 8bit 的字节，不满四个字节的以 = 填充。因为 Base64 将输入的数据编码成只含有 {A-Z, a-z, 0-9, +, /} 这 64 个字符的串，所以称之为 Bas