Explorer les charges utiles et la sérialisation des messages Service Bus

  • 3 minutes

Les messages contiennent une charge utile et des métadonnées. Les métadonnées sont présentes sous la forme de propriétés de paire clé-valeur ; elles décrivent la charge utile et fournissent des instructions de traitement à Service Bus et aux applications. Il arrive que les métadonnées suffisent à elles seules à transporter les informations que l’expéditeur souhaite communiquer aux destinataires, et la charge utile reste donc vide.

Le modèle objet des clients Service Bus officiels pour .NET et Java est mappé vers et depuis les protocoles de transmission pris en charge par Service Bus.

Un message Service Bus se compose d’une section de charge utile binaire que Service Bus ne traite jamais sous quelque forme que ce soit côté service, ainsi que de deux ensembles de propriétés. Les propriétés du répartiteur sont définies par le système. Ces propriétés prédéfinies contrôlent les fonctionnalités au niveau des messages à l’intérieur du répartiteur, ou sont mappées sur des éléments de métadonnées communs et normalisés. Les propriétés de l’utilisateur sont une collection de paires clé-valeur définies et configurées par l’application.

Routage et corrélation des messages

Certaines des propriétés du répartiteur, plus précisément To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId et SessionId, aident les applications à router les messages vers des destinations spécifiques. Les modèles suivants décrivent le routage :

  • Demande/réponse simple : un éditeur envoie un message dans une file d’attente et attend une réponse du consommateur du message. L’éditeur possède une file d’attente pour recevoir les réponses. L’adresse de cette file d’attente est contenue dans la propriété ReplyTo du message sortant. Quand le consommateur répond, il copie le MessageId du message géré dans la propriété CorrelationId du message de réponse, et livre le message à la destination indiquée par la propriété ReplyTo. Selon le contexte de l’application, un même message peut entraîner plusieurs réponses.

  • Demande/réponse de multidiffusion : en guise de variante du modèle précédent, un éditeur envoie le message dans une rubrique et plusieurs abonnés deviennent éligibles pour utiliser le message. Chacun de ces abonnés peut répondre de la manière précédemment décrite. Si ReplyTo pointe vers une rubrique, tel un ensemble de réponses de découverte, il peut être distribué à une audience.

  • Multiplexage : cette fonctionnalité de session permet le multiplexage de flux de messages associés via une file d’attente ou un abonnement unique, de sorte que chaque session (ou groupe) de messages connexes identifiés par des valeurs SessionId correspondantes est acheminée vers un destinataire spécifique qui la verrouille. Pour plus d’informations sur les détails des sessions, consultez cet article.

  • Demande/réponse multiplexée : cette fonctionnalité de session active les réponses multiplexées, ce qui permet à plusieurs éditeurs de partager une file d’attente de réponses. En définissant ReplyToSessionId, l’éditeur peut demander à un ou plusieurs consommateurs de copier cette valeur dans la propriété SessionId du message de réponse. La file d’attente ou la rubrique de publication n’ont pas besoin de prendre en charge la session. Quand le message est envoyé, l’éditeur peut attendre qu’une session avec le SessionId donné se matérialise sur la file d’attente en acceptant de manière conditionnelle un destinataire de session.

Le routage à l’intérieur d’un espace de noms Service Bus utilise des règles de chaînage de transferts automatiques et d’abonnement aux rubriques. Le routage entre espaces de noms peut être effectué à l’aide d’Azure Logic Apps. La propriété To est réservée pour une utilisation ultérieure. Les applications qui implémentent le routage doivent le faire en fonction des propriétés de l’utilisateur plutôt qu’en s’appuyant sur la propriété To ; toutefois, le choix de cette dernière solution n’entraîne pas de problèmes de compatibilité.

Sérialisation de la charge utile

Lorsque la charge utile est en transit ou stockée à l’intérieur de Service Bus, elle constitue toujours un bloc binaire opaque. La propriété ContentType permet aux applications de décrire la charge utile, et le format recommandé pour les valeurs de cette propriété est une description Content-Type MIME conforme à IETF RFC2045, par exemple application/json;charset=utf-8.

Contrairement aux variantes Java ou .NET Standard, la version .NET Framework de l’API Service Bus prend en charge la création d’instances BrokeredMessage en passant des objets .NET arbitraires dans le constructeur.

Le protocole SBMP hérité sérialise les objets avec le sérialiseur binaire par défaut ou avec un sérialiseur fourni en externe. Le protocole AMQP sérialise les objets dans un objet AMQP. Le récepteur peut récupérer ces objets avec la méthode GetBody<T>() en fournissant le type attendu. Avec AMQP, les objets sont sérialisés dans un graphique AMQP d’objets ArrayList et IDictionary<string,object> , et n’importe quel client AMQP peut les décoder.

Cette sérialisation cachée est pratique, mais si les applications doivent contrôler explicitement la sérialisation des objets et convertir leurs graphes d’objets en flux avant de les inclure dans un message, elles doivent effectuer l’opération inverse côté récepteur. Bien qu’AMQP dispose d’un modèle d’encodage binaire très puissant, il est lié à l’écosystème de messagerie AMQP, et les clients HTTP ont des difficultés à décoder les charges utiles de ce type.