Apache Axis2 Web 服务框架构建于新的 AXIOM XML 文档模型之上，可以进行高效的 SOAP 消息处理。与常规的文档模型不同，AXIOM 仅在被访问时才会在内存中构建文档表示。了解为什么这种按需构造的方法对于 SOAP 处理来说非常合适，以及为什么 XOP/MTOM 附件、数据绑定和性能非常适于这种情况。

　　为什么需要另一种文档模型?

　　Apache Axis2 1.1 已经发布，它为那些长期运行 Apache Web 服务框架系列的忠实用户提供了令人兴奋的新特性。我们将在后续的文章中讨论关于 Axis2 的内容，本文将深入研究 AXIs 对象模型 (AXIOM) XML 文档模型，这是 Axis2 的核心。AXIOM 是 Axis2 中一个主要的创新，并且是 Axis2 能够比原来的 Axis 提供更好性能的原因之一。本文将向您介绍 AXIOM 的工作原理、Axis2 的各个部分如何构建于 AXIOM 之上，以及 AXIOM 与其他的 Java™ 文档对象模型的性能比较。

　　文档模型通常用于对 XML 进行处理，并且在 Java 开发中有许多不同的文档模型可供使用，包括原始 W3C DOM 规范的各种实现、JDOM、dom4j、XOM 等等。每种模型都声称与其他模型相比具有某些优点，要么是在性能、灵活性方面，要么是在严格遵守 XML 标准的程度方面，并且每种模型都拥有忠实的支持者。那么，Axis2 为什么需要一种新的模型呢?答案在于 SOAP 消息的结构，尤其是如何在基本的 SOAP 框架中添加相应的扩展。

　　SOAP 简介

　　SOAP 本身仅仅只是 XML 应用程序负载的简单包装。清单 1 提供了一个示例，其中只有那些具有 soapenv 前缀的元素才真正是 SOAP 中定义的。文档中大部分是应用程序数据，这些数据组成了 soapenv:Body 元素的内容。

　　清单 1. SOAP 示例

　　尽管基本的 SOAP 包装非常简单，但是通过使用称为 Header 的可选组件，它提供了不受限制的扩展能力。Header 为添加各种各样的元数据提供了合适的位置，这些元数据与应用程序数据在一起，不会被应用程序看到(可以 在 Header 中包括应用程序数据，但是这样做并不是很合理，您应该将应用程序数据放在消息的正文部分)。构建于 SOAP 之上的扩展(如整个 WS-* 系列)，可以使用 Header 实现相应的目标，而不会对应用程序造成任何影响。这允许将扩展作为外接程序使用，可以在部署时选择某个应用程序所需的特定扩展功能，而无需在代码中对其进行处理。

　　清单 2 显示了与清单 1 SOAP 示例相同的应用程序数据，但其中包括 WS-Addressing 信息。尽管原始的 SOAP 消息只能用于 HTTP 传输(因为 HTTP 提供了双向的连接，使得响应可以立即发送回客户端)，但清单 2 中的版本可以用于其他协议，因为 SOAP 请求消息中直接包括了响应元数据。在对清单 2 的消息进行处理的过程中，甚至可以进行存储转发操作，因为这些元数据同时提供了请求目标和响应目标信息。