Axis2体系结构中文手册

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)

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