Différence entre un courtier de messages et un ESB
J'ai parcouru différentes questions/articles sur Message Brokers et ESB (même sur stackoverflow). Vous ne savez toujours pas quelle est la différence de distinction entre un messager de messages et un ESB? Maintenant, je tente de comparer les produits, Websphere Broker et Mule ESB !!
Tout d’abord, Webshere Broker est-il (quelle que soit sa version) un ESB? Les gars de nos produits IBM prétendent qu'il s'agit d'un ESB (cela ne m'étonne pas).
Mon information limitée me dit qu'un Message Broker fonctionne sur un modèle HUB-SPOKE. Cependant, l'ESB fonctionne sur une architecture de bus. Maintenant, qu'est-ce que cela est censé vouloir dire? J'ai lu que si le hub échouait (indisponible, je suppose), le courtier échouait complètement. Ce qui n'est pas le cas d'un ESB (donc ces gars disent). Ce que je ne comprends pas, c’est "Et si le BUS" échoue?
Maintenant, ce qui est habituel avec les ESB et les courtiers, c’est-à-dire qu’ils fournissent le routage, la transformation, l’orchestration, etc. Donc, si les deux fournissent cela, alors pourquoi devrais-je choisir l’un plutôt que l’autre.
Un autre domaine de conflit concerne la TRANSFORMATION. Est-ce que les ESB le facilitent d'une manière différente par rapport à Message Brokers? J'aimerais vraiment avoir un aperçu de cela.
Parlons maintenant de la mise à l'échelle HORIZONTAL. Qui surpasse le qui? Ou les deux sont-ils également évolutifs en termes de complexité (ou de tout autre facteur). Bien sûr, en ce qui concerne les coûts, Webshpere Broker vous facturera pour chaque boîte (et encore moins pour chaque unité centrale). Je crois que même le MULE ESB commercial ne fait pas cela. En laissant de côté la partie Coût, quelles sont les implications de la mise à l'échelle ESB et de Message Broker. Je sais que vous pouvez passer au niveau de service dans ESB. Est-ce possible dans un courtier de messages?
Vous pouvez utiliser un agent de transformation sans bus de service, et inversement. Pour ce qui est des produits spécifiques, je ne pense pas que l’un soit purement l’un ou l’autre en raison de la manière dont chacun se complète. Certains produits sont plus forts dans un domaine, d'autres plus forts dans un autre. Peut-être faut-il choisir 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 la construction d'une chaîne de transformation qu'un produit ESB. Un courtier mis en service en tant qu'ESB peut être écrasé sous la charge et mal dimensionné, 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 relire 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 soutien transactionnel. Pour que cela fonctionne dans toutes vos "transactions", il faut presque que ce soit des événements commerciaux (une vente, un renouvellement, un changement de propriétaire, etc.) plutôt que quelque chose comme les "mises à jour de base de données" de RPCish.
Avertissement: Je suis un consultant IBM et spécialisé dans WebSphere ESB. Ce commentaire n'est pas laissé dans aucun pouvoir officiel.
Un ESB est davantage un modèle ou un concept architectural qu'un produit - en gros, une manière basée sur le service de concevoir un couplage lâche. Sa définition est discutée et pas exactement figée. En général, un ESB est un ensemble de services non liés (au sens technique): ils exposent des interfaces et les consomment d'autres services. Généralement, il n’ya pas d’architecture en étoile, bien que cela puisse être le cas.
IBM commercialise certainement WebSphere Message Broker et WebSphere ESB en tant que produits facilitant la création d’un ESB (avec l’appliance matérielle DataPower). Ils ont des racines technologiques différentes, mais leurs objectifs se chevauchent. En outre, cela ne veut pas dire que vous ne pouvez pas construire un ESB avec beaucoup d'autres choses qui ne sont pas considérées comme un "produit ESB".
Cela ne répond pas à toutes vos questions, mais, espérons-le, concerne la partie IBM.
La différence entre un courtier de messages et un ESB réside principalement dans le mot "bus".
Pour moi, un courtier de messages est un processus (généralement gros) qui transforme des données d'une structure en une autre structure ou qui modifie le contenu.
Un ESB est un middleware orienté message (MOM) avec des services supplémentaires, dont l'un pourrait être un agent de messagerie. Ainsi, un ESB peut inclure un courtier de messages en tant que composant. Un bus se compose de plusieurs processus, sinon je ne l'appellerais pas un "bus". La nature d’un bus est qu’il existe plusieurs composants servant différentes tâches, chacun communiquant via un MOM et adhérant à une forme de "format de données commun". Un bus comprendrait les éléments suivants: applications envoyant des données au MOM, adaptateurs de base de données, courtiers de messages, ponts MOM, etc.
La séparation est un peu progressive, mais la plus grande différence entre une architecture Message Broker 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 gros Message Broker qui connecte tout le monde. Ou avec un ESB où plusieurs petits composants n'assument que de petites tâches. Par exemple, un adaptateur se connecte à A, un autre à B (mais ne fait pas de transformation), puis chacun envoie ses données à un (ou plusieurs) Message Broker, qui doivent être aussi simples que possible - par exemple. ne pas avoir à connaître le modèle de données de 'A' ou 'B'. Un bon ESB doit avoir une définition commune des données sur le bus, résumant la "différence" des applications individuelles.
TRANSFORMATION: un ESB n’aide pas à la transformation, sauf s’il est livré avec un courtier de messages. Mais chaque bon ESB devrait quand même inclure un courtier de messages. Le courtier de messages devrait être l'expert de votre bus pour les transformations, mais rien d'autre.
Mise à l'échelle HORIZONTALE: si vous ne devez connecter que 3 éléments (maintenant et pour toujours), vous ne pourrez probablement pas gagner l'effort nécessaire pour obtenir un ESB complet. Un courtier de messages a l’avantage d’être un gros processus. Vous pouvez tout configurer et avoir un emplacement central pour tous vos mappages de données, votre filtrage et votre routage.
Mais si vous devez vous connecter à 30 applications, un courtier de messages finirait probablement par s'arrêter. Bien sûr, vous pouvez acheter plus d'instances, exécuter des tâches redondantes, etc., mais vous devez modifier votre stratégie pour "localiser" les emplois. L'adaptateur de chaque application (une petite instance de Message Broker par exemple) devrait pouvoir générer et/ou recevoir un modèle de données commun abstrait (par exemple, XML avec un fichier XSD partagé). Il peut également y avoir un courtier de messages central pour les tâches de transformation, mais cette instance ne doit pas connaître le modèle de données A ou B. Un ESB doit donc transférer le traitement sur le composant expert au lieu de tout conserver dans un emplacement central.
Je viens de lire cet article d'Udi Dahan il y a quelques jours, qui pourrait vous donner une idée plus précise de ce que je considère être une différence fondamentale.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
Citant:
La règle selon laquelle il ne peut y avoir qu'un seul éditeur pour un type d'événement donné est l'une des choses qui différencient les bus des courtiers, bien que les deux vous permettent évidemment d'avoir plusieurs abonnés.
...
Malheureusement, de nombreuses technologies de type courtier sont commercialisées sous la bannière d’Enterprise Service Bus. Certains produits peuvent être déployés de manière centralisée et distribuée (parfois appelés mode "fédéré" ou "incorporé"), mais beaucoup n'appliquent pas la règle "un seul noeud final de publication par type d'événement".
Sans cette contrainte, il est trop facile de faire des erreurs.
J'espère que ça aide.
Un bus de service d'entreprise fournit trois valeurs clés à l'entreprise:
- Routage des transactions en fonction du contexte ou du contenu;
- Transformation d'un domaine de message ou transport vers un autre domaine de message ou transport;
- connectivité de plusieurs à plusieurs services.
Les ESB fournissent un couplage lâche des services, permettent de reconstituer des services dans des contextes d'application totalement différents de ceux qui étaient envisagés ou développés pour la première fois, et promouvaient la réutilisation des applications sans qu'il soit nécessaire de les recoder. WebSphere Message Broker (ou s'appelle maintenant IBM Integration Bus) est un excellent exemple de bus de service d'entreprise. Pour un exemple de simplicité de code qui apporte un grand pouvoir en quelques lignes, vous pouvez consulter mon post ici: http://soabus.org/viewtopic.php?f=3&t=1 . La construction fondamentale à l'intérieur du moteur d'exécution IIB est appelée l'arborescence de messages logique (LMT). Tout ce que le développeur veut faire, c'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 ne peut rivaliser avec l'efficacité et la facilité de développement d'ESB. applications que IBM Integration Bus puisque 90% du codage de ces applications est effectué en glissant-déposant des noeuds sur une palette. Cela ne laisse que 10% du codage à faire par le développeur de Message Flow. A propos, WebSphere ESB a été abandonné par IBM et de nombreux produits concurrents d’IBM Integration Bus n’ont connu aucun nouveau développement depuis plusieurs années. Une liste de diverses offres de produits ESB peut être consultée sur soabus.org.