10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
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.
..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
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
9 comments
Watch Thread Reply