Mensageria–Uma introdução ao Enterprise Integration

Enterprise Integration & SOA

capa

Primeiro vale notar qual a necessidade da mensageria. Hoje muito se fala em sistemas distribuídos, escaláveis, cloud computing e etc. O que nos leva a perceber que a cada dia temos mais sistemas e serviços sendo utilizados em massa, e que logicamente estes sistemas raramente são construídas de forma isolada.

O que temos visto é que a prática de mercado aponta para uma pluralidade de sistemas, o que por sua vez aponta para uma pluralidade de plataformas e linguagens. Neste post vamos iniciar os estudos sobre as técnicas de integração de sistemas (Enterprise Integration Patterns), iniciando pela mensageria.


Um pouco de história

A ideia surge em 1983, quando o indiano Vivek Ranadivé, após seu MBA no MIT, teve a ideia de criar um barramento de software à semelhança do que acontece no barramento de comunicação entre a placa mãe e as demais placas de um PC. Para realizar sua ideia ele criou a empresa Teknekron e começou a desenvolver sua ideia com o TIB (The Information Bus). Em 1985 seu primeiro cliente foi a Goldman Sachs. O conceito teve ótima adoção nas empresas do mercado financeiro, o que levou a expansão do conceito para os demais mercados.

O famoso TIP da Teknekron trabalhava no conceito publish-subscribe (PubSub), onde uma aplicação disponibiliza dados a serem consumidos por outras que subscrevem para ter acesso. O modelo foi um sucesso. Na época todo mundo usava COBOL mas as aplicações poderiam tratar os dados de forma diferente. Quem fazia o meio de campo era o tal TIB (The Information Bus).

As empresas financeiras em geral usavam máquinas IBM para processar o espetacular software da Teknekron. A IBM não ganhava nada porém seus técnicos não ficaram só assistindo. Por volta de 1990 começaram a desenvolver algo do gênero, até que em 1993, lançaram o IBM MQseries (hoje Websphere MQ). Em 1997 foi a vez da Microsoft entrar neste mercado lançando a primeira versão do MSMQ (Microsoft Message Queue).

O conceito PubSub hoje em dia é largamente utilizado por aplicações populares como Facebook e Twitter. Porém antigamente era coisa de rico. Os servidores MQs semelhantes ao TIB, foram durante muitos anos usados quase que exclusivamente por grandes empresas. Um dos principais motivos pela não popularização, foi o modelo vendor lock-in usado pelas empresas que comercializavam os MQs. A elas não interessava permitir interoperabilidade entre diferentes produtos e até dificultavam ao máximo uma eventual troca de fornecedor de MQ.

Os próprios clientes reclamavam disso porque era comum ter que fazer um TIBCO MQ conversar com um IBM MQseries e era um verdadeiro parto... felizmente as coisas mudaram. 

 

Introdução

Hoje porém é consenso que, a integração entre estas múltiplas aplicações é uma necessidade constante. O que precisa ser notado é que para se integrar um simples sistema temos de enfrentar alguns desafios:

  • Redes não são 100% confiáveis;
  • Redes são lentas ;
  • Aplicações podem usar diferentes linguagens, operar em plataformas diferentes e tratar os dados de acordo com suas próprias necessidades;
  • Mudanças são inevitáveis. Uma solução de integração deve minimizar dependências entre aplicações. O acoplamento entre elas deve ser tão baixo que mudanças em uma aplicação não implique em mudanças nas demais.

O que se vê ao longo do amadurecimento das tecnologias de informação, foram diversas tentativas de vencer (ou amenizar) os desafios já citados por meio de algumas abordagens de comunicação entre aplicações distintas:

  1. Comunicação por transferência de arquivo – Quando uma determinada aplicação grava um arquivo em um lugar acordado e a outra lê e apaga após ler. O formato dos dados geralmente era um outro acordo;
  2. Comunicação via armazenamento - Compartilhamento de uma base de dados;
  3. Comunicação via RPC, Remote Procedure Call – Quando uma aplicação expõe as funcionalidades necessárias de modo a possibilitar o acesso remoto. Este tipo de comunicação é real time e síncrono, logo quem solicita algo ao serviço deve esperar a resposta;
  4. Comunicação via Mensagens (ou mensageria) – Neste tipo de comunicação uma aplicação envia uma mensagem para um canal de acesso comum. Neste caso as demais aplicações vão efetuar a leitura quando quiserem, mediante contrato para determinação do canal e formato, bem como alguns detalhes que veremos mais detalhadamente. Geralmente este tipo de comunicação é assíncrona;

 

Com tantas opções, porque falar só sobre mensageria?

Vale notar que ao longo do tempo diversas técnicas foram implementadas, porém a mensageria acabou se tornando o padrão neste caso. Entre os vários motivos que veremos mais detalhadamente, a interoperabilidade, evolução dos protocolos e o consumo assíncrono são de longe as características que elevaram o status da mensageria em relação a integração de sistemas.

 

Então, o que é mensageria?

Vamos considerar o seguinte cenário para a abstração: Uma chamada telefônica é uma forma de comunicação síncrona porque os dois lados precisam estar disponíveis ao mesmo tempo.

FIG1

Já se um dos lados liga e deixa um recado de voz, esta mensagem pode ser ouvida e respondida conforme a disponibilidade do outro lado. Neste caso dizemos que houve uma comunicação assíncrona.

FIG2

Mensageria é uma tecnologia que permite comunicação de alta velocidade e de forma assíncrona entre sistemas diferentes com mensagens entregues de forma garantida.

Os canais, também conhecidos como filas de mensagens (MQ = message queuing), são caminhos lógicos que conectam os sistemas. Eles se comportam como se fossem uma coleção de mensagens compartilhadas entre múltiplos computadores que podem ser acessados concorrentemente por múltiplas aplicações.

Quem envia a mensagem (escreve no canal) é o sender ou producer e o que recebe (lê o canal) é o receiver ou consumer.

A mensagem em si é simplesmente algum tipo de dado.

Normalmente a mensagem contém um cabeçalho (header) e o corpo propriamente dito (body). O header contém os metadados sobre a mensagem. O corpo contém os dados trocados e é ignorado pelo sistema de mensageria. No linguajar DEV, podemos dizer que a mensagem é o corpo.

 

O que é um sistema de mensageria?

É o tal canal. Normalmente é um software que gerencia e coordena as mensagens enviadas e recebidas com a responsabilidade de não perder nenhuma. Em caso de falha, deve ser capaz de tentar novamente até conseguir (ou ocorrer uma intervenção externa). Conhecido em inglês por messaging system ou message-oriented middleware (MOM).

Entre os mais conhecidos e utilizados modelos de MOMs temos o MSMQ (Message Queuing), JMS (Java Message Service) e MQSeries (IBM WebSphere MQ). Estes veremos com mais detalhes em postagens futuras.

Uma mensagem é transmitida em 5 passos:

  1. CREATE – o sender cria a mensagem e a preenche com dados;
  2. SEND – o sender adiciona a mensagem ao canal;
  3. DELIVER – o sistema de mensageria move a mensagem do computador do sender deixando disponível ao computador do receiver;
  4. RECEIVE – o receiver lê a mensagem no canal;
  5. PROCESS – o receiver extrai os dados da mensagem.

Tudo de acordo com a figura abaixo:

FIG3

Dois tipos importantes de envio de mensagens:

  1. Send and forget (ou fire and forget) – O sender cria e envia a mensagem em questão. Completado o envio, o sender assume outras tarefas confiando que o sistema de mensageria  em algum momento entregará a mensagem ao receiver.
  2. Store and forward - Ao enviar, o sender armazena em seu computador a mensagem (na memória ou no disco). O sistema de mensageria igualmente grava a mensagem no computador do receiver. Trocas de mensagens usando o processo Store-and-forward podem ser repetidas quantas vezes forem necessárias sem risco de existir em duplicata no receiver.

 

No próximo post vamos ver sobre os protocolos de mensageria mais conhecidos e praticados no mercado hoje.

 

Referências


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


7 minutes to read