Les systèmes de messageries informatiques asynchrones permettent de réaliser des applications collaboratives et réparties. Basées sur une logique applicative, elles permettent de résoudre du même coup certains problèmes tels que la possibilité d’alerter lorsqu’il y a défaillance de la chaîne de traitement. Qu’en est-il côté bases de données ? Réponse Microsoft : Service broker…

L’architecture SOA (Service Oriented Architecture) a vue se réaliser de nombreux services communiquant des données entre différentes applications. Pour autant est-il toujours approprié de remonter à l’application pour communiquer des informations de base à base ? La réponse est non et le recours à SODA (Service Oriented Database Architecture) devrait être la norme !
SQL Server répond à la logique SODA en fournissant les moyens d’une telle architecture via Service Broker…

Service Broker est un système de messagerie asynchrone permettant de développer des applications SQL Server 2005 en répartissant ses données et les traitements associés sur différentes bases dans différents serveurs, quel que soit la distance entre les serveurs (Internet).

Si Microsoft en est arrivé à un tel système, c’est parce que l’on commence à comprendre l’importance du concept d’applications pilotées par les données, mais aussi que répartir ses données et ses traitements sur différents serveurs, met l’information plus proche de l’utilisateur. En quelques sortes, Microsoft entame avec Service Broker un renouveau de la micro-informatique côté serveur…

Service Broker propose donc un système de messagerie intégrée au serveur SQL : il permet d’élaborer des stratégies de communication d’information (véhiculée via le protocole http), sans jamais quitter l’univers de la base de données et cela de manière asynchrone et transactionnel, ce qui permet d’obtenir un bon lissage de la charge.

Étudions maintenant quelques un des concepts du système : Les messages sont constitués par des informations binaires encapsulant tout type de données. Des dialogues sont initiés entre les applications qui les envoient, et les services qui les consomment. Ces dialogues peuvent être routés de manière spécifique et l’information peut être cryptée. Les messages sont reçus dans l’ordre de leur expédition et sont aiguillé dans les files d’attente (QUEUE).
Ces files d’attente peuvent être à consommateurs multiples ce qui permet par exemple de paralléliser des traitements sur une batterie de serveurs.

On entre ainsi dans le domaine de la base de données répartie et cela quel que soit l’OS, la machine et la version de SQL Server 2005… En effet Microsoft a intégré Service Broker dans la version « run-time », SQL Server 2005 Express, libre et gratuite.

Afin de ne pas recevoir n’importe quoi, un service s’appuie sur des contrats qui définissent quels types de messages il consomme. Vous l’aurez sans doute compris, toute la cinématique de flux des messages est élaborée à l’aide de documents XML et les services sont basés sur le protocole SOAP. En fait les points de livraison des messages sont des « http endpoint », autrement dit des services Web dédié à Service Broker..

Les éléments de l’architecture Service Broker de SQL Server (Microsoft)

C’est avec cette technique que la SNCF à décider de renouveler son back office des recettes « voyageurs » : Nefertiti permet de vérifier les sommes encaissées par les points de vente et permet la reconnaissance physique des versements, leur comptabilisation et remise en banque ainsi que la gestion de coffre. En fait les versements suivent deux chemins : le transfert de fonds (chemin physique) et les flux informatiques (chemin logique). Néfertiti assure le rapprochement entre flux physique et logique notamment au travers de périphériques de reconnaissance monétaires. On comprend bien qu’une telle application est doublement critique : la comptabilisation oblige au zéro défaut et les flux doivent opérer au plus vite car tout retard entraîne de coûteux délais de remise d’argent en banque. Et puis il y a la pression de la clientèle au guichet… Chaque caisse principale enregistrant environ deux millions de transactions par jour.
Afin d’éviter l’indisponibilité du système central et donc l’impossibilité de servir le client, les flux sont enregistrés dans les files d’attente et envoyés de manière asynchrone au serveur central. En cas de coupure du réseau, la caisse est autonome.

Un exemple de mise en Å“uvre :
À quoi sert Service Broker ?

Développez et administrez pour la performance avec SQL Server 2014

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR