级别： 初级 Frank Cohen (fcohen@pushtotest.com), CEO, PushToTest
2003 年 3 月 01 日 对于构建 Web 服务系统，软件开发人员有许多选择。在最近的一项调查中，Frank Cohen 发现 SOAP 编码样式的选择尤其直接影响到系统的可扩展性和可靠性。在本文中，他描述了不同的编码选择并说明了每种编码选择所具有的性能和可靠性得失。他还讲述了您可以用来在自己的环境中进行阶段测试的工具。
我们生活的时代使得软件开发人员总是可以最充分地选择软件开发工具、应用程序服务器和连接性。您所做的每一个选择都会对完成后的应用程序的可扩展性和可靠性产生影响，特别是如果您正在构建 Web 服务的话。例如，在最近一个在特定的客户机环境中对 SOAP 编码样式的研究中，我发现选择某种 SOAP 编码样式比选择其他编码样式使得性能提高 30 倍。通过理解 SOAP 编码样式、Web 服务开发工具、应用程序服务器和平台对性能的影响，您可以使系统性能大大改善。
SOAP 编码样式
SOAP 使用 XML 编入传送到软件应用程序的数据。多数时候 SOAP 在软件对象之间移动数据，但是人们想要 SOAP 规范对旧系统和现代面向对象的系统也有用。因此，SOAP 定义了多种编码方法以将数据在软件对象和 XML 格式进行来回转换。用 SOAP 编码的消息被打包成消息体并发送到主机。然后主机会对 XML 格式的数据进行解码，使其成为软件对象。
自引入 SOAP 以来，有三种编码样式得到接受并在软件供应商和技术供应商之间得以可靠地执行：
-
SOAP 远程过程调用（Remote Procedure Call，RPC）编码，也称为
Section 5 编码，它由 SOAP 1.1 规范定义
-
SOAP 远程过程调用文字编码（SOAP RPC-literal），它使用 RPC 方法进行调用但使用 XML 自制的方法编入数据
-
SOAP 文档样式（document-style）编码，也称为
消息样式（message-style）或
文档文字（document-literal）编码。
还有其他几种编码样式，但是它们没有被软件开发人员广泛地采纳，主要是因为它们的提倡者在标准上不一致。例如，Microsoft 正在推出直接因特网消息交换（Direct Internet Message Exchange，DIME）以对二进制文件数据进行编码，而其他公司则推行带有附件的 SOAP。SOAP RPC 编码、RPC-literal 和文档样式的 SOAP 编码已成为一个软件开发人员可以指望的编码样式。
在我讨论 SOAP 编码样式对性能的影响之前，您应当理解这三种样式之间的差异。
SOAP RPC这种编码样式是最简便的。您对远程对象进行调用，并传递任意必需的参数。SOAP 堆栈将这些参数序列化为 XML，再使用传输协议（如 HTTP 和 SMTP）将这些数据传送到目的地，然后接收响应，并将接收到的响应反序列化为对象，然后将结果返回到调用方法。唷！SOAP RPC 处理了所有的编码和解码工作（即使对于非常复杂的数据类型也是如此）并自动绑定到远程对象。
现在，请想像一下您的某些数据已经是 XML 格式的情况。SOAP RPC 也允许通过文字编码将这些 XML 数据转换为单个字段，然后将这些字段序列化并发送到 Web 服务主机。这就是
RPC-literal编码所指的内容。由于只有一个参数 － 即 XML 树 － 所以 SOAP 堆栈只需要对一个值进行序列化。SOAP 堆栈仍然处理传输问题以将请求传送到远程对象。堆栈将请求绑定到远程对象并处理响应。
最后，在
SOAP 文档样式调用中，SOAP 堆栈将整个 XML 文档发送到服务器，甚至不需要一个返回值。消息可以包含任何种类的对于远程服务适合的 XML 数据。在 SOAP 文档样式编码中，开发人员要处理每一件事，包括确定传输协议（如 HTTP、MQ 或 SMTP）、编入和编出 SOAP 信封体以及对请求和响应中的 XML 进行解析以找到所需的数据。
图 1中对这三种编码系统做了比较。
SOAP RPC 编码对于软件开发人员来说是最简单的；但是所有这些容易都是以牺牲可扩展性和性能为代价的。在 SOAP RPC-literal 编码中，您需要更多地对 XML 解析进行处理，但是这种编码样式对于 SOAP 堆栈来说需要处理开销。SOAP 文档文字编码对于软件开发人员是最难的了，但因此需要很少的 SOAP 开销。
为什么 SOAP RPC 会简单一些呢？使用这种编码样式，您只需要在代码中定义公共对象方法一次；SOAP 堆栈将请求参数编出到对象中并将这些参数直接传送到您的对象的方法调用中。否则，您必须完成在向公共方法进行调用之前遍历 XML 树进行解析以查找需要的元素这一任务。
对于您自己对 XML 数据进行解析这一点有一个论点：既然您最了解 XML 树中的数据，那么您的代码对那些数据进行解析要比通用的 SOAP 堆栈代码效率高。在衡量使用各个 SOAP 编码样式的可扩展性和性能的时候您会发现这一点。
但是在进一步深入讨论之前，让我们看一下企业信息系统管理员如何将 SOAP 编码样式和可扩展性联系在一起。（有关不同编码样式的更多详细情况，请参阅
参考资料。）
简单对象访问需要简单的性能测试
Elsevier 是科学、技术和医学工业的领先研究内容发布者。（欲了解更多信息，请参阅
参考资料。）Elsevier 的下一代内容发布平台使用 SOAP 构建应用程序编程接口。Elsevier 的信息管理员需要知道他们选择的 SOAP 编码样式是否能扩展为处理每天数百万的事务并得以执行。他们的决定会影响到 Elsevier 会如何在新的基础结构上投资。随着时间的推移，这些管理员将需要知道它们自己的软件新的发行版、应用程序服务器软件的新发行版以及平台更改会如何影响可扩展性和性能。
Elsevier 要我根据我的自由的开放源代码 TestMaker 实用程序构建一个新的测试环境（请参阅
参考资料）以回答这些可扩展性和性能问题。我构建的 Elsevier 测试环境（在
图 2中有说明）包括一个处理 RPC、RPC-literal 和文档样式的 SOAP 消息的测试 Web 服务（Test Web Service，TWS），并安装在多种应用程序服务器上。这个环境是用一组智能测试代理程序完成的，用来检查 TWS 的可扩展性和性能。
TestMaker 检查 Web 服务的可扩展性、性能和可靠性。软件开发人员、QA 分析师和 IT 经理使用 TestMaker 构建执行典型用户行为的智能测试代理程序。这些代理程序使用本机协议（HTTP、HTTPS、SOAP、XML-RPC、SMTP、POP3 或 IMAP）驱动 Web 服务，就像真正的用户那样。并行运行多个智能测试代理程序会创建接近生产水平的负载，用于检查系统的可扩展性和性能。
除了检查 SOAP 编码的可扩展性以外，Elsevier 测试环境还提供了一个特定于 Elsevier 的系统的基准程序，以说明对各种应用程序服务器和平台性能的比较。例如，现在已实现的 TWS 可以在 IBM WebSphere Studio、BEA WebLogic 和 SunONE Application Server 上运行。我相信移植到 ElectricMinds Glue、Apache Axis、Systinet WASP 及其他应用程序服务器都将不难做到。
通过定制 TestMaker 来支持 SOAP RPC、SOAP RPC-literal 和 SOAP 文档样式的请求并通过实现 TWS 以对这些编码样式的请求做出响应，我构建了 Elsevier 测试环境。对 TWS 的请求包括两个参数：第一个参数定义了响应的大小，第二个参数定义了响应之前的延迟时间。TWS 通过创建一个响应文档做出响应，这个响应文档包括在五个响应元素（每个元素各有一个子元素）中出现的随机的莫名其妙的文字。TestMaker 测试代理程序使用 Apache SOAP 库向 TWS 发出请求。这个测试代理程序会更改对 TWS 并行请求的数目和响应的有效负载大小。这个测试代理程序将结果记录到一个定界的日志文件中，这个文件随后由一个记录脚本（tally script）进行汇总。这个记录脚本通过对成功事务的持续时间进行计数确定了由测试执行的每秒处理事务数目（transactions per second，TPS）。如果没有传输或 SOAP 错误，测试便成功了。
在 Sun Microsystems 的支持下，我在一个带有 6 个 CPU 和 4 GB 内存的 Sun Solaris E4500 服务器上运行了这些测试。TWS 使用由底层应用程序服务器提供的 SOAP 堆栈。例如，WebSphere Studio 提供 Apache SOAP，BEA WebLogic 提供其自己的实现（其实现使用 JAX-RPC API），而 SunONE Application Server 使用 Java 1.4 JAX-RPC 库。在客户机端，TestMaker 使用 Apache SOAP 库。
在 Elsevier 项目中，我发现开发人员对编码样式的选择在很大程度上决定了 Web 服务的可扩展性和性能。SOAP 实现在使用 SOAP RPC 编码时（特别是在有效负载的大小增加的时候）普遍说明了可扩展性问题，如
图 3。
如
图 3所示，当在响应 SOAP 信封测量 600 字节的 SOAP RPC 编码数据的地方发出请求时，测试代理程序记录的每秒事务数目为 294。当测试代理程序增加响应的大小时，每秒事务数目骤然下跌。当在测量 96,000 字节的 SOAP RPC 编码数据的地方发出请求时，代理程序测量到的每秒事务数目仅为 9.5。
当测试环境使用 SOAP 文档样式编码时，性能进展得好多了，如
图 4中所示。
当测量 600 字节的文档编码的数据时，测试代理程序测量到的 TPS 为 469。别忘了测试 SOAP RPC 编码的相同大小的请求的 TPS 数为 294。此外，当测试代理程序增加响应大小时，TPS 值在测试环境使用文档样式编码的响应时没有显著下降。
当测试环境使用 SOAP RPC-literal 编码时，我发现了一个有效的折衷办法，如
图 5所示。
当测试代理程序测量 600 字节的 SOAP RPC-literal 编码的数据时，TPS 为 422。这与 SOAP 文档样式请求的性能相近。SOAP RPC-literal 编码没有显示当有效负载的大小增加时 SOAP RPC 编码性能的 TPS 功能骤然降低。
您可能想知道各种应用程序服务器在可扩展性和性能上的比较情况。就我的经验来看，每一个生产环境都是独一无二的。因此，在这里我不做比较，而是建议您自己下载这个测试环境并在您自己的生产环境中试一下。我已经构建了 Elsevier 测试环境的一个通用版本，您可以免费下载直接使用（请参阅
参考资料）。
应当让这些工具进行驱动吗？
虽然 SOAP 编码样式提供了广泛的功能和灵活性，但是它们也引入了互操作性问题。Java 平台上的多数 SOAP 工具的缺省编码样式是 SOAP RPC。例如，使用 IBM WebSphere Studio Application Developer，缺省编码样式被设置为 SOAP RPC。另一方面，.NET 开发工具在缺省状态下实现文档样式的 SOAP 调用。这与晚上观看两只小船经过的情况相似。可以使两种开发工具能够互操作，但是开发人员需要对不同编码样式做出明智的选择以避免问题产生。
在他们想使软件开发人员生活得更轻松些的尝试中，这些会影响到可扩展性的工具可能会为您做出决定。最近，当 Microsoft 和 Sun 在于硅谷举行的软件开发论坛（Software Development Forum）活动中针对 J2EE 和 .NET 的相对优点进行辩论时，这个问题便更加突出了。Microsoft 所阐述的理由是它是整个解决方案唯一的提供者，因此它为开发人员提供了最好的服务。而另一方 Sun 则断定开发人员应该可以选择一些他们能够组成一个解决方案的工具。这个自顶向下对自底向上的争论同时渗入到两家公司的开发工具。例如，有人要求 Sun 和 Microsoft 的销售代表阐述为什么开发人员会选择 SOAP RPC 编码而非 SOAP 文档样式编码。Microsoft 的销售代表给出了一个有些技术性的回答，但是承认他们认为这个问题有讨论的余地，因为开发人员应该按照他们的开发工具来做出有关编码样式的决定。
软件开发人员通过做出明智的关于它们的开发工具和环境应当如何有用的决定来尽职尽责。如果您打算开发可靠的、高性能的软件项目的话，明白每一种工具的 SOAP 编码样式的处理很重要。
需要进一步考虑的问题
开发人员应注意的另外一个针对可扩展性影响的地方是应用程序服务器中的 SOAP 堆栈。当构建 Elsevier 测试环境时，我注意到每个 Web 服务平台都有其自己的 SOAP 堆栈实现 － 有些平台甚至带有多个堆栈。例如，BEA WebLogic Server 带有一个实现 JAX-RPC API 的 SOAP 堆栈和另一个实现 Java Web 服务（Java Web Service，JWS）API 的 SOAP 堆栈。IBM WebSphere Studio V4 带有基于 DOM 的 Apache SOAP 库，但 WebSphere Studio V5 却有基于 SAX 的 Apache AXIS 库。我在将来的一些项目中会借机会对所有这些不同之处进行测试。
我还注意到，尽管 WSDL 出色地描述到 SOAP 服务的接口，但 WSDL 常常是不完整的。我发现需要一个网络监视器实际查看通过 HTTP 传输协议都传送了哪些值。
在构建 Elsevier 测试环境时有件事难住了我，这就是 SOAP 实现的本质。2002 年，BEA 和 IBM 发布了他们的 Web 服务应用程序服务器的新版本。因此，SOAP 应用程序服务器的可靠性和性能的目标是不断变动的。这又进一步强化了这里学到的经验：您现在应当使用一个动态的测试环境来检查可扩展性和性能 － 并使这个测试环境保持便利以对新的实现在它们变得可用时进行测试。
参考资料
关于作者  | | | Frank Cohen 擅长为那些需要解决信息系统（特别是 Web 服务）的可扩展性和性能问题的企业解决问题。Frank 负责 TestMaker 的维护，TestMaker 是一个流行的、自由的开放源代码实用程序，它可以检查系统的可扩展性和可靠性。请通过
fcohen@pushtotest.com与 Frank 联系。
|
对本文的评价
| 
