VENTES: 1-800-867-1389

Files d'attente Azure et files d'attente Service Bus - comparaison et différences

Mis à jour: octobre 2014

Auteur : Valery Mizonov, Seth Manheim et Abhishek Lal

Contributeurs : Brad Calder, Jai Haridas, Jason Hogg, Jeff Irwin, Jaganathan Thangavelu, Kartik Paramasivam, Todd Holmquist-Sutherland et Ruppert Koch

Cet article analyse les différences et les ressemblances existantes entre les deux types de files d'attente proposées par Azure : les files d'attente Microsoft Azure et les files d'attente Microsoft Azure Service Bus. À l'aide de ces informations, comparez et opposez les technologies respectives et prenez une décision en toute connaissance de cause concernant la solution la plus adaptée à vos besoins.

Microsoft Azure prend en charge deux types de mécanismes de mise en file d'attente : les files d'attente Azure et les files d'attente Applet de commande.

Les files d'attente Azure, qui font partie intégrante de l'infrastructure du stockage Azure, offrent une interface Get/Put/Peek REST simple, intégrant une messagerie fiable et persistante dans et entre les services.

Les files d'attente Applet de commande font partie intégrante d'une infrastructure de messagerie Azure plus étendue qui prend en charge la mise en file d'attente, ainsi que la publication/abonnement, la communication à distance des services Web et les modèles d'intégration. Pour plus d'informations sur les files d'attente, les rubriques/abonnements et les relais Applet de commande, consultez Vue d'ensemble des modèles de messagerie Service Bus.

Bien que les deux technologies de mise en file d'attente existent simultanément, les files d'attente Azure ont été introduites en premier, en tant que mécanisme de stockage de file d'attente dédié conçu sur les services de stockage Azure. Les files d'attente Applet de commande sont conçues sur l'infrastructure de « messagerie répartie » plus étendue et destinée à intégrer des applications ou des composants d'application qui peuvent s'étendre sur plusieurs protocoles de communication, contrats de données, domaines d'approbation et/ou environnements réseau.

Cet article compare les deux technologies de file d'attente offertes par Azure en traitant des différences de comportement et d'implémentation des fonctionnalités fournies par chacune d'elles. Il fournit également de l'aide pour choisir les fonctionnalités les plus adaptées à vos besoins de développement d'applications.

Les files d'attente Azure et Applet de commande sont des implémentations du service de mise en file d'attente de messages actuellement proposé sur Microsoft Azure. Chacune dispose d'un jeu de fonctionnalités légèrement différent, ce qui signifie que vous pouvez choisir l'une ou l'autre, ou utiliser les deux, selon les besoins de votre solution ou du problème d'entreprise/technique que vous résolvez.

Lorsqu'ils déterminent la technologie de mise en file d'attente adaptée à une solution donnée, les architectes et les développeurs de la solution doivent prendre en compte les recommandations ci-dessous. Pour plus d'informations, consultez la section suivante.

En tant qu'architecte/développeur de solutions, vous devez envisager d'utiliser des files d'attente Azure dans les conditions suivantes :

  • Votre application doit stocker plus de 80 Go de messages dans une file d'attente, où les messages ont une durée de vie inférieure à 7 jours.

  • Votre application veut suivre la progression du traitement d'un message à l'intérieur de la file d'attente. Cela s'avère utile si le processus entier de traitement d'un message se bloque. Un thread de travail suivant peut ensuite utiliser ces informations pour continuer là où le thread de travail précédent s'est arrêté.

  • Vous avez besoin de journaux côté serveur de toutes les transactions exécutées sur les files d'attente.

En tant qu'architecte/développeur de solutions, vous devez envisager d'utiliser des files d'attente Applet de commande dans les conditions suivantes :

  • Votre solution doit être en mesure de recevoir des messages sans devoir interroger la file d'attente. Avec Applet de commande, cela peut être effectué en utilisant l'opération de réception de l'interrogation longue à l'aide des protocoles TCP pris en charge par Applet de commande.

  • Votre solution nécessite la file d'attente pour fournir une remise ordonnée garantie selon le principe FIFO (premier entré/premier sorti).

  • Vous voulez créer une expérience symétrique dans Azure et sur Windows Server (cloud privé). Pour plus d'informations, consultez Service Bus pour Windows Server.

  • Votre solution doit pouvoir prendre en charge la détection automatique des doublons.

  • Vous voulez que votre application traite les messages en tant que flux long parallèles (les messages sont associés à un flux à l'aide de la propriété SessionId sur le message). Dans ce modèle, chaque nœud de l'application consommatrice est en concurrence pour les flux, contrairement aux messages. Lorsqu'un flux est donné à un nœud consommateur, celui-ci peut examiner l'état du flux d'application à l'aide de transactions.

  • Votre solution nécessite un comportement transactionnel et l'atomicité lors de l'envoi ou de la réception de plusieurs messages d'une file d'attente.

  • La durée de vie de la charge de travail spécifique à l'application peut être supérieure à sept jours.

  • Votre application traite les messages dont la taille peut dépasser 64 Ko, mais n'atteindra probablement pas la limite de 256 Ko.

  • Vous traitez une spécification pour fournir un modèle d'accès basé sur des rôles aux files d'attente, et des droits/autorisations différents pour les expéditeurs et les destinataires.

  • La taille de la file d'attente ne sera pas supérieure à 80 Go.

  • Vous voulez utiliser le broker de messagerie basé sur les normes AMQP 1.0. Pour plus d'informations sur AMQP, consultez Vue d'ensemble d’AMQP de Service Bus.

  • Vous prévoyez une migration éventuelle des communications point à point basées sur des files d'attente vers un modèle d'échange de messages qui permet l'intégration transparente des récepteurs (abonnés), chacun d'eux recevant des copies indépendantes de certains ou de tous les messages envoyés à la file d'attente. Ce dernier fait référence à la fonctionnalité de publication/abonné en mode natif fournie par Applet de commande.

  • Votre solution de messagerie doit pouvoir prendre en charge la garantie de remise « Une fois au maximum » sans avoir besoin de générer les composants supplémentaires de l'infrastructure.

  • Vous voulez pouvoir publier et utiliser des lots de messages.

  • Vous avez besoin de l'intégration complète avec la pile de communication Windows Communication Foundation (WCF) dans le .NET Framework.

Les tables des sections suivantes fournissent un regroupement logique des fonctionnalités de file d'attente et vous permettent de comparer, d'un seul coup d'œil, les fonctions disponibles dans les files d'attente Azure et les files d'attente Applet de commande.

Cette rubrique compare certaines des fonctions de mise en file d'attente de base fournies par les files d'attente Microsoft Azure et par les files d'attente Microsoft Azure Service Bus.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Garantie de classement

Non

Pour plus d'informations, consultez la première note de la section « Informations supplémentaires ».

Oui, selon le principe FIFO (premier entré/premier sorti)

(via l'utilisation des sessions de messagerie)

Garantie de remise

Une fois au minimum

Une fois au minimum

Une fois au maximum

Prise en charge des transactions

Non

Oui

(via l'utilisation de transactions locales)

Comportement de réception

Non bloquant

(s'effectue immédiatement si aucun nouveau message n'est trouvé)

Bloquant avec ou sans délai d'attente

(interrogation longue ou « technique des comètes »)

Non bloquant

(via l'utilisation de l'API managée .NET uniquement)

API de style Push

Non

Oui

OnMessage et API (.NET) managée OnMessage sessions.

Mode de réception

Peek & Lease

Peek & Lock

Receive & Delete

Mode d'accès exclusif

Basé sur le bail

Basé sur le verrou

Durée de bail/verrou

30 secondes (par défaut)

7 jours (maximum) (Vous pouvez renouveler ou libérer un bail de message à l'aide de l'API UpdateMessage.)

60 secondes (par défaut)

Vous pouvez renouveler un verrou de message à l'aide de l'API RenewLock.

Granularité de bail/verrou

Au niveau du message

(chaque message peut avoir une valeur de délai d'attente différente, que vous pouvez ensuite mettre à jour lors du traitement du message, à l'aide de l'API UpdateMessage)

Au niveau de la file d'attente

(chaque file d'attente a une granularité de verrouillage appliquée à tous les messages, mais vous pouvez renouveler le verrou à l'aide de l'API RenewLock.)

Réception par lots

Oui

(spécifiant explicitement le nombre de messages lors de la récupération des messages, avec un maximum de 32 messages)

Oui

(activant implicitement une propriété de prérécupération ou explicitement via l'utilisation de transactions)

Envoi par lots

Non

Oui

(via l'utilisation de transactions ou du traitement par lot côté client)

  • Les messages dans les files d'attente Azure sont généralement traités selon le principe du premier entré/premier sorti, mais il arrive qu'ils ne soient pas dans l'ordre correct. C'est le cas, par exemple, quand le délai d'attente de visibilité d'un message expire (par exemple, suite à une panne d'application cliente en cours de traitement). Lorsque le délai d'attente de visibilité expire, le message redevient visible sur la file d'attente afin qu'un autre utilisateur l'enlève de la file d'attente. À ce stade, le message redevenu visible peut se trouver dans la file d'attente (afin d'être enlevé une fois de plus) derrière un message placé à l'origine plus loin dans la file d'attente.

  • Si vous êtes prêt à utiliser les objets blob ou les tables du stockage Azure et que vous commencez à utiliser des files d'attente, une disponibilité de 99,9 % est garantie. Si vous utilisez des objets blobs ou des tables avec des files d'attente Applet de commande, la disponibilité est moins élevée.

  • Le modèle garanti FIFO dans les files d'attente Applet de commande nécessite l'utilisation de sessions de messagerie. Au cas où l'application se bloquerait lors du traitement d'un message reçu en mode Peek & Lock, la prochaine fois qu'un récepteur de file d'attente acceptera une session de messagerie, elle démarrera avec le message ayant échoué après l'expiration de sa durée de vie.

  • Les files d'attente Azure sont destinées à prendre en charge les scénarios de mise en file d'attente standard, tels que le découplage des composants d'application pour augmenter l'évolutivité et la tolérance des échecs, le lissage de charge et la création de flux de travail de traitement.

  • Les files d'attente Applet de commande prennent en charge la garantie de remise Une fois au minimum. En outre, la sémantique Une fois au maximum peut être pris en charge en utilisant l'état de session pour stocker l'état de l'application et en utilisant des transactions pour recevoir les messages de manière atomique et mettre à jour l'état de session. Azure Workflow Service utilise cette technique pour garantir la remise Une fois au maximum.

  • Les files d'attente Azure fournissent un modèle de programme uniforme et cohérent entre les files d'attente, les tables et les objets blob, à la fois pour les développeurs et pour les équipes d'exploitation.

  • Les files d' attente Applet de commande fournissent la prise en charge des transactions locales dans le contexte d'une seule file d'attente.

  • Le mode de réception et de suppression pris en charge par Applet de commande permet de réduire le nombre d'opérations de messagerie (et le coût associé) en échange d'une garantie de remise plus faible.

  • Les files d'attente Azure fournissent des baux avec la possibilité d'étendre les baux de messages. Cela permet aux threads de travail de maintenir des baux de courte durée sur les messages. Par conséquent, si un thread de travail se bloque, le message peut être rapidement traité par un autre thread de travail. En outre, un thread de travail peut étendre le bail sur un message s'il doit le traiter pendant plus longtemps que la durée de bail actuelle.

  • Les files d'attente Azure offrent un délai d'expiration de la visibilité que vous pouvez définir lors de l'empilage ou du dépilage d'un message. En outre, vous pouvez mettre à jour un message avec des valeurs de bail différentes au moment de l'exécution, puis mettre à jour des valeurs différentes dans plusieurs messages de la même file d'attente. Les délais d'expiration de verrou de Applet de commande sont définis dans les métadonnées de file d'attente. Toutefois, vous pouvez renouveler le verrou en appelant la méthode RenewLock.

  • Le délai d'attente maximal pour une opération de réception bloquante dans les files d'attente Applet de commande est de 24 jours. Toutefois, les délais d'expiration basés sur REST ont une valeur maximale de 55 secondes.

  • Le traitement côté client fourni par Applet de commande permet à un client de file d'attente de mettre en lot plusieurs messages dans une seule opération d'envoi. Le traitement par lot est disponible uniquement pour les opérations d'envoi asynchrones.

  • Des fonctionnalités telles que la limite de 200 To des files d'attentes Azure (et davantage lorsque vous virtualisez des comptes) ainsi que les files d'attentes illimitées en font une plateforme idéale pour les fournisseurs SaaS.

  • Les files d'attente Azure offrent un mécanisme de contrôle d'accès délégué performant et flexible.

Cette rubrique compare les fonctionnalités avancées fournies par les files d'attente Azure et les files d'attente Applet de commande.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Remise planifiée

Oui

Oui

Lettre morte automatique

Non

Oui

Augmentation de la valeur de la durée de vie de la file d'attente

Oui

(via la mise à jour sur place du délai d'expiration de la visibilité)

Oui

(fourni par le biais d'une fonction API dédiée)

Prise en charge des messages incohérents

Oui

Oui

Mise à jour sur place

Oui

Oui

Journal des transactions côté serveur

Oui

Non

Mesures de stockage

Oui

Mesure des minutes : fournit des mesures en temps réel pour la disponibilité, TPS, le nombre d'appels d'API, le nombre d'erreurs, etc. (agrégés par minute et rapportés dans les minutes suivant les dernières opérations effectuées en production). Pour plus d'informations, consultez À propos des métriques Storage Analytics.

Oui

(requêtes en bloc par l'appel de GetQueues)

Gestion des états

Non

Oui

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

Transfert automatique des messages

Non

Oui

Fonction de purge de file d'attente

Oui

Non

Groupes de messages

Non

Oui

(via l'utilisation des sessions de messagerie)

État d'application par groupe de messages

Non

Oui

Détection de doublons

Non

Oui

(configurable du côté expéditeur)

Intégration de WCF

Non

Oui

(liaisons WCF prêtes à l'emploi)

Intégration de WF

Personnalisé

(nécessite la génération d'une activité WF personnalisée)

Natif

(activités WF prêtes à l'emploi)

Recherche de groupes de messages

Non

Oui

Récupération des sessions de message par ID

Non

Oui

  • Les deux technologies de mise en file d'attente permettent de planifier la remise ultérieure d'un message.

  • Le transfert automatique des files d'attente permet à des milliers de files d'attente de transférer automatiquement leurs messages à une file d'attente unique, d'où l'application de destination consomme le message. Vous pouvez utiliser ce mécanisme pour mettre en place la sécurité, contrôler les flux et isoler le stockage entre chaque éditeur de message.

  • Les files d' attente Azure fournissent la prise en charge de la mise à jour du contenu du message. Cette fonctionnalité peut être utilisée pour les informations d'état persistantes et les mises à jour incrémentielles de progression dans le message, de façon à ce que celui-ci puisse être traité à partir du dernier point de contrôle connu et non à partir du début. Les files d'attente Applet de commande vous permettent d'activer le même scénario en utilisant des sessions de message. Les sessions vous permettent d'enregistrer et de récupérer l'état de traitement de l'application (à l'aide de SetState et GetState).

  • Les lettres mortes, qui ne sont prises en charge que par les files d'attente Applet de commande, peuvent se révéler utiles pour isoler les messages qui ne peuvent pas être traités correctement par l'application de destination ou lorsque des messages n'atteignent pas leur destination en raison de l'expiration de leur propriété de durée de vie. La valeur de durée de vie indique combien de temps un message reste dans la file d'attente. Avec Applet de commande, le message est déplacé vers une file d'attente spéciale appelée $DeadLetterQueue lorsque la durée de vie expire.

  • Pour rechercher des messages incohérents dans les files d'attente Azure, lors du dépilage d'un message, l'application examine la propriété DequeueCount du message. Si DequeueCount est au-dessus d'un seuil donné, l'application déplace le message vers une file d'attente de lettres mortes définie par l'application.

  • Les files d'attente Azure vous permettent d'obtenir un journal détaillé de toutes les transactions exécutées sur la file d'attente, ainsi que des mesures agrégées. Ces deux options sont utiles pour déboguer et comprendre comment votre application utilise des files d'attente Azure. Ils sont également utiles pour le réglage des performances de votre application et la réduction des coûts d'utilisation des files d'attente.

  • Le concept de « sessions de message » pris en charge par Applet de commande autorise les messages appartenant à un certain groupe logique à être associés à un destinataire spécifique, qui crée ensuite une affinité de session entre les messages et leurs destinataires respectifs. Vous pouvez activer cette fonctionnalité avancée dans Applet de commande en définissant la propriété SessionID sur un message. Les récepteurs peuvent ensuite écouter un ID de session spécifique et recevoir des messages qui partagent l'identificateur de session spécifié.

  • La fonctionnalité de détection des valeurs dupliquées prise en charge par les files d'attente Applet de commande supprime automatiquement les messages en double envoyés à une file d'attente ou à une rubrique, selon la valeur de la propriété MessageID.

Cette section compare les files d'attente Azure et Applet de commande du point de vue de la capacité et des quotas qui peuvent s'appliquer.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Taille de file d'attente maximale

200 To

(limitée à la capacité d'un seul compte de stockage)

1 Go à 80 Go

(défini lors de la création d'une file d'attente et l'activation du partitionnement)

Taille de message maximale

64 Ko

(48 Ko lors de l'utilisation de l'encodage Base64)

Azure prend en charge les messages volumineux en combinant des files d'attente et des objets blob. Vous pouvez alors mettre en file d'attente jusqu'à 200 Go pour un seul élément.

256 Ko

(y compris l'en-tête et le corps, taille maximale d'en-tête : 64 Ko)

Durée de vie de message maximale

7 jours

Illimité

Nombre maximal de files d'attente

Illimité

10,000

(par espace de noms de services, peut être augmenté)

Nombre maximal de clients simultanés

Illimité

Illimité

(le nombre maximal de 100 connexions simultanées s'applique uniquement aux communications basées sur le protocole TCP)

  • Avec les files d'attente Azure, si le contenu du message n'est pas reconnu comme étant du XML sûr, il doit être encodé en Base64. Si vous encodez le message en Base64, la charge utile pour l'utilisateur peut comporter jusqu'à 48 Ko, au lieu de 64 Ko.

  • Avec les files d'attente Applet de commande, chaque message stocké dans une file d'attente est composé de deux parties : un en-tête et un corps. La taille totale du message ne peut pas dépasser 256 Ko.

  • Lorsque les clients communiquent avec les files d'attente Applet de commande via le protocole TCP, le nombre maximal de connexions simultanées dans une même file d'attente de Applet de commande est limité à 100. Ce nombre est réparti entre les expéditeurs et les destinataires. Si le quota est atteint, les requêtes suivantes de connexions supplémentaires sont rejetées et une exception est acceptée par le code appelant. Cette limite n'est pas appliquée aux clients qui se connectent aux files d'attente de l'API REST.

  • Applet de commande impose des limites de taille de file d'attente. La taille de file d'attente maximale est spécifiée lors de la création de la file d'attente. Sa valeur peut être comprise entre 1 et 80 Go. Si la valeur de taille de la file d'attente définie lors de la création de la file d'attente est atteinte, les messages entrants supplémentaires seront rejetés et une exception sera reçue par le code appelant. Pour plus d'informations sur les quotas dans Applet de commande, consultez Quotas Service Bus.

  • Si vous avez besoin de plus de 10 000 files d'attente dans un seul Applet de commande espace de noms de service, contactez l'équipe de support de Azure et demandez une augmentation de ce nombre. Pour faire évoluer ce nombre au-delà de 10 000 files d'attente avec Applet de commande, vous pouvez également créer des espaces de noms de service supplémentaires à l'aide du Portail de gestion Microsoft Azure.

Cette section compare les fonctionnalités de gestion fournies par les files d'attente Azure et par les files d'attente Applet de commande.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Protocole de gestion

REST sur HTTP/HTTPS

REST sur HTTPS

Protocole d'exécution

REST sur HTTP/HTTPS

REST sur HTTPS

AMQP 1.0 Standard (TCP et TLS)

API managée .NET

Oui

(API du client de stockage managée .NET)

Oui

(API de messagerie répartie managée .NET)

C++ natif

Oui

Non

API Java

Oui

Oui

API PHP

Oui

Oui

API Node.js

Oui

Oui

Prise en charge de métadonnées arbitraires

Oui

Non

Règles de dénomination de file d'attente

Au plus 63 caractères

(les lettres d'un nom de file d'attente doivent être en minuscules)

Au plus 260 caractères

(les noms de files d'attente ne respectent pas la casse)

Fonction d'obtention de la longueur de file d'attente

Oui

(valeur approximative si les messages expirent après la date d'expiration de la durée de vie sans être supprimés)

Oui

(valeur exacte, dans le temps)

Fonction Peek

Oui

Oui

  • Les files d' attente Azure prennent en charge les attributs arbitraires qui peuvent être appliqués à la description de la file d'attente, sous forme de paires nom/valeur.

  • Les deux technologies de mise en file d'attente offrent également la possibilité d'avoir un aperçu du message sans avoir à le verrouiller, ce qui est parfois très utile lors de l'implémentation d'un outil explorateur/navigateur de files d'attente.

  • Les API de messagerie répartie managées .NET de Applet de commande tirent parti des connexions TCP simultanées et bi-directionnelles pour améliorer les performances par rapport à l'utilisation de REST sur HTTP. Elles prennent également en charge le protocole standard AMQP 1.0.

  • Les noms des files d'attente Azure peuvent comporter entre 3 et 63 caractères et contenir des lettres minuscules, des chiffres et des tirets. Pour plus d'informations, consultez Affectation de noms pour les files d'attente et les métadonnées.

  • Les noms des files d'attente Applet de commande peuvent comporter jusqu'à 260 caractères et obéissent à des règles d'attribution de noms moins restrictives. Les noms des files d'attente Applet de commande peuvent contenir des lettres, des chiffres, des points (.), des tirets (-) et des caractères de soulignement (_).

Cette section compare les files d'attente Azure et les files d'attente Applet de commande du point de vue des performances.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Débit maximal

Jusqu'à 2 000 messages par seconde

(selon le test d'évaluation avec des messages de 1 Ko)

Jusqu'à 2 000 messages par seconde

(selon le test d'évaluation avec des messages de 1 Ko)

Latence moyenne

10 ms

(avec TCP Nagle désactivé)

20-25 ms

Comportement de limitation

Rejeter avec le code d'erreur HTTP 503

(les demandes limitées ne sont pas traitées comme facturables)

Rejeter avec l'exception/le code HTTP 503

(les demandes limitées ne sont pas traitées comme facturables)

  • Une file d'attente Azure peut traiter jusqu'à 2 000 transactions par seconde. Une transaction est soit une opération Put, Get ou Delete. Envoyer un seul message à une file d'attente (Put) est comptabilisé comme une transaction, mais recevoir un message est souvent un processus en deux étapes impliquant la récupération (Get), suivi d'une demande de suppression du message de la file d'attente (Delete). Par conséquent, un échec de l'opération de dépilage implique généralement deux transactions. La récupération de plusieurs messages dans un lot atténue l'impact, puisque vous pouvez Get jusqu'à 32 messages en une seule transaction, suivie d'une opération Delete pour chacun. Pour améliorer le débit, vous pouvez créer plusieurs files d'attente (un compte de stockage peut avoir un nombre illimité de files d'attente).

  • Lorsque votre application atteint le débit maximal pour une file d'attente Azure, une réponse « HTTP 503 Serveur occupé » est généralement renvoyée par le service de la file d'attente. Dans ce cas, l'application doit déclencher la logique de nouvelle tentative avec un délai de temporisation exponentiel.

  • La latence des files d'attente Azure est en moyenne de 10 millisecondes lors de la gestion de messages de petite taille (inférieure à 10 Ko) depuis un service hébergé situé dans le même emplacement (région) que le compte de stockage.

  • Les files d'attente Azure et les files d'attente Applet de commande assurent le comportement de limitation en refusant des requêtes dans une file d'attente qui est limitée. Toutefois, aucune d'entre elles ne traite les requêtes limitées comme facturables.

  • Les tests d'évaluation sur les files d'attente de Applet de commande ont démontré qu'une seule file d'attente pouvait atteindre un débit de 2 000 messages par seconde avec une taille de message d'environ 1 Ko. Pour obtenir un débit plus élevé, utilisez plusieurs files d'attente. Pour plus d'informations sur l'optimisation des performances avec Applet de commande, consultez Meilleures pratiques relatives aux améliorations de performances à l'aide de la messagerie répartie Service Bus.

  • Lorsque le débit maximal est atteint pour une file d'attente de Applet de commande, une ServerBusyException (lors de l'utilisation de l'API de messagerie répartie managée .NET) ou la réponse HTTP 503 (lors de l'utilisation de l'API REST) est renvoyée au client de file d'attente, indiquant que la file d'attente est limitée.

Cette section traite des fonctionnalités d'authentification et d'autorisation prises en charge par les files d'attente Azure et les files d'attente Applet de commande.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Authentification

Clé symétrique

Clé symétrique

Modèle de contrôle d'accès

Accès délégué via des jetons SAS.

RBAC (contrôle d'accès basé sur les rôles) via ACS

Fédération de fournisseur d'identité

Non

Oui

  • Chaque demande à l'une des technologies de mise en file d'attente doit être authentifiée. Les files d'attente publiques à accès anonyme ne sont pas prises en charge. Avec SAS, vous pouvez traiter ce scénario en publiant un SAS en écriture seule, un SAS en lecture seule ou encore un SAS en accès total.

  • Le schéma d'authentification fourni par les files d'attente Azure implique l'utilisation d'une clé symétrique, qui est un code d'authentification de message basé sur le hachage (HMAC), calculée avec l'algorithme SHA-256 et encodée sous forme de chaîne Base64. Pour plus d'informations sur les protocoles respectifs, consultez Authentification de l'accès à votre compte de stockage. Les files d'attente Applet de commande prennent en charge un modèle similaire en utilisant des clés symétriques. Pour plus d'informations, consultez Authentification avec signature d'accès partagé avec Service Bus.

  • Le Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS) pris en charge par Applet de commande offre trois rôles distincts : Administrateur, Expéditeur et Destinataire, ce qui n'est pas encore pris en charge pour les files d'attente Azure pour le moment.

  • Applet de commande offrant l'intégration ACS, il autorise la fédération avec Active Directory (via l'utilisation d'ADFS) et les fournisseurs d'identité Web communs, tels que Live ID, Google, Facebook et Yahoo.

Cette section compare les files d'attente Azure et les files d'attente Applet de commande du point de vue des coûts.

 

Critères de comparaison Files d'attente de Azure Files d'attente de Applet de commande

Coût de transaction de file d'attente

$0.0005

(par 10 000 transactions)

$0.01

(par 10 000 messages)

Opérations facturables

Tous

Envoi/réception uniquement

(aucun frais pour les autres opérations)

Transactions inactives

Facturable

(interroger une file d'attente vide est comptabilisé comme une transaction facturable)

Facturable

(une opération de réception sur une file d'attente vide est considérée comme un message facturable)

Coût de stockage

$0.07

(par Go/mois)

$0.00

Coûts de transfert des données sortantes

$0.12 - $0.19

(selon la géographie)

$0.12 - $0.19

(selon la géographie)

  • Les transferts de données sont facturés en fonction de la quantité totale de données qui quittent les centres de données Azure via Internet dans une période donnée de facturation.

  • Les transferts de données entre les services Azure situés dans la même région ne sont pas soumis à facturation.

  • À la date de rédaction de ce document, les transferts de données entrants ne sont pas soumis à facturation.

  • Le coût des transactions ACS est insignifiant lorsque vous exécutez des opérations de messagerie sur des files d'attente Applet de commande. Applet de commande acquiert un jeton ACS par instance de l'objet de fabrique de messagerie. Le jeton est alors réutilisé jusqu'à ce qu'il expire, après environ 20 minutes. Par conséquent, le volume des opérations de messagerie dans Applet de commande n'est pas directement proportionnel au volume de transactions ACS requis pour prendre en charge ces opérations.

  • Étant donné la prise en charge de l'interrogation longue, utiliser des files d'attente Applet de commande peut être rentable dans les situations où la remise à latence faible est requise.

noteRemarque
Tous les coûts peuvent faire l'objet de modifications. Le tableau ci-dessus reflète la tarification actuelle à la date de rédaction de cet article et ne comporte aucune offre promotionnelle qui peut être actuellement disponible. Pour obtenir les informations de tarification à jour, consultez la page relative à la présentation de la facturation.

Le choix entre utiliser des files d'attente Azure ou des files d'attente Applet de commande dépend de plusieurs facteurs. Ces facteurs dépendent largement des différents besoins de votre application et de son architecture. Si votre application utilise déjà les principales fonctions de Microsoft Azure, vous préfèrerez peut-être choisir des files d'attente Azure, surtout si vous avez besoin de fonctionnalités de communication et de messagerie de base entre les services ou de files d'attente dont la taille peut dépasser 80 Go.

Les files d'attente Applet de commande fournissant plusieurs fonctionnalités avancées, telles que les sessions, les transactions, la détection des doublons, les lettres mortes automatiques, ainsi que des fonctions de publication/abonnement durables, elles peuvent être votre choix par défaut lorsque vous développez une application hybride ou si votre application nécessite ces fonctionnalités.

Cet article a débuté par un résumé des recommandations normatives, puis a répertorié et comparé les fonctionnalités de chaque technologie de mise en file d'attente offertes par Azure. En répertoriant les fonctionnalités dans des groupes fonctionnels, la rubrique a présenté une analyse côte à côte visuellement intéressante qui peut vous aider à comprendre les ressemblances et les différences entre les files d'attente Azure et les files d'attente Applet de commande. En ayant une meilleure compréhension des deux technologies, vous pouvez prendre une décision en toute connaissance concernant la technologie de file d'attente à utiliser et à quel moment.

Voir aussi

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft