转自：http://www.ibm.com/developerworks/cn/webservices/ws-soa-axis2-1/index.html

Deepal Jayasinghe (deepal@apache.org), 高级软件工程师, WSO2

2006 年 12 月 28 日

Apache Axis2 是 Apache Axis SOAP 项目的后继项目。此项目是 Web 服务核心引擎的重要改进，目标是成为 Web 服务和面向服务的体系结构（Service-Oriented Architecture，SOA）的下一代平台。作为一个干净的可扩展的开放源代码 Web 服务平台，它正逐渐受到广泛的关注。Axis2 的体系结构高度灵活，支持很多附加功能，如可靠消息传递和安全性等。

引言

Web 服务的历史非常悠久，在其发展期间经历了多次迭代。第一代 Web 服务是受到高度控制的交互，可以视为仅是对可行性的测试。Apache SOAP 是第一代中值得注意的 SOAP 引擎之一，主要用作“概念验证”，而根本没有考虑性能。第一代 SOAP 引擎的整个目的是为了让人们认识到 Web 服务是一个理想的选项。

不久，第一代 SOAP 引擎获得了回报。越来越多的公司开始对此产生兴趣，SOA 的概念逐渐成形。可以将此阶段称为第二代 Web 服务，它要求更好更快的 SOAP 引擎。发现和定义等方面已经得到标准化，并需要 SOAP 引擎来支持这些标准。Axis 是这些第二代 SOAP 引擎之一。

现在，第二代 Web 服务的时代已经接近尾声。Web 服务现在的要求非常高，Web 服务领域的参与者也非常多。用于控制 Web 服务交互的不同方面的涉及内容已得到标准化。第三代 Web 服务要求使用更快、更可靠的 SOAP 引擎——现有的 Axis 已不足以满足此要求。Axis2 应运而生，填补了这一空白。

Axis2 体系结构

Axis2 具有模块化体系结构，由核心模块和非核心模块组成。据说，Axis2 核心是纯 SOAP 处理引擎，并没有包含 Java™ API for XML-based RPC (JAX-RPC) 概念作为其核心的一部分。同时，Axis2 体系结构的设计充分考虑了以下原则：

• 逻辑和状态分离，以提供无状态处理机制，因为 Web 服务是无状态的。
• 所有信息位于一个信息模型中，允许对系统进行挂起和恢复。
• 能够在不更改核心体系结构的情况下扩展功能，能以最小或没有核心更改的情况下直接支持新 Web 服务规范。

Axis2 核心体系结构包括以下核心和非核心组件：

• 核心组件
  • XML 对象模型 (AXIOM)
  • SOAP 处理模型：处理程序框架
  • 信息处理模型：上下文和描述
• 其他组件
  • 部署模型
  • 传输
  • 客户机 API
  • 核心生成模型

您可以在图 1 中看到这些组件。

图 1. Axis2 体系结构关系图

Axis2 主要特性

Axis2 不仅是 Apache 的新 Web 服务框架。它还体现了从 Axis 1.x 系列获得的经验和最近两年在 Web 服务领域的发展。推出 Axis2 的主要原因之一是从速度和内存方面获得更好的性能——不过还添加了一些新特性和功能。大部分新特性都是为了提高 Axis2 的易用性，并同时保留通过各种方式扩展功能的空间。大部分新功能所添加到的主要领域如下所示：

1. 新 XML 对象模型 (AXIOM)
2. 基于消息传递的核心
3. 经过改进的部署模型
4. 可插入数据绑定
5. 新客户机 API
6. 信息处理模型

新 XML 对象模型：AXIOM

正如上面提到的，与 Axis 1.x 相比，Axis2 构建于全新的体系结构之上。引入 Axis2 的主要原因之一是获得合适的 XML 处理模型。Axis 1.x 使用 DOM 作为其 XML 表示机制，但使用 DOM 的缺点是，需要在内存中保存完整的对象层次结构（与传入消息对应）。对于小消息，这将不是问题，但对于大型消息就是问题了。为了克服此问题，Axis2 引入了新的 XML 表示形式作为其基础。

Axis2 对象模型（AXIs2 Object Model，AXIOM）是 Axis2 的基础，任何 SOAP 消息在 Axis2 中都表示为 AXIOM。AXIOM 相对于其他 XML 表示形式的优势在于，它基于 pull 解析器技术，而其他大多数则基于 push 解析器技术。pull 与 push 的主要不同之处在于，在 pull 技术中，调用者对解析器具有完全控制权，可以要求下一个事件；而对于 push，当要求解析器继续处理时，它将触发事件，直到达到文档最后为止。

由于 AXIOM 基于 pull 解析器技术，因此具有“随需应变构建”功能，仅在被要求时才会构建对象模型，而且，如果需要，可以直接从 AXIOM 访问基础 PULL 解析器并对其加以使用，而不用构建对象模型（Object Model，OM）。

基于消息传递的核心

Axis2 核心是纯 SOAP 处理引擎，并不了解数据绑定、传输、WSDl 等内容。Axis2 核心的主要功能是处理传输消息，并将其交付给目标应用程序。与 Axis 1.x 一样，Axis2 也具有用于扩展其主要功能的处理程序概念。

阶段和阶段规则 阶段是一个或多个处理程序的逻辑集合，有时候阶段本身也充当处理程序。Axis2 引入了阶段概念，以方便地对核心功能进行扩展。在 Axis 1.x 中，如果您希望向处理程序链添加处理程序，需要更改全局配置文件，但对于 Axis2， 您并不需要进行此工作，因为阶段和阶段规则可解决此问题。阶段规则用于指定如何在阶段内对给定处理程序集进行排序。图 2 说明了阶段如何组成流。

Axis 1.x 并没有异步 Web 服务调用的概念，它完全绑定到请求-响应调用，但在 Axis2 中却是另一番景象。Axis2 体系结构能够支持在客户端和服务器端同时支持异步调用。同时，Axis2 也支持请求-响应样式的调用，但这会以两个异步调用的方式进行。在 Axis2 中，进入系统的消息可能有也可能没有响应，应该注意，Aixs2 支持 WSDL 2.0 中定义的所有八种消息交换模式（Message Exchange Patterns，MEP）。

Axis2 具有流的概念，流是阶段的集合，而阶段是处理程序的集合。根据给定方法调用的 MEP，与其关联的流的数量可能会有所变化。如果仅传入的 MEP 对应方法只具有一个流，则称为 inflow；而对于传入-传出，则具有两个流——inflow 和 outflow。在大多数情况下，inflow 从传输侦听器开始，到消息接收方处结束，而 outflow 能以不同的方式开始，大多数情况下都在传输发送方处结束。

消息接收方 如果消息在没有出现问题的情况下通过执行链，则引擎会将消息转交给消息接收方来进行业务逻辑调用，此后，将由消息接收方调用服务并在必要的情况下发送响应。图 3 说明了消息接收方如何适合执行链。

图 2. 流中的阶段


图 3. Inflow 和消息接收方

新部署模型

Axis 之前的版本没有处理好 Web 服务部署中涉及的用户友好因素，因此开发了 Axis 1.x，其主要目的是为了进行 Web 服务概念证明。因此，在 Axis 1.x 中，用户必须手动调用管理客户机，并更新服务器类路径，然后重新启动服务器，以应用更改。这个有点麻烦的部署模型对新手肯定是一道障碍。Axis2 经过了精心的设计，能够克服此缺点，并提供灵活、用户友好、可方便进行配置的部署模型。

Axis2 部署引入了类似于 Java™ 2 Platform Enterprise Edition (J2EE) 部署机制的概念，开发人员可以在其中将所有类文件、库文件、资源文件和配置文件一起打包为存档文件，并将其放置在文件系统中的指定位置。

热部署 和热更新 的概念并不是新技术术语（对于熟悉 Web 服务平台的人更是如此），但对于 Apache Axis 则是一个新特性。因此开发了 Axis2 来提供进行“热”部署的空间。

热部署：在系统启动并运行时部署服务的功能。系统可用性在实时系统或业务环境中非常重要。如果系统停机（即使很短的时间），损失会很大，可能会影响业务的生存期。不过，会同时需要向系统添加新服务，如果可以在不关闭服务器的情况下完成，则是一个极大的进步。因此 Axis2 对此问题进行了处理，提供了 Web 服务热部署功能，可以在不必关闭系统的情况下部署新 Web 服务。所需要进行的工作就是，将所需的 Web 服务存档放入到存储库的 services 目录中。然后，部署模型将自动部署服务，并进行提供。

热更新：在不必关闭系统的情况下对现有 Web 服务进行更改的能力。这是一个重要的特性，是测试环境中需要的一个功能。不过，在实时系统中使用热更新并不明智，因为热更新可能导致系统进入未知状态。此外，还可能丢失该服务的现有服务数据。为了防止发生这种情况，Axis2 的热更新参数缺省设置为 false。

新部署模型

Axis 之前的版本没有处理好 Web 服务部署中涉及的用户友好因素，因此开发了 Axis 1.x，其主要目的是为了进行 Web 服务概念证明。因此，在 Axis 1.x 中，用户必须手动调用管理客户机，并更新服务器类路径，然后重新启动服务器，以应用更改。这个有点麻烦的部署模型对新手肯定是一道障碍。Axis2 经过了精心的设计，能够克服此缺点，并提供灵活、用户友好、可方便进行配置的部署模型。

Axis2 部署引入了类似于 Java™ 2 Platform Enterprise Edition (J2EE) 部署机制的概念，开发人员可以在其中将所有类文件、库文件、资源文件和配置文件一起打包为存档文件，并将其放置在文件系统中的指定位置。

热部署 和热更新 的概念并不是新技术术语（对于熟悉 Web 服务平台的人更是如此），但对于 Apache Axis 则是一个新特性。因此开发了 Axis2 来提供进行“热”部署的空间。

热部署：在系统启动并运行时部署服务的功能。系统可用性在实时系统或业务环境中非常重要。如果系统停机（即使很短的时间），损失会很大，可能会影响业务的生存期。不过，会同时需要向系统添加新服务，如果可以在不关闭服务器的情况下完成，则是一个极大的进步。因此 Axis2 对此问题进行了处理，提供了 Web 服务热部署功能，可以在不必关闭系统的情况下部署新 Web 服务。所需要进行的工作就是，将所需的 Web 服务存档放入到存储库的 services 目录中。然后，部署模型将自动部署服务，并进行提供。

热更新：在不必关闭系统的情况下对现有 Web 服务进行更改的能力。这是一个重要的特性，是测试环境中需要的一个功能。不过，在实时系统中使用热更新并不明智，因为热更新可能导致系统进入未知状态。此外，还可能丢失该服务的现有服务数据。为了防止发生这种情况，Axis2 的热更新参数缺省设置为 false。

模块体系结构

正如上面提到的，Axis2 也具有处理程序的概念，但与 Axis 1.x 相比，指定和部署处理程序的方式有一些变化。在 Axis 1.x 中，要添加处理程序，需要首先更改全局配置文件，然后需要重新启动系统，并没有在运行时更改处理程序链的动态方法。

为了克服这个问题和增加新特性，Axis2 引入了 Web 服务扩展或模块的概念；其中模块的主要工作是对核心功能进行扩展。在 Axis 1.x 中，可以通过向处理程序链添加处理程序来实现此目标。与 Axis 1.x 处理程序链相比，使用模块的优势在于，您可以在根本不改变全局配置文件的情况下添加新模块。同时，模块是一个自容器，其中可以包含处理程序、第三方库、模块相关资源和模块配置文件。

模块的状态 模块具有两个状态：available 和 engaged。将模块放入存储库中，此模块就为 available 状态，而它的处理程序都不在处理程序链中。模块可以随时参与到系统中。参与就是将其处理程序添加到处理程序链（或流），因此一旦使模块参与系统，它就处于 engaged 状态了。

可以将模块作为存档文件部署，Axis2 为模块采用了一个新扩展文件名 .mar。模块存档文件中最重要的文件是模块配置文件或 module.xml。除非具有 module.xml 文件，否则该模块就是一个错误模块。模块配置文件主要用于指定处理程序及其阶段规则，因此让模块参与系统后，根据阶段规则不同，处理程序将被放置在不同的流上——inflow 或 outflow。

这个思路非常简单。或许您需要支持 WS-Addressing 或 WS-Security。然后您必须下载对应的模块，并将其放置到 Axis2 存储库的 modules 目录中。您可以在部署时通过向 axis2.xml（Axis2 全局配置文件）添加以下条目使模块参与系统，或在运行时通过使用各种方法（如使用 Axis2 Web 管理控制台或 handlerfor exsample）使模块参与到系统中：

<module ref="ModuleName">

新客户机 API

异步或非阻塞 Web 服务调用是目前 Web 服务中的一个主要需求。同时，还存在一些以非阻塞方式调用 Web 服务的方法。第一个是客户机编程模型，在此模型中，客户机能在不阻塞其应用程序的情况下以非阻塞方式调用服务。第二个方法是传输级非阻塞调用，其中的调用是在两个传输协议之间发生的。可以是 SMTP 之类的两个单向传输协议，也可以为两个 HTTP 之类的双向传输协议。Axis2 客户机 API 同时支持上述两个非阻塞调用方案。

Axis2 引入了用于调用服务的非常方便的客户机 API，此 API 包含两个类，分别名为 ServiceClient 和 OperationClient。ServiceClient API 专门用于只需要发送和接收 XML 的普通用户，而 OperationClient 旨在供希望处理 SOAP Header 和其他一些高级任务的高级用户使用。通过使用 ServiceClient，您只能访问 SOAP 主体或有效负载。当然，可以添加 SOAP Header，但无法从服务客户机检索 SOAP Header。为了实现此操作，您将需要使用 OperationClient。

ServiceClient 具有以下用于调用服务的 API：

• sendRobust
• fireAndForget
• sendReceive
• sendReceiveNonBlocking

sendRobust：此 API 的思路是将 XML 块发送给 Web 服务，而不考虑其响应。不过，如果出现了错误，您将也需要知道此情况。因此，此 API 用于调用并不返回值但可能引发异常的服务。

fireAndForget：此 API 只用于发送 XML 块，但并不考虑响应或异常，因此这是调用仅传入的 MEP。

sendReceive：调用具有返回值的服务。这是最常用的 API 之一，可以用于调用传入-传出 MEP。

sendReceiveNonBlocking：以非阻塞方式调用服务。服务具有返回值时，可以使用此方法。为了使用此方法，您必须传递一个回调对象，将在调用完成后立即调用回调对象。

正如前面提到的，OperationClient 用于高级用户，使用 OperationClient 要求您对 Axis2 有良好的了解。在 ServiceClient 中，您并不需要知道有关 SOAP 信封或消息上下文的任何信息，但对于 OperationClient，您必须在调用服务前自己创建它。使用 OperationClient 创建和调用服务涉及到以下步骤：

• 创建服务客户机
• 然后使用创建的服务客户机创建操作客户机
• 创建 SOAP 信封
• 创建消息上下文
• 将 SOAP 信封添加到消息上下文
• 将操作上下文添加到操作客户机
• 调用操作客户机
• 如果有响应，则从操作客户机获取响应消息上下文

总结

Axis2 将不会对 Web 服务概念进行验证，而将提供更好的 SOAP 处理模型，且与 Axis 1.x 及其他现有 Web 服务引擎相比，其速度和内容方面的性能都得到很大的提高。此外，它还为用户提供了方便的 API，用于部署服务、扩展核心功能和新客户机编程模型。现在已经进入了 Axis2 的时代了。