Transações compensatórias usando REST - QCon SP 2011

Transações compensatórias �� usando REST

Bruno Pereira [email protected] Luca Bastos [email protected]

Qcon São Paulo/2011

Outro Título

É possível pensar em transações

usando REST?

Outro Título

Transação com REST é um oximoro(*)?

(*) Segundo a wikipedia, figura de linguagem que harmoniza dois conceitos opostos numa só expressão, formando assim um terceiro conceito que dependerá da interpretação do leitor.

Life is a distributed object system.

However, communicaGon among humans is a distributed hypermedia system, where the mind's intellect, voice+gestures, eyes+ears, and imaginaGon are all components.

Roy T. Fielding, 1998.

Bruno Pereira:

Gerente de operações e pré-‐venda na Concrete SoluGons, atual responsável pelo escritório de SP.

Trabalhou em grandes projetos na Globo.com, Globosat, Alcoa, White MarGns e outros. Engenheiro eletrônico e de computação na UFRJ.

Experiência em muitos projetos web, com experGse no server-‐side e client-‐side.

Um dos pioneiros na adoção de REST no Brasil.

Luca Bastos:

Desenvolvedor do tempo da Carochinha. Se mantém na aGva por pura paixão.

Ávido leitor sendo o hábito da leitura um dos seus 3 principais prazeres na vida.

Segue como esforçado e curioso aprendiz na árdua, porém gostosa tentaGva de se manter atualizado.

Hoje exerço minha paixão na Concrete SoluGons

Onde trabalhamos: �� http://www.concretesolutions.com.br/

A Concrete tem mais de10 anos com variado portfólio de clientes no Brasil e no exterior. No início as maiores ��demandas do mercado eram soluções para integração. ��

Atualmente a diversificação é bem grande tantos nos projetos como nas tecnologias e nas linguagens utilizadas. ��

Temos projetos nas áreas de cloud, mobile e web. ��

Muitos são como alguns de São Paulo para lean startups.

Resumo sobre transações desde as primeiras

Resumo sobre transações desde as primeiras

Inventadas pelos Sumérios

Sumérios viveram na Babilônia entre 5000 e 3000 anos a.C.

Exemplo de uma compra no mercado�� lá na Suméria

A transação era registrada (persistida)

em placas de barro

Existem transações muito mais complexas

E a modelagem delas vem sendo estudada��há muito tempo

Alguns modelos de transações

Nested transactions (transações aninhadas) ��

Conjunto de subtransações que podem ��recursivamente conter outras subtransações��formando uma árvore.

Sagas��

Conjunto de subtransações ACID com uma ��ordem predefinida de execução e incluindo��subtransações que compensam casos de��falha.

Long running transactions ou Long running ��work (transações de longa duração) ��

Levam algum tempo (de frações de segundos��a meses) para terminar

O caso da reserva de vários recursos em��conjunto

A

B

C

D

E

F

Assurbanipal vai ��alugar carros em ��outras cidades

REST, um estilo de arquitetura

Segundo Roy Fielding, ��

estilo de arquitetura é um conjunto ��coordenado de restrições arquiteturais ��



que limitam os papéis e habilidades dos ��elementos arquiteturais e os relacionamentos ��permitidos dentre eles, ��



que limitam os papéis e habilidades dos ��elementos arquiteturais e os relacionamentos ��permitidos dentre eles, ��

dentro de qualquer arquitetura que esteja em��conformidade com tal estilo.

De forma simplista, ��

podemos dizer que REST ��

é um conjunto de restrições ��

ao projeto de um sistema hipermídia.

Restrições básicas do estilo de arquitetura ��REST: ��

1.  Identificação dos recursos 2.  Interface uniforme 3.  Mensagens auto descritivas 4.  Hipermídia comandando o estado 5.  Interações sem estado

É possível projetar uma arquitetura

com transações distribuídas

dentro das restrições do REST?

É possível projetar uma arquitetura

com transações distribuídas

dentro das restrições do REST?

Ou precisamos relaxar algumas das restrições��do Roy Fielding?

Vamos demonstrar como fazer transações ��dentro das restrições da arquitetura REST��usando um caso prático: ��

Reserva de passagens aéreas

Agência

Problema de uma agência de viagens:

Reservar passagens em 2 trechos independentes ligando vôos de 2 empresas aéreas

A

B

Agência

Problema de uma agência de viagens:

Reservar passagens em 2 trechos independentes ligando vôos de 2 empresas aéreas sem ônus se uma delas falhar

A

B

Vamos ver como seria usar REST em um caso deste

Simplificação:

Supomos que as 2 empresas aéreas usam o mesmo contrato de hipermídia para reservas

<div class="reserva pendente"> <div class="voo"> <span class="numero">1520</span> <span class="companhia">Verde</span> <span class="origem">SAO PAULO</span> <span class="desGno">BRASILIA</span> <span class="saida">01/10/2011 10:00</span> <span class="chegada">01/10/2011 11:40</span> </div> </div>

Microformato que poderia ser usado

XML Tradicional com dados relevantes

<reserva> <voo numero="1520" companhia="Verde" origem="SAO PAULO" desGno="BRASILIA" saida="01/10/2011 10:00" chegada="01/10/2011 11:40” > </voo> </reserva>

URI para checar disponibilidade de um vôo: /voo/{voo-‐num}/

A resposta de uma requisição GET a.com/voo/1001/

poderá ser um hyperlink para a idenGficação do recurso vôo ou nada se o vôo está lotado (204 sem conteúdo)

Dados de um Vôo

<voo id="123456789" numero="1520" companhia="Verde" origem="SAO PAULO" desGno="BRASILIA" saida="01/10/2011 10:00" chegada="01/10/2011 11:40” > </voo>

Reserva de um determinado vôo:

O request POST /reserva



incluindo no conteúdo do POST a referência ao vôo: <voo numero=“xpto” />




cria um novo recurso reserva com seu id devolvendo um header locaGon com o caminho do recurso /reserva/{id}/




cria um novo recurso reserva com seu id devolvendo um header locaGon com o caminho do recurso /reserva/{id}/

A reserva pode ser atualizada usando PUT /reserva/{id}/

<reserva id=“123456”> <voo numero="1520" companhia="Verde" origem="SAO PAULO" desGno="BRASILIA" saida="01/10/2011 10:00" chegada="01/10/2011 11:40” > </voo> <link rel=“update” href=“/reserva/123456” /> </reserva>

A reserva pode ser atualizada usando PUT /reserva/{id}/

Composição das reservas:

História 1

Como cliente, quero reservar vôos em 2 trechos independentes ligando vôos de 2 empresas aéreas.

É responsabilidade da agência compor os serviços.

Sem pensar em transação, poderia ser assim:

1. GET a.com/voo/1001/ 2. GET b.com/voo/2002/ 3. POST a.com/reserva 4. POST b.com/reserva



E se a segunda empresa diz que não tem lugar no vôo?



E se a segunda empresa diz que não tem lugar no vôo?

A solução pode ser fazer com que os passos das reservas 3 e 4 sejam tentaGvas que podem ser confirmadas depois.

Disclaimer:

Quase tudo mostrado aqui se baseia no capítulo 23 do livro REST: From Research to PracGce

Towards Distributed Atomic TransacGons over RESTful Services de Guy Pardon (Atomikos) e Cesare Pautasso

O Gpo de solução proposta serve a aplicações distribuídas que precisam de atomicidade.


Se baseia no conceito TCC, Try-‐Cancel/Confirm do Guy Pardon, que tem semelhança com as práGcas de aplicações financeiras que usam transações compensatórias.



É adequado aos cenários que envolvem reserva de recursos.



É adequado aos cenários que envolvem reserva de recursos.

O recurso no estado de reservado aparece para todos e isto evita dupla reserva.

Confirmação das reservas:

História 2

Como cliente, quero ser capaz de confirmar as reservas no fim de tudo e que as reservas não confirmadas não sejam cobradas.

O Serviço REST da empresa aérea retorna um hyperlink de confirmação.

Exemplo: GET /reserva/{id}

recebe como resposta <reserva id={id}> <link rel=“confirma” href=”/reserva/{id}/pagamento”> </reserva>

O pagamento pode ser confirmado com: PUT /reserva/{id}/pagamento contendo <VISA ... >

Workflow do caminho feliz

GET a.com/voo/1001/ 200 POST a.com/reserva 201 (locaGon /reserva/A ) GET b.com/voo/2002/ 200 POST b.com/reserva 201 (locaGon /reserva/B ) GET a.com/reserva/A 200 (link para confirmar: /reserva/{id}/pagamento/ ) GET b.com/reserva/B 200 (link para confirmar: /reserva/{id}/pagamento/ )

Confirmações usando o hyperlink de pagamento recebido:

<reserva id> <link rel=“confirma” href=“/reserva/{id}/pagamento/”> </reserva>

PUT a.com/reserva/{id}/pagamento/ 200 PUT b.com/reserva/{id}/pagamento/ 200

Lembram dos passos


Mas e se o passo 4 que é a segunda reserva falhar?

Lembram dos passos


Cancelamento das reservas:

História 3

Como empresa aérea não quero esperar indefinidamente por uma confirmação. Quero cancelar uma reserva pendente após um certo período de tempo (Gmeout).

A empresa aérea ao receber

POST /reserva/

Retorna

<reserva id={id}> <link rel=“confirma” href=“/reserva/{id}/pagamento/”

limite=“24h”> </reserva>

Conceito Try-‐Cancel/Confirm

Confirm Try Estado inicial

Estado final

Estado reservado

Reserva de um vôo

Confirm Try

Cancel

Estado inicial

Estado final

Estado reservado

Reserva de um vôo com cancelamento

Confirm Try

Timeout

Cancel

Estado inicial

Estado final

Estado reservado

Reserva de um vôo com cancelamento e Gmeout

No protocolo Try-‐Cancel/Confirm, cada request é “tentado” e permanece como tentaGva no estado reservado até que seja confirmado ou cancelado.

Timeout

Exemplo:

Reserva de vôo com modelo Try-‐Cancel/Confirm

POST /reserva

PUT /pagamento/X

DELETE /reserva/{id}

Estado reservado

Conceituando transações REST

Recursos publicados por Web services RESTful devem ser enGdades independentes.



Segundo Pautasso e Wilde, uma solução de transação para REST é desacoplada se os serviços parGcipantes não tem consciência de que são parte de uma transação.



Segundo Pautasso e Wilde, uma solução de transação para REST é desacoplada se os serviços parGcipantes não tem consciência de que são parte de uma transação.

Não são todos os serviços RESTful capazes de parGcipar em transações assim.

Protocolos da solução proposta

Definição de T, R e S:

T é uma transação baseada em REST composta de requests Ri para serviços Si que devem ser confirmados ou cancelados juntos.




Exemplo: T é a transação de reserva dos vôos, R reserva de um vôo e S é o serviço acessado.





Os Ri bem sucedidos tem confirmação explicita Ri,confirma (via pagamento da reserva)





Os Ri bem sucedidos tem confirmação explicita Ri,confirma (via pagamento da reserva) e todos os Ri não confirmados são cancelados.

Importante:

O uso do protocolo Try-‐Cancel/Confirm é a única exigência que se faz aos prestadores dos serviços para esta solução funcionar.

Através de um acordo de negócios, é preciso garanJr que caso o prestador do serviço (neste caso uma empresa aérea) NÃO receba a confirmação dentro do Gmeout (PUT do pagamento), DEVE cancelar a transação.

Caso a agência não receba resposta do PUT de uma empresa aérea, cancelará as reservas feitas com sucesso nas outras.

Arquitetura para o caminho feliz

1. Um workflow transacional T envia requests a disGntas APIs de Web services RESTful Si.

2. Requests Ri podem acarretar mudanças de estado em algum serviço Si idenGficado por alguma URI.

Cliente Motor Workflow 0 1

1 2

2

Try

Try




3. Com o workflow bem sucedido, as URIs de confirmação e mais os conteúdos são passados ao coordenador.

Cliente Motor Workflow

Coordenador de transações

3

0 1

1 2

2

Try

Try Confirm




3. Com o workflow bem sucedido, as URIs de confirmação e mais os conteúdos são passados ao coordenador.

4. O coordenador chama todos os Ri,confirma com um PUT idempotente às URIs passadas e inclui os conteúdos



3

0

4

1

1 2

2

4

Try

Try

Confirm

Confirm

Confirm



3

5

0

6

4

1

1 2

2

4

Try

Try

Confirm

Confirm

Confirm

Protocolo de recuperação em caso de falha

Recuperação precisa ocorrer quando: 1) Falha de nó 2) Timeout



Um serviço Si só reage se a falha ocorre entre os passos de reserva e de confirmação (2 e 4). Neste caso executa Ri,cancela automaGcamente.



Um serviço Si só reage se a falha ocorre entre os passos de reserva e de confirmação (2 e 4). Neste caso executa Ri,cancela automaGcamente.

O coordenador só reage durante o passo das confirmações (passo 4. Se falta resposta de um Si, tenta de novo Ri,confirma. Ri,confirma usa métodos idempotentes e pode tentar muitas vezes.


Importante:

É preciso um log no coordenador começando antes do passo 4 das confirmações.

Caso de exceção

No passo 4 de confirmações, algum serviço Si pode cancelar por Gmeout enquanto o coordenador segue tentando confirmar.

Sem adotar nenhuma aGtude, isto quebraria a atomicidade.

Caso de exceção

No passo 4 de confirmações, algum serviço Si pode cancelar por Gmeout enquanto o coordenador segue tentando confirmar.

Sem adotar nenhuma aGtude, isto quebraria a atomicidade.

Perfeição NÃO existe. O mesmo pode acontecer com as transações clássicas no esGlo XA, 2PC ou usando WS-‐*.

Esta é uma limitação que devemos conviver.

HeurísGca de exceção

Quando um parGcipante completa Ri, pode ser considerado em dúvida. Seu estado já persisGu e só falta a confirmação pendente Ri,confirma. Se opta por Gmeout, a transação T deve ter uma heurísGca de rollback (desfazimento).



O modo de lidar com isto é simplesmente o coordenador ter um log para perceber que suas tentaGvas de confirmação estão sem resposta.



O modo de lidar com isto é simplesmente o coordenador ter um log para perceber que suas tentaGvas de confirmação estão sem resposta.

E quando isto acontecer soltar um alerta para que uma ação manual da operação do sistema possa desfazer as confirmações órfãs já respondidas.

OGmizações possíveis

1. Incluir na respostas dos serviços um link para cancelamento. Vantagem: evitar que o coordenador tenha que esperar o Gmeout para liberar o recurso.



2. PermiGr ao coordenador gerenciar o tempo de Gmeout e assim nem começar as tentaGvas de confirmação perto do fim.




3. O coordenador ter um diálogo com os serviços para os casos de exceção.




3. O coordenador ter um diálogo com os serviços para os casos de exceção.

4. Enfraquecer premissas do padrão TCC em casos especiais (ex. GET read only)

O que vimos:

Uma solução leve e atômica para transações via REST, baseada na aplicação do modelo Try-‐Cancel/Confirm ao projeto de um sistema usando Web services RESTful.

O que vimos:


Um exemplo de um protocolo simples que consegue atomicidade e desacoplamento entre recursos distribuídos se eles forem compa�veis com o padrão Try-‐Cancel/Confirm.

O que vimos:



Que seu uso garante atomicidade e consistência no caso de falhas com as mesmas limitações das soluções clássicas.

O que vimos:



Que seu uso garante atomicidade e consistência no caso de falhas com as mesmas limitações das soluções clássicas.

Que pode ser usado em todos os ambientes de desenvolvimento e por qualquer linguagem de programação.

Agradecimentos:

Jim Gray, Hector G. Molina, Rafael Alonso, Kenneth Selem, Pat Helland, Henry Korth, Eliezer Levy, Abraham Silbershatz, Jim Webber, Savas ParatasGdis, Ian Robinson, Sam Ruby, Leonard Richarson, Guilherme Silveira, Paulo Silveira, Subbu Allamaraju, Mark Li�le, Boris Lublinski, Mercy Njima, Thomas Strandenaes, Randi Karlsen, Robert Grossman, Kotagiri Ramamohanarao, James Bailey, Paolo Buse�a, Eric Newcomer, Philip Bernstein, Andreas Reuter, Stefan Tilkov, Erik Wilde, Guy Pardon e Cesare Pautasso que foram fontes do conhecimento aqui comparGlhado.

Agradecimentos:

Jim Gray, Hector G. Molina, Rafael Alonso, Kenneth Selem, Pat Helland, Henry Korth, Eliezer Levy, Abraham Silbershatz, Jim Webber, Savas ParatasGdis, Ian Robinson, Sam Ruby, Leonard Richarson, Guilherme Silveira, Paulo Silveira, Subbu Allamaraju, Mark Li�le, Boris Lublinski, Mercy Njima, Thomas Strandenaes, Randi Karlsen, Robert Grossman, Kotagiri Ramamohanarao, James Bailey, Paolo Buse�a, Eric Newcomer, Philip Bernstein, Andreas Reuter, Stefan Tilkov, Erik Wilde, Guy Pardon e Cesare Pautasso que foram fontes do conhecimento aqui comparGlhado.

E uma homenagem especial ao Roy Fielding, porque sem ele a Web seria outra ou nem seria.

Obrigado Qcon SP 2011

Perguntas?

@blpsilva (visite o blog) @lucabastos

Thanks Roy REST rocks

Transações compensatórias usando REST - QCon SP 2011

Technology

Transcript of Transações compensatórias usando REST - QCon SP 2011