Java Web 服务，第 2 部分: 深度探索 Axis2：AXIOM

核心提示： 文档模型面临的一个进退两难的问题因为 SOAP Header 的关键思想是允许在消息中添加任何元数据，所以 SOAP 框架必须能够接受某些扩展需要添加的任何内容，Java Web 服务，第 2 部分: 深度探索 Axis2：AXIOM(3)，一般来说，处理任意的 XML 的最简单方法是使用某种形

文档模型面临的一个进退两难的问题

因为 SOAP Header 的关键思想是允许在消息中添加任何元数据，所以 SOAP 框架必须能够接受某些扩展需要添加的任何内容。一般来说，处理任意的 XML 的最简单方法是使用某种形式的文档模型。这正是文档模型的任务所在，即不对该 XML 的形式进行任何假设，如实地表示 XML。

但是对于处理在不同应用程序之间进行数据交换时所使用的 XML 来说，文档模型并不是一种非常高效的方法。通常，应用程序数据具有预定义的结构，并且大多数开发人员更倾向于以数据对象而不是原始的 XML 的形式对这些数据进行处理。数据对象和 XML 之间的转换任务由数据绑定负责完成。与使用文档模型相比，数据绑定为开发人员带来了更大的方便，同时，它在性能和内存使用方面的效率也更高。

所以，大多数应用程序希望使用数据绑定来处理 SOAP 消息的应用程序负载，但是对于处理 Header 中的元数据，使用文档模型的方法更合适。理想的方法是在 SOAP 框架中同时使用这两种技术，但普通的文档模型不支持这种用法。它们希望处理整个文档，或者至少是文档中一个完整的子树。它们无法处理文档中所选的部分，但这是处理 SOAP 的最合适的方式。

以拉方式构建 AXIOM 树

除了 AXIOM 之外，Axis2 还对 Axis 进行了另一个改进。原始的 Axis 使用标准的推式 (SAX) 解析器进行 XML 处理，而 Axis2 使用拉式 (StAX) 解析器。在使用推方式的情况下，由解析器来控制解析操作，需要向解析器提供要解析的文档和处理程序。然后，在对输入文档进行处理的时候，它使用代码中的处理程序作为回调。处理程序代码可以使用这些回调中传递的信息，但是不能影响解析过程（除了引发一个异常）。相反，在使用拉方式的情况下，解析器实际上是一个高效的迭代器，可以根据需要对文档中的不同部分进行遍历。