本文摘自 Frank Cohen 的 Java Testing and Design: From Unit Testing To Automated Web Tests（Prentice Hall Publishing，2003年春季， ISBN 0131421891）一书。在本文中，作者提出：

·         Web 服务软件开发人员选择的编码风格对可伸缩性和性能有很大的影响。

·         开发工具，例如BEA WebLogic Workshop，可以帮助开发人员部署可伸缩的Web 服务。

·         在您自己的环境中对向导、工具和测试代理进行阶段测试。

这个时代允许软件开发人员充分选择软件开发工具、应用服务器和连接性。每种选择都会影响完成后的应用程序的可伸缩性和可靠性，特别是当创建Web 服务时。例如，就像您将在学习本文一样，选择某种SOAP 编码风格比选择其他SOAP 编码风格会使性能提高30倍。通过理解SOAP 编码风格、Web 服务开发工具、应用服务器和平台对性能的影响，您会发现我们的选择极大地提高了系统性能。

为何SOAP如此受欢迎?

依我的经验，当相互独立的科技创新出现交叉时，社会倾向于生活改变产品、服务和技术。例如，灯泡需要电流生成和灯丝技术。在Web服务情况下，企业信息技术管理人员只是改变了多年的散乱状态，他们买来大量的计算机、服务器、路由器和其他网络基础设备。当遇到经济不景气、股票市场低落、世界经济无常、不得不面对恐怖主义和SARS时，这些信息管理人员利用他们现有的网络基础设备通过新的软件项目来提高团队生产力。

同时，大多数软件开发人员意识到他们真的喜欢XML。例如，XML比用Microsoft Windows Registry或者使用基于文本的属性文件来存储和描述应用数据要好得多。软件开发人员看到了XML的优势，想在他们的应用程序中找到更多使用XML的方法。
 
作为一名软件开发人员，我开始注意那些预计可以接收包含XML编码数据值的应用程序接口（API）。例如，为Sun Microsystems构建一个门户系统时，我发现创建新用户帐号的servlet接收那些在XML文件中构成用户联系信息（电子邮箱、地址和电话号码）的字段。而不是每次将一个值传递给一个方法，这种方法采用了一种XML数值，可以同时包含几个值。 使用XML来实现应用接口对于开发人员来说非常清晰。再加上这些描述接口的XML可以跨平台和编程语言运行。有了XML， 每件事情看上去都像是一个接口。这些交叉技术激励了对Web 服务的广泛关注。同时，软件开发人员又做了软件体系结构方面的实验，尤其是应用业务逻辑和表示代码这类领域。表示代码处理窗口、鼠标、键盘和其他与用户间的交互。业务逻辑是定义一个应用程序的行为和操作的指令集。

第一代软件体系结构在单一系统上建立了表示和业务逻辑。第二代软件体系结构中，20世纪60年代的客户/服务器结构导致了大型中央控制数据中心的出现，这时候主机统治整个信息世界。在客户/服务器结构中，桌面系统是一个“哑”终端，只需显示主机提供的数据。早期Internet模仿了客户/服务器结构 ，浏览器只是向服务器发送简单的请求。随着浏览器功能的改进—— 引入了Applets、JavaScript、ActiveX、DHMTL ——一些系统在桌面端也包含了业务逻辑。然而，大多数功能仍保留在服务器端。
 
“网格计算”的时代正向我们走来，此时应用主机业务逻辑模块位于桌面端或者服务器端。这些模块相互之间通过UDDI和P2P 技术识别。同时，业务逻辑模块的多副本可以在数据中心的一个网格中运行，允许完成容错、动态路由和特殊功能。所有这些体系结构都运行在网络环境，同时可以使用Web 服务。
 

因此即使基于SOAP的Web 服务被其他类型的Web 服务技术取代，那么利用XML编码数据的远程调用也会普及很长一段时间。

SOAP编码风格

SOAP使用XML汇集那些传送到软件应用程序中的数据。多数情况下SOAP在软件对象间移动数据，但是人们希望SOAP规范对于老系统和面向对象的新系统都有用。因此，SOAP定义了不止一种的数据编码方法，以便在一个软件程序和XML格式间实现数据的往返转换。 采用SOAP编码的数据被打包到消息体内部并送到主机。然后主机对XML格式的数据进行解码，返回到软件对象状态。
 

自从引入SOAP，已经有三种SOAP编码风格很流行，并可以实现跨软件和技术供应商的可靠执行：

·         SOAP远程过程调用（RPC）编码，也称为Section 5编码，是由 SOAP 1.1和后来的SOAP 1.2定义的RPC编码和惯例规范。

·         SOAP远程过程调用文字编码（SOAP RPC-literal）使用RPC方法实现调用，但是使用了一种XML自自己的方法封送数据。

·         SOAP文档风格编码，也称为是消息类型或文件文字编码。

还有几种其他编码方式，但是软件开发人员没有广泛采用，主要因为他们的发起者标准不一致。例如，早期Web 服务的发明， Microsoft提倡用Internet直接消息交换（DIME）对二进制的文件数据进行编码，而其他计算机公司采用带有附件的SOAP。SOAP RPC编码、RPC-literal和文档风格的SOAP编码已经成为了软件开发人员认可的编码风格。

一些开发人员没有意识到这些编码风格之所以存在是因为他们用来开发Web 服务的工具正在为开发人员进行编码风格的实施工作。例如，BEA WebLogic Workshop提供了一种快速有效的Java Web 服务（JWS）接口工具。 JWS实现一套应用程序接口（API）和JWS引擎需要在服务器上自动配置Web服务的文件标准描述。JWS自动构建Web服务部署描述符。因此您只需定义公共Java方法，同时JWS公布访问这些方法的SOAP代理。这使开发变的非常容易，但是稍后将进行的大量工作是在幕后发生的。

在讨论SOAP编码风格对性能影响前，您应当了解这些SOAP编码风格间的差异。图14-1表明SOAP RPC编码调用的完整堆栈。

图14-1 一种利用SOAP堆栈和SOAP RPC编码调用Web服务的Java方法

SOAP RPC是为开发人员提供的最简单的编码方法。开发人员对远程对象进行调用，同时传递所有必要的参数。SOAP堆栈将参数序列化为XML，利用HTTP和SMTP等传送协议将数据传送到目的地，接收响应、将这些响应反序列化为对象并将结果返回给调用方法。SOAP RPC处理所有编码和解码工作，甚至是非常复杂的数据类型，并自动绑定到远程对象。

如果开发人员已经有一些XML格式的数据，SOAP RPC也允许将这些XML数据作为单独字段进行文字编码，然后将这些字段序列化并发送到Web服务主机中。由于仅有一个参数——XML树——因此SOAP堆栈只需要对一个数值进行序列化。SOAP堆栈还处理将获得的请求发送给远程对象的传送问题。堆栈将请求绑定到远程对象并处理响应。

最后，在SOAP文档风格的调用中，SOAP堆栈将一个完整的XML文件发送到服务器，甚至都不需要有返回值。信息可以包含适于远程服务的任何类型XML数据。在SOAP文档风格编码中，开发人员处理所有事情，包括确定传输协议（如HTTP、 MQ、 SMTP）、封送和解除封送SOAP信封体，以及在请求和响应过程中解析XML以便找到需要的数据。

图14-2中是三种编码系统的比较。

图14-2  SOAP编码风格大大提高了软件开发人员的生产力，但是它是以牺牲性能和系统资源为代价的。

SOAP RPC编码对于软件开发人员来说是最容易的，但是这也带来了可伸缩性和性能问题。SOAP RPC文字编码对于软件开发人员处理XML解析来说要更棘手，但是只需要较少的SOAP堆栈开销。SOAP 文件编码对于软件开发人员来说是最困难的，因此很少需要SOAP开销。

为何SOAP RPC对于开发人员来说比较容易？使用这种编码风格，您只需在代码中一次性定义公共对象方法；SOAP堆栈解除封送对象中的请求参数，并将他们直接传送到对象的方法调用中。另外，您必须要遍历XML树找到需要的数据元素，然后调用公共方法。

有一个参数用于解析XML数据本身：因为您最熟悉XML树中的数据，您的代码将比通用的SOAP堆栈代码更能有效地解析那些数据。在衡量SOAP编码风格的可伸缩性和性能时，我们会发现这一点。

在我进一步深入讨论前，我们先看一下企业信息系统管理人员是如何控制SOAP编码风格和可伸缩性的。

简单对象访问需要简单对象测试

Elsevier（www.elsevier.com）是科学、技术和医药行业领先的研究内容发布者。目前Elsevier 利用SOAP内容发布平台来构建应用编程接口。Elsevier的信息管理人员需要了解他们选择的SOAP编码风格是否可以伸缩，每天执行处理数百万的事务。他们的决定将影响Elsevier如何投资购买新的基础设施。随着时间的推移，他们需要了解自己软件的新发行版和应用服务器软件新发行版，以及平台的改变将如何影响可伸缩性和性能。

Elsevier通过开放源代码社区学习TestMaker并与PushToTest联系，以便了解TestMaker是否满足他们的测试需要 。Elsevier要求PushToTest管理SOAP堆栈和编码风格的独立审计内容，以便回答关于系统性能和可伸缩性的问题。PushToTest推出一种测试网络服务（TWS）用来处理 RPC、RPC-literal和文档风格的 SOAP 消息，并在很多应用程序服务器上运行。这个环境是由一系列智能测试代理程序完成的，用来检查 TWS 的可伸缩性和性能。
 
TestMaker 检查 Web 服务的可伸缩性、性能和可靠性。软件开发人员、QA 分析师和 IT 经理使用 TestMaker 来构建实现用户原型行为的智能测试代理程序。这些代理程序使用本机协议（HTTP、HTTPS、SOAP、XML-RPC、SMTP、POP3 或 IMAP）驱动 Web 服务，就像真实用户使用一样。并行运行的多个智能测试代理程序会创建接近生产水平的负载，用于检查系统的可伸缩性和性能。

除了检查 SOAP 编码的可伸缩性以外，Elsevier 测试环境还提供了一个特定于 Elsevier 系统的基准程序，来说明各种应用程序服务器和平台性能方面的比较。例如，当前TWS已实现了在 IBM WebSphere、BEA WebLogic Workshop和 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 并行发出请求的数目和响应的有效负载规模。此测试代理程序将结果记录到一个限定的日志文件中，这个文件随后由一个对应脚本进行汇总。这个对应脚本通过测试中计算成功事务的持续时间决定每秒处理的事务数（TPS）。如果没有出现传输或 SOAP 错误，测试便定义为成功。
 
在 Sun Microsystems 的支持下，我在一个具有 6 个 CPU 和 4 GB 内存的 Sun Solaris E4500 服务器上运行了这些测试。测试Web服务（TWS） 使用底层应用程序服务器提供的 SOAP 堆栈。例如，WebSphere 提供 Apache SOAP，BEA WebLogic 提供其自己使用 JAX-RPC API的实现方法，而 SunONE Application Server 使用 Java 1.4 JAX-RPC 库。在客户端，TestMaker 使用 Apache SOAP 库。
 
在 Elsevier 项目中，我发现开发人员对编码风格的选择在很大程度上决定了Web服务的可伸缩性和性能。SOAP 实现方法在使用 SOAP RPC 编码时普遍说明了可伸缩性问题，特别是在有效负载规模增加时，如图14-3。

图14-3  SOAP RPC 编码：随着负载规模增加，可伸缩性问题也变得日益明显。文档风格编码：随着负载规模增加，性能保持相对稳定。SOAP RPC-literal类型提供了 SOAP文档风格编码的性能优势，同时只需多做一点通过XML 数据进行解析的工作。

当在响应 SOAP 信封测量的地方发出600 字节的 SOAP RPC 编码数据请求时，测试代理程序每秒记录294条事务。当测试代理程序增加响应规模时，每秒记录的事务数骤然减少。当发出96,000 字节SOAP RPC 编码数据的请求时，代理程序测量到的每秒事务数目只有 9.5了。

当测试环境使用 SOAP 文档风格编码时，性能有很大的提高，当发出 600 字节的文件编码数据的请求时，测试代理程序测量到的 TPS 为 469。回想SOAP RPC 编码处理同样规模的请求时，TPS 数为 294。此外，测试代理程序增加响应规模时，如果使用文档风格编码响应，TPS 值不会明显降低。

当测试环境使用 SOAP RPC-literal 编码时，我发现了一个有效的折衷方法，SOAP RPC-literal提供了SOAP文档风格编码的性能优势，同时只需要多做一点通过XML 数据进行解析的工作。每一个生产环境都是独一无二的。因此，这里提供一个工具包您可以下载并在您自己的生产环境中使用。我已经构建了 Elsevier 测试环境的一个通用版本，您可以免费下载并直接使用： http://www.pushtotest.com/ptt/kits/encodingkit.html。

结束语

在本文中，我们发现软件开发人员为创建Web服务系统有很多选择：SOAP 编码风格、Web服务开发工具和应用服务器，本章介绍了研究结果，说明每种选择都直接影响可伸缩性和可靠性。
 
Elsevier采用SOAP作为创建下一代内容聚合系统的标准方法。我们看到了Elsevier为了提高可伸缩性和性能是如何开发一种方法和测试环境的，从而检验各种SOAP实现，包括应用服务器、SOAP堆栈和实用程序。

关于作者
Frank Cohen（fcohen@pushtotest.com）是PushToTest的创始人，该公司帮助人们理解和优化那些支持Web的应用程序的可伸缩性和性能，特别是 Web服务。Frank是BEA的技术顾问和dev2dev栏目的专栏作者。