Explore as cargas úteis e a serialização de mensagens do Service Bus

  • 3 minutos

As mensagens carregam uma carga útil e metadados. Os metadados estão na forma de propriedades de par chave-valor, descrevem a carga útil e fornecem instruções de manipulação para o Service Bus e aplicativos. Ocasionalmente, esses metadados por si só são suficientes para transportar as informações que o emissor deseja comunicar aos destinatários, e a carga útil permanece vazia.

O modelo de objeto dos clientes oficiais do Service Bus para .NET e Java mapeia de e para os protocolos de conexão suportados pelo Service Bus.

Uma mensagem do Service Bus consiste em uma seção de carga binária que o Service Bus nunca manipula de forma alguma no lado do serviço e dois conjuntos de propriedades. As propriedades do corretor são definidas pelo sistema. Essas propriedades predefinidas controlam a funcionalidade no nível da mensagem dentro do broker ou são mapeadas para itens de metadados comuns e padronizados. As propriedades do usuário são uma coleção de pares chave-valor definidos e definidos pelo aplicativo.

Roteamento e correlação de mensagens

Um subconjunto das propriedades do broker, especificamente To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId, e , ajudam SessionIdos aplicativos a rotear mensagens para destinos específicos. Os padrões a seguir descrevem o roteamento:

  • Simples pedido/resposta: Um editor envia uma mensagem para uma fila e espera uma resposta do consumidor da mensagem. O editor possui uma fila para receber as respostas. O endereço dessa fila está contido na ReplyTo propriedade da mensagem de saída. Quando o consumidor responde, ele copia a MessageId mensagem manipulada para a CorrelationId propriedade da mensagem de resposta e entrega a mensagem no destino indicado pela ReplyTo propriedade. Uma mensagem pode gerar várias respostas, dependendo do contexto do aplicativo.

  • Solicitação/resposta multicast: Como uma variação do padrão anterior, um publicador envia a mensagem para um tópico e vários assinantes tornam-se elegíveis para consumir a mensagem. Cada um dos subscritores pode responder da forma descrita anteriormente. Se ReplyTo apontar para um tópico, esse conjunto de respostas de descoberta pode ser distribuído para um público.

  • Multiplexação: Este recurso de sessão permite a multiplexação de fluxos de mensagens relacionadas através de uma única fila ou assinatura, de modo que cada sessão (ou grupo) de mensagens relacionadas, identificadas por valores correspondentes SessionId , sejam roteadas para um recetor específico enquanto o recetor mantém a sessão bloqueada. Saiba mais sobre os detalhes das sessões aqui.

  • Pedido/resposta multiplexado: Esse recurso de sessão permite respostas multiplexadas, permitindo que vários editores compartilhem uma fila de respostas. Ao definir ReplyToSessionIdo , o editor pode instruir um ou mais consumidores a copiar esse valor para a SessionId propriedade da mensagem de resposta. A fila de publicação ou o tópico não precisa estar ciente da sessão. Quando a mensagem é enviada, o editor pode esperar que uma sessão com o dado SessionId se materialize na fila, aceitando condicionalmente um recetor de sessão.

Serialização de carga útil

Quando em trânsito ou armazenada dentro do Service Bus, a carga útil é sempre um bloco binário opaco. A ContentType propriedade permite que os aplicativos descrevam a carga útil, com o formato sugerido para os valores de propriedade sendo uma descrição do tipo de conteúdo MIME de acordo com o IETF RFC2045; por exemplo, application/json;charset=utf-8.

Ao contrário das variantes Java ou .NET Standard, a versão .NET Framework da API do Service Bus oferece suporte à criação BrokeredMessage de instâncias passando objetos .NET arbitrários para o construtor.

O protocolo SBMP herdado serializa objetos com o serializador binário padrão ou com um serializador fornecido externamente. O protocolo AMQP serializa objetos em um objeto AMQP. O recetor pode recuperar esses objetos com o GetBody<T>() método, fornecendo o tipo esperado. Com AMQP, os objetos são serializados em um gráfico AMQP de ArrayList e IDictionary<string,object> objetos, e qualquer cliente AMQP pode decodificá-los.

Embora essa mágica de serialização oculta seja conveniente, se os aplicativos devem assumir o controle explícito da serialização de objetos e transformar seus gráficos de objetos em fluxos antes de incluí-los em uma mensagem, eles devem fazer a operação inversa no lado do recetor. Embora o AMQP tenha um poderoso modelo de codificação binária, ele está vinculado ao ecossistema de mensagens AMQP e os clientes HTTP têm problemas para decodificar essas cargas úteis.