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

Vous pouvez utiliser un courtier en transformation sans un bus de service, et vice versa. En termes de produits spécifiques, je ne pense pas qu'un produit soit purement l'un ou l'autre, car chacun se complète. Certains produits sont plus forts dans un domaine, d'autres plus forts dans un autre. Il faut peut-être faire un choix en fonction de la fonction qui couvre le mieux un problème individuel.

Un courtier peut avoir de meilleurs "blocs lego" intégrés pour construire une chaîne de transformation qu'un produit ESB. Un courtier utilisé comme un ESB peut être écrasé sous la charge et ne pas bien évoluer, ou peut manquer de journalisation robuste et d'outils pour traiter les journaux.

Certains ESB permettent d'annuler les mises à jour de la base de données et de rejouer les files d'attente dans une application corrigée une fois qu'une erreur de logique flagrante a été découverte et corrigée. Je ne pense pas que la plupart des courtiers intègrent ce niveau de support transactionnel. Pour que cela fonctionne, vos "transactions" doivent presque être des événements commerciaux (une vente, un renouvellement, un changement de propriétaire, etc.) plutôt que des "mises à jour de base de données" à la RPC.

Answer 2

Avertissement : je suis consultant IBM et spécialisé dans WebSphere ESB. Ce commentaire n'est pas laissé à titre officiel.

Un ESB est davantage un modèle ou un concept architectural qu'un produit. Il s'agit en fait d'une méthode de couplage souple basée sur les services. Sa définition est controversée et n'est pas vraiment gravée dans le marbre. En général, un ESB est un ensemble de services non liés (dans un sens technique) - ils exposent des interfaces et les consomment à partir d'autres services. En général, il n'y a pas d'architecture en étoile, bien que cela soit possible.

IBM commercialise certainement WebSphere Message Broker et WebSphere ESB comme des produits qui facilitent la création d'un ESB (avec l'appliance matérielle DataPower). Ils ont des racines technologiques différentes, mais leurs objectifs se chevauchent quelque peu. Cela ne veut pas dire non plus que vous ne pouvez pas construire un ESB avec beaucoup d'autres choses qui ne sont pas marquées comme "produit ESB".

Cela ne répond pas à toutes vos questions, mais j'espère que cela répond à la partie IBM.

Answer 3

La différence entre un Agent de messages et un ESB (Enterprise Service Bus) réside principalement dans le mot "bus".

Pour moi, un Agent de messages est un (généralement gros) processus qui transforme les données d'une structure à une autre ou modifie le contenu.

Un ESB est un intergiciel orienté message (MOM) auquel s'ajoutent des services supplémentaires, dont l'un d'entre eux pourrait être un Agent de messages. Un ESB peut donc inclure un Agent de messages comme l'un de ses composants. Un bus est constitué de plus d'un processus, sinon je ne l'appellerais pas un "bus". La nature d'un bus est qu'il y a plusieurs composants servant différentes tâches, chacun communiquant sur un MOM et adhérant à une forme de "format de données commun". Un bus se compose des éléments suivants : applications envoyant des données au MOM, adaptateurs de base de données, courtiers en messages, ponts MOM, etc.

La séparation est un peu progressive, mais la plus grande différence entre une architecture d'Agent de messages et un Bus est celle de granularité . Si votre tâche consiste à intégrer les applications A, B, , Z et quelques bases de données, vous pouvez le faire avec un grand Agent de messages connectant tout le monde. Ou avec un ESB où plusieurs petits composants prennent en charge de petites tâches. Par exemple, un adaptateur se connecte à A, un autre à B (mais ils ne font pas de transformation), puis chacun envoie ses données à un (ou plusieurs) Agent de messages, dont chacun doit rester aussi simple que possible - par exemple, il ne doit pas connaître le modèle de données de 'A' ou 'B'. Un bon ESB devrait avoir une définition commune des données sur le bus, en faisant abstraction de la "différence" des applications individuelles.

TRANSFORMATION : un ESB n'aide pas à la transformation, sauf s'il est accompagné d'un Agent de messages. Mais tout bon ESB devrait de toute façon inclure un Agent de messages. L'Agent de messages doit être l'expert de votre bus pour les transformations, mais rien d'autre.

Mise à l'échelle HORIZONTALE : si vous n'avez que trois choses à connecter (maintenant et pour toujours), il n'est probablement pas utile d'acquérir un ESB complet. Un Agent de messages a l'avantage de n'être qu'un seul gros processus. Vous pouvez tout y configurer et disposer d'un emplacement central pour tous vos mappages, filtrages et routages de données.

Mais si vous avez 30 applications à connecter, un seul Agent de messages risque de s'enliser. Bien sûr, vous pouvez acheter plus d'instances, faire fonctionner les choses en redondance, etc. mais vous devriez changer votre stratégie pour "localiser" les tâches. L'adaptateur de chaque application (il pourrait s'agir d'une petite instance d'Agent de messages chacun) devrait être capable de générer et/ou de recevoir un modèle de données commun abstrait (par exemple XML avec un XSD partagé). Il pourrait également y avoir un Agent de messages central pour les tâches de transformation, mais cette instance ne devrait pas connaître le modèle de données A ou B. Ainsi, un ESB devrait déplacer le traitement vers le composant expert au lieu de tout garder dans un endroit central.

Answer 4

Je viens de lire cet article d'Udi Dahan il y a quelques jours, qui pourrait vous donner une vision plus claire de ce qui me semble être une différence fondamentale.

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

Je cite :

La règle selon laquelle il ne peut y avoir qu'un un seul éditeur pour un événement donné type d'événement est l'une des choses qui différencie les bus des brokers, bien que les deux permettent évidemment d'avoir plusieurs abonnés

...

Malheureusement, il existe de nombreux technologies de type courtier qui sont commercialisées sous la sous la bannière de l'Enterprise Service Bus. Alors que certains produits ont la capacité d'être déployés à la fois de manière centralisée centralisé et distribué (parfois (parfois appelé mode "fédéré" ou "intégré"). ou "embarqué"), beaucoup ne respectent pas la règle du "point d'extrémité de publication unique par type d'événement". point d'accès de publication par type d'événement". règle.

Sans cette contrainte, c'est juste trop facile de faire des erreurs.

J'espère que cela vous aidera.

Answer 5

Un Enterprise Service Bus fournit trois valeurs clés à l'entreprise :

1. Acheminement des transactions en fonction du contexte ou du contenu ;
2. Transformation d'un domaine ou d'un transport de messages en un autre domaine ou transport de messages ;
3. la connectivité des services de type "many-to-many".

Les ESB assurent un couplage lâche des services, permettent de reconstituer les services dans des contextes applicatifs entièrement différents de ceux dans lesquels ils ont été envisagés ou développés à l'origine, et favorisent la réutilisation des applications sans qu'il soit nécessaire de les recoder. WebSphere Message Broker (ou maintenant appelé IBM Integration Bus) est un excellent exemple de bus de services d'entreprise. Pour un exemple de simplicité de code qui apporte une grande puissance en quelques lignes, vous pouvez consulter mon post ici : http://soabus.org/viewtopic.php?f=3&t=13 . La construction fondamentale à l'intérieur du runtime IIB s'appelle le Arbre de messages logiques (LMT). Tout ce que le développeur veut faire est un type d'opération sur le LMT. ESQL est le langage le plus efficace qu'un développeur puisse utiliser pour effectuer ces opérations sur le LMT, bien que de nombreux autres langages soient pris en charge (par exemple, Java, PHP, Python, etc.) Aucun autre produit n'est aussi efficace et facile à développer des applications ESB qu'IBM Integration Bus, puisque 90 % du codage de ces applications est effectué par glisser-déposer de nœuds sur une palette. Il ne reste donc que 10 % du codage à effectuer par le développeur de Message Flow. À propos, IBM a abandonné WebSphere ESB et bon nombre des produits concurrents d'IBM Integration Bus n'ont pas fait l'objet de nouveaux développements depuis plusieurs années maintenant. Une liste des différentes offres de produits ESB peut être consultée sur soabus.org.