谁需要Web服务事务处理？
作者：Mike Lehmann
事务处理支持出现在Web服务标准当中。
想想商务应用程序中的事务处理，你会立刻想到银行业务、股票交易与航空订票系统，这些都是典型的规模巨大且非常昂贵的企业系统，这些系统的信息如果有误，可能会导致严重后果。
奇怪地是，当试图利用Web服务来构建第一个应用程序时，你就会发现关于Web服务事务处理的信息
非常缺乏。把销售商的文件从头看到尾，可能什么都找不到。
当然，在Web服务（过去5年中最主要的技术发展趋势）的某个地方，应当有很多关于面向服务的事务处理的信息。本专栏将阐述Web服务事务处理规范的过去、现在和未来。
Web服务事务处理的历史
好像并不是Web服务刚一出现，这个行业就忽略了事务处理。更确切地说，是事务处理至今一直都没有成为那些已经使用了Web服务的应用程序的成功基础。
许多早期的Web服务项目致力于已经证实的需求／响应Web结构的再开发和多元化利用，其中对事务处理的支持要么是利用传统的Web技术（如HTTP会话或cookie）明确编进应用程序层，要么通过让应用程序只提供对后端商务系统的只读访问而明确禁止。但更多的开发人员正在立项以测试简单Web服务的限度，促使几个标准研究计划将事务性语义引入Web服务。
2000年，许多重量级销售商编写了一个叫做事务处理授权标记语言（Transaction Authority Markup Language）的规范。2001年，BEA创立了一个叫做商业事务处理协议（Business Transaction Protocol）的规范。2002年，IBM与微软创立了WS-Transaction和WS-Coordination，作为用于面向Web服务的业务流程执行语言（Business Process Execution Language for Web Services ，BPEL4WS）的组成部分。2003年8月，一个包括Oracle在内的销售商联盟提出了Web服务复合应用框架（Web Services Composite Application Framework ，WS-CAF），将其作为以前那些研究计划的扩充。
事务处理：需要还是不需要？
在传统应用程序中，多数事务往往耗时短且同时进行，而且参与者也不多：一个将向银行贷款的客户，一个预定飞机票的旅客，一个完成购买的股票商。这些都是基本事务处理。人们对这些都很清楚；一直就缺少的是这些事务语义的Web服务层。
在商务处理领域将事务性语义与Web服务集成在一起变得更为复杂。这里，Web服务的交互时间变长且不同时进行，涉及的当事人也很多。例如，一个旅客通过旅行社来筹划商务旅行说明了典型商务流程的复杂性。处理这样一个基于Web服务的商务旅行事务可能需要旅行社与航空订票系统、饭店预订系统及汽车租贷系统进行交互。这种情况如图 1所示。
图1：一个商务旅行者通过一个旅行社预定一次旅行
这种方案会导致很多问题：
任何一个交互出现问题，旅客可能都需要与旅行社一起重新考虑整个商务旅行，也许不仅要改变出了问题的事项，还要改变相关的事项。
与传统的基本事务处理不同，在等待其他事务完成的同时很难锁定全部参与资源。例如，航班与饭店预订系统不可能一直等待汽车租贷系统中某一操作的结束。
每个子事务都必须独自完成，然后以某种方式与更大的耗时久的商务旅行事务建立联系。在现实生活中，商务旅行事务也往往是更大的一个事务当中的一部分。例如，旅客或许想把商务旅行同休假结合起来。
这样的事务处理称作商务活动。商务活动往往具有传统基本事务处理的一些特征，但因为它们耗时久，有时需要好几分钟、好几小时，甚至好几天，所以必须创建一个新的语义集，以处理这些差别。
将事务映射到Web服务
中介（如一个旅行社）在管理这些交互操作时，每个问题可能都需人为干预。但在Web服务中，这些步骤常常都自动进行，以减少对人为干预的需求。
多数被提议的Web服务事务处理规范既可处理基本事务又可处理商务活动事务，因为他们不可避免地要联合制定Web服务方案。事实上，由于事务处理与商务流程关系清晰，BPEL4WS与WS-Transaction和WS-Coordination规范是联合发布的。
Web服务事务处理的定义程序是一个分布式事务处理协调程序。与我们方案中的旅行社有些类似，该事务处理协调程序相当于一个中介，它跟踪所有涉及基本服务的交互操作，并且根据来自旅客的通知（通过商务应用程序），协调事务的接收或"提交"。
与基本事务处理工具（如Oracle数据库）中的传统分布式事务协调程序不同，Web服务事务处理协调程序自身就是一种Web服务，它通过SOAP消息接收信息。但是，作为事务处理协调程序并不定义事务处理协议本身是什么。该协议通常是由协调规范的补充规范定义的--例如，WS-Transaction和WS-Transaction 管理。这些规范概括了Web服务执行过程是如何在基本事务处理和商务活动事务处理的上下文中描述诸如"开始"、"提交"与"回滚"等普通事务处理操作的。
事务处理协议满足了执行Web服务事务处理的各种要求，但并不独立定义一个在并行的交互操作中只识别一个特殊的基本事务处理或商务活动事务处理的共享上下文。源于Web服务复合应用框架的WS-Context概括了如何创建一个公用共享上下文，它可以用于在参与该事务的Web服务间传送这一信息。这个新的商务旅行方案中的这些移动部分如图 2所示。
图2：用于商务旅行的Web服务事务处理
商务活动与补偿事务
迄今为止除了Web服务层之外，Web服务事务处理并未显示出与平常的事务处理有很大差别。不过，其真正的不同之处在于商务活动。特别是所有的Web服务事务处理规范都定义了一个补偿的事务处理功能，在发生异常中止时并不回滚事务，而是指定一组撤消动作以应用于一个或多个Web服务交互操作。
再看一下我们的旅行方案，设想旧金山与温哥华之间的直航不再可行。可以执行一个补偿事务处理，以设法预订另一航班以及可在西雅图中转的路线。这可能会影响相应的旅馆预订，需要另一补偿事务来提供到达及离开不同旅馆的时间。
补偿事务处理是自动化商务处理流程的基础，所以BPEL4WS引入了一个明确的声明机制将其嵌入，来处理出了问题的Web服务活动，如上述情形。
上述规范何时才能基于标准？
你可能已经注意到本文将WS-Transaction/WS-Coordination和WS-CAF都称作规范，而不是标准。不过在完成本文时，WS-CAF已经提交给OASIS，对于那些准备将Web服务由一项基础技术变为进行企业应用开发与集成所依靠的关键技术的机构来说，这是个好兆头。
请关注Oracle技术网，因为Oracle不但继续帮助制定Web服务标准，如WS-CAF，而且也开始提供Oracle应用程序服务器10g中的Web服务事务处理支持的预览工具。
Mike Lehmann ()是Oracle Application Server Containers for J2EE 10g的首席产品经理。
