Ed. Note: REST [REpresentational State Transfer] is posed as an alternative to SOAP in some applications. Much discussed, it is not familiar to all. 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 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
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
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.