Axis2 体系结构

前言

结构都是它本身所能产生效率的结果。任何一个成功结构都是基于它期望的需求。我们通过期望用 Axis2 做什么来开始我们的 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 ，可以用同步或者异步的编程方式。

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

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

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

体系结构

在说明体系结构前，需要说明：

Axis2 的体系结构分离了逻辑和状态，在其内部逻辑处理都是无状态的，这样就允许在几个平行的进程间处理同样的代码。

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

Axis2 是模块化的结构， Axis2 框架是构建在核心模块上，其他的模块则构建在核心模块上。核心模块包括：

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

XML 处理模型，处理 SOAP 消息是最重要和复杂的任务，它的效率是影响性能的主要因素，我们通过 AXIOM 来有效的处理 SOAP 消息和 XML 文件。

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

客户端的 API ，它为用户提供了方便的 API 来处理 Web Service 。可以用来和 IN-OUT 和 IN-only 方式的消息交换模型。

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

非核心模块：

代码生成， Axis2 提供了代码生成器，可以生成服务器端和客户端的测试代码。生成的代码也就简化了服务的部署和服务的调用，

数据绑定， Axi2 的基本的客户 API 允许用户在信息集合上处理 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() 两个方法来实现 Pipes 。两个管道为 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 中处理一消息后就会创建另一消息，在新的消息中，更复杂的模型可能出现。

两种类型 Pipe 和服务器 / 客户端模型类似， SOAP 处理模型简化了复杂性，为用户提供了抽象的接口。 Pipe 的不同阶段 phases 都已命名。处理器通常运行在一个阶段中，阶段提供了一种预定处理器的机制。两种 Pipe 都内建了 phases ，也都为用户提供了 User Phases ，可以由用户自定义。

下图中可以看到 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 ）就会创建，然后通过消息上下文 In-Pipe 就会被执行。

让我们看下在执行过程中每个阶段都发生了什么，处理过程在服务端和客户端都会发生，这里说明一个特殊的双向传输，在 In-Pipe 开始的四个阶段可能不会发生。

传输阶段，在这个阶段处理器从传输配置中抽出，根据规则执行。

预分发阶段，由于服务还未存在，处理器会在全局使用。

分发阶段，如果服务还为发行，分发器就会在此阶段查找服务。

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

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

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

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

发送消息的处理过程

Out-Pipe 是相对简单，因为此时服务都已被所知， Out-Pipe 由消息接收器或客户 API 实现。

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

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

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

扩展消息处理模型

以上我们讨论了 Axis2 默认处理模型，现在我们讨论下 SOAP 消息处理的扩展机制，很多 SOAP 引擎研究也集中在其扩展性。

根据处理器和阶段使在 SOAP 处理中更容易的修改处理过程，阶段概念使在处理器之间加入新的处理器，也就更容易扩展默认的处理过程。

用处理器扩展 SOAP 处理模型

通过阶段规则（ Phase rule ）将处理器放在不同位置定制阶段来扩展 SOAP 处理模型。

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

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

在一个给定处理器之前

在一个给定处理器之后

通过模块扩展 SOAP 处理模型

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

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

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

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

部署

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

Axis2.xml 文件

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

全局参数

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

用户定义的阶段名

全局被用到的模块

全局的消息接收器

服务包（ Service Archive ）

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

服务级的参数

服务级的模块

服务中特定消息接收器

服务内部的操作

模块包（ 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)

// 由给定的数据绑定类型创建样本对象