深入探讨SOAP

深入探讨SOAP

在这篇Soapbox的观点文章中，Brett McLaughlin 以批判的眼光来看“简单对象访问协议”，评估了这经常讨论的新技术提供给开发人员的价值，并用老的 RPC（远程过程调用）技术的混合和用 XML 演示其基本原理。Brett 详细审查了 RPC、XML-RPC、RMI 和 SOAP，比较和对照每一个的用法，并讨论 SOAP 是否有意义。本文还包含了 SOAP 信封的样本代码。

几乎如任何与 XML 相关的事物一样，“简单对象访问协议”近来倍受新闻界的注意。您可能会感到惊奇，虽然 SOAP 的橱窗装扮成新的，但其下面所呈现的要回溯至数年前，甚至是数十年前。在本文中，我揭开了围绕着 SOAP 的面纱，并查看它应该是什么样，而实际是什么样，以及它如何与类似的技术相比。与我的所有文章一样，底线是确定该技术是否适合于您，而在这里我将尝试撇开 SOAP 附带的华丽辞藻来确定它可以给您的应用带来的价值。

我将从快速查看构成 SOAP 首字母缩略词混合的开始，包括在 RPC（远程过程调用）它不怎么顺利的起源，以及它使用 XML 来解决一些 RPC 的早期问题。接下来，我将涉及 SOAP 为表带来的一般 XML-RPC 工具箱中不交付的特性，以及这些附加物是重要还是不重要的原因。从那里，我继续将 SOAP 和一般而言的 RPC 与它的最大竞争对手之一，远程方法调用（RMI）相比较。我将讨论 RPC 模型、RMI 信息流模型以及在这种环境中使用 XML 的益处。我还将看一下如何使 SOAP 为您工作。最后，我将涵盖 SOAP 的实用性对比其未来的展望，以及潜在的 XML 是否是您通信需求的完整答案，或者只是较大因素的一部分。

首字母缩略词混合

SOAP 是 YAA － “还有另一个首字母缩略词”。（是的，我正在用首字母缩略词来说明首字母缩略词；如果您感到不解，请查寻字典中的讽刺！）正如上面所提到，"SOAP" 代表“简单对象访问协议”（Simple Object Access Protocol），与现在大多数首字母缩略词一样，它本身并不意味着什么。只是另外四个要记住的字母，对吗？实际上，比那要复杂得多。在下面，SOAP 需要其它几个首字母缩略词方面的知识。它基于远程过程调用，或 RPC。除此之外，它建立在更传统的 XML-RPC 之上。还有一个事实是，SOAP 需要远程过程调用如何工作的基本知识，并且您还需要了解另一个首字母缩略词 XDR（外部数据表示标准）和 HTTP（超文本传输协议）。有那么多要记住，不是吗？要了解 SOAP 的真正本质，有必要看一下它的基础。

SOAP 从 RPC 开始

关于 RPC 的讨论会阐明 SOAP 的各个方面，这些方面是 SOAP 特别固有的。这里您可以发现您喜欢的关于 SOAP 的事情与 SOAP 没有直接的联系，但是，事实上，是 XML-RPC 的特性。这提出使用任何技术时的重要观点：确保不要使用过于复杂的包来处理也许是相当简单的需求。如本文中我会多次提到，去芜存箐。在您的应用程序中没有地方来放乱七八糟的东西。按那种说法，该是仔细回忆的时候了。

SOAP 之路以 RPC 开始，如果您一直在做面向对象编程，那么它是与您可能习惯使用的完全不同的模型。RPC 是一种通过网络来发送请求的基于消息的方式。与其尝试抽象地解释它，不如看一个实际的示例。

RPC 示例

考虑执行有关人类基因项目工作的应用程序。这些应用程序允许科学家输入信息和接收计算完的结果，同时应用程序核心执行大量计算。由于这些计算通常消耗相当长时间，在完成等式之前附加信息可能进入。所以理想的方案如下：科学家将数据输入应用程序。计算开始。科学家和应用程序继续执行。在接受新数据之前，程序不会暂停并等待这些大量计算的完成；它只是启动进程。（将它想象成 Java 中启动一个线程。）更多信息出现了，它被输入程序，计算被修改，进程继续（因为那个线程是在后台）。在某一刻,无需用户干涉，程序完成计算并提交结果。

RPC 进程与 OO 交互对比

在 RPC 示例中描述的交互与 OO 类型的交互完全不同，在 OO 交互中调用一个方法，在完成该方法后，返回结果。在我刚描述的 RPC 情形中，数据被发送到执行复杂计算的机器，然后该机器返回一个相当于“好，我已经开始了”的响应。计算不断地继续下去。同时应用程序继续前进，不等待计算的结果。那这是如何工作的呢？唔，它实际上是 RPC 的基础。RPC 是基于消息的：消息被发送到大的服务器，然后，在某一刻，会收到从大的服务器发出的“好，我做完了”的消息。您开始了解到在方法上 RPC 与您过去可能习惯的 00 方法之间的区别？

RPC 和编码

现在，在 RPC 中，由于机器通常通过网络进行通信，发送到执行计算的机器的数据必须被编码。数据必须转换成某种容易在网络传输的格式。所以自变量（数据)－ 无论是浮点数、整数、字符串还是复杂对象 － 都要编码成可以传输到 RPC 接收方的格式。在 RPC 中，该格式是我早先提到过的外部数据表示 (XDR) 标准。然后，接收方从 XDR 译码消息，并对数据进行处理。返回消息反向执行同样的过程（从服务器移到客户机）。由于 HTTP 易于使用，这些消息经常通过 HTTP 发送。所以如果您所希望的是这种通信方式，那么 RPC 也许适合于您。换句话说，SOAP 不提供该功能；成为 SOAP 基础的 RPC 基础。记住，这里没有什么是特定于 SOAP 的；我正在谈论的是任何 RPC 系统的基本基础。

XML-RPC

您也许已经发现 RPC 的问题：编码。正如我所演示的，RPC 使用 XDR 编码格式。当然，如果您象我一样，当我第一次看到 XDR 时，说“那是什么鬼东西？”唔，它是专为 RPC 创建的。最初，该编码在任何其它环境中是毫无用处的。由于它与 RPC 的联系太紧密，在几乎所有应用程序中，开发人员仅对 RPC 使用 XDR。它只是不适合于在其它通信或数据表示形式中使用。然而，在 1998 年，随着人们逐渐热衷于 XML，开发人员开始连接到网站上，认识到 XML 可能能够替代 XDR 而成为 RPC 数据编码格式。他们还认识到可以在应用程序中的许多其它地方使用 XML，譬如，数据库存储和表示。XML-RPC 是这种想法的实现：它只不过是普通的 RPC，但是用 XML － 而不是 XDR － 作为编码格式。

XML 的益处

XML 是标准语言，很容易为它编写编码器和译码器。但是益处不仅仅是这些。将字符流转换成 XML，然后语法分析和理解那个 XML 是易如反掌。XML 给您带来的不仅仅是容易编码和译码。以 XML 格式存储数据逐渐开始普及。例如，考虑这样的事实，用很少或无系统开销就可以相对不修改地将 XML 数据发送到 XML-RPC 调用。同样，想象出现允许使用不同格式的 XML-RPC 系统方便地从一种格式转换到另一种格式的 XML 转换 (XSLT)。最后，想象在某处企业的 XML-RPC 发送方将一个 XML-RPC 有效负载发送到另一个企业。不是严格地以 RPC 来处理它，发出调用的企业以 B2B（抱歉，这又是另一个首字母缩略词，这个词代表“商家到商家”）方式使用信息，然后返回 RPC 风格的响应。您突然发现自己在仅仅使用 XML-RPC 来编写 B2B 应用程序，XML-RPC 是可以自由获取用于几乎任何编程语言的库！

忠于 XML-RPC

我想说，倾心于 SOAP 中接近于 75% 的人实际是倾心于简单的 XML-RPC。如果您发现您自己在考虑：“我可以发送 XML 远程调用和使用简单库来做到？哇，太好了！今天我将开始使用 SOAP”，然后忠于 SOAP。可以跳过 SOAP 下载，仅抓住简单的 XML-RPC（请参阅参考资料这一节中的链接）。您会对稳定的代码、更简单的接口以及更少的开销，感到更高兴。在可以使用更少处理能力来做同样工作的建议中，我知道我正在涉足这一神圣的领域。但是要记住“去芜存箐”这条谚语。将这牢记在心中，下一节将讲述用 SOAP，您将获得什么。

现在讨论 SOAP

大问题是：“SOAP 将什么添加到该等式中？”答案相当简单。提交给 W3C 的有关 SOAP 的说明定义了除了基本的 XML-RPC 特性之外 SOAP 所包含的两项主要项。首先是 信封，携带关于所包含消息的信息。其次是一套应用程序特定数据类型编码 的规则。让我们看一下这些项。

信封

SOAP 信封类似于实际信的信封。它提供关于正在 SOAP 有效负载中编码的消息的消息，包括与接收方和发送方相关的数据以及关于消息本身的细节。例如，SOAP 信封的头可以确切指定如何处理消息。这意味着在应用程序继续处理消息之前，应用程序可以决定关于消息的信息，包括它是否可以处理该消息。与标准 XML-RPC 调用的情况不同，使用 SOAP 实际的解释，以便决定关于消息的某些事。典型的 SOAP 消息还可能包含编码风格，它帮助接收方解释该消息。清单 1 显示了 SOAP 信封，用指定的编码完成。

一套简单的编码规则

SOAP 带给表的第二个主要元素是编码用户定义的数据类型的简单方式。在 RPC（和 XML-RPC）中，编码只可能针对预先定义的数据类型发生。编码其它类型需要修改实际的 RPC 服务器和客户机自身。然而，用 SOAP，XML 模式可以方便地用来指定新数据类型（用 complexType 结构），然后那些新类型可以方便地用 XML 表示，作为 SOAP 有效负载的一部分。究竟这是如何起作用超出了本文所讨论的范围，并且可能需要我进一步详细阐述 SOAP 和 XML 模式。考虑到本文的目的，显示在 SOAP 消息中的任何数据类型编码是多么容易就已足够了，您可以用 XML 模式逻辑地描述该消息。

SOAP 怀疑论

讨论至今，可以看到 SOAP 不是仅由一个，而是由三个首字母缩略词组成。如果您所需要的是经过网络发送消息的方法，那么紧紧抓住 XML-PRC。但是如果您发现经常因尝试用复杂的、用户定义的类型进行通信而烦恼，如果您的应用程序在处理该消息以前 必须检查消息的指令，或者如果您希望赶上最新潮流，那么 SOAP 是适合您的。对于 SOAP 的使用，如果有些怀疑，确实如此。如果经由网络发送复杂的数据类型，将这些结构编码以及译码成 XML，这与使用如 RMI（远程方法调用）技术一样，可能需花大量时间。而且，所有事情都是平等的，人们几乎总是推荐 RMI，而不是 SOAP。 RMI 已有很长一段时间，这意味着它有较少的错误，有更多的时间成熟，并且在编程社区中，大家普遍接受 RMI。那意味着我从来不用 SOAP 或从来不推荐它？当然不是！但与任何新技术一样，当您希望使用胜过一般意义上的新技术时，小心和有一个好的理由使用技术，这将省去向您见识短浅的老板解释时的尴尬。

展望 RMI

在下一篇文章中，我将继续深入探讨 SOAP。首先，我将从第一部分漏讲的地方谈起，比较和对照（听起来象高中的英语作业？）RPC 和 RMI。毫不惊奇，总会有 SOAP 和 RPC 有意义的时候也会有 RMI 起作用的时候，所以在本系列中的下一篇文章将帮助搞清楚涉及的折衷方法。接下来我将研究现在使用 SOAP 意味着什么，看一下您对哪些折服，仍然有哪些遗漏的，以及今后出现的标准有些什么。经过所有这些之后，我仍会保持一种怀疑的眼光，以确保这一 SOAP 评估避免协议已引来的欺骗。

结束语

希望我所演示的 SOAP 并不是人们通常所认为的魔弹。更为重要的是，希望您能够了解 SOAP 的众多“特性”，并不是对 SOAP 是唯一的，事实上是 RPC 和 XML-RPC 的一部分。我确实标识了 SOAP 的某些特定的特性，如 SOAP 信封。

在您自己的工作中使用 SOAP 的价值和可行性这一点上，有可能作出任何结论吗？绝对可以！首先，这不是什么新的东西，您应该总是紧盯商业需求，而不是技术需求。摆弄 SOAP 有许多乐趣，并且在您那些标新立异的朋友当中显得非常与众不同，事实是，如果它不能为您提供一种解决问题的方法，那么它可能会浪费大量时间。同样，并且这是很重要的一点，使用 XML-RPC 完成任务要比您选择使用 SOAP 更容易，这是很有可能的。不要被广告所欺骗。SOAP 已经到来，但它不是天外来客。相反，SOAP 仅仅是已经持续了很长一段时间的大的，有时是臃肿的同类技术，并且通常易于使用。下次我将更深入地剖析 SOAP，并探讨更多有关它可为您所做的事。