Saga over REST for microservices

Ondra Chaloupka / ochaloup@redhat.com

wfly narayana

narayana logo

earlier Arjuna, renamed to Narayana
JTA implementation in JBoss/WildFly
JTS distributed transaction over IIOP
webservice transactions (WS-AT/WS-BA)
STM for Vert.x
saga transactions over REST

Agenda

What is meant under term microservice in scope of this presentation
How the the distributed transactions and 2PC works
What is saga and why could be good fit for microservice architecture
What are and how to use Narayana Long Running Actions

Microservice architecture

posta msa

(credit: Christian Posta, http://blog.christianposta.com)

Distributed transactions

posta msa with wfly

An ACID transaction

An atomic unit of the work where everything or nothing is finished
- usually in regards of data manipulation
Protecting shared resources from multiple users
A notion of a global consensus
ACID properties guaranteed

test tubes

Atomicity
Consistency
Isolation
Durability

Distributed vs. XA transaction

distributed transaction runs over multiple services
XA transaction joins operations over multiple resources

XA handling

xa handling

XA transaction: 2PC

2pc

Demo

posta msa with wfly xa

ACID distributed transactions: assuming

closely coupled environment
- harder to scale
- tight data coupling
short duration
- locking reduces parallelism

Microservice architecture: expecting

loosely coupling
scaling
long duration activities

Sagas

Transactional model for long living transaction
Saga paper (H. Garcia-Molina, K. Salem; 1987)
Relaxing ACID properties
Eventual consistent
Web services: WS-BA specification, SOA design pattern
REST and event sourcing: microservices

Sagas (#2)

saga confirm

consists of a sequence of autonomous operations, each immediatelly visible to outer world
responsibility of failures handling to developer (handlers)
transaction manager is responsible for calling handlers

Sagas (#3)

saga compensate

compensation handler defined by developer, called by transaction manager

Saga transaction

saga

The concept of the original paper talks about single node database but it could be applied to distributed transactions (as was already shown).

Saga could be classified as Base transaction (at least from my understanding) as it does not lock resources a.k.a locks and letting data of resources being available for other transactions to work with.

As you could see the transaction handling introduced by Saga requires the application to define compensation actions or define actions as idempotent (you can repeat operation on the resource multiple times and you will get the same result - operation being repeated not leading to a different outcome).

Still you can handle all the data integrity yourself in your application and design your system architecture to handle with failures. It’s up to you if concept of Saga is useful for you or not.

https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf (Sagas, Priceton University, 1987)
http://queue.acm.org/detail.cfm?id=1394128 (Base: An Acid Alternative, base transactions)
https://www.atomikos.com/Blog/ACAPSolutionProvingBrewerWrong (A CAP Solution (Proving Brewer Wrong) aka CQRS)

Narayana and Sagas

XTS: WS-BA (Web Services Business Activity)
Compensating transactions (CDI annotations)
LRA (Long Running Actions, over REST)

Narayana LRA

LRA: Long Running Actions
Saga implementation for REST calls
based on the Eclipse MicroProfile stack (JAX-RS, CDI)

microprofile

Java EE stack for microservices
LRA specification proposal, https://github.com/jbosstm/microprofile-sandbox
Microprofile Google group, http://bit.ly/transactions-microprofile

Demo

msa calls

Summary

Narayana LRA - implementation of Saga for REST calls
a better fit for MSA than ACID transactions
a tool that can help in desiging the application
- MSA principles should be preserved

Sources

cajk