Java Web服务，第2部分: 深度探索Axis2：AXIOM - 编程入门网
| 一些文档模型出现了性能问题。Xerces2 在这种情况下最糟糕，但是 AXIOM 也出现了较大的开销，这可能是该图表中反映出来的最麻烦的问题。在许多 Web 服务中，较小的消息是很常见的，而 AXIOM 应该可以高效地处理这些消息。因为 AXIOM 设计为按需展开文档树，所以对于两个较大的文档，在时间上并不存在很大的问题，至少与其他的文档模型非常接近。
图 2. 写入文档的时间（单位为毫秒）
图 2 显示了使用每种模型将文档写入到输出流中的平均时间。这里，Xerces2 的性能要高出一大截（但这并不足以弥补它在构建步骤中糟糕的性能，这两张图表的比例并不一样），而 AXIOM 最差。同样的，AXIOM 对于较小的文档尤其糟糕。 图 3. 文档内存大小（单位为 KB）
Java Web服务，第2部分: 深度探索Axis2：AXIOM(8)时间:2011-02-02 IBM Dennis Sosnoski最后，图 3 显示了每种框架在表示文档时所使用的内存大小。dom4j 又是最好的，而 AXIOM 则比其他的差了一大截。AXIOM 在内存使用方面的糟糕性能，在一定程度上是由于在所构建的文档中引用了解析器，以便在使用文档实例的过程中保存解析器实例。这也是 AXIOM 在处理较小文档时尤其糟糕的原因中的一部分。然而，AXIOM 作为文档组件所使用的对象也比其他文档模型的对象大的多，这种差别可能正是 AXIOM 对两个较大的测试文档使用过多内存空间的原因（其中，固定大小的解析器开销和其他数据结构只占总的内存使用中的一小部分）。 如果将前两个图表的时间累加起来，dom4j 的总体性能最好，而 Xerces2 的性能最差（AXIOM 比它稍微好一点）。在内存使用方面，dom4j 又是最好的，而 AXIOM 在这方面是毫无争议的失败者。是不是为 AXIOM 感到遗憾呢？ 如果始终构建完整的树表示，那才是应该 遗憾的，但请记住，AXIOM 的关键思想是在通常情况下并不需要完整的表示。图 4 显示了在 AXIOM 中初始文档构建的时间，并与其他文档模型构建文档表示所需的时间进行了比较。在这个测试中，AXIOM 比其他的文档模型快得多（对于两个较大的文档，甚至快得无法记录时间）。同样的比较也可以应用于内存方面。最后的结论是，如果只需要处理文档模型中的某些部分（如按文档顺序的“第一”部分），AXIOM 提供了优秀的性能。 图 4. 初始文档构建
继续学习 Axis2 本文深入研究了 Axis2 中的 AXIOM 文档对象模型。AXIOM 中包含了一些有趣的思想，尤其是构建完整表示的按需构建方法。当您需要完整地展开表示时，它无法与其他的 Java 文档模型相比。尤其是对于较小的文档，其性能比较糟糕，但是它为 Web 服务处理所提供的灵活性完全可以抵销这些问题。 现在，您已经了解了 Axis2 如何使用 AXIOM 处理 SOAP 消息表示，包括如何与数据绑定框架相互传递 XML。下一篇文章将从用户的角度来研究 Axis2 如何支持不同的数据绑定框架，包括使用三种框架的代码示例。 本文配套源码 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
