File d'attente de message

Les files d'attente de message permettent le fonctionnement des liaisons asynchrones normalisées entre deux serveurs, c'est-à-dire de canaux de communications tels que l'expéditeur et le récepteur du message ne sont pas contraints de s'attendre l'un l'autre, mais poursuivent chacun l'exécution de leurs tâches. La file d'attente stocke les messages émis par l'expéditeur, jusqu'à ce que le destinataire les recherche. L'expéditeur n'a pas à attendre que le récepteur commence à traiter son message, il poste son information et peut passer à autre chose.

Le principe très général de la file d'attente est énormément utilisé pour les besoins internes des systèmes d'exploitation. Les files d'attente sont indispensables pour la synchronisation ou le travail multitâche des processus.

D'autres réalisations de file d'attente permettent une communication entre différents systèmes informatiques (« serveurs »), connectant plusieurs applications, ou plusieurs systèmes d'exploitation. Ces systèmes de synchronisation de messages sont typiquement dotés d'une fonctionnalité de persistance pour s'assurer que les messages ne sont pas perdus en cas d'échec du système.

Ce système de communication par message est par exemple fourni par des logiciels (appelés également intergiciel orienté message) comme WebSphere MQ de IBM (anciennement MQ Series), MSMQ (en) de Microsoft, Oracle Advanced Queuing (en) avec Oracle database. Comme souvent pour les intergiciels, Java propose uniquement un standard nommé Java Message Service dont il existe des implémentations propriétaires ou libres. Des projets open source existent également, comme RabbitMQ qui est un logiciel libre avec une licence de type Mozilla Public License.

Dans une implémentation typique de file de messages, un administrateur système installerait et configurerait l'intergiciel orienté message (gestionnaire de files d'attente), puis définirait l'identifiant pour chaque file d'attente de messages.

Une application pourrait alors s'enregistrer pour « écouter » des messages placés sur cette file d'attente.

Une autre application se connecterait à cette file d'attente et enverrait un message.

Le gestionnaire de files d'attente stockerait le message jusqu'à ce que l'application de réception soit connectée, et demande le message en attente.

L'application en réception pourrait alors traiter ce message de façon appropriée.

De nombreux choix ont une influence sur la façon précise de passer les messages comme :

• Persistance : les données envoyées peuvent être simplement gardées en mémoire ou si elles ne doivent pas être perdues même en cas d'échec système seront stockées dans un fichier voire une base de données.

• Sécurité : les messages et l'accès aux files de messages peuvent être protégés.

• Obsolescence : les messages et les files peuvent imposer des durées limites de validité.

• Filtrage de messages : certains systèmes permettent à une application de fournir des critères pour ne recevoir que certains messages.

• Stratégie de livraison : faut-il garantir que chaque message envoyé est reçu au moins une fois ou plutôt jamais plus qu'une fois ?

• Stratégie de routage : dans un système composé de multiples serveurs, quel serveur s'occupera de quelle file de messages ?

• Stratégie de groupage : faut il traiter chaque message individuellement ou est-il préférable de les regrouper pour diminuer le nombre d'échanges ?

• À quel moment un message est-il considéré comme envoyé ? Quand l'application l'a posté ? Dès qu'une file de réception l'a ? Toutes les files de réception ?

• Faut-il prévenir l'envoyeur que son message a été reçu ? Par tous les destinataires ?

Ces considérations ont un impact sur la sémantique d'envoi et de réception, la fiabilité et les performances du système complet.

Plusieurs protocoles de transmission largement répandus, sont synchrones de nature. L'exemple le plus connu est le protocole HTTP.

Dans un modèle synchrone, les systèmes en interaction envoient une demande et se mettent en attente d'une réponse. Dans beaucoup de situations c'est raisonnable (Par exemple, un utilisateur envoie une demande d'une page Web, puis attend une réponse).

Cependant, il y a d'autres situations pour lesquelles ce n'est pas approprié. Par exemple, si une application souhaite informer les autres qu'un évènement s'est produit, mais n'a pas besoin de réponse. Un autre exemple est dans le cas des modèles en publicateurs/abonnés, où une application publicatrice « poste » une information. Dans ces deux exemples il ne serait pas acceptable pour l'expéditeur de l'information de devoir attendre la réponse si un destinataire ne répond plus.

À l'opposé, une application interactive aura besoin de répondre immédiatement à une sollicitation (par exemple pour prévenir un client que son paiement est accepté et que le stock est prévenu de sa commande) et pourra mettre en file d'attente d'autres demandes d'actions (envoi de la facture à la comptabilité, etc.) Dans ce type d'utilisation, faire la part entre les traitements synchrones et asynchrones peut améliorer le comportement du système.