Padarias e Transações

Todo domingo vou com a minha esposa tomar café da manhã em uma padaria perto de casa. Normalmente, depois do café, minha esposa aproveita para levar coisas para o lanche da tarde como pão, queijo, etc. Um dia, a fornada de pães demorou para sair e não havia aquele que gostamos. Claro que, como de costume, tomamos o nosso café assim mesmo. Não faria sentido não tomarmos o café da manhã, só porque a padaria estava atrasada com os seus produtos.

Mais tarde retornei para comprar o nosso pão favorito. No caminho, pensei que, da mesma forma, se caso a máquina de expresso tivesse algum problema pela manhã, e que se a fornada de pães tivesse saído na hora, muito provavelmente, teríamos comprado e pão e resolvido o nosso café da manhã em outro lugar.

As operações de "compra de pão" e "tomar café da manhã" não possuem um relacionamento rígido. É assim que a maioria esmagadora de atividades humanas se comporta: são fracamente acopladas umas às outras.

É assim também em SOA. As operações realizadas em um sistemas são, ou devem ser, fracamente acopladas entre si. Esse é uma dos principais características ou objetivos de uma Arquitetura Orientada a Serviços. Mais do que desejável, este nível de acoplamente baixo deve ser perseguido. Contudo, infelizmente, nem sempre é assim...

É muito comum o requerimento de "Transação" quando o assunto é SOA. Talvez até mais comum ainda em BPM. É muito comum ainda o termo "Transação" ser usado como sinônimo de "Atomicidade" de operações distribuídas. Aquele "tudo-ou-nada" normalmente implementado por Gerenciadores de Bancos de Dados. "Rollbacks" mágicos desfazendo operações previamente realizadas.

Vários entendimentos equivocados acontecem neste tema. O primeiro é usar "Transação" como sinônimo de "Atomicidade". Na verdade, esta característica é uma das diversas que uma Transação pode ter. "Atomicidade" é simplesmente o "A" do conhecido Modelo Transacional ACID:

• A - Atomicidade ("Atomicity")
• C - Consistência ("Consistency")
• I - Isolamento ("Isolation")
• D - Durabilidade ("Durability")

O Modelo ACID foi amplamente discutido e formalizado por Jim Gray e Andreas Reuter no clássico livro "Transaction Processing: Concepts and Techniques".

Eu havia dito que Atomicidade é uma das características que uma Transação pode ter. Pode ter. E não, deve ter. Uma Transação sem Atomicidade ainda é uma Transação.

Eu diria que, em um mundo real, a definição de transações distribuídas com Atomicidade, na grande maioria dos casos, não é desejável. É uma má idéia. SOA encaixa-se em uma situação como essa. Em termos de aplicações, Atomicidade promove um nível de acoplamento alto que, por definição, é ruim e deve ser evitado.

O engano, talvez, tenha vindo do uso de Atomicidade em Transações de um Gerenciador de Bancos de Dados. Como temos esse recurso nativamente oferecido pelo produto, também deveriam usá-lo em outros níveis de abstração. Como por exemplo, SOA. Mais uma vez, um grande engano. Transações com Atomicidade são razoáveis e necessárias para Bancos de Dados. Não são razoáveis para aplicações. São níveis de abstração diferentes e, por conta disso, não possuem requerimentos iguais.

Um dos modelos ou padrões de desenho usados quando estamos lidando com aplicações (e SOA é um exemplo disso) é aquele baseado em "Ações de Compensação". Isto é, se algo sai errado com uma operação, aplicamos outras operações que funcionalmente compensam aquelas que tiveram sucesso. As operações de compensação fariam com que aquelas sem erro voltassem ao seu estado original. O modelo Saga descrito por Hector Garcia-Molina, professor de Stanford, autor de "Database System Implementation" foi uma das primeiras formalizações disso.

Outra questão importante: vamos supor que haja uma situação onde uma transação distribuída com Atomicidade seja requerida. Em SOA, ela, talvez, não seja passível de implementação. Ou, se preferir, o custo de implementação seria proibitivo. Por exemplo: suponha que um Serviço tenha como responsabilidade operações em dois legados: Siebel (CRM) e SAP (ERP). A operação do Siebel ocorre sem problemas, mas, por qualquer razão, a operação com o SAP não consegue ser concluída. Em um Transação com Atomicidade, a operação do Siebel seria "desfeita" e voltaríamos à situação original. Contudo, o Siebel não possui capacidades para tornar-se uma unidade de execução de uma transação distribuída. Ele simplesmente não entende comandos como "rollback" ou "desfaça tal operação". O mesmo ocorre para o SAP e na grande maioria das aplicações caseiras e pacotes de mercado. Isto não é exatamente um problema, pois, como disse anteriormente, uma Transação com Atomicidade entre Siebel e SAP não seria desejável.