使用Axis2来构建Web Service客户端

本文翻译自Apache Axis2 User Guide，介绍Axis2提供的四种调用模式。<o:p></o:p>

author: ZJ <st1:chsdate w:st="on" year="2007" month="3" day="13" islunardate="False" isrocdate="False">07-3-13</st1:chsdate>

Blog: http://zhangjunhd.blog.51cto.com/

<o:p> </o:p>

Web services可以用来为用户提供广泛的功能，从简单的，少时间消耗的功能到多时间消耗的业务服务。当我们使用（调用客户端的应用程序）这些Web Service时，我们不能用简单的调用机制来针对那些对时间消耗有很大要求的服务操作。例如，如果我们使用一个简单的传输通道（如HTTP）并使用IN-OUT模式来调用一个需要很长时间来完成的Web Service，那么多数情况下，我们得到的结果将是"connection time outs"。另一方面，如果我们从一个简单的客户端应用程序调用一个同步的服务，使用"blocking"的客户端API将会降低客户端应用程序的性能。现在来分析一下一些常用的服务调用形式。

许多Web Service引擎提供给客户Blocking和Non-Blocking的客户端APIs。

1）Blocking API-一旦服务被启用，客户端的应用程序将被挂起，直到operation被执行完毕（表现为收到一个response或fault），才能重新获得控制权。这是调用Web Service最简单的方式，并且这种方式适用于多数业务情形。

<o:p> </o:p>

2）Non-Blocking API-这是一个回叫或轮询机制的API。因此，一旦服务被起用，客户端应用程序马上得到控制权，通过使用一个callback对象来获得response。这种方式使得客户端应用程序可以很方便的同步启用多个Web Service。

这两种机制都是工作在API层面上的。称将通过使用Non-Blocking API而产生的异步行为方式为API Level 异步。

这两种机制都使用单一的传输连接来发送request和接收response。它们的性能远远落后于使用两个传输连接来发送request和接收response（不管是单工还是双工）。所以这两种机制都不能解决需要长时间处理的事务的传输问题（在operation处理完成之前，很有可能你的连接已经超时了）。一种可能的解决方法是使用两个独立的传输连接来发送和接收request&response。这种异步行为，我们称为Transport Level 异步。

通过组合API Level异步和Transport Level 异步，我们可以得到四种调用模式。如下所示。

API (Blocking/Non-Blocking)	Dual Transports (Yes/No)	Description
Blocking	No	最简单和常用的调用模式
Non-Blocking	No	使用回叫或轮询机制
Blocking	Yes	在单工模式下，service operation为IN-OUT时，很有用。（如SMTP）
Non-Blocking	Yes	此模式下的异步效果最大

Axis2提供了所有上述4种调用Web Service的实现方式。<o:p> </o:p>

出自 51CTO.COM博客