TEST

Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.


Atomic Distributed RESTful Transactions

Cesare Pautasso, University of Lugano, Switzerland
c.pautasso@ieee.org
@pautasso

Does REST need transactions?

Mike Amudsen

The Context

The Problem

Single state transfers from/to
the client are idempotent

How do we make both interactions atomic?

Constraints

Try-Confirm/Cancel

TCC Participant's view

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:

TCC Workflow

Compensation vs. TCC

TCC Benefits

Interop Risk

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

Minimize Interop Risk

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

Work in collaboration with Dr. Guy Pardon, http://www.atomikos.com

References


Atomic Distributed RESTful Transactions

Cesare Pautasso, University of Lugano, Switzerland
c.pautasso@ieee.org
@pautasso

Heuristics

A matter of timing

Agreement is reached if the confirmation phase ends before the resources undo the state transitions because of the timeouts

A matter of timing

If the confirmation runs longer than the earliest timeout, agreement cannot be guaranteed
(heuristic exception)

Use a spacebar or arrow keys to navigate