Concrete Logo
Hamburger button

Introdução à mensageria

  • Blog
  • 23 de Janeiro de 2012
Share

[fblike]

 

Mensageria = sistemas conectados que trocam mensagens roteadas por um servidor intermediário em geral chamado de message broker.

Quem quiser tem uma boa noção sobre o que vem a ser isto, o melhor link que conheço é o texto do Gregor Hohpe em https://www.eaipatterns.com/Introduction.html.

 
Atenção, atualização depois do artigo publicado:

Como o site do Gregor Hohpe estava fora do ar e sem ele, este artigo ficaria incompleto, coloquei umas poucas observações minhas em um resumo traduzido de algumas partes do artigo original, que por sorte ainda tinha aqui aberto na minha máquina. Assim esta introdução não perde o sentido. Chamei o resumo de Apoio à Introdução à mensageria. Caso esteja fora do ar o site original do Gregor, muito melhor do que meu resumo, não perderá tanto quem clicar no link.

 

O princípio

A idéia veio de um engenheiro de hardware. O indiano Vivek Ranadivé, após seu MBA no MIT em 1983, pensou que deveria existir 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 por em prática, criou a empresa Teknekron e começou a desenvolver a aplicação “killer” a qual chamava de TIB (The Information Bus). Em 1985 seu primeiro cliente foi a Goldman Sachs. O conceito foi muito bem aceito nas empresas do mercado financeiro e os próximos passos levaram ao domínio do mercado. No fim de 1993 vendeu a Teknekron para o grupo Reuters por $ 125,1 mi cash.

O Vivek seguiu trabalhando na Reuters. Mas em 1997, aproveitando sua fama no mercado de mensagens corporativas, criou uma companhia independente com o nome de TIBCO (The Information Bus COmpany). Hoje o Vivek ainda é o Chairman e CEO da TIBCO.

 

Os seguidores

O software 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). No mesmo ano de 1997 em que o Vivek criou a TIBCO, a Microsoft se infiltrou nesse mercado lançando a primeira versão do seu 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, durante muitos anos eram 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.

 

JMS (Java Message Service)

Em 2001 nasceu o JMS (Java Message Service) tentando resolver os problemas de interoperabilidade e de vendor lock-in por meio de uma API Java comum que escondesse as peculiaridades de cada fornecedor. Na verdade, como veremos adiante, resolveu apenas para a plataforma Java. Em um ambiente puramente Java normalmente é possível trocar de message broker apenas alterando configurações em um arquivo externo, como um jndi.properties por exemplo.

As melhores referências que conheço para aprender a usar JMS diretamente estão nos capítulos 3 e 4 do livro Java Messaging de autoria do colunista da revista Dr.Dobb’s Eric Bruno.

Além do modelo PubSub que no linguajar do JMS vira Topic

 

o JMS também trabalha com o conceito de filas (Queue para o JMS)

 
A API JMS tem interfaces específicas para os domínios Topic e Queue. O JMS trata por domínios os paradigmas de mensagens.

É mais comum usar JMS por debaixo dos panos através dos Message Driven Beans. Achei boas dicas sobre como usar no blog C0dez0ne do Leandro Silva.

A idéia do JMS é muito boa. JMS foi e ainda é bastante usado. Há ótimos servidores de mensageria com suporte comercial pago ou inteiramente gratuitos, alguns estão listados no fim deste artigo. Mas como veremos a seguir, a tentativa de padronização via API peca por tentar ser uma espécie de tomada universal que atenda a todos os tipos de plugs.

 

Porque JMS não serve como solução de interoperabilidade em plataformas heterogêneas

Na área de mensageria existem diferente protocolos wire-level, isto é, descrevendo os formatos dos dados que trafegam na rede como fluxos de bytes (ou octetos = unidade de informação com 8 bits). Cada plataforma tem seu formato preferido de troca de dados. O JMS usa um protocolo wire-level chamado OpenWire. Um protocolo muito usado pelas plataformas Ruby, Python, Perl e PHP é o STOMP (Simple or Streaming Text Orientated Messaging Protocol). A turma do .NET usa outra coisa.

Através do uso de algumas soluções proprietárias ou particulares de cada message broker, é possível trocar mensagens entre a plataforma Java e uma outra como .NET, Ruby, Python, Perl, PHP, etc.. Há message brokers, como o ActiveMQ por exemplo, que fazem a ponte traduzindo de um protocolo OpenWire para STOMP e assim facilita escrever um cliente Ruby, Python, Perl e PHP para trocar mensagens com JMS.

Isto resolve o problema da interoperabilidade apenas aparentemente. Em outras palavras, não resolve e por vários motivos:

    – Os protocolos podem eventualmente não suportar o mesmo tipo de corpo de mensagem (se é objeto, se é um fluxo de bytes, etc.),
    – Nem todos os brokers suportam as mesmas pontes.
    – Os protocolos nem sempre aceitam os mesmos tipos de dados usados em cliente oriundos de plataformas diferentes.
    – Se nenhum dos clientes for Java, é mais difícil encontrar um broker que entenda os dois lados.

Assim parece claro que padronizar a API como faz o JMS, não é a solução para plataformas heterogêneas. A padronização necessária tem mesmo que ser no protocolo das mensagens. Precisa ser um padrão wire-level que descreva como a mensagem em formato binário deve ser estruturada e enviada pela rede.


Protocolo wire-level de padrão aberto

Em 2004 o pessoal do JPMorgan Chase & Co, pelos motivos descritos no item anterior, achou que precisava de outro tipo de solução e junto com a iMatix, começou a desenvolver o AMQP (Advanced Message Queuing Protocol), um protocolo wire-level de padrão aberto. A idéia de ser um padrão aberto significa que qualquer um pode implementar e qualquer aplicação que siga este padrão, poderá trocar mensagens com qualquer vendor que adote este padrão.

 

AMQP Advanced Message Queuing Protocol

O AMQP é um protocolo binário com features tais como: multicanal, negociável, assíncrono, seguro, portável, neutro e eficiente. Ele se divide em duas camadas:

    – Camada funcional que define um conjunto de comandos ou métodos que fazem trabalho útil em benefício da aplicação permitindo suportar diversos estilos de trocas de mensagens.

    – Camada de transporte – cobre o conteúdo relativo ao meio de transporte, coisas do tipo multiplexação de canais, pacote de dados (framing), encoding do conteúdo, heart-beating, representação dos dados e tratamento de erro.

Os métodos citados na camada funcional são operações do tipo métodos HTTP e não tem nada em comum com os métodos das linguagens orientadas a objetos. São agrupados logicamente em classes de funcionalidade.

Para quem quer saber mais, nada como consultar diretamente as especificações. Recomendo ler a AMQP 0-9-1 Specification (PDF) que é a usada atualmente pelo RabbitMQ (na versão 2.7.1 enquanto este texto era escrito)

 

Links para alguns sistemas de mensageria

Os que estão assinalados como JMS também trabalham com outros protocolos usando alguma ponte mas foram feitos para JMS.

Nós na Concrete Solutions, não temos nenhum problema para estudar e aprender a usar softwares comerciais como os cinco primeiros da lista acima. Aliás já fizemos muitas vezes. Porém muitas das soluções para nossos atuais clientes se baseiam em softwares Open Source e alguns de nossos desenvolvedores participam do desenvolvimento de softwares Open Source. Sendo assim, no futuro quando formos mostrar algum exemplo de uso de um sistema de mensageria, provavelmente será com algum dos quatro últimos.

Assim como a poesia lá em cima está incompleta (pode ser lida inteira ao clicar no nome), este artigo é o primeiro de uma série sobre este assunto. Até breve quando voltaremos falando sobre um destes sistemas de mensageria.

Por enquanto deixo um link para outro texto do Gregor HohpeO que significa usar mensageria