<</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 <http://modualrit.blogspot.com/>.>>
/
/You can find this at:
http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1350094,00.html
/
/Gervas
/
- [service-orientated-architecture] Eric explains the differ... Gervas Douglas
-
