Et y en a-t-il? Pour moi, MB connaît à la fois les abonnés et les éditeurs et agit en tant que médiateur, avertissant les abonnés des nouveaux messages (effectivement un modèle «push»). MQ, en revanche, est davantage un modèle «pull», dans lequel les consommateurs extraient les messages d'une file d'attente.
Suis-je complètement hors de propos ici?
Réponses:
Dans l'ensemble, en ce qui concerne les produits logiciels des fournisseurs, ils sont utilisés de manière interchangeable et n'ont pas les distinctions fortes en termes de poussée ou d'attraction que vous décrivez.
Le BUS vs QUEUE est en effet un concept hérité, le plus récemment issu de systèmes comme IBM MQ et Tibco Rendezvous. MQ était à l'origine un système 1: 1, en fait une file d'attente pour découpler divers systèmes.
Tibco, en revanche, était (vendu comme une) épine dorsale de messagerie, où vous pouviez avoir plusieurs éditeurs et abonnés sur les mêmes sujets.
Cependant (et les produits concurrents plus récents) peuvent jouer dans l'espace de l'autre ces jours-ci. Les deux peuvent être configurés pour interrompre ainsi que pour interroger les nouveaux messages. Les deux arbitrent les interactions entre divers systèmes.
Cependant, l'expression file d'attente de messages est également utilisée pour les pompes de messages intra-thread internes et autres, et dans ce contexte, l'utilisation est en effet différente. Si vous pensez à la pompe de messages Windows classique, il s'agit en effet davantage du modèle pull que vous décrivez, mais il est vraiment plus intra-application qu'inter-application ou inter-box.
Bus de messages
Un bus de messages est une infrastructure de messagerie permettant à différents systèmes de communiquer via un ensemble partagé d'interfaces ( bus de messages ).
Source: EIP
File d'attente de messages
L'idée de base d'une file d'attente de messages est simple:
Deux processus (ou plus) peuvent échanger des informations via l' accès à une file d'attente de messages système commune .
Le processus d'envoi place via un module de transmission de messages (OS) un message dans une file d'attente qui peut être lu par un autre processus
Source: Dave Marshall
Différence
Message Queue contient la règle FIFO ( premier entré, premier sorti ), contrairement à Message Bus .
Conclusion
Les deux REGARD comme faisant même genre de travail - passer des messages entre deux applications ou modules ou interfaces ou systèmes ou processus , à l' exception de la petite différence FIFO
Il y a eu un peu de flou entre ces deux concepts, car certains produits prennent désormais en charge des fonctionnalités qui n'appartenaient auparavant qu'à l'une ou l'autre catégorie (par exemple, Azure Service Bus prend en charge les deux approches).
Une file d'attente de messages reçoit les messages d'une application et les met à la disposition d'une ou plusieurs autres applications selon le principe du premier entré premier sorti (FIFO). Dans de nombreux scénarios architecturaux, si l'application A doit envoyer des mises à jour ou des commandes aux applications B et C, des files d'attente de messages distinctes peuvent être configurées pour B et C.A écrirait des messages séparés dans chaque file d'attente, et chaque application dépendante lirait à partir de son propre file d'attente (le message est supprimé lors de la suppression de la file d'attente). Ni B ni C ne doivent être disponibles pour que A envoie des mises à jour. Chaque file d'attente de messages est persistante, donc si une application redémarre, elle commencera à extraire de sa file d'attente une fois qu'elle sera de nouveau en ligne. Cela permet de rompre les dépendances entre les systèmes dépendants et peut fournir une plus grande évolutivité et une plus grande tolérance aux pannes aux applications.
Un bus de messages ou bus de services permet à une (ou plusieurs) application de communiquer des messages à une ou plusieurs autres applications. Il n'y a peut-être aucune garantie de commande du premier entré, premier sorti, et les abonnés au bus peuvent aller et venir à l'insu des expéditeurs de messages. Ainsi, une application A pourrait être écrite pour communiquer des mises à jour d'état à l'application B via un bus de messages. Plus tard, l'application C est écrite qui peut également bénéficier de ces mises à jour. L'application C peut être configurée pour écouter le bus de messages et agir en fonction de ces mises à jour également, sans nécessiter de mise à jour de l'application A. Contrairement aux files d'attente, où l'application d'envoi ajoute explicitement des messages à chaque file d'attente, un bus de messages utilise une fonction de publication / abonnez-vous au modèle. Les messages sont publiés sur le bus et toute application qui s'est abonnée à ce type de message le recevra.
La principale différence qui n'a pas vraiment été mentionnée explicitement dans les autres réponses est qu'un bus de messages autorise plusieurs abonnés alors qu'une file d'attente retirera les éléments un par un de tout ce qui écoute la file d'attente. Si vous vouliez que plusieurs auditeurs voient les mêmes éléments sortir de la file d'attente, vous devrez le gérer vous-même, un bus de service le ferait pour vous.
La façon dont je vois les choses est que la file d'attente de messages crée le bus de messages . Les clients (c'est-à-dire les nœuds) peuvent alors écouter le bus de messages. Cela est particulièrement vrai dans le cas où vous avez un MQ diffusant des messages via UDP, en d'autres termes, il envoie des messages à une adresse de diffusion / multidiffusion sans savoir ou se soucier de qui va les recevoir. Pour une description plus détaillée de ce scénario, vous pouvez consulter cet article .
Service Bus est un terme plus général que Message Queue.
MQ est un simple FIFO, mais il existe des moyens plus sophistiqués d'implémenter un Service Bus, c'est-à-dire un Event Hub, qui est un énorme "centre" pour manipuler les messages. Outre la fonctionnalité fournie par MQ, il permet de stocker les messages (et donc d'utiliser plusieurs abonnés), etc.
Un bus de messages est un modèle de distribution 1-à-plusieurs. La destination dans ce modèle est généralement appelée sujet ou sujet. Le même message publié est reçu par tous les abonnés consommateurs. Vous pouvez également appeler cela le modèle «diffusion». Vous pouvez considérer un sujet comme l'équivalent d'un sujet dans un modèle de conception Observer pour l'informatique distribuée. Certains fournisseurs de bus de messages choisissent efficacement de l'implémenter en tant qu'UDP au lieu de TCP. Pour le sujet, la livraison du message est «feu et oublie» - si personne n'écoute, le message disparaît tout simplement. Si ce n'est pas ce que vous voulez, vous pouvez utiliser des «abonnements durables».
Une file d'attente de messages est une destination 1 à 1 des messages. Le message est reçu par un seul des destinataires consommateurs (veuillez noter: l'utilisation systématique d'abonnés pour les clients de rubrique et de récepteurs pour les clients de file d'attente évite toute confusion). Les messages envoyés à une file d'attente sont stockés sur le disque ou la mémoire jusqu'à ce que quelqu'un le récupère ou qu'il expire. Les files d'attente (et les abonnements durables) ont donc besoin d'une gestion active du stockage, vous devez penser aux consommateurs lents.
Dans la plupart des environnements, je dirais que les sujets sont le meilleur choix car vous pouvez toujours ajouter des composants supplémentaires sans avoir à changer l'architecture. Les composants ajoutés pourraient être la surveillance, la journalisation, l'analyse, etc. Vous ne savez jamais au début du projet à quoi ressembleront les exigences dans 1 an, 5 ans, 10 ans. Le changement est inévitable, acceptez-le :-)