总结Axis2分析报告.ppt

系统设计 – Axis2的模块 部署模块 代码生成模块 信息处理模块 SOAP处理模块 XML处理模块 客户端API 传输组件 最新.课件 * 系统设计 - 管道过滤器模式 管道过滤器模式：Pipeline and Filters pattern，从名称上可以看出来，它形象得描述了一种消息处理的模式，即以一种类似管道和过滤器的处理方式逐步对数据进行处理。 管道：需要处理的数据。 过滤器：处理的执行。 最新.课件 * 系统设计 - 管道过滤器模式 前一个过滤器的输出是后一个过滤器的输入。 执行过程环环相扣，如果一个过滤器没有输出，后续过滤器就没有了输入，因此无法进行。 每一个执行点都可以有反馈机制，这样整个执行过程是可控制的。 例如一些脚本执行器就是采用类似管道过滤器模式，如下图： 最新.课件 * 系统设计 – 管道过滤器处理方式 为了满足需求分析中：分段、高效、支持扩展的处理方式。Axis2使用了管道过滤器模式的处理方式。 最外层管道 逻辑处理流：SOAP请求和回应 中层管道 引擎执行流：处理单元 底层管道 单元执行流：最基本原子执行单元 最新.课件 * 系统设计 – 第一层：逻辑处理流 Axis2会根据MEP（消息交换模式）的不同来决定最外层的逻辑处理流： 最新.课件 * 系统设计 – 第二层：引擎执行单元 Axis2的执行引擎是在第二层之上的，在第一层逻辑层之下，引擎处理层则把输入流和输出流的各个步骤具体刻画出来。 最新.课件 * 系统设计 – 第三层原子执行 到达第三层，执行的模块就不可再分了。Axis2会使用原子执行模块代表管道过滤器中的节点。 最新.课件 * 系统设计 – 多层管道过滤器的连接 多层管道过滤器采用类似面对对象编程中对象的继承和多态特性，一层管道过滤器看起来是线性的，但是一个过滤器类型的执行可能会诱发另一个子管道过滤器，这样这个过滤器的执行就是其包含的子管道过滤器先得执行。那么此时逻辑上这个管道过滤器执行就具有多层的意义了。如下图： 最新.课件 * Axis执行引擎概括 – 第一层 客户端 基于HTTP网络服务传输协议 Axis2执行引擎 服务端 SOAP请求 InFlow或者InFaultFlow 接受方 WebService执行 SOAP回应 OutFlow或者OutFaultFlow 最新.课件 * Axis2执行引擎 – 第二层，第三层 下图中的Phase代表第二层单元，Handler代表第三层概念。具体代码实现在后面会详解。 最新.课件 * 第三部分：系统实现分析 最新.课件 * Axis2最底层管道过滤器 - Handler和Context 刚才讲过，Axis2中的最底层管道过滤器执行是原子的，不可再分的，因此管道过滤器直接对应Handler和MessageContext对象： 最新.课件 * Axis2最底层管道过滤器 - Handler和Context Handler是一个接口。命名空间：org.apache.axis2.engine Handler是没有状态存储的：Stateless。因此可以理解成是一种静态的支持并发操作的对象，当然实际上它还是非静态的。 管道过滤器的具体执行类型都是可扩展的：Handler和MessageContext都是可扩展类型，仅定义必要执行和操作接口。 整个过程是可控制的： 通过InvocationResponse类型。 最新.课件 * Handler类型 Handler类型定义如下常用方法： 名称 作用 getName 返回名称 getParameter 根据参数名称返回参数类型（Parameter类型） invoke 参数MessageContext，返回值InvocationResponse。调用Handler 的执行 flowComplete 参数MessageContext，类似事件。当Handler执行完毕后，Axis2引擎会调用Handler的flowComplete函数。 最新.课件 * Handler类型 ?Handler定义一个Nested Class：InvocationResponse，后者定义三个静态字段：CONTINUE、SUSPEND、ABORT 控制当一个过滤器完成后，是否继续或者暂停还是停止后续的操作。 最新.课件 * AbstractContext类型 介绍完管道过滤器中的过滤器类型：Handler，我们来看管道对应的类型：AbstractContext。 Axis2的AbstractContext类型在命名空间：org.apache.axis2.context内。 该类型是用来存储任何过滤器操作中的抽象数据类型核心定义 最新.课件 * AbstractContext类型 类型定义如下字段（全部是派生类