简介： 并不是所有的 Web 服务都同步工作；某些情况下，对 Web 服务请求的响应并不是立即提供的，而是在最初的请求事务完成后的某个时候提供。Web 服务规范和标准并不显式支持这种 异步操作 ；但是，那些标准的确包含可以作为异步操作基础的基础架构和机制。在本文中，Holt Adams 说明了为什么任何 Web 服务设计师都需要理解异步操作是如何运行的。本文将帮助您开始使自己的服务适应异步环境。
Web 服务调用本质上是异步的，因为服务提供者必须能够接收来自客户机的请求而无需通知。但是，有时 Web服务请求的响应在调用的同一个执行线程上可用；这种操作通常被称为同步操作。这篇对异步操作的讨论将不会集中在客户机对请求消息的启动或服务提供者对请求消息的处理上；而是将集中在如何处理对 Web 服务请求的响应上，这种响应不是立即提供，而是在最初的请求事务完成后才提供。这种 异步行为 对于要求可能花费几分钟或者甚至几天的时间才能完成的复杂处理的服务来说很常见 ― 例如，当 Web 服务实现依赖于批处理或者需要人工介入的手工步骤时。
在本文中，我将讨论异步 Web 服务的理论基础。您将了解到异步事务是由什么构成的，以及什么样的传输可以传送这种事务。我还将探究开发者在把异步操作支持构建到他们的 Web 服务中时所面临的特定问题。
Web服务客户机的设计者需要决定如何处理异步响应以及如何确保他或她的实现与服务提供者支持异步操作的方法一致。客户机的一个选择是发送一个请求然后在等待响应时阻塞它的执行线程，但出于一些很明显的原因，这并不是一个好的供选方法；它会导致资源利用效率低下，还会引起事务性和伸缩性问题及其它问题。首选的解决方案是把异步行为构建到客户机内。客户机发送一个请求作为一个事务的一部分并接着使用执行线程。然后由另一个线程在一个单独的事务内处理响应消息。在这个模型中，客户机作为一个服务请求者要求一个通知机制和一个已注册的侦听器组件来接收响应。同样，必须有一个在客户机和服务提供者之间交换的 相关器（correlator） （一个相关性或事务标识）将响应与它们的请求关联起来。
一个典型的异步案例将包括下列内容：
可以把交换的消息看做这样的数据报，为了使事务被处理，该数据报不需要或不期望任何答复。通过使用这种数据报，考虑到双方之间的真正异步关系，完全可以把消息的发送方（或称始发方）与接收方分开。
为支持异步操作，必须解决许多响应同步时不存在的问题。异步实现需要解决的问题包括：
可以用于 Web 服务通信的传输促进异步操作支持的能力是不同的。因此，不仅仅 Web 服务行为可以描述为异步或同步；用于交换 Web服务消息的传输也可以归为两类。其接口本身就支持响应消息与请求消息的相关性以便应用程序使用，并支持“推”（push）和“拉”（pull）类型消息交换的传输通常被称为异步传输。同步传输不提供这些手段，当用于异步操作时，它们要求应用程序（为方便讨论，假设是客户机和服务提供者）管理所交换消息的相关性，方法是不仅定义将如何在每条消息内传送相关器，还把响应与请求匹配起来。可以用于支持异步操作的传输的示例包括：
在下面的参考资料部分，您可以找到更多关于这许多传输的信息。
不管正用于异步操作的传输，客户机（或者客户机所用的服务代理）和服务提供者负责生成一个相关器，传输在管理请求和响应时可以使用这个相关器。
通常情况下，当商业伙伴利用 Web 服务集成他们的业务流程时，他们更倾向于使用 HTTP、HTTPS 和 HTTPR作为传输进行跨因特网通信；在企业内，当存在相似的应用程序平台时，将使用本机传输和接口，比如 JMS、RMI/IIOP 和 JCA（Java连接体系架构，Java Connection Architecture）。
异步传输使客户机能够在请求一个服务调用后立即继续在自己的执行线程上处理；它们还提供一些机制使客户机能够确定它的 Web 服务请求的状态并能够检索对那些请求的响应。
不提供在另一个执行线程上初始化响应传输能力的 Web 服务的实现将无法用于异步操作。这种实现的示例将是那些在前端数据库应用程序中使用的 EJB 或者通过使用本地接口（比如 JCA）提供对企业系统的访问的实现。
随着业界进一步开发确定如何协调 Web 服务之间的流程以及如何描述实现业务流程的 Web服务间的依赖性的规范，对异步操作的支持将被简化。但目前的 Web服务规范和标准并不直接描述异步操作支持，尽管它们的确包含可以作为异步操作基础的基础架构和机制。现在，您应该知道如何开始把异步操作支持构建到目前的Web 服务中。
在本系列的第二部分，我将讨论一些异步 Web 服务模式。这些模式将作为您构建高级异步 Web 模式的基础。您可以通过掌握这里概述的概念为第二部分做好准备。
联系客服
