异步操作和 Web 服务，第 1 部分: 异步事务入门

核心提示：并不是所有的 Web 服务都同步工作；某些情况下，对 Web 服务请求的响应并不是立即提供的，异步操作和 Web 服务，第 1 部分: 异步事务入门，而是在最初的请求事务完成后的某个时候提供，Web 服务规范和标准并不显式支持这种 异步操作；但是，客户机作为一个服务请求者要求一个通知机制和一个已注册的侦听器组件来接收响

并不是所有的 Web 服务都同步工作；某些情况下，对 Web 服务请求的响应并不是立即提供的，而是在最初的请求事务完成后的某个时候提供。Web 服务规范和标准并不显式支持这种 异步操作；但是，那些标准的确包含可以作为异步操作基础的基础架构和机制。在本文中，Holt Adams 说明了为什么任何 Web 服务设计师都需要理解异步操作是如何运行的。本文将帮助您开始使自己的服务适应异步环境。

Web 服务调用本质上是异步的，因为服务提供者必须能够接收来自客户机的请求而无需通知。但是，有时 Web 服务请求的响应在调用的同一个执行线程上可用；这种操作通常被称为同步操作。这篇对异步操作的讨论将不会集中在客户机对请求消息的启动或服务提供者对请求消息的处理上；而是将集中在如何处理对 Web 服务请求的响应上，这种响应不是立即提供，而是在最初的请求事务完成后才提供。这种 异步行为对于要求可能花费几分钟或者甚至几天的时间才能完成的复杂处理的服务来说很常见 ― 例如，当 Web 服务实现依赖于批处理或者需要人工介入的手工步骤时。

在本文中，我将讨论异步 Web 服务的理论基础。您将了解到异步事务是由什么构成的，以及什么样的传输可以传送这种事务。我还将探究开发者在把异步操作支持构建到他们的 Web 服务中时所面临的特定问题。

Web 服务客户机的设计者需要决定如何处理异步响应以及如何确保他或她的实现与服务提供者支持异步操作的方法一致。客户机的一个选择是发送一个请求然后在等待响应时阻塞它的执行线程，但出于一些很明显的原因，这并不是一个好的供选方法；它会导致资源利用效率低下，还会引起事务性和伸缩性问题及其它问题。首选的解决方案是把异步行为构建到客户机内。客户机发送一个请求作为一个事务的一部分并接着使用执行线程。然后由另一个线程在一个单独的事务内处理响应消息。在这个模型中，客户机作为一个服务请求者要求一个通知机制和一个已注册的侦听器组件来接收响应。同样，必须有一个在客户机和服务提供者之间交换的 相关器（correlator）（一个相关性或事务标识）将响应与它们的请求关联起来。