BT

Eric Newcomer On Difference Between RESTful vs. Web Service Transactions

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT