Concrete Logo
Hamburger button

A Concrete no QCon SP 2011 – parte 2

  • Blog
  • 23 de Setembro de 2011
Share

[fblike]

 

O conceito de transações com REST é um oximoro? O Roy Fielding disse que sim e quem somos nós para discordar.

Foi o Roy quem criou o estilo de arquitetura chamado de REST. E segundo ele mesmo no capítulo 5 da sua famosa tese de doutorado, os fatores que caracterizam um estilo de arquitetura são as restrições que limitam os papéis dos elementos componentes e os relacionamentos entre tais elementos.

Então, para uma arquitetura ser qualificada como “RESTful”, ela deve obedecer às restrições do criador deste estilo. Quais são mesmo as restrições? As básicas são:

  • – Identificação dos recursos
  • – Interface uniforme
  • – Mensagens auto descritivas
  • – Hipermídia comandando o estado
  • – Interações sem estado

E estaria errado um sistema que violasse algumas destas restrições?

É claro que não. O sistema poderia funcionar com toda a excelência. Só que sua arquitetura não deveria ser chamada de REST.

Na prática há um monte de sistemas em funcionamento violando um ou mais princípios que por uma questão de marketing ou por outro motivo qualquer, se auto denominam como RESTful.

Antes de seguir falando sobre transações vale uma lembrança importante:

Só que é impossível evitá-las em alguns casos, e precisamos encará-las.

Muitos especialistas defendem que o melhor modo é seguir os “padrões” WS-* e OASIS dos chamados Web services tradicionais. Só que os tais “padrões” sofrem de pelo menos 3 problemas sérios:

  1. – Não são padrões obrigatórios. Nem todos os ambientes de desenvolvimento adotam suas prescrições por completo.
  2. – Foram escritos como se fosse possível prever todos os casos e talvez seja este um dos motivos do problema abaixo.
  3. – Conduzem o sistema para uma solução complexa de construir sem auxílio de ferramentas e difícil de manter mesmo com uso das ferramentas usadas na construção

Deve haver alguma alternativa mais fácil e mais flexível de arquitetar.

Perguntas:

  1. – Se o próprio Roy não acredita que se possa construir um sistema para lidar com transações distribuídas dentro da arquitetura REST, porque então insistir nisto?
  2. – Se é possível desenvolver uma boa e simples solução de integração de sistemas sem precisar se valer da complexidade dos WS-* e WSDLs quase ilegíveis, porque se manter estritamente dentro das restrições do REST?

Considerando que muita gente conhece bem HTTP e que REST hoje em dia já é um estilo bem conhecido, seria vantajoso manter-se dentro das restrições para não precisar explicar porque relaxou isto ou aquilo.

Será que em todos os casos de integração de sistemas em que se precisa usar o conceito de transações distribuídas é possível se manter dentro das restrições do REST?

A resposta correta é não. Em alguns casos ainda não se percebeu como fazer.

Mas existem casos em que isto é perfeitamente possível tal como está na apresentação de Luca Bastos e Bruno Pereira no QCon SP 2011.

Foi mostrado um exemplo daqueles em que é possível fazer um acordo de negócio entre as partes envolvidas na integração. Só se exige que este acordo estipule o seguinte:

  • – Se o fornecedor do serviço não receber uma mensagem confirmando o pedido do objeto da transação dentro de um determinado limite de tempo, deverá cancelar tal pedido.
  • – Se quem solicita o serviço não receber resposta ao seu pedido de confirmação, deve supor que foi cancelado e enviar mensagem de cancelamento aos demais serviços envolvidos.

Nenhum estado trafega entre os participantes, ou seja, as interações não tem estado.

O acordo de negócio citado que todas as partes devem cumprir é o chamado protocolo Try-Cancel/Confirm. Sempre que for possível aplicar o modelo Try-Cancel/Confirm, não será necessário relaxar nenhuma das restrições do REST.

O modelo Try-Cancel/Confirm está descrito na figura abaixo:

 

Bem, a apresentação se propõe a mostrar um dos casos em que este protocolo permite um sistema que faz transações distribuídas e ainda se mantém dentro das restrições do estilo de arquitetura REST. Se alguém discordar, comentários são bem-vindos.

Os slides com pequenas alterações/inclusões aos que foram mostrados estão em

A apresentação foi filmada e quem tiver paciência de ir até o final poderá ver também as perguntas e respostas ao final.

 

Os links estudados em parte ou totalmente que serviram de base para esta apresentação serão listados no próximo blog sob o título A Concrete no QCon SP 2011 – parte 3