Introdução à Abordagens para Integrações entre Sistemas

Pretendo iniciar uma pequena série de posts sobre Arquitetura de Integrações com foco na abordagem da Arquitetura Orientada a Eventos, conhecida como EDA em inglês (Event Driven Architecture).

Pela minha experiência profissional (que é 95% Microsoft), notei que é uma arquitetura pouquíssimo conhecida. E é legal notar que quando a explico ou até mesmo monto algum protótipo dela, as pessoas gostam. Os projetos em que pude usá-la foram bem sucedidos, e a curva de aprendizado dos desenvolvedores que a implementaram foi pequena -- ela é uma arquitetura relativamente simples.

Se você não faz a menor ideia sobre o que estou falando, essa arquitetura tem tudo a ver com sistemas de mensageria ou message queuing systems (já ouviu falar sobre MSMQ - Microsoft Message Queuing?). Outros termos relacionados comumente usados são enfileiramento, filas, canais, etc.

Antes de mergulhar no assunto, gostaria de dar uma breve introdução aos tipos mais comuns de integração entre sistemas.

Transferência de Arquivos

Uma aplicação coloca um arquivo em determinado local (conhecido entre as aplicações participantes) para que outra aplicação use-o (leia, escreva). A transferência de arquivo promove um bom desacoplamento e é relativamente fácil entrar num acordo sobre um formato (geralmente em texto puro). Os problemas começam quando questões sobre quem e quando deve-se apagar o arquivo, por exemplo. Outra desavantagem é que essa arquitetura geralmente é usada apenas para processamento em lote. Seria difícil fazer uma integração do tipo requisição/resposta nesse formato (request/reply). Por exemplo: liste todos os usuários do departamento de marketing.

Banco de Dados Compartilhado

É difícil encontrar alguém que nunca tenha feito isso. Eu julgo que o pior é adaptar (ou até mesmo modelar) um schema para mais de uma aplicação. Um atributo em uma aplicação é do tipo numérico, mas no outro é um texto; os campos sempre sobram para alguém; etc. e por exemplo. Um ponto muito negativo nessa abordagem é o acoplamento temporal -- se o banco cai, o acesso é interrompido.

Chamada Remota de Procedimento (RPC)

Chique o nome, não? Honestamente, eu acho a pior de todas. O acoplamento é tremendo, mudanças nos contratos são caóticas e cria-se uma rede de dependências muito complexa. A performance é um fator muito crítico aqui também. Acredito que a palavra que melhor descreve essa abordagem é arcaica.

Web Services

Essa abordagem é a "É difícil encontrar alguém que nunca tenha feito isso - versão II". Eu acho que é um dos padrões mais usados hoje em dia para integração entre aplicações. É uma abordagem que já está bastante madura e tem uma interoperabilidade ótima, ou seja, qualquer linguagem de programação hoje tem suporte à troca de mensagens no formato SOAP (que é estruturado em XML). Contudo, eu acho que ela sofre da síndrome da confusão entre conceito e técnica quando o assunto é Barramento de Serviços. Já testemunhei muita gente falando que "esse é meu Barramento de Serviços" (ou Service Bus), quando na verdade era um monte de Web Services (ou até mesmo serviços WCF). Mas isso é um outro assunto e muito extenso porque entra governança, diretórios de serviços, etc.

Voltando às vantagens e desavantagens dessa abordagem. Web services sofrem um pouco das mesmas desavantagens de um banco de dados compartilhado -- acoplamento temporal. Se o serviço cai, ninguém usa. Outro ponto (com defensores e ofensores) é a sincronicidade: web services são síncronos por natureza. O tempo de resposta da sua aplicação consumindo um web service vai depender do tempo de resposta da aplicação a qual está fazendo a requisição.

Mensageria

É a minha abordagem preferida para a maioria dos cenários de integração entre sistemas. É relativamente fácil, promove um bom desacoplamento (principalmente temporal), é bastante tolerante à falhas, e é a menos dolorosa e mais barata (sem contar com as soluções comerciais que são caríssimas -- TIBCO, por exemplo) para escalar porque a escalamos horizontalmente muito facilmente (pretendo falar mais sobre isso em posts futuros). Ela tem também as vantagens e desavantagens da assincronicidade.

Aí está um resumo bem enxuto das abordagens mais conhecidas para integrações de sistemas.

Se você se interessou por esse assunto ou quer se aprofundar mais, eu recomendo fortemente o livro Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Gregor Hohpe e Bobby Woolf). Apesar de ser um livro de 2003, ainda é uma referência no assunto de integrações usando sistemas de mensagens com muitos exemplos em Java e C#.