Mensageria e os Protocolos–Choose your poison

Enterprise Integration & SOA

Uma das questões mais interessantes da mensageria são os protocolos. Na arquitetura de software é fundamental entender a diferença entre os protocolos de mensagens e qual deve ser utilizado em cada tipo de aplicação.

capa

Hoje com a multiplicidade de sistemas e plataformas, os arquitetos de software tem optado pela utilização do famoso Message Broker (que vou abordar em um próximo post). Porém escolher um middleware de mensagens também implica em entender as diferenças sutis entre os protocolos de transporte, o que pode ser uma tarefa difícil.

Neste post vou apresentar os principais e mais utilizados protocolos de mensagem da atualidade.

 

AMQP - Advanced Message Queuing Protocol

amqp

O AMQP é um protocolo binário com diversas 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. Para isso é só acessar o AMQP 0-9-1 Specification (PDF) e ler direto na fonte.

 

MQTT - Message Queue Telemetry Transport

mqttorg

Inicialmente desenvolvido pela Pervasive Computing Team da IBM, o MQTT ao longo dos últimos anos, foi movido para a comunidade de open source, e o que se viu foi um crescimento significativo na popularidade e utilização deste protocolo.

Os padrões de design e objetivos do MQTT são mais simples que o AMQP. Sendo assim é mais fácil fornecer o publish-and-subscribe messaging (sem se utilizar o mecanismo de fila, apesar do nome). O MQTT foi projetado especificamente para dispositivos com recursos limitados e baixa largura de banda, alta latência de rede (como linhas dial-up e links de satélite, por exemplo), o que o torna ideal para ser usado em sistemas embarcados.

Os pontos fortes da MQTT são a simplicidade (apenas cinco métodos na API), a carga útil do pacote binário compacto (sem propriedades de mensagem, cabeçalhos compactados, muito menos detalhados do que algo como HTTP), e faz um bom ajuste para cenários simples impulso de mensagens como temperatura atualizações, tickers de preços de ações, feeds de pressão de óleo ou notificações móveis. É também muito útil para conectar máquinas em conjunto, como conectar um Arduino dispositivo para um serviço web com MQTT .

 

MSMQ - Microsoft Message Queuing

MSMQ

Microsoft Message Queuing (MSMQ) foi desenvolvido pela Microsoft (sério?) e está disponível desde 1997 em todas as plataformas do Windows (tem que ser instalado como componente do Windows), e sua versão mais atual é a 6.3.

O MSMQ está disponível em quase todas as máquinas Windows a partir do Windows 2000 (embora não o home edition Win2000). Com o Windows XP e Server 2003, a Microsoft introduziu MSMQ 3.0 e Service Pack 2 trouxe MSMQ para a versão 3.1, com um conjunto de recursos enterprise-ready.

O MSMQ fornece integração com o Active Directory, suporta operações nativas, bem como transações distribuídas utilizando o distributed transaction coordinator integration. As mensagens são gravadas em disco na máquina local, o que leva a necessidade de se implementar um armazenamento distribuído e redundante para evitar a perca de mensagens em caso de falha de disco.

Outro problema é a baixa interoperabilidade nativa do MSMQ, já que ele é executado em sistemas operacionais Windows. É razoavelmente rápido quando utilizado com código gerenciado (disponível no framework .NET) e ainda mais rápido quando combinado com código não gerenciado. Escalabilidade e alta disponibilidade podem ser alcançados com a construção de um cluster MSMQ (ou usar o NServiceBus ou ainda migrar para o Azure Service Bus). A administração de MSMQ é bastante fácil. Ele pode ser instalado, gerenciado e configurado com o PowerShell, no Microsoft Management Console (MMC) ou com ferramentas de terceiros.

Durante o tempo em que a Divisão de Sistemas Conectados à Microsoft estava desenvolvendo Indigo (agora conhecido como WCF), a intenção era substituir MSMQ com algo novo, porém o esforço para substituir MSMQ foi abandonado e MSMQ foi integrado ao WCF.

 

JMS - Java Message Service

JSM

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, 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 para aprender a usar JMS diretamente estão nos capítulos 3 e 4 do livro Java Messaging de autoria do colunista Eric Bruno da revista Dr.Dobb’s.

 

STOMP - Simple/Streaming Text Oriented Messaging Protocol

Protocol

STOMP (Streaming de texto simples / Orientada Messaging Protocol) é um protocolo baseado em texto, o que o torna mais análogo ao HTTP em termos de como ele olha debaixo do capô. Assim como o AMQP, o STOMP fornece um cabeçalho e corpo para a mensagem. Os princípios de design aqui eram para criar algo simples, e amplamente interoperável. Por exemplo, é possível conectar-se usando algo tão simples como um cliente telnet.

STOMP é simples e leve, com uma vasta gama de suporte a linguagens. Um dos exemplos mais interessantes é com RabbitMQ Web Stomp, que lhe permite expor mensagens em um navegador através websockets .

 

RabbitMQ – O protocolo poliglota

rabbitmq

O RabbitMQ é uma implementação open source baseada em AMQP onde é possível se beneficiar de outros sistemas  como OTP (Open Telecommunication Platform), que é utilizado pelas empresas de telecomunicação para gestão de exchanges para chamadas de voz, VoIP e agora vídeo.

O RabbitMQ é uma implementação open source baseada em AMQP, porém ao invés de criar uma nova infra-estrutura de mensagens, a equipe do RabbitMQ construiu uma camada em Erlang em cima de OTP (Open Telecommunication Platform). Toda a API é fornecida para que os desenvolvedores se conectam a ele sobre o protocolo AMQP. Isto combina a robustez e escalabilidade de uma plataforma comprovada com a flexibilidade do modelo de mensagens AMQP.

John O'Hara, Presidente do AMQP Working Group disse: "Um padrão forte precisa de uma variedade de interoperabilidade e implementações, e eu estou satisfeito em acolher o RabbitMQ na família. A visão do AMQP Working Group é por meio da padronização AMQP, permitindo que as empresas reduzam seus custos de integração utilizando processamento de transações simples e robusta entre as empresas no mundo todo."

 

Conclusão

A ideia neste post é de apenas apresentar os protocolos de transporte mais utilizados. Vale notar que deixei de fora diversos protocolos já que hoje os mais utilizados são os que privilegiam a interoperabilidade. Nessa brincadeira temos como intruso o MSMQ que ainda é extremamente utilizado devido o grande legado de utilização do Windows como SO.

 

Referências

MQTT.org

Message Queuing (MSMQ)

RabbitMQ

Stomp


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