Java Web服务，第2部分: 深度探索Axis2：AXIOM - 编程入门网
wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:97AE2B17231A8584D811537402403691</wsa:MessageID>
</soapenv:Header>
<soapenv:Body>
<matchQuakes xmlns="http://seismic.sosnoski.com/types">
<min-date>2000-03-28T13:13:08.953Z</min-date>
<max-date>2001-03-11T02:26:54.283Z</max-date>
<min-long>-81.532234</min-long>
<max-long>65.25895</max-long>
<min-lat>-14.234512</min-lat>
<max-lat>57.174187</max-lat>
</matchQuakes>
</soapenv:Body>
</soapenv:Envelope>
Java Web服务，第2部分: 深度探索Axis2：AXIOM(2)时间:2011-02-02 IBM Dennis Sosnoski文档模型面临的一个进退两难的问题 因为 SOAP Header 的关键思想是允许在消息中添加任何元数据，所以 SOAP 框架必须能够接受某些扩展需要添加的任何内容。一般来说，处理任意的 XML 的最简单方法是使用某种形式的文档模型。这正是文档模型的任务所在，即不对该 XML 的形式进行任何假设，如实地表示 XML。 但是对于处理在不同应用程序之间进行数据交换时所使用的 XML 来说，文档模型并不是一种非常高效的方法。通常，应用程序数据具有预定义的结构，并且大多数开发人员更倾向于以数据对象而不是原始的 XML 的形式对这些数据进行处理。数据对象和 XML 之间的转换任务由数据绑定负责完成。与使用文档模型相比，数据绑定为开发人员带来了更大的方便，同时，它在性能和内存使用方面的效率也更高。 所以，大多数应用程序希望使用数据绑定来处理 SOAP 消息的应用程序负载，但是对于处理 Header 中的元数据，使用文档模型的方法更合适。理想的方法是在 SOAP 框架中同时使用这两种技术，但普通的文档模型不支持这种用法。它们希望处理整个文档，或者至少是文档中一个完整的子树。它们无法处理文档中所选的部分，但这是处理 SOAP 的最合适的方式。 以拉方式构建 AXIOM 树 除了 AXIOM 之外，Axis2 还对 Axis 进行了另一个改进。原始的 Axis 使用标准的推式 (SAX) 解析器进行 XML 处理，而 Axis2 使用拉式 (StAX) 解析器。在使用推方式的情况下，由解析器来控制解析操作，需要向解析器提供要解析的文档和处理程序。然后，在对输入文档进行处理的时候，它使用代码中的处理程序作为回调。处理程序代码可以使用这些回调中传递的信息，但是不能影响解析过程（除了引发一个异常）。相反，在使用拉方式的情况下，解析器实际上是一个高效的迭代器，可以根据需要对文档中的不同部分进行遍历。 推方式和拉方式分别具有各自的用途，但是对于处理包含逻辑上独立的不同部分的 XML（如 SOAP），使用拉方式更有优势。。使用拉式解析器，处理文档某一部分的代码仅解析它所需的部分，然后由解析器进行接下来的文档处理。 AXIOM 构建于 StAX 拉式解析器接口的基础之上。AXIOM 提供了一种可以按需扩展的虚拟文档模型，仅构建客户端应用程序所请求的树结构文档模型表示。这种虚拟的文档模型工作于 XML 文档的元素级。当解析器报告元素开始标记时创建元素表示，但是该元素的初始形式仅仅只是一个壳，其中保存了对解析器的引用。如果应用程序需要获取元素内容的细节信息，它只需要通过调用接口（如 org.apache.axiom.om.OMContainer.getChildren() 方法）的方法，就可以请求相应的信息。然后，在对这个方法调用的响应中，解析器将构建该元素的子内容。 因为解析器按照文档 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
