Une file d'attente de message ou simplement file de messages est une technique de programmation utilisée pour la communication interprocessus ou la communication de serveur-à-serveur. Les logiciels fournissant ce type de service font partie des « Message-Oriented Middleware » ou MOM.
Les files d'attente de message fournissent des liaisons asynchrones normalisées. Elles ont pour but que l'expéditeur et le récepteur du message ne soient pas contraints de s'attendre l'un l'autre. Des messages placés dans la file d'attente sont stockés, 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.
Beaucoup de réalisations de files d'attente sont créées pour les besoins internes des systèmes d'exploitation. Elles 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, connectant plusieurs applications, ou plusieurs systèmes d'exploitation. Ces systèmes de synchronisation de messages fournissent typiquement 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 de Microsoft, Oracle Advanced Queuing (AQ) 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.
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 impactent 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 évident 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èle en publicateur/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 de d'utilisation, faire la part entre les traitements synchrones et asynchrones peut améliorer le comportement du système.