Neste artigo veremos alguns dos tópicos abordados no livro. Começaremos pela motivação para a existência de integrações, passaremos pelos principais aspectos a se considerar em integrações e posteriormente pelas principais abordagens de integração existentes – algumas delas estabelecidas por Martin Fowler. Por fim, veremos um comparativo entre as abordagens descritas. Comecemos então pela questão: Por que integrações são necessárias? A resposta é simples. Integrações são inevitáveis para prover uma experiência unificada e produtiva para funcionários da organização, parceiros e clientes.

Em um mundo ideal, pode se imaginar uma organização que tenha um sistema único e coeso, projetado desde o inicio para funcionar de forma unificada e coerente. Porém, a realidade que vemos é completamente diferente. Em uma empresa, mesmo que pequena, muito dificilmente existe apenas uma aplicação. E mesmo que se opte por desenvolver tal aplicação única, diversos seriam os desafios que acabariam por inviabilizar a estratégia.

E para se prover uma experiência unificada para funcionários, parceiros e clientes, devemos considerar que integrações podem ocorrer entre soluções estruturadas em plataformas distintas, separadas geograficamente dentro e fora do escopo da organização e que usam tecnologias distintas.

Neste contexto, o livro sugere que a escolha por uma abordagem de integração apropriada deva levar em consideração alguns aspectos. Vejamos:

• Formato de dado: Para se integrarem, aplicações devem concordar em um formato de dado. Considerando que alterar todas as aplicações da organização para considerar um formato de dado único pode ser inviável, tradutores intermediários podem ser empregados. Outro assunto relacionado é como a evolução do formato do dado ao longo do tempo pode impactar as aplicações dependentes.
• Seleção de tecnologia: Diferentes abordagens de integração requerem diferentes quantidades de licenças de software e hardware. Tais ferramentas podem ser caras, podem levar a dependência da organização com fornecedores específicos e ao aumento da curva de aprendizado dos desenvolvedores.
• Exposição de funcionalidades: Muitas abordagens de integrações permitem que aplicações compartilhem não apenas dados, mas também funcionalidades. Tal compartilhamento é interessante, pois gera um nível maior de abstração entre as aplicações envolvidas.
• Tempo para atualização: Integrações devem ser estruturadas pensando na minimização do tempo de defasagem de dado. Idealmente, aplicações consumidoras de dado deveriam ser informadas assim que o dado estivesse pronto para consumo. Quanto mais tempo se leva para o compartilhamento do dado, maior a probabilidade de falta de sincronismo de dados.
• Processamento assíncrono: A chamada de funcionalidades remotas de forma síncrona pode ser algo custoso para a aplicação consumidora. A capacidade de realizar tarefas assíncronas traz diversas vantagens como, por exemplo, escalabilidade. Porém, tal solução tem design, desenvolvimento e depuração mais complexos.
• Confiabilidade: Conexões remotas não são apenas lentas, mas também são muito menos confiáveis do que a execução de procedimentos locais. Aplicações remotas podem não estar disponíveis ou a rede pode estar temporariamente indisponível. Comunicações assíncronas e confiáveis permitem que a aplicação origem realize outras tarefas, de forma confiante que a aplicação destino receberá a informação.
• Acoplamento entre aplicações: Aplicações integradas devem minimizar as dependências entre si, de forma que cada uma possa evoluir sem causar problemas para as demais. Integrações devem ser específicas o suficiente para cumprir seu papel, porém, genéricas o suficiente para garantir que mudanças não façam com que as aplicações dependentes parem.
• Intrusividade: Integrações devem causar o mínimo de impacto em códigos existentes e devem requerer pouca codificação.
• Esforço de desenvolvimento*: Algumas soluções de integração podem endereçar bem os diversos fatores apresentados, porém, podem ser difíceis de se desenvolver, depurar e manter. Profissionais específicos podem ser necessários para monitorá-las e para gerenciar erros.
• Escalabilidade*: Integrações devem causar o mínimo de impacto na performance dos sistemas envolvidos. Também devem ser projetadas para suportar aumento no volume de dados trafegados e ainda pensando-se nos impactos decorrentes de acréscimo no número de sistemas consumidores de uma determinada informação.*Não constam no livro. Adicionados por mim por considera-los igualmente importantes com relação aos demais.

Segundo o livro Enterprise Integration Patterns, nenhuma abordagem de integração endereça todas estas características ao mesmo tempo de forma igualmente bem. Porém, determinadas abordagens de integração podem ser melhores do que outras em determinados cenários. Ainda segundo o livro, existem quatro principais categorias/ estilos de integração. Vejamos a seguir:

File Transfer (Martin Fowler): As aplicações produzem arquivos de dados compartilhados para outras aplicações consumirem.

Remote Procedure Invocation (Martin Fowler): As aplicações expõem algumas das suas operações de forma que elas possam ser invocadas remotamente. Outras aplicações invocam tais operações para realizar determinadas tarefas ou para compartilhar dados.

Shared Database (Martin Fowler): As aplicações gravam dados que se deseja compartilhar em um banco de dados de comum acesso.

Messaging: As aplicações se conectam a um sistema comum de mensageria, de forma a compartilhar dados e a invocar operações através do uso de mensagens.

Cada uma dessas abordagens possuem vantagens e desvantagens. A ideia não é usar sempre a mesma, mas ao invés, aquela que melhor se adeque a um cenário em particular.

Conforme podemos observar na tabela comparativa a seguir, elaborada com base no conteúdo do livro, as abordagens File Transfer e Shared Databasesão as que apresentam os problemas considerados como os mais graves. Ambas não possibilitam a exposição de funcionalidades, o que permitiria um nível considerável de desacoplamento entre aplicações. A abordagem File Transfer apresenta ainda questões relacionadas ao tempo de atualização de dados, o que pode gerar falta de sincronismo e, por consequência, falta de confiança nos dados apresentados.

Já o Shared Database, ao contrário do File Transfer, é bastante versátil quando se trata de sincronismo de informações, já que as aplicações compartilham um mesmo repositório de dados. Porém, tal abordagem pode não ser viável quando se adquire um pacote de mercado. Fornecedores de tais pacotes, em geral, se reservam o direito de evoluir a estrutura (schema) da sua base de dados em novas versões do seu produto. Outros problemas intrínsecos desta abordagem são o alto acoplamento gerado entre as aplicações que a adotam, uma vez que uma alteração em uma estrutura de dados pode afetar diversas aplicações de uma só vez, e escalabilidade, já que problemas de concorrência podem ocorrer à medida que o número de aplicações que atualizam com frequência uma mesma estrutura cresça. Bloqueios de registros podem fazer com que seleções de dados simples demorem mais do que o esperado. Atualizações massivas ou frequentes podem ainda causar impactos significativos na performance dos demais sistemas.

Apesar da abordagem Remote Procedure Invocation permitir exposição de funcionalidades (o que garante um bom nível de abstração entre as aplicações envolvidas), o acoplamento ainda é considerado alto neste tipo de abordagem, uma vez que a indisponibilidade da aplicação provedore ou que mudança em formatos de dados impactem diretamente as aplicações consumidoras. A abordagem também é considerada como pouco escalável, de forma semelhante a abordagem Shared Database, considerando que diversos consumidores dependeriam de um único recurso, neste caso a aplicação provedora, e que o aumento no número de consumidores impactaria diretamente tal aplicação provedora.

O livro ainda sugere que dentre as abordagens apresentadas, a Mensageria (Messaging) é a que teria mais vantagens e o que endereçaria melhor os aspectos apresentados anteriormente. E tal sugestão parece ser válida. Note que a abordagem Messaging é a que tem, de fato, mais aspectos positivos nos critérios avaliados.

A abordagem Messaging não requer que aplicações envolvidas sejam modificadas para suportar formatos de dados específicos. Tradutores intermediários podem ser usados para tal (Message Translator). Também permite que funcionalidades sejam executadas quando do recebimento de mensagens (exposição de funcionalidades). Já com relação ao tempo de processamento, padrões de integração near real-time e real-time podem ser usados nesta abordagem. E padrões near real-time logo remetem a processamento assíncrono, que somado a padrões que permitem a garantia de entrega de mensagens (Guaranteed Delivery), vem a garantir maior confiabilidade da integração.

Acoplamento e Intrusividade também são itens com mais aspectos positivos nesta abordagem, quando comparado com as demais. Pela fato de empregar um sistema intermediário entre provedor e consumidor de dado, um não é necessariamente diretamente afetado por modificações no outro. A abordagem ainda é considerada pouco intrusiva, já que o código da aplicação não precisa ser afetado pelo código da integração. E uma vez que haja tal separação e que abordagens assíncronas sejam usadas, a abordagem é considerada altamente escalável, já que o processamento de um grande volume de mensagens pode ocorrer no ritmo que a aplicação suporta e não no ritmo que as demais aplicações impõem.

Seus principais problemas não são tão relevantes quando comparados com os das demais abordagens. A seleção de tecnologia, por exemplo, é considerada como negativa para esta abordagem, dada a dependência tecnológica que se adquire com sistemas de mensageria específicos. O esforço de desenvolvimento também é maior quando comparado com as demais abordagens, dada a complexidade intrínseca do desenvolvimento assíncrono e a necessidade de aquisição de conhecimento especializado.

 

Artigo publicado originalmente em http://nelsonbassetto.com/blog/2013/02/enterprise-integration-patterns/