Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Mark Little on Jun 15, 2009
There has been a long debate about the benefits of REST versus other approaches (notably Web Services), or simply the benefits of using it for Web-based integrations. The discussions continue, but several people have begun to try to move the debate to whether or not there are certain capabilities we take for granted elsewhere that are missing in REST, or specifically in REST-over-HTTP. One of those things is distributed transactions and there has been a recent to-and-fro on the REST-discuss mailing list, triggered when Bill Burke pointed people at an implementation done on RESTeasy and asked for comments.
Pretty clean API. I want to see if Atom Links can replace some of the published URI schemes so that we can limit the number of URIs exposed by the system and give more flexibility to the system as a whole. I'm also wondering if we standardize on Link Relationships rather than data format, this may free a DTX standard from having to define a data format altogether.
This initially triggered a lively debate about whether you need ACID transactions or compensation-based transactions, with Bob Haugen (ex-Choreology and OASIS BTP) pointing out:
The basics are: 1. In the first phase, all participants update their resources provisionally (whether by state or by separate provisional resource), 2. Upon commit, all participants update their resources in their final state (or create final resources). 3. Upon abort or cancel, all participants delete their provisional resources, or mark them cancelled, or create new cancelled resources. The pattern also allows selective commits or cancels, for example for a bidding process.
There seemed to be general agreement that if you needed transactions at all then some form of extended transaction (of which compensations is a specific example) were the way to go, for the same reasons as with Web Services. Mike Amundsen added:
I prefer using the Saga model since it is an "optimistic" pattern and I find that easier to model over HTTP. On the more pragmatic side, I can model the initial interaction set w/o employing the details of the saga (implementing either 'forward compensation' or 'backward compensation' steps). I can then add the compensation work later in the implementation process (sometimes weeks or months!) without much disruption to clients or proxies, etc.
After a while Roy Fielding joined in the discussion, having said several years previously ...
This topic has come up a few times on webdav and http-wg lists. The transaction is a resource, but the relationship between it and the requested resource can be accomplished via a header field that defines each request as a sequenced resource within a hierarchical transaction. In other words, ask the server for a transaction begin, send the URI it gives the client in each request as a header field with a request number appended to it, and finally abort or commit the transaction as a final request to the transaction's URI. That's basically how I did it for the still-vapor waka protocol.
However, over the years Roy's opinions have changed, based on his experiences.
If you find yourself in need of a distributed transaction protocol, then how can you possibly say that your architecture is based on REST? I simply cannot see how you can get from one situation (of using RESTful application state on the client and hypermedia to determine all state transitions) to the next situation of needing distributed agreement of transaction semantics wherein the client has to tell the server how to manage its own resources. Most likely, the system you are thinking of is just doing CRUD operations on multiple servers. Each of those actions might be based on a RESTful architecture. When all of them are done and the client makes a final request to approve or cancel the changes, it might be interacting with a TM-style manager resource that tells all of the other services to commit the associated changes to a more persistent or public set of resources, just like a staging server might be used to prepare content prior to publication. The sum of all those actions might be equivalent to an ACID transaction. None of that matters to the REST client. As far as the client is concerned, it is only interacting with one resource at a time even when those interactions overlap asynchronously. There is no "transaction protocol" aside from whatever agreement mechanism is implemented in the back-end in accordance with the resource semantics (in a separate architecture that we don't care about here). There is no commit protocol other than the presentation of various options to the client at any given point in the application. There is no need for client-side agreement with the transaction protocol because the client is only capable of choosing from the choices provided by the server.
There was a lot of follow-up to this, with examples of where extended transaction protocols (not ACID) could and are being used in what the posters believe to be a RESTful manner. However, Bill Burke interjected that that wasn't really the point of his original post:
This was what I meant in my original post that defining and standardizing a few link relationships might simplify things a lot, both at the client resource level and resource/TM interactions.
This did seem to resonate with a several of the people on the mailing list. In fact Alexandros Marinos then pointed people at a protocol (ACID based) that he and colleagues have been working on implementing. The discussion continues, but there seems to be no clear answer to whether or not (extended) transactions really do fit in a REST world. However, it does seem conclusive that many people believe they need them for one reason or another.
Right Collaboration Architecture Drives Business Transformation
Restful BPM, Pragmatic SOA, Mashups, Avoiding Failure: SOA track @ QCon London in March
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
..repeats. The complexity creeps in. One size does not fit all. The revolutionary change dies a slow death through incremental accretion of cruft.
All those people being shot down by the REST school for asking "what about transactions?" must feel vindicated right about now!
I fully agree with Roy. I think distributed transactions are bad for REST just as much as they are bad for SOA and just as much as ws-atomictransactions are bad for SOAP
I blogged that in more detail here
REST will be hijacked by the same SOA people that think changing protocols will somehow magically solve their distributed data consistency problem.
What you need is a new way of thinking about doing distributed systems where you manage consistency and data aggregation differently, rather than how to encode 2PC in HTTP
I suggest you read the entire discussion thread on the mailing list. Most people agree that ACID transactions, e.g., WS-AT, are bad for REST let alone SOA and Web Services. That argument was debated ad nauseam many years ago, so do we really need to revisit those same arguments?
You tell me :). After all this news bit, written by you and which appear on a wider forum than the rest list brings this issue up again. Efforts like RETRO (which triggered my post) also do that...
Arnon, remember this markclittle.blogspot.com/2007/07/is-anyone-out-...
Meet back here in another 2 years for the same discussion? ;)
Mark, of course I do :)
I didn't say that the topic isn't discussed to death - but it does seem to come up again and again. So now there's a new distribution hype going on (REST) and the same ol' topics have to be rehashed (e.g. my next post will explain why CRUD is bad for REST). I guess we never learn :)
There's a glitch in the Matrix. It's deja vu ;-)
Hi,
We at Atomikos did not support WS-AT because we figured nobody would want it. And yet, people today are asking us to provide this... I am talking about ACID, which is of course bad for inter-company solutions but actually acceptable for intra-company solutions where interop is needed.
AFAIK interop with, say, MS is the only good reason to use web services in the first place...
When it comes to SOA there seems to be consensus that ACID is bad and something based on compensation is needed. Here is our approach to that:
www.atomikos.com/Publications/TryCancelConfirm
Also see the whitepaper that can be downloaded from our front page:
www.atomikos.com
I guess this same model could just as well be applied to REST solutions. There would be no tight coupling nor locks, and you would get the best of the loosely coupled REST world with the guarantees of transaction monitors.
Best
Guy
www.atomikos.com
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
9 comments
Watch Thread Reply