VENTES: 1-800-867-1389

Création d'applications qui utilisent des rubriques et des abonnements Service Bus

Mis à jour: octobre 2014

Auteur : David Ingham

Réviseurs : Seth Manheim

La version de septembre 2011 de Microsoft Azure Service Bus comprend un nouvel ensemble de technologies middleware orientées messages basées sur le cloud qui offrent des fonctionnalités de mise en file d'attente des messages fiable ainsi que des fonctionnalités de publication/abonnement durables. Cet article repose sur les informations fournies sur la page Création d'applications qui utilisent des files d'attente Service Bus et présente les fonctionnalités de publication/abonnement offertes par les rubriques Service Bus. Cet article n'a pas vocation à couvrir toutes les fonctionnalités de Service Bus. Il contient toutefois des informations de base pour commencer à utiliser cette nouvelle fonctionnalité.

Cet article poursuit le scénario de vente au détail présenté sur la page Création d'applications qui utilisent des files d'attente Service Bus. Pour rappel, les données de vente des terminaux de point de vente (PDV) doivent être acheminées vers un système de gestion des stocks qui utilise ces données pour déterminer quand le stock doit être reconstitué. Chaque terminal de PDV transmet ses données de vente en envoyant des messages à la file d'attente DataCollectionQueue. Ceux-ci y restent jusqu'à ce que le système de gestion des stocks les reçoive, comme illustré ici :

Service Bus1

Dans notre scénario, une nouvelle exigence est ajoutée au système : le propriétaire du magasin souhaite surveiller les performances de celui-ci en temps réel.

Pour satisfaire cette exigence, le système doit « puiser » des informations dans le flux de données de vente. Ici encore, chacun des messages envoyés par les terminaux de PDV doit être transmis au système de gestion des stocks. En outre, une copie supplémentaire de chaque message doit être utilisée pour présenter l'affichage du tableau de bord au propriétaire du magasin.

Pour permettre à différentes parties d'utiliser un même message, vous pouvez utiliser la fonctionnalité de rubrique Service Bus. Les rubriques offrent un schéma de publication/abonnement dans lequel chaque message publié est mis à la disposition d'un ou plusieurs abonnements enregistrés auprès de la rubrique. En comparaison, avec les files d'attente, chaque message est reçu par un seul consommateur.

Qu'il s'agisse d'une rubrique ou d'une file d'attente, le processus d'envoi des messages est identique. En revanche, ce sont les abonnements et non les rubriques qui reçoivent les messages. Vous pouvez considérer un abonnement à une rubrique comme une file d'attente virtuelle qui reçoit des copies des messages envoyés à cette rubrique. Le processus de réception des messages est identique pour les abonnements et les files d'attente.

Revenons à notre scénario : la première étape consiste à remplacer la file d'attente par une rubrique et à y ajouter un abonnement qui sera utilisé par le composant Système de gestion des stocks. Le système se présente maintenant comme suit :

Service Bus2

La configuration est ici identique à celle de la précédente conception basée sur les files d'attente. Les messages envoyés à la rubrique sont dirigés vers l'abonnement Inventory (Stock), à partir duquel ils sont utilisés par le système de gestion des stocks.

Pour prendre en charge le tableau de bord de gestion, nous devons créer un deuxième abonnement sur la rubrique, comme illustré ici :

Service Bus3

Dans cette configuration, chacun des messages des terminaux de PDV est mis à la disposition des abonnements Dashboard (Tableau de bord) et Inventory (Stock).

Création d'applications qui utilisent des files d'attente Service Bus explique comment créer un compte Service Bus et un espace de noms de service. Pour utiliser l'espace de noms de service Service Bus, une application doit faire référence à l'assembly Service Bus, et plus spécifiquement à Microsoft.ServiceBus.dll. Cet assembly fait partie du Kit de développement logiciel (SDK) des bibliothèques clientes pour .NET. Au moment de la rédaction de ce document, la version en cours était la version 1.6 publiée en novembre 2011. Cette version peut être téléchargée sur la page de téléchargement Kit de développement Azure (SDK).

Les opérations de gestion des entités de messagerie Service Bus (files d'attente et rubriques de publication/abonnement) s'effectuent via la classe NamespaceManager. Service Bus utilise un modèle de sécurité basée sur des demandes implémenté à l'aide de Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS). Des informations d'identification appropriées sont nécessaires pour créer une instance NamespaceManager pour un espace de noms de service particulier. La classe TokenProvider représente un fournisseur de jeton de sécurité avec des méthodes de fabrique intégrées retournant quelques fournisseurs de jeton bien connus. Nous utiliserons une classe SharedSecretTokenProvider pour stocker les informations d'identification de secret partagé et gérer l'acquisition des jetons appropriés à partir du service ACS. L'instance NamespaceManager est ensuite construite avec l'adresse de base de l'espace de noms de service Service Bus et du fournisseur de jeton.

La classe NamespaceManager fournit des méthodes pour créer, énumérer et supprimer des entités de messagerie. L'extrait de code présenté ici montre comment l'instance NamespaceManager est créée et utilisée pour créer la rubrique DataCollectionTopic.

Uri uri = ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);
    string name = "owner";
    string key = "abcdefghijklmopqrstuvwxyz";
     
    TokenProvider tokenProvider = TokenProvider.CreateSharedSecretTokenProvider(name, key);
    NamespaceManager namespaceManager = new NamespaceManager(uri, tokenProvider);
 
    namespaceManager.CreateTopic("DataCollectionTopic");

Notez qu'il existe des surcharges de la méthode CreateTopic qui vous permettent de définir les propriétés de la rubrique. Vous pouvez par exemple définir la valeur de durée de vie (TTL) par défaut des messages envoyés à la rubrique. Ajoutez ensuite les abonnements Inventory et Dashboard.

namespaceManager.CreateSubscription("DataCollectionTopic", "Inventory");
    namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard");

Pour les opérations d'exécution sur les entités Service Bus, par exemple l'envoi et la réception de messages, une application doit d'abord créer un objet MessagingFactory. Semblable à la classe NamespaceManager, l'instance MessagingFactory est construite à partir de l'adresse de base de l'espace de noms de service et du fournisseur de jeton.

MessagingFactory factory = MessagingFactory.Create(uri, tokenProvider);

Les messages que les rubriques Service Bus envoient et reçoivent sont des instances de la classe BrokeredMessage. Cette classe se compose d'un jeu de propriétés standard (telles que Label et TimeToLive), d'un dictionnaire contenant les propriétés d'applications et d'un corps de données d'applications arbitraires. Une application peut définir le corps en passant tout objet sérialisable (l'exemple qui suit passe un objet SalesData qui représente les données de ventes du terminal de PDV), qui utilisera DataContractSerializer pour sérialiser l'objet. En guise d'alternative, vous pouvez fournir un objet Stream.

BrokeredMessage bm = new BrokeredMessage(salesData);
    bm.Label = "SalesReport";
    bm.Properties["StoreName"] = "Redmond";
    bm.Properties["MachineID"] = "POS_1";

Pour envoyer des messages à la rubrique, le plus simple consiste à utiliser CreateMessageSender pour créer directement un objet MessageSender depuis l'instance MessagingFactory.

MessageSender sender = factory.CreateMessageSender("DataCollectionQueue");
    sender.Send(bm);

Comme avec les files d'attente, pour recevoir des messages d'un abonnement, le plus simple consiste à utiliser un objet MessageReceiver, que vous pouvez créer directement à partir de la fabrique MessagingFactory à l'aide de CreateMessageReceiver. Vous pouvez utiliser un des deux modes de réception (ReceiveAndDelete et PeekLock), comme indiqué sur la page Création d'applications qui utilisent des files d'attente Service Bus.

Notez que lorsque vous créez un MessageReceiver pour les abonnements, le paramètre entityPath se présente sous la forme topicPath/subscriptions/subscriptionName. Par conséquent, pour créer un MessageReceiver pour l'abonnement Inventory de la rubrique DataCollectionTopic, entityPath doit être DataCollectionTopic/subscriptions/Inventory. Le code se présente comme suit :

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionTopic/subscriptions/Inventory");
    BrokeredMessage receivedMessage = receiver.Receive();
    try
    {
        ProcessMessage(receivedMessage);
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        receivedMessage.Abandon();
    }

Jusqu'à présent, dans cet article, tous les messages envoyés à la rubrique ont été mis à la disposition de l'ensemble des abonnements enregistrés. Les maîtres mots sont ici « mis à la disposition ». Les abonnements Service Bus voient tous les messages envoyés à la rubrique, mais vous pouvez vous contenter de copier un sous-ensemble de ces messages dans la file d'attente virtuelle des abonnements. Pour ce faire, vous devez utiliser des filtres d'abonnement. Lorsque vous créez un abonnement, vous pouvez fournir une expression de filtre sous la forme d'un prédicat de type SQL92 qui opère via les propriétés du message, les propriétés système (par exemple, Label) et les propriétés d'application, comme StoreName dans l'exemple précédent.

Pour illustrer ceci, nous allons faire évoluer notre scénario de vente au détail et ajouter un deuxième magasin. Les données de vente de l'ensemble des terminaux de PDV des deux magasins doivent toujours être acheminées vers le système de gestion des stocks centralisé, mais le responsable d'un des deux magasins, qui utilise l'outil de tableau de bord, s'intéresse ici uniquement aux performances de son magasin. Vous pouvez donc utiliser le filtrage d'abonnement. Notez que lorsque les terminaux de PDV publient des messages, ils définissent la propriété d'application StoreName sur le message. Avec deux magasins, par exemple Redmond et Seattle, les terminaux de PDV du magasin de Redmond procèdent à l'horodatage de leurs messages de données de vente en définissant le paramètre StoreName sur Redmond tandis que les terminaux de PDV du magasin de Seattle définissent le paramètre StoreName sur Seattle. Le responsable du magasin de Redmond souhaite uniquement voir les données des terminaux de PDV de son magasin. Le système se présente comme suit :

Service Bus4

Pour configurer ce routage, vous créez l'abonnement Dashboard comme suit :

SqlFilter dashboardFilter = new SqlFilter("StoreName = ‘Redmond’");
  namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard", dashboardFilter);

Avec ce filtre d'abonnement, seuls les messages dont la propriété StoreName est définie sur Redmond sont copiés dans la file d'attente virtuelle de l'abonnement Dashboard. Mais les possibilités offertes par le filtrage d'abonnement ne s'arrêtent pas là. Outre la capacité à modifier les propriétés d'un message lorsqu'il est transféré vers la file d'attente virtuelle d'un abonnement, les applications peuvent comporter plusieurs règles de filtrage par abonnement.

Grâce à cet article, vous avez pu commencer à utiliser la fonctionnalité de publication/abonnement basée sur une rubrique introduite dans Service Bus.

Tous les critères d'utilisation de la mise en file d'attente décrits sur la page Création d'applications qui utilisent des files d'attente Service Bus s'appliquent également aux rubriques, notamment :

  • Découplage temporel : il n'est pas nécessaire que les producteurs et consommateurs de messages soient connectés en même temps.

  • Nivellement de la charge : les pics de charge sont nivelés par la rubrique, ce qui permet de configurer les applications consommatrices pour une charge moyenne au lieu d'une charge maximale.

  • Équilibrage de charge : comme pour les files d'attente, plusieurs consommateurs concurrents peuvent écouter un même abonnement et chaque message est transféré à un seul consommateur, ce qui équilibre la charge.

  • Faible couplage : vous pouvez faire évoluer le réseau de messagerie sans affecter les points de terminaison existants. Par exemple, vous pouvez ajouter des abonnements ou modifier les filtres d'une rubrique pour autoriser de nouveaux consommateurs.

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