讨论 Apache Axis2 的各个组成部分，并了解其为何凭借模块化和可扩展特性正逐渐成为下一代 Web 服务平台。

　　引言

　　2006 年 5 月推出 Apache Axis2 1.0 是一个大的里程碑。Axis2 1.1 于 2006 年 11 月推出，提供了大量新功能（其中大部分都是其用户最初提出的）以及大量错误修补程序（使其更加稳定）。：从最初的 Apache Axis 和 Apache SOAP 到目前的 Axis2，经历了很大的发展。它不仅更高效、模块化、基于 XML，而且具有灵活性和可扩展性，实现了安全性和可靠性等企业功能。Apache Axis2 的易用性和功能确实使其成为了下一代 Web 服务平台。在本文中，您将了解目前已实现了哪些功能。您将看到一个支持新一代可互操作标准（如 WS-Security、WS-Reliable Messaging 和 WS-Addressing）的成熟产品。

　　Axis2 体系结构：组件视图

　　图 1. 组件视图
 
　　AXIS 对象模型（AXIs Object Model，AXIOM）是 Apache Axis2 的 XML 对象模型。Axiom 之上的内核层包含引擎、模块和部署框架。在 Axis2 的核心部分没有特定于 Java? 的概念。所有其他组件都在内核之上的层中。各种传输协议（如 HTTP 和 SMTP）和数据绑定（在 XML 和 Java 代码之间进行转换）并不在核心中，因为它们是可插入的，因此提供了很大的灵活性。所有其他相关技术（如 Java API for XML Web Services (JAX-WS)）都在 Axis2 之上的层次中。

　　我们现在将分析 Axis2 的以下组件：

　　AXIOM（新 XML 信息集表示形式）
　　可扩展消息传递引擎
　　可插入模块体系结构
　　经改进的部署模型
　　新客户机 API
　　可插入数据绑定
　　代表性状态传输（Representational State Transfer，REST）支持

　　AXIOM

　　AXIs 对象模型 (AXIOM) 是一个 XML 对象模型，设计用于提高 XML 处理期间的内存使用率和性能，基于 Pull 解析。通过使用 Streaming API for XML (StAX) Pull 解析器，AXIOM（也称为 OM）可以控制解析过程，以提供延迟构建支持。延迟构建是指 AXIOM 不完全构建对象模型，模型的其余部分基于用户的需求构建。以下示例对此概念进行了说明：

　　假定某个用户需要从 XML 输入流中获得第一个人的 <Location> 元素值，AXIOM 构建的对象模型将一直包含到 <Location> 元素结束的内容，而让其他内容保留在流中：

　　清单 1. 对象模型的 AXIOM 部分构建
    
　　<Persons>
　　  <Person>
　　     <Name>Dihini Himahansi</Name>
　　     <Sex>Female</Sex>
　　     <Location>Colombo, Sri Lanka</Location> 
　　     <— Object model is being built only up to this point
　　  </Person>
　　  <Person>
　　     <Name>Thushari Damayanthi</Name>
　　     <Sex>Female</Sex>
　　     <Location>Elpitiya, Sri Lanka</Location>
　　  </Person>
　　</Persons>
 
　　这里的优势在于，尽可能仅使用能满足用户的需求的内存。如果用户希望访问较大的文档中前面的数个字节或数千字节，则延迟构建功能将改善该应用程序的内存需求情况。

　　可以从任何元素获得 StAX 事件，而不管是否完整构建了对象模型。在有些情况下，Axis 2 中的此功能非常有用。例如，当 Axis2 作为中介传递时，如果需要仅读取 SOAP 消息的 Header，AXIOM 将防止其读取整个 SOAP 消息，使其具有很高的内存效率。另一个例子是，当 Web 服务实现能够直接使用 StAX 事件时，由于采用了 AXIOM，Web 服务所需的内存非常小。

　　此外，AXIOM 内置了消息传输优化机制（Message Transfer Optimization Mechanism，MTOM）支持。对于 AXIOM 体系结构，可以通过实现 AXIOM 接口并将其插入到 Axis2 中来执行自己的对象模型。

　　由于 AXIOM 最初是作为 Axis2 的对象模型而开发的，因此 AXIOM 提供了构建于基础 AXIOM API 之上的 SOAP 接口。这允许您使用 envelope.getHeaders 和 envelope.getBody 之类的便利方法查看 SOAP。

　　与其他广泛使用的对象模型相比，AXIOM 已被证明更快速高效。有关对 AXIOM 进行的一些性能测试的信息，请参见参考资料。

　　可扩展消息传递引擎

　　正如前面提到的，Axis2 是一个纯 SOAP 处理器，并不依赖于任何 Java 特定的规范。例如，JAX-WS 将作为 Axis2 上的一个层实现，而不会进入核心部分中。

　　图 2. 可扩展消息传递引擎
 
　　引擎通过传输协议接收到消息后，将调用之前注册的一系列拦截器（称为处理程序）。处理程序通常处理 SOAP Header 内的信息，不过并不限制同时对消息的其他部分进行处理。随后会将消息传递给消息接收者——消息的最终接收方。消息接收者同时也负责对消息进行相应的处理，大部分时候都会将此消息传递给服务实现类进行处理。

　　Axis2 的管道模型

　　可以使用一组关系对 Axis2 的核心消息处理部分进行建模。Axis2 引擎的传入消息会通过“In”管道。所有传出消息都会通过“Out”管道。

　　图 3. Axis2 的管道模型
 
　　消息交换模式（Message Exchange Pattern，MEP）

　　让我们看一下客户机和服务器之间的消息交换。如果客户机需要从服务器获得股票报价，则将向服务器发送请求消息，服务器将随后向客户机发送一条响应消息。从服务器的角度而言，它将接收一个“In”消息，发送一个“Out”消息。这是用于请求-响应方案的模式，名为 In-Out MEP。与此类似，客户机可以向服务器发送 In-Only 消息来发出请求，例如订阅邮件列表。

　　有关消息交换模式的更多信息，请参见 W3C 网站。
 
　　通过组合使用不同数量的 In 和 Out 管道，Axis2 可以处理任何 MEP。例如，可以使用一个 In 管道和一个 Out 管道来支持进行 In-out 交互。可以使用一个 In 管道来支持 In-Only 交互。这些管道之间的连接由消息接受者进行。

　　Axis2 可以处理 Web 服务描述语言（Web Services Description Language，WSDL）2.0 规范中定义的大部分 MEP，且可以扩展为支持任何自定义 MEP。

　　阶段

　　每个 Axis2 管道内部被逻辑划分为名为阶段 (Phase) 的区域。（阶段是管道中的处理程序逻辑集。）将按特定的方式对这些阶段进行命名，以表示在该阶段对消息的处理方式。例如，管道中的第一个阶段是 TransportIn 阶段，所有进行传输信息处理的处理程序都可能位于此处。Dispatch 阶段中的处理程序将标识此消息的目标服务和操作。

　　这些阶段都会有用处，特别是尝试部署新处理程序时，因为我们可以指定处理程序需要在哪个阶段中执行。

　　上下文层次结构

　　Axis2 环境需要在不同的级别保存信息。例如，整个引擎公用的信息应该在系统级别进行维护，而消息级别的信息应该保存在消息级别。有些信息是动态的，而有些信息是静态的。为了处理这些不同的需求，Axis2 提供了上下文层次结构来在不同级别维护信息。

　　图 4. 上下文层次结构
 
　　层次结构的左侧包含所有动态信息，而右侧则包含静态信息（大部分都是从文件中读取的）。

　　MessageContext 包含与所处理的消息相关的信息，而 OperationContext 包含此消息所属的特定 MEP 相关的信息。ConfigurationContext 包含系统级的动态信息，而 AxisConfiguration 包含系统级的静态信息（大部分都是从 axis2.xml 读取的）。

　　调度

　　传入 Axis2 引擎的每条消息都以特定服务和操作为目标。标识此服务/操作组合的过程称为调度，Axis2 引擎提供了进行此工作的四种基本方法：
　　
　　基于请求 URI 进行调度：有时候可以通过查看请求 URI 确定消息的目标服务。例如，通过请求 URI“http://myip/axis2/service/StockQuoteService/getQuote”可以确定，该消息的目的地是 StockQuoteService 的 getQuote 操作。

　　传输信息：可以将 SOAPAction HTTP Header 用于确定服务和操作。

　　WS-Addressing Header：如果传入消息包含 WS-Addressing Header，也可以将其用于进行调度。

　　如果 SOAP 主体的第一个子项的 QName 是使用 RPC 规则定义的，则也可以使用此名称。

　　这些是 Axis2 引擎的一些基本功能。我们现在将了解模块如何为 Axis2 提供扩展机制。

　　可插入模块体系结构

　　模块为服务器提供了一个扩展机制。Axis2 中的每个模块都包含一组相关的处理程序。例如，WS-Addressing 模块将包含一组为 Axis2 引擎提供 WS-Addressing 支持的处理程序。Axis2 管理员可以下载 WS-Addressing 模块，并将其部署到 Axis2 引擎中，从而为 Axis2 引擎添加 WS-Addressing 支持。module.xml 文件包含指定处理程序应属于哪个管道和阶段的规则。

　　图 5. 可插入模块体系结构
 
　　模块非常有用，因为在需要支持某个 WS-* 规范的情况下，可以下载并部署相应的模块，而不必担心处理程序应该归入何处。模块的扩展名为 .mar，指示其为模块存档 (module archive)。以下是支持已经构建的 WS-* 规范的几个模块：

　　Sandesha2 模块：提供 WS-Reliable Messaging 支持
　　WS-Addressing 模块：为 Axis2 提供 WS-Addressing 支持
　　Rampart 和 Rahas 模块：提供 WS-SX（安全相关规范）支持
　　Kandula 模块：提供 WS-AT 支持
　　Savan 模块：提供 WS-Eventing 支持

　　模块可用性和参与

　　模块部署到 Axis2 引擎中后，它就“可用”，并能够参与到系统中。模块的参与可以在以下级别进行，具体取决于特定要求：

　　系统级别：模块将影响整个系统，此模块中的处理程序将应用于传入系统的所有消息。

　　服务级别：此模块中的处理程序将应用于以特定服务为目标的消息。这些处理程序应该始终部署在调度阶段后。

　　操作级别：此模块中的处理程序将应用于以特定操作为目标的消息。这些处理程序应该始终部署在调度阶段后。

　　部署服务后，可以通过在描述符中加入一个较小的条目来使模块参与到服务中。

　　经改进的部署模型

　　Axis2 现在支持将服务热部署到 Axis2 引擎中。这就允许用户在不用重新启动服务器的情况下部署服务。服务应该存档为 ZIP 文件，且在文件名中使用 .aar（Axis2 存档，Axis2 archive）作为扩展名。服务存档包含以下信息：

　　服务实现类

　　Services.xml 文件描述其使用的消息接收者、所需的任何模块和可用的操作
可选依赖库打包在 lib 文件夹内

　　可以将这些服务存档文件复制到 Axis2 存储库中（其中包含所有服务和模块），或通过 Axis2 所属的管理控制台进行更新。

　　新客户机 API

　　Axis2 可以采用两种方式调用 Web 服务。ServiceClient API 是最简单的方法，但为用户提供的控制较少。OperationClient API 在调用期间提供了大量的控制。这两个 API 都内置了基本 In-Out 和 In-Only MEP。

　　Axis2 现在同时支持阻塞和非阻塞调用模型。非阻塞调用在设计用户界面时以及服务调用非常费时的情况下很有用。

　　用户现在可以为调用的不同路径选择不同的传输方法。例如，对于 In-Out 调用，用户可以按照以下方式进行处理：

　　使用 HTTP 发送消息，并使用相同的 HTTP 通道接收响应（使用一个双向通道传输方法）

　　使用 HTTP 发送消息，但使用不同的 HTTP 通道接收响应（使用两个双向通道传输方法）

　　使用 SMTP 发送消息，并使用 SMTP 接收响应（两个不同的传输方法）
这个功能可在选择交互的恰当传输时为用户提供最大的控制。

　　可插入数据绑定

　　在纯 SOAP 级别上工作有时候比较麻烦，因此大部分用户更喜欢使用 Java 代码，而让框架处理 XML 和 Java 代码间的转换。这称为数据绑定。有很多数据绑定框架可用，用户会因为各种不同的原因而偏好使用某个框架。Axis2 支持目前可用的大部分数据绑定框架，而且没有任何限制。例如，Axis2 内置了对 XMLBeans、JAXB 和 JiBX 的支持，用户可以选择使用其中任何一个。任何其他数据绑定框架都可以方便地插入。

　　Axis2 还提供自己的简单数据绑定框架，称为 Axis2 Data Binding (ADB)。这就允许用户下载 Axis2 并使用它，而不用太多考虑数据绑定框架。由于 ADB 和 Axis2 内部元素之间实现了紧密的集成，可以预见，与其他框架相比，此框架的性能和生成代码维护方面都更具优势。最近的 WS 互操作性研讨会中对 ADB 进行了大量的测试（请参见参考资料）。

　　REST 支持

　　随着 Web 2.0 的推出，代表性状态传输（REpresentational State Transfer，REST）得到了认可。一段时间以来，REST 阵营和 SOAP 阵营一直在就使用哪个规范进行激烈的争论。我们尝试在 Axis2 中同时支持二者，采用了 WSDL 2.0 中将 REST 与 Web 服务结合的工作成果。

　　在 Axis2 中，用户可以调用 Axis2 引擎中采用 REST 方式部署的所有 Web 服务，但受到 WSDL 2.0 HTTP Bindings 规范中定义的约束的限制。

　　Axis2 中其他值得注意的改进

　　WSDL 2.0 支持：Axis2 现在支持 WSDL 2.0。我们在最近进行的互操作性研讨会中成功地进行了初始互操作性测试。

　　工具支持：复杂操作始终需要使用工具来简化工作。Axis2 随附了 WSDL2Java 和 Java2WSDL 工具，同时提供了与 Axis2 协同工作的 Eclipse 插件。通过在 Web 容器中部署管理控制台，可以更方便地对 Axis2 引擎进行远程管理。

　　各种传输协议支持： Axis2 支持 HTTP、SMTP、TCP 和 JMS。

　　Spring 支持：Axis2 内置了 Spring 服务支持。您可以编写 Spring Bean，然后方便地使用 Axis2 将其作为 Web 服务公开。

　　WS-Policy 集成：Axis2 完全支持 WS-Policy，该规范已集成到了引擎的核心中。

　　关于作者

　　Eran Chinthaka 是首创 Apache Axis 2 项目的架构师，专职是 Lanka Software Foundation 的软件工程师。他曾经为 Axis 2 实现了 AXIOM、WS-Addressing、SOAP 1.1 和 1.2，以及 BPEL4WS 的可视化建模工具。此外，他还做过 Web 服务、业务过程自动化、移动开发和电信网络管理项目的架构师。