级别： 初级 Brett McLaughlin (brett@newInstance.com), Enhydra 策略顾问, Lutris Technologies
2001 年 4 月 01 日 在这篇临时讲台的观点文章中，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，并探讨更多有关它可为您所做的事。
参考资料
关于作者  | | |
Brett McLaughlin 是 Lutris
Technologies 的 Enhydra
策略顾问，专长于分布式系统体系结构方面。他是
Java and
XML
(O'Reilly) 的作者。他参与了如 Java Servlet、Enterprise
JavaBean 技术、XML 和商家对商家应用程序等技术的研究。最近，他与
Jason Hunter 一起发起了
JDOM
项目，该项目为从 Java 应用程序中操纵 XML 提供了一个简单的
API。他还是 Apache Cocoon 项目、EJBoss EJB 服务器的活跃开发人员以及
Apache Turbine 项目的共同创始人。 可以通过
brett@newInstance.com
与他联系。
|
对本文的评价
| 
