APSQL

Service Broker

SQL Server propose avec service broker un véritable middleware orienté message (MOM).

Service Broker offre la possibilité de travailler en mode asynchrone avec une base de données. Ainsi le client va envoyer un message au serveur de base de données via Service Broker et être capable de continuer son travail sans qu'il lui soit nécessaire d'attendre la réponse de la base de données. L'objectif de ce service est de limiter autant que possible les goulets d'étranglement au niveau de la base de données. Certains d'entre vous utilisent peut être déjà une technique similaire qui consiste à insérer de façon non structurée toutes les informations puis d'avoir un processus qui traite une à une les lignes qui sont présentes dans cette table. Même sir cette solution est simple à mettre en œuvre, elle présente moins d'avantages que Service Broker. En effet Service Broker permet de structurer l'ensemble de l'échange entre la client et le serveur. De plus Service Broker offre la possibilité de travailler facilement avec plusieurs instances SQL Server en proposant un service de messagerie fiable entre les instances.

Pour structurer cet échange, Service Broker, utilise la notion de dialogue, de contrat, de messages et de files d'attentes. Le dialogue au sens Service Broker permet un échange de messages entre un émetteur et un récepteur. Le type de messages à la disposition de l'émetteur et du récepteur sont définis par le contrat.

Observons, maintenant comment il est possible de mettre en place Service Broker sur une base de données. Ce type de d'utilisation de Service Broker peut être intéressant, lorsqu'il est nécessaire de répondre ponctuellement à une grosse charge de travail, par exemple des commandes sur un site web. Ainsi Service Broker permet de prendre en charge les informations de façon quasi immédiate même si l'insertion finale dans la base cible n'est pas fait de façon instantanée. L'application client peut alors être en mesure de signaler que les informations sont correctement prisent en charge.

Pour expliquer le fonctionnement de Service Broker, il est possible de faire une analogie avec un dialogue qui s'installe entre 2 individus.

L'animation suivante illustre le fonctionnement de service broker


Video: Fonctionnement Service Broker

Les types de messages

Avant de définir tout autre élément, il est nécessaire de définir les types de messages qui vont pouvoir être utilisés pas l'émetteur et le récepteur. Il est normal que chacun soit au courant du vocabulaire employé dans le dialogue.

Pour que 2 individus puissent dialoguer, ils doivent utiliser la même langue et le même vocabulaire.

Les types de messages sont définis avec l'instruction CREATE MESSAGE TYPE (détail de la syntaxe). L'exemple suivant permet     de créer un message de type XML. Ce sera le seul message défini dans l'exemple qui va nous permettre d'illustrer l'intérêt de Service Broker.

Définir un nouveau type de message

Bien entendu toutes les opérations décrites ici sous forme de script Transact SQL peuvent être réalisée depuis SQL Server Management Studio à partir du nœud Service Broker de la base de données cible dans l'explorateur d'objets.

Le contrat

Dès que les différents types de messages sont définis, il est possible de mettre en place le contrat. Ce contrat permet de préciser quels sont les types de messages utilisables par l'émetteur et quels sont ceux utilisables par le récepteur. Bien entendu, tout comme les types de messages, les contrats doivent être définis à l'identique sur tous les participants à une conversation.

Le contrat est défini à l'aide de l'instruction CREATE CONTRACT ou bien depuis SQL Server Management Studio.

Exemple de creation d'un contrat Service Broker)

Les files d'attentes

Dans le cadre d'échange de messages et d'un traitement asynchrone de ces messages, il est nécessaire que chaque participant à la conversation puisse stocker de façon temporaire et fiable les messages avant de les traiter. Le stockage de ces messages s'effectue par l'intermédiaire d'une file d'attente. Une file d'attente doit être définie pour l'émetteur et une seconde pour le récepteur, même sir les 2 services résident sur le même serveur.

Creation de file d'attente avec CREATE QUEUE

Les files  d'attentes crées ci dessous le sont avec les paramètres par défaut.  Il est possible de paramétrer la file d'attente afin de l'adapter au contexte d'utilisation. Par exemple, il est possible d'y associer un processus (procédure stockée). Le rôle de cette procédure est alors de traiter les éléments présents dans cette file d'attente.

Les services

C'est par l'intermédiaire des services que l'échange est possible entre l'émetteur et le récepteur. Lors de la création du service, il est nécessaire de préciser la file d'attente utilisée pour les messages entrant, ainsi que le ou les contrats supportés par le service.

Création des services Service Broker

Activer la prise en charge de Service Broker

Pour que les éléments relatifs à Service Broker soient disponibles sur la base, il est nécessaire d'activer la prise en charge du service au niveau de la base de données par l'intermédiaire de l'instruction ALTER DATABASE.

Il est possible de contrôler l'activation de Service Broker au niveau des différentes bases en interrogeant la colonne is_broker_enabled de la table système sys.databases depuis la base master.

Activer Service Broker au niveau de la base

Etablir le dialogue

Maintenant que tous les éléments sont définis, il est possible d'initialiser une conversation au sens Service Broker. Pour mener à bien cette tâche le Transact SQL s'est enrichi des termes suivants: BEGIN DIALOG CONVERSATION, MOVE DIALOG, GET CONVERSATION GROUP, END CONVERSATION, SEND, RECEIVE, GET TRANSMISSION STATUS, BEGIN CONVERSATION TIMER. La syntaxe détaillée de ces différentes instructions est disponible dans la documentation en ligne de SQL Server 2005, mais une utilisation de quelques une de ces instructions est illustrée avec les exemples qui suivent.

Dans le premier exemple, illustré ci dessous, l'initiateur et la cible de la conversation , respectivement service 1 et service 2 sont exécutés sur le même base et depuis le même script. La message au format xml est transmis à la cible qui le récupère depuis la file d'attente associé au service cible, c'est à dire dans ce cas la file2 qui est la file d'attente associée à sevice2. Cet exemple simple, permet de valider simplement l'ensemble de la structure mise en place et d'illustrer les instructions spécifiques au dialogue entre les 2 services.

 

Les exemples complets de mise en place de Service Broker