O que é o envio de mensagens?

Temos uma boa notícia! Você já é especialista no envio de mensagens (apenas não sabia disso). O envio de mensagens faz parte do nosso dia a dia e é fundamental para que as coisas aconteçam. Como seres humanos, enviamos e recebemos informações de forma contínua. Somos incrivelmente bons em processar dados para entender como funcionar em tempo real no mundo ao nosso redor. No entanto, não damos o devido valor às nossas aptidões sofisticadas. Seu telefone toca, você atende e instantaneamente compartilha dados com a pessoa que está do outro lado da linha.

Como seria um mundo sem o envio de mensagens? Essa ideia pode parecer forçada, mas é um problema muito real no mundo da computação: Como você conversa com um software? Como um software conversa com outro? Como um software conversa com você?

É aqui que entra o software de envio de mensagens. Nós, desenvolvedores de software, detestamos ter de resolver o mesmo problema repetidas vezes. É um uso ineficiente do nosso tempo, surgem inconsistências e a compatibilidade é prejudicada. Isso também dificulta a ampliação do nosso aplicativo para alcançar mais usuários. Já que a movimentação de informações é fundamental para nossos ecossistemas de aplicativos, os desenvolvedores querem apenas uma maneira simples de enviar mensagens para que possamos focar totalmente o valor e a qualidade do nosso código novinho em folha.

Qual é a diferença entre o envio de mensagens e o envio de mensagens?

Nem todos os sistemas de envio de mensagens e as mensagens são iguais. Se quisesse avisar a um amigo que você chegará com alguns minutos de atraso, poderia enviar uma mensagem curta dizendo: “Vou me atrasar 10 minutos”.

O que acontecerá, exatamente, depois que você clicar em “Enviar” depende da tecnologia por trás do serviço de mensagens. Normalmente, esse tipo de sistema é otimizado para disponibilidade e velocidade, pois garantir a entrega da mensagem pode custar caro em termos de computação, especialmente quando há uma alta taxa de transferência.

O serviço fará o melhor, em resumo, para transportar sua mensagem no máximo uma vez. É provável que seu amigo a receba, mas isso pode não acontecer. Nesse exemplo, o impacto de não receber a mensagem provavelmente será muito pequeno, sendo facilmente corrigido com um simples pedido de desculpas.

A maioria dos sistemas de envio de mensagens oferece uma série de opções conhecidas como “Qualidades de Serviço (QdS)” para dar suporte às necessidades variadas dos designers de aplicativos para o envio e o recebimento de mensagens. Por exemplo, o protocolo MQTT define três:

  • QdS 0: no máximo uma vez
  • QdS 1: no mínimo uma vez
  • QdS 2: exatamente uma vez

Você se sentiria confortável com uma QdS “no máximo uma vez” no caso de uma mensagem mais importante?

Considere o exemplo de uma equipe de alpinistas que alcança um ponto de parada para comunicação:

[alpinista]
> Dave machucou a perna.
> Podem providenciar uma equipe de resgate de emergência?
> Está muito mais quente do que pensávamos.
> Podem enviar água para a próxima parada?

Nesse exemplo, é muito importante que a segunda e a quarta mensagens sejam processadas. Precisamos, evidentemente, enviar tais mensagens com uma QdS que garanta a entrega. Uma QdS “pelo menos uma vez” ou “exatamente uma vez” seria desejável. Além disso, a cobertura de rede não será perfeita na subida de uma montanha e os alpinistas podem não ter tempo para esperar uma resposta. Portanto, a confirmação de envio precisa realmente significar que a mensagem foi enviada.

Algum tempo depois, os alpinistas recebem a confirmação:

[apoio]
> OK.

A resposta faz algum sentido, mas a que mensagem ela está relacionada?

Na terminologia do envio de mensagens, essa conversa entre duas partes costuma ser chamada de troca de solicitação-resposta. O padrão de troca de mensagens de “solicitação-resposta” oferece um mecanismo para a correlação de mensagens. Assim, podemos descobrir a que mensagem a resposta se refere.

Voltando ao nosso exemplo:

[alpinista]
> [messageId=002,correlationId=001] Podem providenciar uma equipe de resgate de emergência?
> [messageId=004,correlationId=002] Podem enviar água para a próxima parada?

[apoio]
> [messageId=001,correlationId=001] OK.
> [messageId=002,correlationId=002] OK.

Agora, temos uma confirmação positiva de que as duas mensagens foram processadas pelo apoio e de que a ajuda e os suprimentos estão a caminho.

Se quiser ter certeza de que sua mensagem será recebida, uma abordagem será continuar a enviando. O padrão de troca de mensagens “disparar-e-esquecer” funciona bem para determinados tipos de dados em determinados aplicativos. Um sensor de temperatura tagarela pode não ser tão ruim. Se um termômetro em uma sala de estar estivesse se comunicando com um sistema de calefação a cada sessenta segundos, quando uma interrupção momentânea na rede fizesse com que uma leitura fosse perdida, a próxima chegaria apenas sessenta segundos depois.

Apesar de simples, nem sempre essa abordagem consegue produzir o resultado correto. Não seria inteligente, por exemplo, continuar clicando no botão “Comprar agora” em um site de compras na internet a cada poucos minutos até a primeira confirmação aparecer na forma de um entregador batendo à porta da sua casa. Nesse cenário, queremos que a mensagem relacionada à nossa sessão de compras seja entregue “somente uma vez” ou esperamos que o aplicativo de processamento seja esperto o suficiente para deduplicar as solicitações de compra.

Fila de mensagens ao resgate

É difícil ter uma ótima conversa quando ninguém está escutando. O correio de voz foi inventado para esse tipo de problema.

A maioria dos aplicativos de software é estruturada como uma coleção de serviços independentes. Alguns deles podem ser de propriedade interna, enquanto outros serviços podem pertencer e ser gerenciados por terceiros. Voltando ao exemplo de compras: o front-end da web pode ser de propriedade interna, enquanto os serviços de pagamento, os serviços de atendimento e os serviços de compras vêm de provedores externos. Essa coleção de serviços depende de alguma forma de troca assíncrona de dados para facilitar a comunicação sem atrito. O que acontecerá se um dos serviços não estiver disponível ou apresentar lentidão? Nosso negócio não pode simplesmente parar por causa disso.

A fila de mensagens permite o desacoplamento do aplicativo para removermos a necessidade de processos frágeis e demorados. Após o envio, uma mensagem é armazenada com segurança em uma fila até que o aplicativo consumidor consiga processá-la. O aplicativo remetente é capaz de avançar e continuar processando outros pedidos. O IBM MQ e a API Java Message Service são dois exemplos de implementações de fila de mensagens.

Estilos de envio de mensagens

Dois domínios (ou estilos) de envio de mensagens são usados em sistemas de envio de mensagens:

  • Envio de mensagens de ponto a ponto: esse estilo de envio de mensagens usa filas de mensagens em que as mensagens são processadas por um único consumidor. Os produtores de mensagens são chamados de remetentes; os consumidores, de destinatários.

  • Envio de mensagens de publicação/assinatura: nesse estilo de envio de mensagens, cópias das mensagens são entregues a todos os aplicativos consumidores interessados. Os produtores de mensagens são chamados de editores; os consumidores, de assinantes.

O Apache Kafka é um sistema de envio de mensagens com base em publicação/assinatura. O IBM MQ oferece suporte aos dois estilos de envio de mensagens.

Protegendo as mensagens

Segurança é essencial. Como consumidores, instintivamente procuramos o símbolo de cadeado na barra de endereço do nosso navegador da web para ter certeza de que temos uma conexão segura ao fazer compras online. Os desenvolvedores também precisam garantir que as trocas de mensagens entre componentes dentro de um aplicativo estejam seguras e protegidas de hackers que possam tentar vê-las ou manipulá-las.

No software, a segurança é alcançada graças ao uso de técnicas de criptografia e encriptação padrão do setor. Segurança de software é um termo amplo. Além disso, os recursos exatos de que um aplicativo precisa influenciam a escolha da tecnologia de envio de mensagens.

Em geral, a segurança da mensagem inclui estas considerações principais:

  • Como os usuários são autenticados? Eles estão autorizados a usar recursos como filas e tópicos? Além disso, o software de envio de mensagens se integra aos sistemas de autenticação que já estão em vigor?

  • Como os dados em trânsito são protegidos? Por exemplo, há suporte para Transport Layer Security (TLS) de modo a oferecer encriptação?

  • Como os dados em repouso são protegidos? Por exemplo, as mensagens ou suas cargas úteis são criptografadas quando armazenadas?

Resumo

O software de envio de mensagens fornece uma maneira conveniente, flexível e estruturada de incorporar a comunicação em aplicativos de software. Oferecendo suporte a vários padrões comuns de troca de mensagens e a uma série de qualidades de serviço, o software de envio de mensagens libera os desenvolvedores de aplicativos para se concentrarem no valor de negócios dos seus códigos. Quando usadas adequadamente, as estruturas de envio de mensagens promovem implementação de aplicativo fracamente acoplada e ampliação de soluções, além de ajudarem os desenvolvedores a maximizar a reutilização dos serviços existentes.