Transactions for the REST of us

Cesare Pautasso, University of Lugano, CH
Guy Pardon, ATOMIKOS

Does REST need transactions?

• The typical conversation thread about transactions over HTTP goes something like this:

Mike Amudsen

• "You don't want transactions over HTTP"
• But I need to organize number of steps into a single unit I can deal with easily.
• "OK, but you don't need transactions over HTTP"
• But I need the ability to back out changes in multiple locations safely and consistently.
• "OK, but you can't do transactions over HTTP!"
• Really?

• And here the topic usually dies or descends into a heated debate.

The Context

The Problem

Single state transfers from/to
the client are idempotent

How do we make both interactions atomic?

Constraints

• Interoperability
  • No changes/extensions to HTTP
  • No additional verbs
  • No special/custom headers
• Loose Coupling
  • REST services should remain unaware they are participating in a transaction
• Simplicity
  • Transactions will not be adopted in practice unless they can be made simple enough

Try-Confirm/Cancel

TCC Participant's view

• Try: Insert into reservation db
• Confirm: Update reservation,
  set status = confirmed
• Cancel: Invalidate reservation
• Timeout: Invalidate reservation

Try

POST /booking HTTP/1.1
Host: api.swiss.com

HTTP/1.1 201 Created
Location: /booking/{id}

Confirm

PUT /booking/{id} HTTP/1.1

HTTP/1.1 200 OK

Cancel

DELETE /booking/{id} HTTP/1.1

HTTP/1.1 200 OK

TCC Example

Failure before Confirm

Failure after Confirm

Failure during Confirm

Timeout during Confirm

Timeout?

GET /booking/{id} HTTP/1.1
Accept: application/vnd.atomikos.tcc+xml

HTTP/1.1 200 OK
Content-Type: application/vnd.atomikos.tcc+xml

<tcc>
<reserved url="/booking/{id}" timeout="24h"/>
</tcc>

After a Timeout

PUT /booking/{id} HTTP/1.1

HTTP/1.1 404 Not Found

Workflow

Try to reserve multiple resources

POST /telephone HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 201 Created
Location: /telephone/0586664302

POST /bill HTTP/1.1
Host: api.post.ch

HTTP/1.1 201 Created
Location: /bill/42

If everything is successful, confirm the bookings

PUT /telephone/0586664302 HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 200 OK

PUT /bill/42 HTTP/1.1
Host: api.post.ch

HTTP/1.1 200 OK

Workflow

Try to reserve multiple resources

POST /booking HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 201 Created
Location: /telephone/0586664302

POST /bill HTTP/1.1
Host: api.post.ch

HTTP/1.1 500 Internal Server Error

Incorrect billing address

If something fails, do nothing.
The reserved resources will eventually timeout.

If something fails, a polite workflow would explicitly cancel the successful reservations

DELETE /telephone/0586664302 HTTP/1.1
Host: api.swisscom.ch

HTTP/1.1 200 OK

Overview

Deployment

Deployment: Web Browser

Transactions as a Service

Comparison

Compensatable Workflow

Workflow models happy path + completion

The model is:

• Overly complex
• Hard to test
• Hard to maintain

TCC Workflow

• Push undo onto participant services
  • Services can cancel reserved states
  • Increased Autonomy
  • Decouples error handling from the (explicit) workflow
• Add a confirmation outcome too
• Delegate the coordination of completion to a coordinator service
  • Either confirm all participant services, or
  • Make sure all participant services cancel
  • "Stateful Utility Service"

Compensation vs. TCC

• Invoke: Buy
• Undo: Sell
• Try: Reserve
• Confirm: Pay
• Cancel: Release

TCC Benefits

• Business can focus on the happy path (try-phase)
• No combinatorial explosion of error path complexity
• Participating services have increased autonomy

Interop Risk

An interoperability risk exists if: two endpoints need to communicate, and both are outside your control

Minimize Interop Risk

• With TCC, you always control at least one end of each communication link
• There is no transaction context to ship
• There are no interceptors to configure
• Everything makes sense to the business
• “Real” SOA approach to transactions

Lower Coupling
Higher Autonomy

With TCC, participating services do not need to know the coordinator (unlike WS-*)

WS-*: Transaction Scope Risk

A service call can carry a transaction context, but still the service can ignore it!

WS-AT: DoS Risk

WS-AT is ACID, meaning locks

Conclusion: REST/TCC

• Distributed atomic transactions with guaranteed interoperability
• Applicable for reservation-style business models
• Design pattern, not a middleware
• Fits really well with REST design constraints
• We are looking for early adopters that need transactions in their SOA built with REST
  (or even SOAP)

Transactions for the REST of us

Cesare Pautasso, http://www.pautasso.info/
Guy Pardon, http://www.atomikos.com/