The challenge here is to try to say something meaningful without writing something too long for the Web site.
The shortest explanation I could come up with is: "WS-Transactions are like everyone sitting in a circle holding hands, while REST based transactions are like everyone sitting in a circle passing a ball around." WS-Transactions is based on the model in which all resource (database) sessions are connected using a shared context, while the REST based approach assumes only one session has knowledge of the transaction at a given point in time. One other thing you could say is that in the typical TP design when you move from a single database to a multiple database transaction, an independent transaction manager is necessary to coordinate the transaction managers in each database. Every database has a transaction manager, but it can only really manage transations for itself. I was asked if I could answer this question "without writing a book" and I tried to do so - of course more information on TP infrastructure and how 2PC works is available in the book I wrote with Phil Bernstein. In December we finally finished the second edition (due out in June), and it also now includes information about the REST based approach. But you can also find details about the REST based approach in "RESTful Web Services" chapter 6. Eric ________________________________ From: Marcelo Augusto <[email protected]> To: [email protected] Sent: Friday, March 6, 2009 10:24:21 PM Subject: Re: [service-orientated-architecture] Eric explains the difference between REST and WS* transactions The subject is great, but I found the text a little bit confusing... One may say I don´t have enough knowledge of some concepts to understand the text, but I would reply "people who have it can learn something from it?". Let´s put this way, as the Philadelphia´ s lawyer would say: "explain it as if I were 2 years old". :-) 2009/3/6 Gervas Douglas <gervas.douglas@ gmail.com> <<The SearchSOA.com community has asked "What is the difference between RESTful transactions and Web Services transactions?" First, it's helpful to define the terms a bit here, because people often have a reaction to the term "transaction" that doesn't distinguish between local and global transactions. Local transactions are used in every almost every database operation today, and this is exactly the same for both Web services and RESTful applications. 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. (I should also clarify that Web services are a technology while REST is an architectural approach, so this is going to be a bit of an apples-to-oranges comparison.) Web services transactions (as defined in the OASIS WS-Transactions set of specifications) are intended to be compatible with existing TP infrastructures, which basically evolved from mainframe systems. The REST approach, on the other hand, evolved from the Web, which is based on an entirely different technology stream. Some of the key differences derive from the very different assumptions behind mainframe systems and Web based systems. Mainframe systems were designed assuming an environment for resources and users under the control of a single organization. Web based systems on the other hand were designed assuming a world wide network of independent but cooperating systems under the control of different organizations and individuals. Today's corporate IT systems can be more or less divided between those developed before the Web and those developed for the Web. Systems designed for the Web have much less control over things like workload, uptime, the need to provide a good experience to users, etc. These different assumptions impact transactions because they result in very different solutions to the requirement for distributed access to shared data, or shared state. At the technical level the biggest manifestation of the difference is in the design of the communications system. Transactional communications mechanisms that evolved from mainframe designs use persistent sessions to share state between programs. The communications protocol used in REST oriented systems, HTTP, does not support persistent sessions because they negatively impact scalability. If you are operating in a carefully controlled environment, that impact is manageable. 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. The other participants have no knowledge of what's going on at another participant and their operations on shared state can't be coordinated. They are responsible only for knowing what they must do when they receive the shared state – when it's their turn. This creates is a very different design requirement 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. Eric Newcomer is a distributed computing specialist and independent consultant. Newcomer is a chair of the OSGi Alliance Enterprise Expert Group and former CTO of IONA Technologies. He writes a blog on OSGi matters.>> You can find this at: http://searchsoa. techtarget. com/news/ article/0, 289142,sid26_ gci1350094, 00.html Gervas -- Marcelo Augusto Costa
