InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

REST和分布式事务

作者 Mark Little 译者 马国耀 发布于 2009年6月17日

领域
架构 & 设计,
企业架构
主题
REST ,
事务处理 ,
容错技术 ,
SOA
标签
事务

对于REST和其他方法(尤其是Web服务)孰优孰劣的讨论已持续了很长时间。简言之,在基于Web的集成中使用REST的优势何在。讨论继续进行着,但是一些人开始把讨论转移到在REST(或REST/HTTP)是否丢失了其他方法中存在一些理应具备的能力。分布式事务是其中之一,最近,一个REST讨论的邮件列表正来来回回地进行着,这个讨论是由Bill Burke就一个基于RESTeasy的实现向人们征求意见引发的。

相当简洁的API。我想看到Atom链接是否可以取代已发布的URI模式,那样我们就可以限制系 统所暴露的URI的数量,使得它从整体上更灵活。 我还在想我们是否能标准化链接关系(Link Relationships)而不是数据格式,这样可能就能使DTX标准从必须一并定义数据格式的限制中解放出来。

这篇发文引发了一场围绕着ACID事务和基于补偿的事务之间的选择的踊跃讨论,Bob Haugen(ex-Choreology and OASIS BTP) 指出:

基本步骤:1:第一步,所有的参与者临时更新资源(不是通过状态,就是通过独立的临时资源)2 :一旦提交,所有的参与者更新资源的最终状态(或者创建“最终资源”)3:一旦放弃或取消,所有参与者删除临时资源,或者将临时资源标记为“已取消”,或者创建新的“已取消资源”。 这种模式还允许选择性地提交或取消,比如在竞价流程中使用。

似乎达成一致的是,基于和Web服务相同的原因,如果需要事务,那么扩展事务(补偿是一个具体的例子)将是可能的发展方向。Mike Amundsen 补充道:

我更倾向于Saga模型,因为它是一个“乐观的”模式,而且我发现它在HTTP上建模更简单。从实用性来说,我可以不需要使用saga的细节(实现“向前补偿”或“向后补偿”)就可以为最初的交互建模。之后(有时是几周之后或几个月之后)在实施时,我可以在不影响客户端或代理的情况下添加补偿任务。

后来Roy Fielding也加入了讨论,他在几年前曾经说过……

这个话题多次出现在webdav和http-wg列表上。事务是一个资源,但是它和被请求资源之间的关系可以通过一个消息头字段来定义,该消息头把每一次请求定义成层级事务之中的顺序资源。换言之,服务器开始一个事务,每一次请求,将(事务的)URI作为包含着请求号的消息头的字段传送给客户端,最后通过向事务的URI发送一个最终请求来取消或提交事务。我在still-vapor waka协议中基本上是这么做的。

然而时过境迁,Roy的观点也有所变化。

如果你需要分布式事务的协议,那么你怎么可以说你的架构是基于REST的呢?简单来说,我看不到你如何能够从一种情形(在客户端使用RESTful应用状态,使用超媒体来决定状态间的过渡)到另一种情形(需要事务语言的分布式约定,而客户端如何告诉服务器来管理(客户端)的资源)。你正在考虑的问题很可能是多服务器之间的CRUD操作,而每次操作都是基于RESTful架构的。当所有操作完成时,客户端需要发起最后的请求来取消或确认(之前做的)更改,可能是与一个TM式(TM-Style)的管理资源交互,通知所有的服务提交所做的更新,从而使这组资源进入一个更持久或者公开的状态,就像登台服务器(staging server,即负责整个处理中某阶段工作的服务器)被用来准备要发布的内容。所有这些操作加起来可能等同于一个ACID事务。而它们跟REST客户端没有任何关系。就REST客户端而言,它在一个时刻只和一个资源交互,尽管有时候这些交互可能是重叠的或者异步的。除了依据资源的语义而在后台实现的约定机制之外(存在于独立的架构中,这里我们不关心它),REST并无“事务协议”;除了为客户端提供(任意点上)的多选择的展现之外,REST并不包含提交协议。而且,客户端事务协议的约定也没有必要,因为客户端只能在服务端提供的选择范围内进行选择。

这之后还有很多追踪邮件,比如扩展事务协议(不是ACID)可以以RESTful方式用在何处,以及已经使用的何处的跟帖。但是,Bill Burke插话说,讨论并已偏离了最初的主题:

我最初发帖的目的是,在客户端资源层以及资源/TM交互层,如何通过定义以及标准化若干链接关系来大大简化工作。

这似乎得到了一些邮件列表里的人的响应。事实上,后来Alexandros Marinos把大家引到一个基于ACID的协议,他和他的同事们正在实现这个协议。讨论依然继续着,但对于REST世界是否有合适的(扩展)事务,似乎并没有明确的答案。然而,几乎可以定论的是很多人认为分布式事务是需要的,基于某个或某些原因。

查看英文原文:REST and transactions?

译者 马国耀 关注企业级应用相关的开发、架构及思想的发展。尤其对Java EE、SOA、ESB和Cloud Computing等领域持有浓厚兴趣。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。