Différence entre un Agent de messages et un ESB

Question

J'ai parcouru différentes questions/articles sur les Message Brokers et les ESB (même sur stackoverflow). Je n'ai toujours pas la moindre idée de la différence claire et nette entre un courtier en messages et un ESB. Maintenant, je suis ici en train d'essayer de comparer des produits, Websphere Broker et Mule ESB !

Tout d'abord, Webshere Broker (quelle que soit sa version) est-il un ESB ? Nos spécialistes des produits IBM affirment qu'il s'agit d'un ESB (ce qui ne me surprend pas).

Mes informations limitées me disent qu'un Agent de messages fonctionne sur un modèle HUB-SPOKE. Cependant, l'ESB fonctionne sur une architecture de bus. Mais qu'est-ce que cela peut bien vouloir dire ? J'ai lu que si le HUB tombe en panne (indisponible, je suppose), le courtier tombe complètement en panne. Ce qui n'est pas le cas d'un ESB (c'est ce que disent ces personnes). Ce que je ne comprends pas ici, c'est "Que se passe-t-il si le BUS" tombe en panne ?

En général, les ESB et les courtiers fournissent des services de routage, de transformation, d'orchestration, etc. Donc, si les deux fournissent ces services, pourquoi en choisir un plutôt que l'autre ?

Une autre zone de conflit concerne la TRANSFORMATION. Les ESB la facilitent-ils d'une manière différente par rapport aux Message Brokers ? J'aimerais vraiment avoir un avis sur la question.

Nous parlons maintenant de la mise à l'échelle HORIZONTALE. Qui surpasse qui ? Ou bien les deux sont-ils également évolutifs en termes de complexité (ou de tout autre facteur). Bien sûr, en ce qui concerne le coût, Webshpere Broker va vous faire payer pour chaque boîte (sans parler de chaque processeur). Je crois que même l'ESB commercial MULE ne fait pas cela. En laissant de côté la partie coût, quelles sont les implications de la mise à l'échelle de l'ESB et de l'Agent de messages. Je sais qu'il est possible de faire évoluer l'ESB jusqu'au niveau de service. Est-ce possible dans un Agent de messages ?

Answer 1

Je copie cette explication de Shimon Amit, trouvée dans un autre sujet ( https://stackoverflow.com/a/3346417/5816637 ), ce qui me paraît parfaitement logique.

• Un site ESB fournit des couches supplémentaires au dessus d'un courtier en messages, telles que le routage, les transformations et la gestion des processus métier. Il s'agit d'un médiateur entre les applications, intégrant les services Web, les points d'extrémité REST, les connexions aux bases de données, etc. les connexions aux bases de données, les serveurs de messagerie et les serveurs ftp, etc. Il s'agit d'une colonne vertébrale d'intégration de haut niveau qui orchestre les éléments suivants l'interopérabilité au sein d'un réseau d'applications qui utilisent des différents protocoles.

• A courtier en messages est un composant de niveau inférieur qui vous permet en tant que de relayer des messages bruts entre les éditeurs et les abonnés, généralement entre les composants d'un même système, mais pas toujours. Il est utilisé pour permettre un traitement asynchrone afin de maintenir des temps de réponse faibles. Certaines tâches sont plus longues à traiter et vous ne voulez pas qu'elles retardent les choses si elles ne sont pas à temps. retarder les choses si elles ne sont pas sensibles au temps. Au lieu de cela, postez un message dans une file d'attente (en tant qu'éditeur) et demandez à un abonné de le récupérer et de le traiter "plus tard". le traiter "plus tard".

Answer 2

Depuis, IBM a changé les noms de son offre ESB. Je ne m'attarderais donc pas sur les noms ou les fournisseurs.

L'ESB permet aux informations commerciales de circuler entre des applications disparates sur plusieurs plateformes matérielles et logicielles. L'ESB est plutôt une couche d'intergiciel qui contient la logique de connectivité des applications et une logique d'entreprise minimale ou nulle. Cela permet aux applications de faire ce qu'elles font le mieux sans se soucier d'intégrer une logique de connectivité sur la façon d'interagir avec un nombre N d'autres applications qui ont besoin de leurs données. L'architecture ESB tente de résoudre le problème des spaghettis point à point dans une entreprise.

ESB et Message Broker sont en quelque sorte des synonymes l'un de l'autre, cependant, comme l'a souligné l'une des réponses ci-dessus, le modèle Message Broker est une partie du domaine ESB plus large. La lettre "B" dans ESB est analogue au bus (matériel) dans l'architecture informatique. Le bus sur la carte mère ou dans un ordinateur connecte divers composants pour le fonctionnement de l'ordinateur. L'ESB est un bus logiciel qui relie différents services dans une entreprise. Le modèle "hub and spoke" est l'un des modèles pris en charge par l'architecture ESB. Dans le monde monolithique, chaque fournisseur a sa propre architecture de déploiement à haute disponibilité pour garantir la disponibilité de l'ESB. Les offres récentes de tout fournisseur d'ESB se présentent sous la forme d'un modèle de déploiement basé sur les microservices ou hébergé dans leur propre nuage connu sous le nom d'iPAAS. Cela permet de garantir que le bus ne tombera jamais en panne ou qu'il tombera temporairement en panne avec un système d'auto-réparation basé sur le modèle de déploiement choisi. Avec le déploiement basé sur les microservices ou les iPAAS, les ESB ont maintenant des capacités d'auto-échelle (horizontalement ou verticalement) dont les caractéristiques varient en fonction du fournisseur choisi.

Pour connaître les capacités de très haut niveau offertes par l'ESB, vous pouvez consulter le lien suivant : =>. https://en.wikipedia.org/wiki/Enterprise_service_bus