前言
结构都是它本身所能产生效率的结果。任何一个成功结构都是基于它期望的需求。我们通过期望用
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)
//
由给定的数据绑定类型创建样本对象
|
posted on 2006-12-22 17:42
SIMONE 阅读(3175)
评论(0) 编辑 收藏 所属分类:
AXIS 、
JAVA 、
JSP