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

异步操作和Web服务，第2部分：构建异步Web服务的编程模式2010-07-22 IBM Holt Adams在本系列的第一篇文章中，我讨论了异步操作的性质以及它们如何应用于 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. 单向和通知操作