My thoughts about RETRO: A RESTful Transactions Model

Transactions has typically been one of the aspects that the WS-* followers continuously point out as one of the weaknesses of the REST model. Even though we all agree that atomic transactions in distributed systems are JUST A BAD IDEA and everybody that follows Werner Vogels's lectures knows that the eventually consistent model is the way to go, we can't deny that transactions (conceptually) are an important part of everyday's business processes. However, let's just all be on an agreement that conceptual transactions don't necessarily have to be implemented as atomic transactions and there are simpler and more scalable models that have been successfully adopted by the industry. The RESTful model is not an exception to that rule and consequently we need an efficient way to model transactions without violating the principles of REST.

In the RESTful services book, the authors take an initial stab to this problem by proposing a model on which transactions are represented as resources. This is a good idea in principle but maybe too simplistic for real world applications. A few weeks ago I spent the entire five hours of my flight to Las Vegas going through the RESTful transaction model (RETRO) specification proposed by a few researchers at the  Department of Computing, University of Surrey . I have to admit that I was a bit skeptical at the beginning but just a few pages into it I was completely blown away but the technical quality of the work. I am very aware that this work has received some negative reviews and a LOT OF POSITIVE ones.

The negative reviews are all somehow related to the classic argument that transactions are not feasible for highly distributed and scalable solutions. I have no intentions of sounding disrespectful but, after reading almost all the negative reviews,  I think we still need to do a better job evangelizing the principles of REST and how that model can be applied on real world applications. Either that, or the people providing the feedback didn't really take the time to read and understand the ideas of the RETRO model.

The RETRO specification is extremely loyal to the principles of REST. Even to a level of details that makes me wonder if it could be ever be applied 100% on real world systems. But we all know that almost no real system is entirely RESTful. My good friend Jim Webber prefers to use the term Web-based services to name those systems that are almost RESTful but they make some concessions to accommodate specific requirements.

If you are still wondering what makes RETRO so RESTful I think there are a few aspects that should be highlighted.

  • Resource Identifications: RETRO uses a resource representations for modeling all elements of a transactional interaction such as transactions, owners, etc.
  • Resource's URI: In RETRO every resource can be uniquely accessed by an URI that varies whether the resource is locked or not.
  • Hypermedia: RETRO leverages various hypermedia types to describe the type of resources that the client can manipulate.
  • Statelessness: All interactions proposed in RETRO are completely stateless which is an important factor to guarantee the scalability of solutions that use this transaction model. This approach highly contrasts with the WS-Coordination and WS-AtomicTransaction protocols which relies on a highly stateful model.

Yes, we all agree that atomic transactions are almost a fantasy in highly distributed enviroments, especially those that rely on the Web. However I still think RETRO proposes a fairly clean and scalable model that does not violates any of the principles of REST.

What do you think?

1 Comment

  • Hi Jesus,

    It's a coordination protocol. It might even pass the REST-discuss test, because it works harmoniously with the Web.

    However HTTP is already a coordination protocol (serverless in this case). Each time I interact with a service I get coordination metadata which tells me whether or not I can make forward progress.

    Whether I need a second-order coordination protocol like RETRO is domain specific. But generally I'd say you wouldn't need it.

    Jim

Comments have been disabled for this content.