XML Web Service 基础

SOAP

　　Soap 是 XML Web Service 的通信协议。当把 SOAP 描述为一种通信协议时，多数人都会想到 DCOM 或 CORBA，并且会问“SOAP 如何激活对象？”或“SOAP 使用什么样的命名服务？”等问题。虽然 SOAP 实现方案可能会包含上述内容，但 SOAP 标准并未对其进行规定。SOAP 一种规范，用来定义消息的 XML 格式 - 这是规范中所必需的部分。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 SOAP 消息。这是不是很简单？

　　SOAP 规范的其他部分介绍如何将程序数据表示为 XML，以及如何使用 SOAP 进行远程过程调用 (RPC)。这些可选的规范部分用于实现 RPC 形式的应用程序，其中客户端将发出一条 SOAP 消息（包含可调用函数，以及要传送到该函数的参数），然后服务器将返回包含函数执行结果的消息。目前，多数 SOAP 实现方案都支持 RPC 应用程序，这是因为习惯于开发 COM 或 CORBA 应用程序的编程人员熟悉 RPC 形式。SOAP 还支持文档形式的应用程序，在这类应用程序中，SOAP 消息只是 XML 文档的一个包装。文档形式的 SOAP 应用程序非常灵活，许多新的 XML Web Service 都利用这一特点来构建使用 RPC 难以实现的服务。

　　SOAP 规范的最后一个可选部分定义了包含 SOAP 消息的 HTTP 消息的样式。此 HTTP 绑定非常重要，因为几乎所有当前的 OS（以及许多以前的 OS）都支持 HTTP。HTTP 绑定虽然是可选的，但几乎所有 SOAP 实现方案都支持 HTTP 绑定，因为它是 SOAP 的唯一标准协议。由于这一原因，人们通常误认为 SOAP 必须使用 HTTP。其实，有些实现方案也支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但由于 HTTP 非常普遍，几乎所有当前的 XML Web Service 都使用它。由于 HTTP 是 Web 的核心协议，因此大多数组织的网络基础结构都支持 HTTP，并且员工已经了解了如何对其进行管理。如今，已经建立了用于 HTTP 的安全保护、监视和负载平衡的基础结构。

　　开始使用 SOAP 时，最容易混淆的是 SOAP 规范及其许多实现方案之间的差异。多数使用 SOAP 的用户并不直接编写 SOAP 消息，而是使用 SOAP 工具包来创建和分析 SOAP 消息。这些工具包通常将函数调用从某种语言转换为 SOAP 消息。例如，Microsoft SOAP Toolkit 2.0 将 COM 函数调用转换为 SOAP，而 Apache Toolkit 将 JAVA 函数调用转换为 SOAP。函数调用的类型和支持的参数的数据类型随每个 SOAP 实现方案的不同而不同，因此适用于一个工具包的函数可能并不适用于另一个工具包。这并不是 SOAP 的限制，而是所使用的特定实现方案的限制。

　　到目前为止，SOAP 最引人注目的特征是它可以在许多不同的软件和硬件平台上实现。这意味着 SOAP 可用于链接企业内部和外部的不同系统。过去曾试过多种方法以提出一个可用于系统集成的通用通信协议，但它们都没有象 SOAP 一样获得广泛的认可。为什么呢？因为与许多早期的协议相比，SOAP 更小巧，而且更易于实现。例如，DCE 和 CORBA 的实现需要数年时间，所以只发布了很少几个实现方案。而 SOAP 可以利用现有的 XML 分析器和 HTTP 库完成大部分艰苦的工作，因此 SOAP 实现方案在数月内便可完成。这就是为什么现在已经有 70 多个 SOAP 实现方案的原因。当然，SOAP 并不具备 DCE 或 CORBA 的全部功能，虽然功能减少了，但由于其复杂程度大大降低了，因此 SOAP 更易于应用。

　　HTTP 的普及和 SOAP 的简单性使您几乎可以从任何环境调用它们，因此成为 XML Web Service 的理想基础。有关 SOAP 的详细信息，请参阅 MSDN SOAP（英文）主页。