Axis2体系结构

用Axis2做什么

在SOAP的术语里，一个Web Service交互的参与者都称作一个SOAP的节点。SOAP消息在SOAP发送者和接收者之间传递。SOAP消息的传递是基于构建Web Service交互的单元之上。

Web Service 封装了 SOAP 消息处理的复杂性，允许用户用他们所熟悉的开发语言进行开发。 Axis2 就是通过用 Java 语言开发 Web Service 的工具，在其内部处理 SOAP 消息，这一切对于用户都是透明的。

Axis2 封装了 SOAP 消息的处理，同时还有做了其他的大量的工作，这些都进一步简化了 Web Sercice 的开发者的工作，主要有以下几点：

• 提供了一个处理 SOAP 消息的框架，这个框架是极易扩展的，用户可以在每个服务或操作上扩展它。用户也可以在这个框架的基础上对不同的消息交换模型（ Message Exchange Patterns ） MEPs 进行建模。

• 部署 Web Service （可以用 WSDL 或者不用）。

• 提供了客户端 API 用来调用 Web Service ，该API支持同步或者异步的编程方式。

• 通过部署来配置 Axis2 和它的组件。

• 在不同传输层发送和接收 SOAP 消息。

除了上述的这些功能，在内存和速度等性能方面也是 Axis2 的重点。 Axis2 的核心框架是构建在 WSDL ， SOAP 和 WS-Addressing 上，其他的如 JAX-RP ， SAAJ 和 WS-Policy 是在核心框架之上的层。

体系结构

为了保持统一性，AXIS2有几点原则，如下 ：

• Axis2 的体系结构将逻辑和状态分离，在其内部逻辑处理都是无状态的，使得代码能够在多个线程中同时执行。

• 所有的信息都被保存在一个信息模型中，允许系统阻塞和重启。

Axis2 是模块化的结构， Axis2 框架是构建在核心模块上，并用和核心模块一起构成了AXIS2的体系结构的核心，其他的模块则构建在核心模块上。核心模块包括：

• 信息模型， Axis2 定义了一个处理信息的模型，所有的状态都保存在这个模型中。在这个层次结构中，系统处理对象的生命周期。

• XML 处理模型，处理 SOAP 消息是最重要和复杂的任务，其效率是影响性能的主要因素，web service工程中这一部分是由一个子项目处理，该项目（AXIOM,即AXIS对象模式）为SOAP和XML信息集提供一个简单的API，隐藏了处理XML的复杂性
• 发布模型，它使得用户对于每一个系统、服务或者操作，能够发布服务、配置传输并且扩展SOAP处理模型，

• SOAP 处理模型，它控制了处理过程的执行。这个模型定义了不同的处理阶段，用户可以在不同的阶段扩展这个模型。

• 客户端的 API ，它为用户提供了方便的 API 以便和Web Service进行通信 。客户端API里定义的类的集合能够可以通过 IN-OUT 和 IN-only 方式进行消息的交互，他们也可以用来构建其他的消息交换模型。

• 传输器（ Transports ）， Axis2 定义了传输框架，允许用户使用不同的传输方式。在 SOAP 消息处理模型中可以利用传输器，在实现中定义了几个通用的传输器，当然用户也可以在需要的时候自定义传输器。

非核心模块：

• 代码生成， Axis2 提供了代码生成工具，可以生成服务器端和客户端的测试代码。生成代码简化了服务的部署和服务的调用，提高了AXIS2的可用性
  

• 数据绑定，在信息集层， Axi2 基本的客户 API 使得用户能够处理 SOAP 消息，数据绑定通过封装信息层，提供编程接口，可以使用户更加方便的处理SOAP信息。

、

信息模型

信息模型有两个主要的层次，上下文（ Contexts ）和描述（ Descriptions ），通过 UML 描述如下：

两个层的连接如上图，描述层代表静态数据，这些数据通过配置文件装载并且一直存在于 Axis2 的生命周期中，比如部署服务，操作。另一方面，在上下文的层中包括了不止一个实例的动态信息。

在两个层次创建的模型提供了搜索值对的能力，当在一个层上搜索值时，如果搜索不到就会在这个层的垂直体系上进行搜索，直到招致为止。在结果模型中，低层的值覆盖了高层的值。比如，如果在 Message Context 上找不到一个值时，就会在 Operation Context 上进行搜索，依次向上进行。同理在 Descriptions 也是一样的。

这样用户就可以声明和重载值，是一个非常易配置的模型，这也给系统带来了弱点，就是搜索的代价。特别是对于一些不存在的值，当然分析后，开发者认为它还是可以很好的工作。

Configuration Context

 

保持了运行时状态，本质上是 Axis2 的拷贝。

 

Axis Configuration

 

保持全部的全局配置，传输器，全局模块，参数，服务等。

Service Group Context

 

保持了不同服务组的特殊用法信息，它的生命周期开始于用户和属于该组的服务交互时，这个可以被用来在简单的交互中在不同的服务（属于同一组）中共享信息。

Axis Service Group

 

保持特殊服务组的部署时信息。

Service Context

 

在不同服务的用法中都是可用的。在一个简单的交互中，可以被用来在同一个服务中在若干个 MEPs 中共享信息。

AxisService

 

保持了多个操作和服务的配置信息。

Operation Context

 

保持了当前的 MEPs 的信息，维护当前的 MEPs 的消息。

AxisOperation

 

保持了操作层的配置。

Message Context

 

保持了当前正被执行的消息的所有信息。

AxisMessage

 

到目前为止，不保存任何信息，在未来可以作为一个扩展点。

 

XML 处理模型

参考 OM Tutorial

SOAP 消息处理模型

体系结构定义了 SOAP 处理器两个基本动作，发送和接收 SOAP 消息。这两个基本动作是由两个管道（ Pipes ），或者 Flows 来执行的。 Axis 引擎或者 Axis2 驱动定义了 send() 和 receive() 两个方法来实现管道。两个管道为 In Pipe 和 Out Pipe ，通过合并这两个 Pipes 可以构建复杂信息交模型 MEPs 。

通过处理器（ handler ）来实现 SOAP 消息处理的易扩张性。当一个 SOAP 消息被处理时，被注册的处理器就会执行，处理器可以注册在全局变量，服务，或操作范围内，最后处理器链从所有的范围内计算合并所有的处理器。

处理器也扮演了拦截器（ Intercepter ）的作用，他们处理部分 SOAP 消息，提供附加的服务，通常处理器工作在 SOAP 头上，也可以访问和改变 SOAP 体。

当一个 SOAP 消息通过客户端 API 发送， Out Pipe 就被触发， Out Pipe 调用处理器直到 SOAP 消息送到目的结点（ endpoint ），在目标端的接收传输器接收。在接收端 In Pipe 开始读 SOAP 消息。 In Pipe 由处理器和消息接收者组成。

上述发生的消息处理过程发生在所有的消息交换中。在 Axis2 中处理一消息后就会创建另一消息，在新的消息中，更复杂的模型可能出现。

两种管道 在服务端 和客户端相似， SOAP 处理模型简化了复杂性，为用户提供了抽象的接口。 在AXIS2中Pipe 的不同部位被看作是不同的阶段。处理器通常运行在一个阶段中，该阶段提供了一种机制能按顺序调用处理。无论是管道阶段还是用户阶段，都由用户自定义。

下图中可以看到 User Phases

Axis2 默认处理模型

Axis2 有很多内建在 Phases 中的处理器，它们可以为 Axis2 创建默认配置。在下节中，我们会仔细研究如何扩展 Axis2 的默认处理模型。

Axis2 中有三种特殊的处理器：

• 分发器（ Dispatchers ）为SOAP 消息查找服务和操作。通常运行在 In-Pipe 的 dispatch 阶段。根据不同的条件，如 WS-Addressing ， URI 信息， SOAP Action 信息来分配特殊的操作。

• 消息接收器（ Message Receiver ） 读 SOAP 消息将其提交给应用，运行在 In-Pipe 的 Message Processing 阶段。

• 发送传输器（      Transport Sender ）发送 SOAP 消息至目的节点，作为 Out-Pipe 中最后一个处理器。

处理收到的 SOAP 消息

由接收传输器收到消息，一旦消息到达，传输头就会被解析，消息上下文（ Message Context ）就会创建，该消息封闭了所有的信息，包括SOAP信息和传输头，此时In-Pipe 就会执行。

处理的每一个阶段所作的工作（处理过程在服务端和客户端都会发生）

• 传输阶段：验证信息以及向消息上下文中加入信息

• 预分发阶段，为信息的分发作准备工作，如SOAP信息为寻址，则将地址头加入到消息上下文中。

• 分发阶段，为信息找到正确的服务和操作，post条件检查服务和操作是否找到，如果没有，则该处理过程挂起并返回“service not found”的提示

• 用户自定义阶段，运行用户自定义处理器。

• 消息验证阶段，验证 SOAP 消息处理是否正常执行。

• 消息处理阶段，在这里执行 SOAP 消息的业务逻辑，每个操作都注册了一个消息接收器，消息接收器（关联到特定操作）就会作为这个阶段的最后一个处理器执行。

可能还有其他的处理器，用户也可以自定义处理器来重载每个阶段的处理逻辑。

发送消息的处理过程

Out-Pipe 是相对比较简单，因为在此时服务都已被所知， Out-Pipe 由消息接收器或客户 API 实现。out管道主要是以下向个阶段：

• 消息初始化阶段， Out-Pipe 的第一个阶段，作为自定义处理器的存放文件夹。

• 用户阶段，执行用户阶段的处理器

• 传输阶段，执行从传输配置层的传输处理器，作为传输处理器的最后处理器发送 SOAP 消息到目的端。

扩展消息处理模型

收入处理器和阶段的概念是为了让 SOAP 处理顺序中更容易修改，阶段概念使在处理器之间加入新的处理器，也就更容易扩展默认的处理过程。

用处理器扩展 SOAP 处理模型

通过设定规则可以将处理器不同的阶段

• 作为一个阶段的第一个处理器

• 作为一个阶段最后一个处理器

• 在一个给定处理器之前

• 在一个给定处理器之后

通过模块扩展 SOAP 处理模型

Axis2 定义了一个叫模块（ Module ）的实体，由模块来引入处理器和 Web Service 操作，在 Axis2 中的模块作为一个包，包中包括了一些处理器和相关的关于规则的描述，模块是有可用性和被用时，可用性表示模块存在于系统中，但仍没被激活，就是被包括在模块中的处理器没有在处理机制中，当一个模块被用时，它就会被激活，然后在阶段中找到合适的位置，这些处理器就会按照上面的方法执行。通常模块被用来实现在 WS-Addressing 时的 WS-* 功能。

除了上面基于 handlers 实现扩展外， WS-* 参考建议另一种增加操作（ Operations ）的方法，比如，用户在服务中增加创建序列（ Create Sequence ）的操作，需要在服务端可以用，就可以通过在模块中定义操作来实现，一旦模块被服务所用，需要的操作就会被增加到服务中。

服务，操作或系统都可以利用模块，一旦模块被用到，在其中定义的处理器，操作就会添加到这个实体中。

当 Axis2 正在运行时，模块就不能被添加，除非系统重启。

部署

部署模型提供了详细配置 Axis2 的机制，主要有三个部分来配置 Axis2

1.Axis2.xml 文件

这个文件为客户端和服务器端提供了全局的配置，主要包括下面的信息。

全局参数

注册的发送传输器（ Transport In ）和接收传输器（ Transport Out ）

用户定义的阶段名

全局被用到的模块

全局的消息接收器

2. 服务包（ Service Archive ）

服务包必须包含 META-INF/services.xml 文件和一些相关的类， services.xml 包含以下信息

服务级的参数

服务级的模块

服务中特定消息接收器

服务内部的操作

3. 模块包（ Module Archive ）

模块包必须包含 META-INF/module.xml 文件和一些相关的类， module.xml 包含了模块参数和在其中定义的操作。

当系统启动时， Axis2 就会创建 Axis 的配置，首先会找 axis2.xml ，构建全局配置，接下来就会检查模块包和服务包，这样相关的服务和模块就会被添加到配置中，然后在配置基础上，构建上下文， Axis2 就准备接收和发送 SOAP 消息，服务也可以热部署，有一个线程循环的检测容器，看是否有新的服务被部署。

客户端 API （ Client API ）

有三个参数决定了 Web Service 的交互

消息交换模型（ MEP ）

传输器的行为，是 One-way 或者 Two-way

客户端 API 是同步或者异步

由于这三个参数的变化导致了很多语义的不确定性，尽管 Axis2 是构建在运行多种消息交互的核心上，但开发者一般都用两种主要的 MEP 。

在 Client API 中，两种支持的传输器是单向（ One-Way ）和双向（ Request-Response ）。是基于 ServiceClient 类来实现的， Axis2 中有每种 MEP 的扩展支持。

单向消息传输

ServiceClient 为用户提供了简单的接口，由 ServiceClient 提供的 fireAndForge 支持 One-Way 方式， Axis2 支持 HTTP/SMTP 和 TCP 传输， HTTP 的情况，如果返回通道（ Channel ）不可用，就会返回 HTTP 202 OK 。

双向（ Request Response ）消息传输

由在 ServiceClient 中的 sendReceive() 提供，为用户提供了简单的接口，在客户 API 中有四种方法配置消息交换。

阻塞或非阻塞方式，由 sendReceive() 和 sendReceiveNonBlocking() 来决定。

发送传输器，传输器被用来发送 SOAP 消息

监听传输器，传输响应收到信息。

利用分离通道，决定是否响应是通过分离的传输连接或者非分离的来发送。如果发送和监听器是相同的机会失败，这样就是双向传输。

上面四个参数的不同就会使 Axis2 进行不同的操作。

传输器

Axis2 有两种不同传输结构， transport in 配置和 transport out 配置，通过消息上下文来访问他们。

服务器利用 transport in 来收到消息， outgoing transport 是由寻址信息（ Addressing Information ） (ReplyTo 或 FaultTo) 决定的，如果寻址信息不可用，则 outgoing transport 和 incoming transport 相同。

在客户端，用户可以自由使用 transport 。

transport in 配置和 transport out 配置包含以下信息

对外的传输发送器

对内的传输监听器

传输的参数

传输的处理器

每个对外的传输配置都定义了一个传输代理，传输发送器通过自己的传输发送消息。

传输接收器等待 SOAP 消息，一旦 SOAP 消息到，就会用 In Pipe 来处理消息。

Axis2 目前支持以下的传输

HTTP ，在 HTTP 的传输中，传输监听器是一个 Servlet 或者是由 Axis2 提供的 org.apache.axis2.transport.http.SimpleHTTPServer ，传输发送器用 commons-httpclient 来连接和发送 SOAP 消息。

TCP ，这是最简单的传输，但需要 WS-Adressing 支持

SMTP ，需要 Email 帐号，传输接收者在确定的时间间隔内检测邮件的到来。

代码生成

尽管代码生成的目标没有改变，但在 Axis2 中采用了一种不同的代码生成方法，主要变化是采用了模版，命名为 XSL 来以各种语言生产代码，提供了很好的灵活性。

主要思想，设置生成器来生成 XML ，利用模版解析 XML 来生成代码文件，下图描述了生成工具的结构

不管代码是如何生成的，关键是和从 WSDL 生成信息相同，代码生成器利用 WOM （ WSDL Object Model ）操作 WSDL 文件，传输信息到 Emitter ， Emitter 生成 XML ，然后 XML 由相应的 XSL 解析生成代码。除非用到的模版不同，不管编程如何，处理过程都是相同的。

数据绑定

集成代码生成引擎

Axis2 M2 支持代码生成，但不支持数据绑定， version0.9 有完整的方案来支持数据绑定，因为有数据绑定工具 Xml-bean ，所以这个方法是可行的，最初的代码生成框架没有明显的变化，数据绑定作为一个扩展插件加入到代码生成引擎中， version0.91 不支持 SOAP 解码，它仅支持 RPC 文本型消息。

序列化和发序列化

AXIOM 是基于 StAX （ Streaming API for XML ） API ， Xml-beans 支持 StAX 的数据绑定，通过 AXIOM 用 Xml-bean 来实现，在代码生成阶段，对于每个 WSDL 的操作都有些支持的类， WSDL 的操作中有很多有用的方法，可以从 AXIOM 反序列化到数据绑定对象，也可以从数据绑定对象序列化到 AXIOM 。比如在 WSDL 文件中有一个叫 echoString 的方法，一旦代码生成， echoStringDatabindingSupporter.java 类就会生成，其中包括类似于以下的代码，

public static org.apache.axis2.om.OMElementtoOM(org.soapinterop.xsd.EchoStringParamDocument param)// 这个方法处理序列化public static org.apache.xmlbeans.XmlObject fromOM(org.apache.axis2.om.OMElement param, java.lang.Class type) // 这个方法处理反序列化public static org.apache.xmlbeans.XmlObject getTestObject(java.lang.Class type)// 由给定的数据绑定类型创建样本对象