Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Eric Newcomer On Difference Between RESTful vs. Web Service Transactions
Posted by Dilip Krishnan on Mar 18, 2009
Eric Newcomer, chair of the OSGi Alliance Enterprise Expert Group and former CTO of IONA Technologies, posted an answer to the question “What is the difference between RESTful transactions and Web Services transactions?”
Eric sets the context by differentiating transactions into local and global transactions, saying that local transactions are not particularly interesting as they work the same way in both cases.
The question therefore really pertains to global transactions -- those that involve more than one database, potentially on different computers -- since that's where things are very different.
He warns that since Web services are a technology, and REST is an architectural approach the comparison might not be accurate. However he attributes the differences in implementations of transactions to the different assumptions arising from the underlying infrastructure, especially related to distributed access to shared data, or shared state.
Web services transactions ([…]WS-Transactions[…]) are intended to be compatible with existing TP [Transaction Processing] infrastructures. The REST approach, on the other hand, evolved from the Web.
As a result he states that the key differences between the two types of transactions are based on:
1. How the transactions are coordinated among participating systems
For compatibility with existing shared state mechanisms, Web services transactions propagate shared transactional context among participants in a global transaction so that each participant's access to shared state can be coordinated with the others. REST based transactions assume that only one party to a global transaction accesses the shared state at any given time, sort of like passing a token. […] They are responsible only for knowing what they must do when they receive the shared state – when it's their turn.
2. How the systems handle transaction failure and recovery
RESTful systems require a very different design for handling failure and recovery, since it cannot be automated, the trade off in additional application level design and coding pays results in a system better suited to the assumptions of the Web.
Be sure to check the original article.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
No comments
Watch Thread Reply