Web服务内幕，第10部分：深入主题：可靠性和事务

James Snell（jasnell@us.ibm.com）

软件 工程师，IBM Software Group

2001 年 11 月

就本质而言，Web 服务体系结构是应用程序通过智能的消息交换相互进行集成的 方法。对于企业，这意味着关键业务信息（比如：订购单、合同以及报价索取（RFQ））的交换。由 于这种信息的关键性本质，企业必须确保底层消息传递体系结构的可靠性。在 Web 服务内幕的这篇 文章中，James Snell 继续他的关于影响在企业中使用 Web 服务的问题的讨论，侧重于可靠的消息传递和事务。

在 Web 服务内幕的前一篇文章中，我邀请了 Maryann Hondo — IBM 的 Web 服务安全标准的领导者，来帮助我通览了一遍各种安全性和保密性问题，这是使用 Web 服务的企业开发者必须考虑的。在这篇文章中，我将花些时间来探索企业中对 Web 服务的其它两个关键性要求：可靠性和事务。该讨论将分成三部分：

a. 可靠的消息传递的讨论

b. 有条件的消息传递的讨论

c. 称为相关性环境的新的类型的事务管理机制的介绍

可靠的消息传递

“可靠的消息传递”的简单定义是确保消息的发送方和接收方都知道消息是不是确实被发送或接收了，此外要确保消息一次发 送给目标接收方，且只能是一次。很简单？是的。容易实现？并不是这样。

从一开始，可靠的消息传递所存在的问题一直是困扰因特网应用程序开发的问题。究其本质，因特网本身就是不 可靠的。服务器在某一时刻启动并运行，但是可能在另一时刻当机。用来连接发送方和接收方的 协议并没有设计成支持可靠的消息传递构造，诸如：消息标识符和确认。消息的接收方必须能够确 认这样一个事实，即实际上他们已经确确实实接收到了消息。万一没有接收到确认并且需要再次发送消息时，消息的发送方必须能够高速缓存那些消息。今天推动因特网的基本技术 不支持这样的机制。因此，迫使开发者去实现新的协议、新的技术，从而满足这些需要。

现在，很明显，可靠的消息传递不是新的问题；也不是开发者现在才努力去解决的问题。源 自众多技术供应商的许多现有产品以一种或另一种形式实现可靠的消息传递。问题是 — 这是我继 续这篇 Web 服务讨论的关键点 — 目前还没有可采纳的可靠的消息传递的解决方案，可以容易地与其它解决方案进 行交互操作。为了解决这个问题，IBM 所采取的方法为：并不是定义一个可靠的消息传递应用，而 是定义另一个标准化的、与应用无关的可靠的消息传递协议，它基于广泛存在的超文本传输 协议（HTTP）。

HTTP 不是可靠的协议，这是很显而易见的。以下面的方案作为实例。这些内容最初在 7 月 developerWorks 网站上发表的“HTTPR 概述”中讨论过（请参阅参考资料）。

图 1：同步的、不可靠的消息传递

图 1 展示了典型的 HTTP 请求／响应流程。现在，请考虑一下出现 在第 1 步和第 2 步（由红色的圆点标注）之间的某种类型的通信故障。请求方将只知道出现了连接错误 ，但不知道请求是否曾传给了响应方、应不应该回滚请求、响应方能不能处理这个消息或 者响应是不是仅仅是在返回给请求方的途中被中断。对于那些在线购物的人来说，这恰恰是为什么 会看到这样的警告：不要多次按提交按钮，否则您的信用卡上将会多次计费的原因。

HTTPR 增强了 HTTP，在 HTTPR 中它添加了必需的元素来消除或者说至少可以减少在请求／响应过程中出现任何类 型的故障时随之产生的怀疑程度。HTTPR 工作原理超出了本文讨论的范围。相反，我将向 您推荐早些时候发布在 developerWorks 网站的“HTTPR 概述”（请参阅参 考资料）以及“HTTPR 规范”（请参阅参考资料），以获取关于 HTTPR 如何发挥作用的详细的技术信息。而下面的图 2 说 明了 HTTPR 怎么可以改变上图所示的请求／响应事务流程，从而实现可靠的消息传递。

图 2：异步的、可靠的消息传递

您可能要问的主要问题是 HTTPR 为什么是“可靠的 HTTP”？为什么将 HTTP 用作可靠消息传递协议的基础？回答是：这仅仅是因为 HTTP 已有的广泛的部署基础。Web 服务是因特网技术渐进发展的结果。没有必要去重新开发不需要重新开发的东西。将可靠的消息传递建立在 HTTP 基础上，将允许已经对 Web 服务器技术的投资的公司利用可靠的消息传递性能，同时继续利用已有的投资。作为 HTTP 的扩展，HTTPR 也能利用 HTTP 安全性、会话、代理、防火墙支持等设施。

有条件的消息传递

与可靠的消息传递概念紧密相关的是有条件的消息传递，它涉及到各种条件的建立，这些条件用于确定怎 样以及什么时候传递消息。例如，10,000 台 ThinkPad 膝上电脑的报价可能只在收到报价后 10 天 内有效。另一个示例可以表述为：只允许某些人查看消息内所包含的信息，其中所涉及的内容可以 链接到以前的关于安全性和保密性的讨论。（请参阅参考资料。）

有条件的消息传递是基于规则的可靠的消息传递。一般情况下，这些规则总是在应用层实现。直 到现在，表达消息条件事实上还没有一个一致的方法，以便们可以应用于中间件层。对 Web 服 务来说，这种概念将作为企业中启用 Web 服务的关键因素出现 — 允许公司在定义的约束和条件下动态地集成 业务过程。

事务和相关性环境

因特网开发的一个典型的长期存在的争论是：是否需要两阶段提交方式的 Web 事务。如果需要，究竟怎样实现它。简单的、却相反的回答是：不，不需要。传统的两阶段提交不适于 Web 服务，对于这个问题的解释，我赞同 ActiveState's ASPN 站点（由 Walter Perry 主持）上的关于该问题的精彩讨论（请参阅参考资料）。

IBM 的研究小组提出了实现分布式事务的另一种途径。这种实现途径称为相关性环境，在最近提交给“企业分布式对象计算会议”（Enterprise Distributed Object Computing（EDOC）Conference）（9 月初在西雅图举行）的论文中讨论了。

相关性环境是新的类型的事务环境，它允许在单个事务中交换出现同步和异步分布式消 息传递风格。这究竟意味着什么？那么，来看一看一个示例方案，这是在 IBM 研究人员呈交给 EDOC 会 议的论文中所提出的（请参阅参考资料）。

“Web 站点的访问者开了一个新的帐户，在此之后必须在两个不同的分布式旧系统中创建 ：用于帐户管理的 ERP 数据库和用于客户支持的 CRM 数据库。以实体 EJB 实现到 ERP 数 据库的接口，但是访问 CRM 数据库必须通过 JMS/MQ 消息传递接口。难题在于以单个分布式事 务怎样在 ERP 和 CRM 数据库中完成两个帐户的创建。” — Stefan Tai 等人 所著的 Dependency-Spheres: A Global Transaction Context for Distributed Objects and Messages。

该论文继续指出：目前绝对没有能支持这种类型事务的中间件支持。您可以进一步深入，设想 CRM 和 ERP 应用都远程地托管基于 SOAP 的 Web 服务（用 WSDL 描述），一个使用 EJB 托管在 WebSphere 环境，另一个托管在 Microsoft.NET 的环境。现在，由于现有的基础架构这种问 题完全不可能解决。

相关性环境解决了这个问题。作为第三方 Web 服务建立，相关性环境可以提供必需的事务环境，确保上面示例中的两个帐户的创建操作即使是在分布式的异种环境中都能进行，并且 正确地进行。我不打算详细地解释相关性环境怎样工作，关于这些内容，请参阅由 IBM 从 事该领域研究的研究小组成员所撰写的精彩论文。（请参阅参 考资料。）

这种方法很大程度上依赖于其中的可靠的和有条件的消息传递原则，为了确定给定的事务是成功还是失败 ，必须监控消息传递，从而确保能够恰当处理应用于消息传递和处理的规则。

现在，必须指出相关性环境仍然是一个研究项目，至少就这一点来说，它并不是在 Web 服务体 系结构内实现事务的唯一最有效和最有价值的方法。但是，对于怎样在分布式的 Web 服务环境 中实现事务这个难题，它有希望给出一些可靠的回答。

下一步是什么？

下面我所列出的参考资料将给您研究 Web 服务中可靠的的消息传递、有条件的消息传递以及事务支持提供充 足的背景资料。要在 Web 服务中实施可靠的消息传递，我建议您从 IBM 的 alphaWorks 站点下载 最新版本的 Web Services ToolKit（版本 2.4）。样本示例中包含 HTTPR 协议演示。

参考资料

请参加关于本文的讨论论坛。

通过阅读 HTTPR 概述学习“可靠的 HTTP”。

也可以得到 IBM 发布的 HTTPR 规范。

本站点有关于 IBM 研究 有条件消息传递方面的信息。

提交给 EDOC 会议的 Dependency Sphere 讨论论文可在线得到。

要获取更多的关于 EDOC 的信息，请访问其 Web 站点。

下载最新版本的 Web Services ToolKit 来运用 HTTPR。

关于作者 James Snell 身兼作者和开发者两职，他是 IBM Web 服务开发小组最新的成员之一。他带着定制企业应 用程序开发和企业对企业集成方面深厚的技术背景来到 IBM，他热衷于 Web 的尖端技术。 您可以通过 jasnell@us.ibm.com 与他联系。 浏览：Web服务内幕，第1部分 Web服务内幕，第2部分 Web服务内幕，第3部分 Web服务内幕，第4部分 Web服务内幕，第5部分 Web服务内幕，第6部分 Web服务内幕，第7部分 Web服务内幕，第8部分

Web服务内幕，第9部分