异步操作和 Web 服务，第 2 部分：构建异步 Web 服务的编程模式

核心提示：在本系列的第一篇文章中，我讨论了异步操作的性质以及它们如何应用于 Web 服务，异步操作和 Web 服务，第 2 部分：构建异步 Web 服务的编程模式，在某些情况下，对 Web 服务请求的响应并不是立即提供的，Web 服务标准的未来版本可能会简化对异步操作的支持，但使用本文中概述的这几个模式，而是在初始请求事务完成后

在本系列的第一篇文章中，我讨论了异步操作的性质以及它们如何应用于 Web 服务。在某些情况下，对 Web 服务请求的响应并不是立即提供的，而是在初始请求事务完成后的某个时候提供。Web 服务规范和标准并不显式支持这种 异步操作（asynchronous operation）；但是，那些标准的确包含可以作为异步操作基础的基础架构和机制。通过本系列的第一部分，您应该已经知道了如何使用现有的基础架构来支持异步行为；如果您还没有看过那篇文章，我强烈建议您去看看，因为那里的信息将帮助您理解现在的这一部分。

在这篇文章中，我将讨论异步 Web 服务的几个设计模式。这些模式将帮助客户机和服务提供者应用程序的开发者将他们的代码设计为支持异步行为，同时考虑到代码的复杂性、给定传输的使用以及显式确认的需要。您或许还有兴趣看看另一个支持 Web 服务中异步行为的包。

Web 服务异步模式和基本传输类型

就象 Web 服务描述语言（Services Description Language，WSDL）规范版本 1.1 中定义的那样，这里讨论的支持异步 Web 服务操作的四个模式以端点可以支持的四种基本传输类型为基础：

单向（One-way）：端点接收一条消息。

请求／响应（Request/response）：端点接收一条消息并发送一条对应的消息。

征求／响应（Solicit/response）：端点发送一条消息并接收一条对应的消息。

通知（Notification）：端点发送一条消息。

IBM 的 Web 服务调用框架和异步操作

Web 服务调用框架（Web Service Invocation Framework，WSIF）向用来使用本地代理（例如，一个存根）异步调用 Web 服务的客户机 API 提供了根据调用上下文使用不同传输的能力。本文中讨论的许多模式都可以由 WSIF 组件支持，这样允许真正支持异步 Web 服务操作。

我们应该注意，本文中讨论的基本传输类型的数目与模式的数目之间是完全无关的。

每一个模式都要引入一个在客户机和服务提供者之间交换的 相关器（correlator），用于把响应与请求关联起来。相关器可以由参与交换的任一端提供，它的创建者可以根据底层传输来确定。例如，在使用 HTTPR 和 JMS 时，消息源提供相关器：一个事务标识或者 JMSMessageID 与 JMSCorrelationID 的一个组合。

对于单方向操作，如果您正使用 HTTP 或者 HTTPS，并且服务调用的接收需要由客户机确认，那么客户机的 HTTP 协议处理程序在等待 HTTP 响应（例如，一个 200 状态码）时应该阻塞调用以确保请求已被服务提供者的 HTTP 侦听器成功地接收。对于客户机使用服务代理的情况，任何与请求有关的错误状态都应该会导致异常被抛出。为服务代理的接口建模使其模型与服务提供者定义的 WSDL 操作相匹配很重要。例如，如果一个客户机调用一个单向操作，代理将永远不会向客户机返回一个参数（例如，一个状态码）。这种交换将有效地使操作成为一个请求／答复操作，并且答复信息不是来自服务提供者。

人们期望 W3C 的 WSDL 工作组能够通过提供在 WSDL 内正式定义回调机制（例如，回复地址）的能力扩展语言的异步操作支持。同时，上面列出的四种基本类型可以用于支持异步操作。但是，目前可用来使客户机端服务代理生成过程自动化的 IDE 和其它 Web 服务工具一般只支持请求／响应模型。

模式 1：单向和通知操作

在这个模式中，请求和响应是单独的 WSDL 操作内定义的两条消息。请求被建模为一个入站单向操作，响应被建模为一个出站通知操作。每条消息都被作为单独的传输层传送发送。

这个模式（参见 图 1）提供了客户机和服务提供者之间的高级分离，因为它支持使用两个数据报在双方之间进行交换，一个用于请求，一个用于响应。

图 1. 单向和通知操作

对于这个模式，客户机负责创建相关性标识（correlation ID）并通过双方已同意的任一种机制将其发送给服务提供者。SOAP 报头、HTTP 报头和 JMSCorrelationID 都将是可接受的机制。

定义答复地址 ― 它指出响应应该发送到何处 ― 也是客户机的职责，而向服务提供者通知这个地址的方法取决于 WSDL 是如何为操作定义的。如果客户机发布了一个支持单向操作的通知侦听器服务，它的 WSDL 将包含该服务的端口地址。同样，服务提供者将需要访问客户机的服务的 WSDL 来确定将响应发送到何处。通过在初始请求上传递 WSDL 的引用可以在提供者的 Web 服务被部署时或运行时提供对通知侦听器服务的 WSDL 的访问权。作为替代方法，也可以把指出响应将发送到何处的特定地址（例如 URI）作为请求的参数显式提供。

这种模型也适用于发布和订阅（pub/sub）及事件通知类型的服务。市场指数更新应用程序将是 pub/sub 服务的一个不错的示例；事件通知服务的示例包括这样的应用程序 ― 该程序向有兴趣的各方通知业务流程任务已经完成或者任务中的异常、一个长期运行的报表已完成或达到了某些库存阈值。把答复地址信息作为请求（例如，订阅一个主题或事件的请求）的参数来提供将使得服务提供者可以用极少的管理支持来支持大量的订户。

对于这个模式（在该模式中使用单独的传输层传送发送消息而不需要在客户机和服务提供者之间交换的应用层确认），如果消息流支持的业务流程非常重要，所使用的传输应该是被认为可靠的。

模式 2：请求／答复操作

在这个模式中，请求和响应是单个请求／答复操作内定义的两条消息，并作为两个独立无关的传输层传送发送。

这个模式（参见 图 2）也可以提供客户机和服务提供者之间的高级分离，因为它支持为请求和响应使用两个数据报在双方之间进行交换。但是，要使用这个模式，服务供提供者在运行时处理信息时肯定会更复杂一点。例如，服务提供者将需要能够把它要发送响应的目标地址（例如答复地址）作为输入参数处理。

图 2. 请求／答复操作

对于这个模式，客户机负责创建相关性标识并通过双方已同意的任一种机制将其发送给服务提供者。与前面一样，SOAP 报头、HTTP 报头和 JMSCorrelationID 都是可接受的机制。

定义指出响应应该发送到何处的答复地址也是客户机的职责。由于对这个模式使用单操作，对地址或显式地址自身的引用 必须作为请求的参数提供。例如，如果客户机发布了一个支持单向操作的异步响应侦听器服务，那么在初始请求上就可以提供对服务的 WSDL 的引用。

这个模式也适用于其请求只产生一个响应的通用服务；这种服务的示例包括数据的持久保存或检索，或者由单个工作单元组成的业务流程（比如一次电子付款）的启动。模式 2 与模式 1 相似，在这种模式中，使用单独的传输层传送发送消息而不需要在客户机和服务提供者之间交换的应用层确认。因此，如果消息流支持的业务流程非常重要，用于这个模式的传输也应该是被认为可靠的。

模式 3：使用轮询的请求／答复操作

在这个模式中，使用两个单独的 WSDL 操作内定义的四条消息处理请求和响应。初始请求被建模为请求／答复操作，有两条消息（一个传送和一个答复）被作为单个传输层交换发送。响应由第二个请求检索，它也被建模为请求／答复操作，同时有两条消息被作为单个传输层交换发送。这两个操作应该被作为同步流实现，同时，从服务提供者为每个请求返回的信息为客户机提供每个请求的一定级别的确认。

这个模式（参见 图 3）使得客户机端实现在支持基于自助的解决方案时更简单，在这种模式中，客户机应用程序启动所有的交互，同时还提供客户机和服务提供者之间一定级别的分离。但是，假设请求／答复操作是同步的，那么答复消息流将使用本机传输答复机制（例如，HTTP 响应（HTTP Response）操作）。

图 3. 使用轮询的请求／答复操作

在 图 3的示例中，服务提供者生成相关性标识，客户机负责使用它检索响应；但理论上参与交换的任一方都可以创建相关性标识。

由于不需要通知机制和侦听器组件，这个模式使得客户机实现更为简单。但是，客户机必须实现一个工具，使用这个工具，它可以周期性地轮询来自服务提供者的响应。这个模式的效率可能不是最高的（因为如果初始服务请求尚未完成的话，每个响应可能需要多个请求来检索响应），但它使得实现更为简单。因而，这个模式适合优先考虑简单性和服务的期望负载比较低的情况。某些服务类型可以从轮询中受益，它们的示例包括一个长期运行的业务流程的开始、生成复杂报表的请求以及基于浏览器的、面向客户的解决方案所使用的服务。

模式 4：使用公布的请求／答复操作

在这个模式中，使用两个单独的 WSDL 操作内定义的四条消息处理请求和响应。初始请求被建模为请求／答复操作，同时有两条消息被作为单个传输层交换发送。响应被建模为征求／答复操作，同时有两条消息被作为单个传输层交换发送。这两个操作应该被作为同步流实现，同时，从消费方为每个请求返回的信息为请求方提供每个请求的一定级别的确认。

这个模式（参见 图 4）与模式 1 相似，当使用同步传输时以及客户机和服务提供者要求一个应用层确认时这个模式对 pub/sub 或事件通知服务很有用。由于这种相似性，模式 1 下给出的示例情况也可由模式 4 来解决；其它要求显式确认的服务类型的示例包括用来交换医疗业或金融业的对业务至关重要的信息或机密信息 ― 例如，资金转移或者保险索赔的提出 ― 的服务。

图 4. 使用公布的请求／答复操作

WebSphere 和异步 Web 服务模式

IBM 的 WebSphere Application Server 版本 4 和 WebSphere Studio Application Developer 目前完全支持模式 3。但如果两个操作都是请求／答复模式，它们也支持模式 4，由服务提供者执行服务请求者的角色向客户机发送响应。对于这种情况，服务提供者的 WSDL 将不具有任何对响应操作（ 图 4中的操作 B）的任何引用，因为这将由客户机的 WSDL 来定义。

如果为处理响应把客户机和服务提供者的角色反过来，也可以为客户机把发送响应的 WSDL 操作定义为请求／答复操作。角色互换只是为了方便；这样做便于模式的开发，因为目前的工具不支持征求／答复操作。在双方之间流动的消息不被更改；只是本文用来描述客户机的和服务提供者的角度的模型会有不同。

结束语

对异步 Web 服务操作的支持既可以用同步传输协议，也可以用异步传输协议来实现。异步传输的使用（这时内在提供请求和响应消息的关联性并提供独立查询状态和检索响应消息的机制）使得支持客户机端和服务提供者端的异步操作更加容易，因为面向消息的中间件为 Web 服务请求和响应的传输提供可靠的消息传递。同样，同步传输也可以支持异步操作的更简单的实现，特别是在客户机应用程序更倾向于自助风格时。

下表概述了本文中讨论的四个模式，并为解决方案供应商提供了注解和注意事项。

异步模式	适用的传输	用法示例	注解和注意事项
1. 单向和通知操作	HTTPR、JMS、MQSeries 消息传递（MQSeries Messaging）、HTTP、HTTPS、RMI/IIOP、SMTP	Pub/sub；事件通知	异步传输内在支持。当不需要保证请求或响应的传递时，可以使用同步操作。
2. 请求／答复操作	HTTPR、JMS、MQSeries 消息传递（MQSeries Messaging）、HTTP、HTTPS、RMI/IIOP、SMTP	带一个响应的一般服务；事务性服务	异步传输内在支持。当不需要保证请求或响应的传递时，可以使用同步操作。
3. 使用轮询的请求／答复操作	HTTP、HTTPS * 、RMI/IIOP **	自助	最简单的客户机端实现。同步传输很容易支持应用层确认（例如，通过 HTTP 响应）。
4. 使用公布的请求／答复操作	HTTP、HTTPS * 、RMI/IIOP **	Pub/sub；事件通知	比较简单的客户机端实现。与模式 1 相似，但带有与同步传输一起使用的显式应用层确认。

^* ：被当前的 Web 服务工具支持。
^** ：虽然您也可以为这些模式使用异步传输，但这样做是不切实际的，因为异步传输提供使模式 1 和模式 2 更易于实现的机制。

就象本系列的第 1 部分声明的那样，Web 服务标准的未来版本可能会简化对异步操作的支持。但使用本文中概述的这几个模式，您应该可以开始构建实现目前各种用途的异步 Web 模式。