到目前为止，web service交互作用是独立同步的，同时本质上是应答式的。不过，很显然同步应答类型在基于消息的应用中只是一个很小的子集。消息在耦合松散系统中是非常重要的，因此这种限制很关键。Web service规范，例如WS-addressing和WSDL，已经融入了消息的概念并且为包含一个相当大范围的消息应用奠定了基础。Apache Axis2 架构既不基于任一个消息交换模式，也不基于同步/异步行为。这篇文章解释了消息概念和Axis2在几种众所周知的消息场合中怎样被扩展使用。
消息的简单介绍
贯穿计算历史，分布式运算是其中的一个很大的挑战：当资源是分布式时，进程间的通信变得相当困难，研究人员仍然在寻找更好的解决方案。有趣的是，几乎所有关于分布式计算机计算能力问题的解决方案来源于两种概念基础： 远程过程调用(RPC) 和消息传递。
毫无疑问，使用RPC在开发人员中是非常流行的技术，部分原因是是本地过程调用与它的类似之处。本地过程调用在程序员中很有人气，所以在分布式系统中使用RPC是很自然的选择，而另一方面，消息传递不是非常流行，当它被提起时很少有开发人员关注它。不过，在某些场合使用消息相比RPC系统有更好的优势。
RPC和消息框架的基本差异如下所示：
●消息完全不懂客户端和服务器，因为一个消息框架（通常所说的面向消息的中间件，或message-oriented middleware，即MOM）集中于传递消息，所有接收和散发消息的节点身份平等，术语称之为对等体。RPC始终有服务请求者 (AKA client) 和服务提供者 (AKA server)的概念。
●消息对于一个特定范畴是时间独立的。没有任何对等体希望实时接收消息－－当对等体可用时MOM关注于传递一个消息到相应的对等体，然而，RPC在失去一方时立即失效。
●消息可被复制并且轻易的传递到众多对待体。RPC本质上是一种一对一的交流方式，而消息更灵活，并且毫不费力地传递同一消息的拷贝到多种对等体。
Web service消息
Web service是在XML消息的基础上定义的，下面3个因素描述了一个给定的Web service的消息交互。
●消息交换模式
●同步和异步客户端API
●单向和双向传送行为
从最抽象的角度来讲，，web service消息传递建立在发送和接收消息基础上，一个给定的消息被一方发出，并且被另一方接收。消息可能相互关联，识别这些相互关联的消息群中的最常见的应用场合是非常重要的，这些消息群被定义为消息交换模式(message exchange patterns)，简称MEPs.
过渡时期下在两种相关消息间的一个服务请求者的行为在客户端API定义了消息同步/异步行为。同步场合下，客户端请求将会阻塞，在相关消息到达目的地后前一直等待，在非阻塞场合下，客户端请求不会阻塞，当相关消息到达时，它与之前的消息相互联系。
传送分类为单向或双向，基于单方或双方行为。类似SMTP和JMS传送即是单向传送的，不会阻塞，另一方面，类似HTTP和TCP即是双向传送，相关消息可能在回路中返回，实际上，在Web service消息中，双向传送可能被用作单向传送，但是在这些场合下，它们可被有效的处理为单向方式。
消息交换模式
根据W3C建议，消息交互模式就是一个为交流双方构建消息交换的一个模板，一个MEP将相关消息确定为一组。MEPs根据服务请求者和服务提供者来定义，需要注意，为了清晰，MEPs以服务提供者的消息特性来命名。为方便理解，所有的命名都可以用request代替in, 用response代替out。
例如，我们看看两个有名的MEPS
1.In-only/"发后不理:" 服务请求者发送消息给服务提供者但是不关心任何后继相关消息
2.In-out/"应答式:" 服务请求者发送消息给服务提供者并希望返回结果
MEPS概念仍在扩展中，模式的数目是没有限制的，所以Web service中间件应用强制使用几种选定的MEPs，"发后不理"和 "应答式" 是被明确使用的，其它大多数的模式可由这两种组合使用。
客户端API同步/异步行为
同步/异步（或阻塞/非阻塞）行为是基于在web service请求的线程，同步服务将会阻塞，等待相关消息到达。另一方面，异步请求仅仅返回，等待相关消息被后台另一个不同线程执行。
这两种途径有典型的用例。考虑一下银行事务，其需要一定数量的消息来来回传递。银行事务本质是连续的，当结果到达时后执行下一步骤，因此同步等待结果很有意义。另一方面，设想一个航班预约程序，其需要搜集多种数据来源，根据这些结果再匹配。这个案例中，异步行为发挥作用，因为程序可以提交所有结果并且当数据到达时工作。考虑到网络响应，异步方式获得较好的结果。
同步请求很简单：请求在相关消息到达前等待，并且可以像本地过程调用一样被编码。但是异步消息的相互关系就比较复杂，客户端必须处理这种复杂性。尽管如此，通过一些额外工作来处理这种复杂情况仍是必要的。
传输层的行为
传输层的行为是个关键因素，决定了Web service消息的发生，传输根据依据其行为分类为单向和双向。
单向传送减少web service消息的复杂性，因为相关消息必须来源于各自的通道。另一方面，如果传送是双向的，消息有机会选择使用单向还是双向，例如，传输是HTTP时，相关消息来自HTTP连接的返回路径，或者这么讲web service提供者可以写HTTP 200来指出没有来自同一连接的响应，在这种案例下回应经由独立的HTTP连接发送。
Web service寻址角色
webs ervice寻址框架（也被称为WS-addressing）是为了在同一web service交互活动中交换不同信息部分，下面的5个因素定义了交互活动：
1.消息交换模式
2.可被访问的服务传送
3.相关消息传送
4.传送的行为
5.客户端API的同步/异步行为
服务提供者申明了头两个，客户端定义了其余因素，客户端级别的同步/异步行为对服务提供者是完全透明的，客户端使用WS-addressing来解释web service消息。
在其它大多数结构中，WS-addressing定义了四种标题：To, ReplyTo, RelatesTo, FaultTo以及一个被称为匿名地址的特定地址，当一个服务提供者接收到SOAP消息时，它会查找在to地址上的目标服务并且调用服务。如果有结果，即被发送到ReplyTo地址，错误被发送到FaultTo地址，如果以上任一个的标题没有指定或具有匿名值，结果通过双向传送返回路径返回（因为匿名决定双向传送返回路径）。
传送和WS-addressing一起定义了查找相关消息的机制，消息是相关缘于它们共享了相同的传送通道，也可能因为它们都共享把它们互相链接的公共信息。web service RelateTo标题正好提供了这种关系。
下面的表显示的明确定义的消息交互活动的寻址标题的不同值
Axis2客户端API概念
Axis2客户端API处理了In-Only和In-OutMEPs，所有的消息结合在下面的章节讨论。MEPs的空间是无限的，因此，Axis2强制提供了支持任意消息交换模式的核心，并且提供了两种常被使用的模式In-Only和In-Out的API，有两种方法实现更多的复杂模式：组合In-Only和In-Out来完成希望的模式，或者对希望的模式写新的扩展。因为Axis2为任意MEP提供核心级别的支持，实现是显而易见的。In-Only和In-OutMEPS被InOnlyMEPClient和InOutMEPClient类支持，下两节即做具体描述。
In-Only MEP 支持: InOnlyMEPClient
InOnlyMEPClient类对发送不理消息提供了支持，所有的传送类型作为单向传送对待，InOnlyMEPClient和InOutMEPClient真正的差别是寻址参数起先没有锁定，并且寻址参数随后被Axis2控制。作为可被控制的寻址参数，InOnlyMEPClient可被用作消息API，并且在此基础上构建更复杂的消息交互。
In-Out MEP 支持: InOutMEPClient
InOutMEPClient和继承了InOutMEPClient的调用类为应答式消息提供了支持，Axis2关注完整的操作，除了To地址外的所有的寻址属性都在Axis2的控制下
用户可以配置InOutMEPClient 来表现不同，利用以下的四个参数。
1.发送者传输
2.监听者传输
3.是用单独监听
4.使用阻塞
客户端API当前提供了针对HTTP和SMTP传输的支持，下面的表格显示了这些参数可能的组合以及它们怎样结合来提供不同特效。
举例
下面的代码实例显示了怎样使用Apache Axis2做几个定义明确的交互作用,用户可以在客户端API简单的转换属性从而转换不同的交互作用，客户端Axis2 API仅仅支持XML级别的消息和代表大块XML的OME元素。
调用单向消息
单向MEP简单之处在于在仅有一个消息来回传送时它能表现正确的单向，这些消息被异步对待并且传送是单向的。
应答式消息
可以表现四种方式的应答式消息
1.双向In-Out 同步
2.双向In-Out 异步
3.单向In-Out 同步
4.单向In-Out 异步
下面的代码实例说明这些案例怎样被Axis2寻址，注意客户端API的四种属性怎样被使用。
1.In-Out同步，HTTP作为双向传输方式
OMElement payload = .... Call call = new Call();call.setTo(
new EndpointReference(AddressingConstants.WSA_TO,
"HTTP://...));call.setTranspo
