Explorar o conteúdo e a serialização de mensagens no Barramento de Serviço

  • 3 minutos

As mensagens carregam um conteúdo e metadados. Os metadados estão na forma de propriedades de par chave-valor, descrevem o conteúdo e oferecem instruções de tratamento para o Barramento de Serviço e para aplicativos. Ocasionalmente, esses metadados sozinhos são suficientes para carregar as informações que o remetente deseja comunicar aos destinatários e o payload permanece vazio.

O modelo de objeto dos clientes oficiais do Barramento de Serviço para .NET e Java mapeia de/para os protocolos de transmissão compatíveis com o Barramento de Serviço.

Uma mensagem do Barramento de Serviço consiste em uma seção de payload binário que o Barramento de Serviço nunca manipula em nenhuma forma no lado do serviço e dois conjuntos de propriedade. As propriedades do agente são definidas pelo sistema. Essas propriedades predefinidas controlam a funcionalidade de nível de mensagem dentro do agente ou são mapeados para os itens de metadados comuns e padronizados. As propriedades do usuário são uma coleção de pares chave-valor definida pelo aplicativo.

Roteamento e correlação de mensagens

Um subconjunto das propriedades do agente, especificamente To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId e SessionId, ajuda os aplicativos a rotear mensagens para destinos específicos. Os seguintes padrões descrevem o roteamento:

  • Solicitação/resposta simples: um editor envia uma mensagem para uma fila e espera uma resposta do consumidor da mensagem. O editor tem uma fila para receber as respostas. O endereço dessa fila está contido na propriedade ReplyTo da mensagem de saída. Quando o consumidor responde, ele copia a MessageId da mensagem em questão para a propriedade CorrelationId da mensagem de resposta e a entrega para o destino indicado pela propriedade ReplyTo. Uma mensagem pode render várias respostas, dependendo do contexto do aplicativo.

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

  • Multiplexação: esse recurso de sessão permite a multiplexação de fluxos de mensagens relacionadas por meio de uma única fila ou assinatura, de modo que cada sessão (ou grupo) de mensagens relacionadas, identificadas por valores correspondentes da SessionId, seja roteada para um receptor específico enquanto o receptor mantém a sessão bloqueada. Leia mais sobre os detalhes das sessões aqui.

  • Solicitação/resposta multiplexada: esse recurso de sessão permite respostas multiplexadas, permitindo que vários editores compartilhem uma fila de resposta. Ao definir ReplyToSessionId, o editor pode instruir um ou mais consumidores a copiar esse valor na propriedade SessionId da mensagem de resposta. A fila ou tópico de publicação não precisa ter reconhecimento de sessão. Quando a mensagem é enviada, o editor pode aguardar uma sessão com a determinada SessionId ser materializada na fila aceitando condicionalmente um receptor de sessão.

O roteamento em um namespace do Barramento de Serviço usa as regras de encadeamento de encaminhamento automático e de assinatura de tópico. O roteamento entre namespaces pode ser realizado usando o Azure LogicApps. A propriedade To está reservada para uso futuro. Os aplicativos que implementam roteamento devem fazer isso com base nas propriedades do usuário e não depender da propriedade To. No entanto, fazer isso não causará problemas de compatibilidade.

Serialização de payload

Quando estiver em trânsito ou armazenado dentro do Barramento de Serviço, o payload é sempre um bloco opaco e binário. A propriedade ContentType permite que os aplicativos descrevam o conteúdo com o formato sugerido para os valores de propriedade, sendo uma descrição de tipo de conteúdo MIME de acordo com a 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 Barramento de Serviço dá suporte à criação de instâncias BrokeredMessage ao passar 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 receptor pode recuperar esses objetos com o método GetBody<T>(), fornecendo o tipo esperado. Com AMQP, os objetos são serializados em um gráfico AMQP dos objetos ArrayList e IDictionary<string,object>, e qualquer cliente do 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 do objeto e transformar os grafos de objeto em fluxos antes de incluí-los em uma mensagem, então eles devem fazer a operação contrária do lado do receptor. Embora o AMQP tenha um avançado modelo de codificação binária, ele está vinculado ao ecossistema de mensagens AMQP e os clientes HTTP tem problemas para decodificar esses conteúdos.