Fonctionnalités de Service Broker

Conversations

La technologie Service Broker est conçue à partir des fonctions élémentaires d'envoi et de réception des messages. Chaque message fait partie d'une conversation Chaque conversation est un canal de communication permanent et fiable. Les messages, comme les conversations, présentent un type spécifique dont Service Broker assure la mise en œuvre pour aider les développeurs dans l'écriture d'applications fiables.

De nouvelles instructions Transact-SQL permettent aux applications d'envoyer et de recevoir ces messages selon une méthode éprouvée. Une application envoie des messages à un service, désignation sous laquelle est regroupé un ensemble de tâches connexes. Une application reçoit des messages depuis une file d'attente, qui n'est autre qu'une vue de table interne.

Les messages d'une même tâche font partie de la même conversation. Service Broker s'assure dans chaque conversation qu'une application reçoit tous les messages qui lui sont destinés une seule et unique fois, selon leur ordre d'envoi. Le programme responsable de la mise en œuvre d'un service peut associer les conversations connexes d'un même service dans un groupe de conversations, comme décrit dans la rubrique Avantages de Service Broker.

La sécurité basée sur les certificats permet de protéger les messages confidentiels et de contrôler l'accès aux services. Pour comprendre le fonctionnement de Service Broker, comparez-le à un service postal. Pour entretenir une conversation avec un collègue éloigné, vous communiquez au moyen de lettres que vous postez. Le service postal trie les lettres, puis les distribue. Votre collègue et vous-même récupérez ensuite le courrier qui vous est adressé dans vos boîtes aux lettres respectives. Vous lisez votre courrier, y répondez par l'intermédiaire d'une nouvelle lettre envoyée et ce jusqu'à ce que la conversation s'achève. La remise du courrier s'effectue de façon asynchrone tandis que votre collègue et vous êtes occupés à d'autres tâches.

Les programmes peuvent utiliser Service Broker comme un service postal pour prendre en charge des conversations asynchrones avec d'autres programmes. Les messages Service Broker fonctionnent comme des lettres. Un service de Service Broker correspond à l'adresse à laquelle le bureau de poste distribue le courrier. Les files d'attente sont les boîtes aux lettres dans lesquelles sont conservés les courriers une fois distribués. Les applications reçoivent les messages, agissent conformément à leur contenu et envoient les réponses.

Lorsqu'une application envoie un message à un service de Service Broker, il est isolé des détails d'implémentation de l'application à l'autre extrémité de la conversation. L'application de destination peut être reconfigurée ou remplacée dynamiquement par un nouveau code sans affecter l'application émettrice. L'application de destination peut même être arrêtée temporairement ; la seule conséquence est que Service Broker continue à ajouter de nouveaux messages à la file d'attente jusqu'à ce que l'application de destination soit redémarrée.

Classement et coordination des messages

Service Broker gère les files d'attente (technique de programmation de base de données active) différemment d'un produit classique, selon les deux axes clés suivants :

• Les files d'attente Service Broker sont intégrées à la base de données.

• Les files d'attente coordonnent et organisent les messages connexes.

L'utilisation de files d'attente intégrées signifie que la maintenance et l'administration d'une base de données normale incluent également Service Broker. En règle générale, un administrateur n'assure aucune opération de maintenance courante associée à Service Broker.

L'infrastructure Service Broker fournit une interface Transact-SQL simple (envoi et réception de messages), combinée à un ensemble de garanties solides dont le but est de protéger la remise et le traitement des messages. Service Broker veille à ce qu'un programme reçoive chaque message d'une conversation une seule et unique fois, en faisant respecter l'ordre selon lequel les messages ont été envoyés, et non l'ordre de leur intégration à la file d'attente. Dans les produits classiques, la mise en file d'attente s'effectue suivant l'ordre d'arrivée des messages dans la file d'attente. Cette pratique oblige l'application à déterminer un ordre et un regroupement des messages. Service Broker garantit que deux lecteurs de files d'attente ne peuvent pas traiter simultanément les messages provenant de la même conversation ou du même groupe de conversations connexes.

Chaque conversation Service Broker comporte deux parties. La partie qui démarre la conversation est appelée l'initiateur ; l'autre partie est appelée la cible. Chaque partie a un service ; le service initiateur et le service cible. Chaque service est associé à une file d'attente de messages.

Le scénario suivant illustre l'échange de messages dans une conversation classique :

• Au niveau de l'initiateur :

  • Un programme lance la conversation.

  • Le programme génère un message qui contient les données requises pour effectuer une tâche.

  • Le programme envoie le message au service cible.

• Au niveau de la cible :

  • Le message est placé dans la file d'attente associée au service cible.

  • Un programme reçoit le message par le biais de la file d'attente et effectue le travail.

  • Le programme répond en envoyant un message au service initiateur.

• Au niveau de l'initiateur :

  • Le message de réponse est placé dans la file d'attente associée au service initiateur.

  • Un programme reçoit la réponse et la traite.

Ce cycle se répète jusqu'à ce que l'initiateur termine la conversation, car il n'a plus de demandes à envoyer à la cible.

Service Broker prend en charge la définition de priorités qui varient entre 10 (élevée) et 1 (faible) pour chaque conversation. Cela garantit que le travail de priorité faible ne bloque pas le travail de priorité élevée. Les systèmes Service Broker peuvent être configurés pour offrir différents niveaux de service. Pour plus d'informations, consultez Priorités de conversation.

Service Broker gère les tâches les plus difficiles qui sont liées à l'écriture d'applications de messagerie. Ces tâches difficiles incluent la coordination et la remise fiable des messages, le verrouillage et le lancement des lecteurs de file d'attente. Les développeurs de base de données peuvent ainsi se consacrer à la résolution des problèmes liés à l'activité de l'entreprise.

Programmation asynchrone transactionnelle

Dans l'infrastructure Service Broker, la remise des messages entre les applications est de nature transactionnelle et asynchrone. De ce fait, si une transaction est restaurée dans une messagerie Service Broker, toutes les opérations Service Broker incluses dans la transaction sont restaurées. Les opérations d'envoi et de réception sont comprises. Dans une remise asynchrone, le Moteur de base de données gère la remise des messages tandis que l'application poursuit son exécution. Pour gagner en évolutivité, Service Broker fournit des mécanismes assurant le démarrage automatique de programmes dédiés au traitement d'une file d'attente dès que cela s'avère nécessaire. Pour plus d'informations, consultez Activation Service Broker.

La programmation asynchrone constitue une aide pour les développeurs qui écrivent des applications utilisant des files d'attente. De nombreuses applications de base de données contiennent des tables dont le fonctionnement est similaire à celui des files d'attente de travaux à accomplir en fonction des ressources disponibles. Les files d'attente peuvent présenter deux avantages pour les applications de base de données :

• Une application peut répondre à un utilisateur interactif immédiatement après avoir placé sa demande de travail dans une file d'attente. L'application n'a pas à attendre que tout le travail associé à la demande soit terminé avant de répondre. La demande en attente est traitée lorsque les ressources sont disponibles. Cela permet de conserver la capacité de réaction de la base de données pour les utilisateurs interactifs et d'utiliser efficacement les ressources disponibles.

• Le travail impliqué dans une seule demande peut être parfois divisé en plusieurs unités de travail traitées comme des transactions séparées. Dans ce cas, une application de base de données peut lancer chaque unité de travail en plaçant une demande dans une file d'attente. Service Broker va encore plus loin en permettant aux applications de répartir le travail sur plusieurs instances de Service Broker sur des ordinateurs séparés.

Le codage des applications pour classer et traiter correctement les éléments dans les files d'attente est souvent compliqué. Les développeurs peuvent utiliser la fonctionnalité Service Broker intégrée au moteur de base de données pour simplifier le codage nécessaire pour implémenter les files d'attente de base de données.

Prise en charge d'applications faiblement couplées

Service Broker prend en charge les applications faiblement couplées. Ces applications sont constituées de plusieurs programmes qui envoient et reçoivent des messages indépendamment les uns des autres. De telles applications doivent contenir des définitions identiques pour les messages échangés et configurer la même structure d'ensemble pour l'interaction entre les services. Toutefois, les applications n'ont pas à être exécutées en même temps ni dans la même instance de SQL Server, ou à partager les détails d'implémentation. Une application peut ignorer l'emplacement physique ou l'implémentation de l'autre participant de la conversation.

Composants de Service Broker

Service Broker comporte trois types de composants :

• Composants de conversation. Les groupes de conversations, les conversations et les messages forment la structure d'une application Service Broker au moment de l'exécution. Les applications échangent des messages dans le cadre d'une conversation. Chaque conversation fait partie d'un groupe de conversations et ce groupe peut contenir plusieurs conversations. Chaque conversation Service Broker est un dialogue. Un dialogue est une conversation dans laquelle deux participants exactement échangent des messages. Pour plus d'informations sur les composants de conversation, consultez Architecture des conversations.

• Composants de définition de service. Il s'agit de composants intervenant au moment de la conception et qui précisent la structure de base de la conversation que l'application utilise. Ils définissent les types de messages, le flux des messages et le stockage de la base de données pour l'application. Pour plus d'informations sur les composants de définition de service, consultez Architecture du service.

• Composants réseau et de sécurité. Ces composants définissent l'infrastructure utilisée pour échanger des messages entre des instances du moteur de base de données. Pour faciliter la tâche des administrateurs de base de données qui gèrent des environnements évolutifs, Service Broker permet de configurer ces composants indépendamment du code de l'application. Pour plus d'informations sur les composants réseau et de sécurité, consultez Réseau et sécurité distante.

Les composants de définition de service, les composants réseau et les composants de sécurité font partie des métadonnées pour la base de données et l'instance de SQL Server. Les groupes de conversations, les conversations et les messages font partie des données contenues dans la base de données.

Voir aussi

Concepts

Autres ressources