Integrações assíncronas com mensagens

Um sistema é construído para um determinado fim. Em um modelo de negócios no qual é necessário automatizar ou controlar diferentes necessidades, é natural a utilização de diferentes sistemas, que, por questões variadas, podem também pertencer a fornecedores diferentes. Por isto a instalação de um novo sistema, e principalmente a substituição de um sistema já existente por um novo, muitas vezes requer também o desenvolvimento de uma ou mais integrações entre o novo sistema e os sistemas já existentes no ambiente.

A MATERA tem vivido esta situação com frequência, e dentre as possíveis abordagens para desenhar integrações entre sistemas uma que tem ganhado força nas nossas soluções é a construção de integrações assíncronas com uso de mensagens. Esta abordagem utiliza um middleware de mensagens (também chamado de message broker) que se situa entre as duas ou mais aplicações, tal que quando uma aplicação origem necessita se comunicar com uma aplicação destino (seja para invocar uma funcionalidade, fazer uma consulta ou transmitir um dado ou notificação), a aplicação origem posta uma mensagem no middleware, onde a mensagem reside até que seja retirada pela(s) aplicação(ões) destino. Se as aplicações residem em máquinas diferentes, tipicamente o middleware é instalado em ambas as máquinas.

Ao mesmo tempo que permite uma comunicação mais rápida do que aquela obtida através de integrações baseadas em trocas de arquivo, esta solução não introduz a fragilidade que se enfrenta quando a aplicação origem invoca diretamente a aplicação destino, como em chamadas RPC, invocação direta de APIs ou mesmo em web services.

Dentre as vantagens oferecidas destacam-se:

Robustez

Diminuição dos pontos de falha:

  • de máquina – se a máquina da aplicação destino não estiver operacional, isto não causa uma falha na aplicação origem. Um reboot para recuperação de um crash ou mesmo um reboot de manutenção não causam qualquer efeito na aplicação origem, pois o middleware de mensagens trata de entregar a mensagem assim que a máquina destino volta a ficar operacional.
  • de aplicação – se a máquina estiver operacional mas a aplicação destino não (imagine por exemplo que o banco de dados da aplicação destino está fora do ar ou que o web container da aplicação precisou ser reinicializado) isto também não causa um erro, pois as mensagens permanecerão no middleware até que a aplicação destino possa solicitá-las.
  • de rede – instabilidades de rede, que são ainda mais relevantes em soluções globais, não impedem a integração já que o middleware geralmente possui a feature de “garantia de entrega” na qual tenta entregar a mensagem até conseguir.

Throughput

  • send and forget” – diferentemente da abordagem de invocação direta, a thread de execução das aplicações origem não fica bloqueada em uma chamada às aplicações destino esperando que estas concluam o processamento da requisição. Uma aplicação não espera pela outra. Isto evita espalhar entre as aplicações eventuais problemas de performance que uma das aplicações venha a apresentar.
  • sobrecarga – aplicações destino nunca são sobrecarregadas em caso de um pico de múltiplas requisições das aplicações origem, pois as aplicações destino retiram mensagens do middleware na taxa com a qual conseguem processá-las.

Desacoplamento

  • de tecnologia – uma vez que uma aplicação é tornada apta a se integrar através de mensagens, ela é capaz de se integrar com todas as outras aplicações do ambiente que também utilizam o sistema de mensagens, independentemente da tecnologia ou plataforma utilizada por estas aplicações.
  • da localização do sistema destino – para a aplicação origem é transparente onde se encontra na rede o destino da mensagem. Isto é configurável no middleware de mensagens e para o desenvolvimento da integração não importa se o destino será um sistema local ou remoto.
  • troca de sistemas – se além do uso de uma solução baseada em mensagens o layout destas mensagens for bem desenhado com o objetivo de criar um formato canônico (no qual o layout de uma mensagem ataca as necessidades do problema sendo resolvido e não considera especificidades dos sistemas sendo utilizados), a troca de um sistema não afeta o sistema da outra ponta pois a integração permanece a mesma, independentemente da tecnologia e características do novo sistema.

Apesar de suas várias vantagens o uso de mensagens também introduz novos desafios e dificuldades:

  • modelo de programação – o uso de integrações assíncronas requer que os sistemas sejam desenhados com um modelo de programação baseado em eventos, o qual pode ser um pouco mais complexo de codificar.
  • ciclo de vida – para aplicações que necessitam esperar por uma resposta em relação a uma mensagem enviada, isto geralmente introduz mais uma etapa no ciclo de vida de uma entidade de negócio. Se uma entidade passa por diversos “status” durante seu ciclo de vida, pode-se ter que criar um novo status que indica que está sendo aguardada uma resposta sobre uma mensagem enviada.
  • tratamento de erro no consumo – quando ocorre em uma aplicação destino um erro ao tentar consumir uma mensagem, dependendo da criticidade do processo pode não ser aceitável uma solução que apenas descarte a mensagem. Pode ser necessário desenhar um processo que garanta novas tentativas de processamento da mensagem, seja enviando para o sistema origem uma notificação para enviar a mensagem novamente posteriormente, ou persistindo localmente a mensagem com problema para tentar processá-la após resolução do problema.
  • ordenação de mensagens – freqüentemente se utiliza multi-threading nas aplicações destino para processar as mensagens recebidas.  Se multi-threading é utilizado em uma situação onde a ordenação das mensagens recebidas é relevante (de maneira que uma mensagem só pode ser processada após o consumo de uma outra mensagem) tem-se uma alta dificuldade de programação e teste da solução.

A MATERA tem adquirido experiência nas vantagens e dificuldades de uso de mensagens, nos permitindo entregar com agilidade soluções de integração preparadas para lidar com os aspectos envolvidos no uso deste tipo de solução.

Por JOÃO GUILHERME LIMA

Investigador, gosta de entender os porquês de fazer assim ou assado. Pai de duas filhas e nas horas que sobram é arquiteto de sistemas.

Postado em: 28 de maio de 2012

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário