Java Web服务，第2部分: 深度探索Axis2：AXIOM - 编程入门网
| （到 java.io.OutputStream、java.io.Writer 或 StAX javax.xml.stream.XMLStreamWriter），以及为包装的内容返回解析器实例的另一种方法。OMElement 实现可以使用 OMDataSource 的实例按需提供数据，而 OMFactory 接口提供了创建这种类型的元素的方法。
性能 我们将对性能进行简要的分析，以此总结关于 AXIOM 的内容。在撰写这篇文章的时候，AXIOM 1.1 已经发布，这意味着本文中描述的接口应该比较稳定。另一方面，随着实际实现代码的修改，性能总在发生着变化。与其他的文档模型相比，我们并不期望 AXIOM 在性能上有什么重大的改进，但是其中的一些具体细节可能有些差异。 为了将 AXIOM 与其他的文档模型进行比较，我们对以前的文档模型研究（请参见参考资料部分）中的代码进行了更新，添加了 AXIOM 和另一种新的文档模型 (XOM)，对代码进行转换使其使用 StAX 解析器标准，而不是较早的 SAX 标准，并切换到使用 Java 5 中引入的改进的 System.nanoTime() 计时方法。性能测试代码首先将测试中使用到的文档读入到内存中，然后对文档进行一系列的操作。首先，使用解析器构建文档表示的某个数量的副本，并保存每个结果文档对象。接下来，对每个文档对象进行遍历，这意味着代码将扫描整个文档表示（包括所有的属性、值和文本内容）。最后，将所有的文档对象写入到输出流。对每项单独的操作，记录其时间，并在测试结束后计算其平均值。 因为 AXIOM（尤其是用于 Axis2 中时）主要关注于处理 SOAP 消息，所以我们使用了三个不同的 SOAP 消息测试用例来检查性能。第一个测试用例是一个 Web 服务性能测试的示例响应，该服务提供了某个时间段和经/纬度范围内的地震信息（“quakes”文档，18 KB）。这个文档包含许多重复的元素和一些嵌套的情况，并大量使用了属性。第二个测试用例是来自 Microsoft WCF 可互操作性测试的一个较大的示例，由单个重复的结构组成，并且在取值上有一些细微的变化（“persons”文档，202 KB）。这个文档具有带文本内容的子元素，但是没有使用属性。第三个测试用例是由 30 个较小的 SOAP 消息文档组成的集合，这些消息来自于一些较早的可互操作性测试（总大小为 19 KB）。从测试文档中删除了所有用来进行格式化的空格，以建立真正的生产服务（通常关闭格式化，以减少消息的大小）交换使用的 XML 文档表示。 下面的图表显示了对每个文档进行 50 次处理所需的平均时间。测试环境为 Compaq 笔记本系统，1600 MHz ML-30 AMD Turion 处理器和 1.5 GB RAM，在 Mandriva 2006 Linux 上运行 Sun 的 1.5.0_07-b03 JVM。我们测试了 AXIOM 1.0、dom4j 1.6.1、JDOM 1.0、Xerces2 2.7.0 和 Nux 1.6 分发版中的 XOM。为 dom4j、JDOM 和 Xerces2 使用 StAX 解析器的自定义构建程序，而对 XOM 则使用 Nux StAX 解析器构建程序。所有的测试都使用了 Woodstox StAX 解析器 2.9.3。 图 1 显示了测试序列中前两个步骤所需的平均时间的总和，即使用解析器构建文档，并遍历文档表示以检查其中的内容。如果单独研究第一个步骤（这里没有显示时间），AXIOM 要比其他的文档模型好得多，至少对于前面两个文档来说是这样的。然而，这仅表示 AXIOM 正如预料的那样工作，直到需要时才真正构建完整的文档。我们希望使用在内存中构建完整的表示所需的时间来进行公平的比较，这正是图表中将这两个时间加在一起的原因。 图 1. 构建和展开文档的时间（单位为毫秒）
如图 1 所示，从整体上看，除了 Xerces2 之外，AXIOM 比所测试的任何其他文档模型都要慢一些。 Java Web服务，第2部分: 深度探索Axis2：AXIOM(7)时间:2011-02-02 IBM Dennis Sosnoski在处理较小的文档组成的集合（“soaps”）时，有 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
