Qu'est-ce que Microsoft Message Queuing (MSMQ) ? Comment fonctionne-t-il ?

Question

Je dois travailler avec MSMQ (Microsoft Message Queuing). Qu'est-ce que c'est, à quoi ça sert, comment ça fonctionne ? En quoi est-il différent des services web ?

Answer 1

Avec tout le respect dû à la réponse de @Juan, les deux sont des moyens d'échanger des données entre deux processus déconnectés, c'est-à-dire des canaux de communication interprocessus (IPC). Les files de messages sont asynchrones, tandis que les services Web sont synchrones. Ils utilisent des protocoles et des services dorsaux différents pour ce faire. Ils sont donc complètement différents dans leur mise en œuvre, mais similaires dans leur objectif.

Il est préférable d'utiliser les files d'attente de messages lorsqu'il est possible que l'autre processus de communication ne soit pas disponible, mais que vous souhaitez néanmoins que le message soit envoyé au moment choisi par le client. La livraison aura lieu lorsque le processus à l'autre bout se réveillera et recevra la notification de l'arrivée du message.

Answer 2

Comme son nom l'indique, il s'agit simplement d'un gestionnaire de file d'attente.

Vous pouvez envoyer des objets (sérialisés) à la file d'attente où ils resteront jusqu'à ce que vous les receviez. Elle est normalement utilisée pour envoyer des messages ou des objets entre applications de manière découplée.

Cela n'a rien à voir avec les services Web, ce sont deux choses différentes.

Informations sur MSMQ :

https://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx

Informations sur les services Web :

http://msdn.microsoft.com/en-us/library/ms972326.aspx

Answer 3

Gestion des files d'attente transactionnelles 101

Une file d'attente transactionnelle est un système intergiciel qui achemine de manière asynchrone des messages d'une sorte ou d'une autre entre des hôtes qui peuvent être connectés ou non à un moment donné. Cela signifie qu'elle doit également être capable de conserver le message quelque part. Voici des exemples de tels systèmes MSMQ y IBM MQ

Une file d'attente transactionnelle peut également participer à un processus d'échange de données. transaction distribuée et un retour en arrière peut déclencher l'élimination des messages. Cela signifie qu'un message est garanti d'être délivré avec au moins une fois la sémantique ou la livraison garantie s'il n'y a pas de retour en arrière. Le message ne sera pas remis si :

• L'hôte A affiche le message mais l'hôte B n'est pas connecté

• Quelque chose (peut-être mais pas nécessairement nécessairement initié par l'hôte A) annule la transaction

• B se connecte après que la transaction soit annulée

Dans ce cas, B ne sera jamais au courant de l'existence du message, à moins d'en être informé par un autre moyen. Si la transaction a été annulée, cela n'a probablement pas d'importance. Si B se connecte et récupère le message avant que la transaction ne soit annulée, l'annulation annulera également les effets du message sur B.

Notez que A peut poster le message dans la file d'attente avec la garantie d'une livraison au plus une fois. Si la transaction est validée, l'hôte A peut supposer que le message a été livré. délivré par le moyen de transport fiable. Si la transaction est annulée, l'hôte A peut supposer que tous les effets du message ont été annulés.

Services Web

Un service web est appel de procédure à distance ou un autre service (par exemple API RESTFul ) publié par un serveur (généralement) HTTP. Il s'agit d'un protocole de demande/réponse synchrone qui ne comporte aucune garantie de livraison. C'est au client de valider que le service a été correctement exécuté. En général, cela se fait par une réponse à la demande ou par le dépassement du délai d'appel.

Dans ce dernier cas, les services web ne garantissent pas la sémantique "at-most-once". Le serveur peut achever le service et ne pas livrer de réponse (éventuellement à cause d'un problème extérieur au serveur). L'application doit être capable de gérer cette situation.

IIRC, les services RESTFul doivent être idempotents (le même état est atteint après un nombre quelconque d'invocations du même service), qui est une stratégie pour faire face à ce manque de notification garantie de succès/échec dans les architectures de services web. L'idée est que, conceptuellement, on écrit un état plutôt que d'invoquer un service, donc on peut écrire un nombre illimité de fois. Cela signifie qu'un manque de retour d'information sur le succès peut être toléré par l'application car elle peut réessayer l'écriture jusqu'à ce qu'elle reçoive un message de "succès" du serveur.

Answer 4

Notez que vous pouvez utiliser Windows Communication Foundation (WCF) comme couche d'abstraction au-dessus de MSMQ. Cela vous donne l'impression de travailler avec un service - avec seulement des opérations à sens unique.

Pour plus d'informations, voir : http://msdn.microsoft.com/en-us/library/ms789048.aspx

--larsw

Answer 5

En fait, il n'y a pas de relation entre MSMQ et WebService. L'utilisation de MSMQ pour la communication interprocessus (vous pouvez également utiliser les sockets, la messagerie Windows, la mémoire mappée). C'est un service Windows qui est responsable de la conservation des messages jusqu'à ce que quelqu'un les retire de la file d'attente. On peut dire qu'il est plus fiable que les sockets car les messages sont stockés sur un disque dur mais il est plus lent que les autres techniques IPC.

Vous pouvez utiliser MSMQ dans dotnet avec de petites lignes de code, il suffit de déclarer votre MessageQueue et appeler Receive y Send méthodes. Le message lui-même peut être une chaîne normale ou des données binaires.