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

核心提示： 推方式和拉方式分别具有各自的用途，但是对于处理包含逻辑上独立的不同部分的 XML（如 SOAP），Java Web 服务，第 2 部分: 深度探索 Axis2：AXIOM(4)，使用拉方式更有优势，，dom4j 将类似 DOM 的接口和 Java 集合类组合到一起，这种非常灵活的 API 提供了

推方式和拉方式分别具有各自的用途，但是对于处理包含逻辑上独立的不同部分的 XML（如 SOAP），使用拉方式更有优势。。使用拉式解析器，处理文档某一部分的代码仅解析它所需的部分，然后由解析器进行接下来的文档处理。

AXIOM 构建于 StAX 拉式解析器接口的基础之上。AXIOM 提供了一种可以按需扩展的虚拟文档模型，仅构建客户端应用程序所请求的树结构文档模型表示。这种虚拟的文档模型工作于 XML 文档的元素级。当解析器报告元素开始标记时创建元素表示，但是该元素的初始形式仅仅只是一个壳，其中保存了对解析器的引用。如果应用程序需要获取元素内容的细节信息，它只需要通过调用接口（如 org.apache.axiom.om.OMContainer.getChildren() 方法）的方法，就可以请求相应的信息。然后，在对这个方法调用的响应中，解析器将构建该元素的子内容。

因为解析器按照文档顺序（与 XML 文档文本中项目的出现顺序相同）传递数据，所以 AXIOM 所实现的按需构造需要某种灵活的处理方法。例如，通常有多个元素处于不完整的（正在构建的过程中）状态，但是这些元素都必须位于继承结构的一条直线中。如果从根元素在顶端的标准 XML 树关系图的角度来看，不完整的元素将始终位于该树右侧的直线中。随着应用程序请求更多的数据，该树逐渐向右扩充，并且首先完成顶端的元素。

使用 AXIOM

就所提供的 API 而言，所有的 XML 文档模型都具有很多相同之处（这并不奇怪，因为它们都需要处理相同的基础数据），但是与其他的文档模型相比，它们又各有千秋。原始的 W3C 文档对象模型 (DOM) 设计提供跨语言和跨平台的兼容性，所以构建于各种接口之上，并且在其自身的版本中避免使用 Java 特定的集合。JDOM 使用了具体类而不是接口，并且在这种 API 中集成了标准的 Java 集合类，许多 Java 开发人员认为它比 DOM 更友好。dom4j 将类似 DOM 的接口和 Java 集合类组合到一起，这种非常灵活的 API 提供了很多强大的功能，但却在一定的程度上增加了复杂性。