MSMQ : Architecture et principes

Présentation de MSMQ

MSMQ, acronyme de Microsoft Message Queuing est une implémentation Microsoft de Message Queue. Une Message Queue est un ensemble de techniques permettant l’échange asynchrone de messages. Par exemple, une boite mail peut être considérée comme un MQS (j’utiliserai par la suite cette abréviation pour parler de manière générique des message queuing system), càd un endroit où l’on peut déposer de l’information dans le but d’être traité plus tard. Ainsi, dans sa version basique, l’émetteur ne se soucie pas des actions entreprises par le destinataire, tablant sur le fait que le message étant présent dans le queue, il sera traité par qui de droit quand il en sera capable. C’est donc un composant utilisé pour communiquer de l’information entre différent processus ou différent thread d’un même processus permettant.

C’est queues prennent souvent la forme de « stack » et donc hérite des propriétés de ces dernières. Bien que majoritairement de type FIFO, les 3 opérations standards des stack (push/pop/peek) ainsi que les opérations utilitaires (status/count/clear/dup/swap) sont implémentées par les fournisseurs de Message Queue. Si ces notions vous sont étrangères et souhaitez utiliser activement des systèmes de queue, je vous conseils de faire un petit tour par wikipedia 😉

Dans la pratique, on ne développe que rarement ses propres systèmes de queues et l’on préfère déployer des solutions existantes fonctionnant « off-the-shelf » comme IBM Webshpere MQ/Message Broker, MSMQ, JMS, RabbitMQ,… Ensuite on définit des queues nommées dans lesquels les applications viendront déposer leurs messages dans le but d’être traitées par d’autres systèmes ensuite. On délègue la responsabilité de la gestion des messages (envoi, routing, ACK, …) et de l’infrastructure au système de message queuing  ce qui permet découpler de souvent l’application cliente et serveur en utilisant le MQS comme « interlocuteur privilégié ».

Pour résumer, je vais refaire mon analogie avec la boite mail du point de vue de l’emetteur et du destinataire, remplacez boite mail par queue, mail par messages et le tour est joué 😉

Une boite mail est un espace de stockage de message accessible par des applications et gérée par une application serveur. Quand je veux envoyer un mail à quelqu’un, j’indique l’adresse de sa boite mail, écrit mon mail et envoi ensuite le mail au serveur d’envoi qui le transfert vers le serveur du destinataire qui, basé sur l’adresse de la boite mail principalement, peut placer le message dans un espace accessible par le propriétaire de l’adresse. Lorsque j’envoie un mail, je ne me soucie ni de l’emplacement de mon destinataire, ni du client de messagerie qu’il utilise ni de sa disponibilité. Je n’ai besoin que d’un protocole commun d’échange (SMTP pour le mail) compris par les deux parties. Je pars du principe que le mail étant envoyé, mon destinataire le lira quand il ira relever son courrier.

Le destinataire lui, lorsqu’il consulte sa boite mail, vas souvent du plus ancien non-lu au plus récent, (accès séquentiel). Mais rien ne m’empêche d’accéder directement (accès aléatoire) au message qui m’intéresse en me basant sur par exemple les métas données du mail (émetteur, objet du message, flag d’importance, …) Un fois le message consulté, je le supprime de ma boite mail (plus actuellement avec les boites mail illimité) ou le place dans un dossier de tri pour le consulter plus tards.

MSMQ, c’est une sorte de service mail pour les applications. Lancé depuis NT4 et Windows 95, MSMQ  tire parti de l’intégration au système microsoft et en fait un système d’échange de message très correct pour beaucoups de besoins. MSMQ à une déclinaison cloud pour Azure, appelé Azure Storage queue et AppFabric Service Bus. Des systèmes de messaging complexe sont aussi disponibles par exemple pour les ESB, mais cela dépasse de loin le scope de cet article.

Propriétés d’MSMQ

Le diagramme ci-dessus résumé l’échange de messages MSMQ. On y distingue deux types d’applications. Les applications d’envois et celles de réceptions. Voici les caractéristiques et options principales de chacune :

Sending	Receiving
(non)/Transactionnel	Lecture local ou remote
Express/Recoverability	(non)/Transactionnel
Envoi direct ou en store and forward (une copie sur   chaque intermédiaire)	Lecture synchrone ou asynchrone
Authentification	Lecture en peek ou retreive
Encryption	Online ou Offline
Online ou Offline

 

Je vais détailler certains points qui peuvent sembler peu explicite.

Express/Recoverability permet de stocker une copie du message et d’attendre un ACK de la part du destinataire. SI le ACK ne parvient pas, le message sera ré-envoyé jusqu’au moment où le destinataire
confirmera la bonne réception du message. C’est un peu comparable à UDP/TCP.

Direct/Store-and-forward. En store-and-forward une copie du message est gardée sur chaque intermédiaire. Cela permet par exemple de ne pas interrompre l’envoi du message dans le cas où un des intermédiaires serait inaccessible.

Peek/Retrieve. En Peek, le message est conservé dans la queue alors qu’en retreive l’accès à un message le supprime de la queue.

Conclusion

Nous avons maintenant une idée globale de ce que propose MSMQ. Dans le prochain article je vous ferai une petite démo de comment utiliser MSMQ depuis du C# sur un scénario simple pour une application de chat. A bientôt 🙂