虽然面向服务的体系结构（Service-Oriented Architecture，SOA）——特别是 Web 服务——通常旨在支持广泛的消息交换模式，但是当今的现实是大多数生产实现都基于请求-响应和单向模式。诸如“信用卡授权”、“税款计算”、“获取项目”、“查找图书”、“检查股票”等简单的短时间请求-响应服务占据支配地位。
出现这种情况的原因有几个。当然，其中之一是 Web 服务通常是使用不可靠的无状态传输协议（明确地说是 HTTP）来实现的。但更重要的是，一些希望通过 Web 来执行复杂业务事务的公司对此问题采取了一种太“技术相关”的观点，并预期 Web 服务技术和相关供应商产品完全支持这样的工作。
诸如 OASIS 等标准机构和诸如 IBM®、Microsoft®、Oracle、BEA 和等领先的 SOA 供应商认识到了处理所谓的“对话”消息交换模式的需要，该模式与 Web 服务实现中的实际业务事务（或操作系列，它们定义诸如按次序处理或保险报价处理等内聚的多步骤交互）等效。后来，出现了多个 Web 服务规范，例如 WS-Addressing、WS-Resources 和 WS-Coordination 以及 WS-Transaction。而且最重要的是，业务流程执行语言（Business Process Execution Language，BPEL）1.0 规范已经整合了新的“WS-”标准建议的许多用于处理复杂业务事务的功能。然而，和许多与安全相关的 Web 服务标准不同，处理 Web 服务对话的新标准和相关供应商技术还没有得到广泛使用。此外，在当前版本中，BPEL 本身在这个特定方面具有显著的缺点。
同时，Web 服务设计人员正在面临挑战，他们需要在更多类型的传输协议（例如，HTTP、SNMP 等等）、更多类型的客户端设备上满足更多用户对 Web 上所有类型的实时交互的需要——例如，获取有关最合适产品的建议，而不只是在线购买商品。要应对此类挑战，将需要对服务（甚至是对那些服务的基础——它们的组件和对象模型）的设计进行日常维护。
支持复杂业务事务的最有效方法之一是使用所谓的以活动为中心的服务——这些服务是明确地为处理定义良好的任务或流程而设计的，并通过维护特定活动使用的所有应用程序的计算状态来完成其工作。
  |
|
概括地说，以活动为中心的服务旨在执行单个活动，此活动涉及到许多不同的应用程序（或系统）和每个应用程序中的大量特定功能和数据表示形式。以活动为中心的服务的主要特征之一在于这些服务提供了执行保证，这不仅限于传统的 ACID（原子性、一致性、隔离性和持久性）属性，并且可以包括时间上的约束、状态访问灵活性和多重交互的事务执行。这些保证不仅可能在应用程序之间有所不同，而且可能在一个应用程序中的不同事务之间也有所不同，具体取决于事务任务的属性、用户首选项和可用的系统资源。
图 1 中的示例场景（搜索大量航班以查找最低票价的旅行预定服务）说明了这一点。在此示例中，客户端提供多组起飞和目的地信息，该服务搜索相关的航线以了解可用航班和票价。如果没有可用航班，则客户端与服务之间的交互必须停止。否则，该服务将向客户端返回航班和票价列表。然后，如果客户端从列表中选择某个特定航班，则该服务将要求客户端提供所需的私人信息以完成交易，例如姓名、地址和信用卡信息。此时，将执行若干任务。首先，将根据安全和信用卡授权规则验证所提供的信息，并在所提供的信息存在问题时通知客户端。如果所提供的私人信息可接受，则该服务将尝试预订航班。如果预订成功，则创建客户旅程记录，并向客户端返回该记录的标识符以便旅行者将来使用。
图 1. 示例场景——查找最低票价
如果从计算的角度查看这里引用的示例....
本文转自IBM Developerworks中国
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
