Différence entre un courtier de messages et un ESB

J’ai parcouru différentes questions / articles sur les courtiers de messages et les ESB (même sur stackoverflow). Toujours pas la moindre idée de ce qu’est la différence de démarcation CLEAR entre un courtier de messages et un ESB? Maintenant, j’essaie de comparer les produits, Websphere Broker et Mule ESB !!

Premièrement, Webshere Broker est-il un ESB? Nos spécialistes des produits IBM le prétendent être un ESB (je ne suis pas surpris).

Mes informations limitées me disent 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 c’est censé vouloir dire? J’ai lu que si le HUB échoue (indisponible je suppose) alors le courtier échoue complètement. Ce qui n’est pas le cas d’un ESB (alors ces gars-là disent). Ce que je ne comprends pas, c’est “Et si le BUS” échoue?

Maintenant, les trucs habituels sur les ESB et les courtiers sont les suivants: ils fournissent un routage, une transformation, une orchestration, etc. Donc, si les deux fournissent cela, alors pourquoi choisirais-je l’un sur l’autre.

Un autre domaine de conflit concerne la TRANSFORMATION. Est-ce que les ESB le facilitent différemment par rapport à Message Brokers? J’aimerais vraiment avoir un aperçu de cela.

Parlons maintenant de la mise à l’échelle HORIZONTALE. Qui surpasse les qui? Ou sont-ils tous les deux également évolutifs en termes de complexité (ou d’autres facteurs). Bien sûr, Webshpere Broker va vous facturer pour chaque boîte (sans parler de chaque processeur). Je crois que même le commercial MULE ESB ne le fait pas. En dehors de la partie coût, quelles sont les implications de la mise à l’échelle ESB et de la mise à l’échelle de Message Broker. Je sais que vous pouvez augmenter le niveau de service dans ESB. Est-ce possible dans un courtier de messages?

    Vous pouvez utiliser un courtier de transformation sans bus de service et inversement. En ce qui concerne 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 complète l’autre. 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 la mieux adaptée à un problème individuel.

    Un courtier peut avoir de meilleurs “blocs de lego” intégrés pour construire une chaîne de transformation qu’un produit ESB. Un courtier mis en service en tant qu’ESB peut être écrasé sous une charge et ne pas évoluer correctement, ou peut ne pas disposer d’une journalisation robuste et d’outils pour traiter les journaux.

    Certains ESB permettent de restaurer les mises à jour des bases de données et de rejouer les files d’attente dans une application corrigée, une fois qu’une erreur de logique majeure 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, toutes 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 firebase database” de RPCish.

    Disclaimer: Je suis un consultant IBM et je me spécialise dans WebSphere ESB. Ce commentaire n’est laissé à aucun titre officiel.

    Un ESB est plus un modèle ou un concept architectural qu’un produit – au sens large, un mode d’ingénierie basé sur le couplage lâche. Sa définition est disputé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 consumnt à partir d’autres services. En général, il n’ya pas d’architecture en écanvas, bien qu’il puisse y en avoir.

    IBM commercialise certainement WebSphere Message Broker et WebSphere ESB comme des produits facilitant la création d’un ESB (avec l’appliance matérielle DataPower). Ils ont des racines technologiques différentes, mais leurs objectives se recoupent. En outre, cela ne veut pas dire que vous ne pouvez pas créer un ESB avec beaucoup d’autres choses qui ne sont pas qualifiées de «produit ESB».

    Cela ne répond pas à toutes vos questions mais, espérons-le, répond à la partie IBM.

    Je viens de lire cet article d’Udi Dahan il ya quelques jours, ce qui pourrait vous donner une vision plus claire de ce que j’estime ê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érencie les bus des courtiers, même si les deux permettent évidemment d’avoir plusieurs abonnés.

    Malheureusement, de nombreuses technologies de type courtier sont commercialisées sous la bannière du bus de service d’entreprise. Alors que certains produits peuvent être déployés de manière centralisée et dissortingbuée (parfois appelée mode «fédéré» ou «intégré»), nombreux sont ceux qui n’appliquent pas la règle du «sharepoint terminaison de publication unique par type d’événement».

    Sans cette contrainte, il est trop facile de faire des erreurs.

    J’espère que cela aide.

    La différence entre un courtier de messages et un ESB est principalement le mot «bus».

    Pour moi, un Message Broker est un processus (généralement important) qui transforme les données d’une structure à une autre ou modifie le contenu.

    Un ESB est un middleware orienté message (MOM) plus des services supplémentaires, dont l’un peut être un Message Broker. Un ESB peut donc inclure un Message Broker parmi ses composants. Un bus se compose de plusieurs processus, sinon je ne l’appellerais pas «bus». La nature d’un bus réside dans le fait qu’il existe plusieurs composants servant des tâches différentes, chacun communiquant sur une MOM et adhérant à une forme quelconque de «format de données commun». Un bus comprendrait: des applications envoyant des données à la MOM, des adaptateurs de firebase database, des courtiers de messages, des 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 la 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 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 fichiers à un (ou plusieurs) Message Broker, chacun d’entre eux devant restr aussi simple que possible. avoir à connaître le modèle de données de «A» ou «B». Un bon ESB devrait avoir une définition de données commune sur le bus, en dérogation à la «différence» des applications individuelles.

    TRANSFORMATION: un ESB n’aide pas à la transformation, à moins qu’il ne soit accompagné d’un Message Broker. Mais chaque bon ESB devrait inclure un Message Broker. Le Message Broker devrait être l’expert de votre bus pour les transformations, mais rien d’autre.

    Mise à l’échelle HORIZONTALE: si vous n’avez que 3 choses à connecter (maintenant et pour toujours), cela ne vaut probablement pas la peine d’obtenir un ESB complet. Un courtier de messages a l’avantage d’être un grand processus. Vous pouvez tout configurer là-bas et disposer d’un emplacement central pour tous vos mappages de données, filtrage et routage.

    Mais si vous avez 30 applications à connecter, un Message Broker devrait probablement s’arrêter. Bien sûr, vous pouvez acheter plus d’instances, exécuter des tâches redondantes, etc., mais vous devez changer votre stratégie pour «localiser» les tâches. L’adaptateur de chaque application (peut être une petite instance de Message Broker) doit pouvoir générer et / ou recevoir un modèle de données commun abstrait (par exemple XML avec un XSD partagé). Il pourrait également y avoir un courtier 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. Un ESB devrait donc transférer le traitement au composant expert au lieu de tout garder au centre.

    Un bus de service d’entreprise fournit trois valeurs clés à l’entreprise:

    1. Acheminement des transactions en fonction du contexte ou du contenu;
    2. Transformation d’un domaine de message ou transport à un autre domaine ou transport de message;
    3. connectivité de service plusieurs à plusieurs.

    Les ESB permettent un couplage libre des services, permettent de reconstituer les services dans des contextes applicatifs totalement différents de ceux envisagés ou développés pour la première fois, et favorisent la réutilisation des applications sans avoir à recoder les applications. WebSphere Message Broker (ou maintenant appelé IBM Integration Bus) est un exemple de bus de service d’entreprise. Pour un exemple de simplicité de code qui apporte une grande puissance en quelques lignes, vous pouvez consulter mon article ici: http://soabus.org/viewtopic.php?f=3&t=13 . La construction fondamentale à l’intérieur de l’environnement d’exécution IIB s’appelle l’ arborescence de messages logiques (LMT). Tout ce que le développeur veut faire, c’est un certain 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.). des applications que IBM Integration Bus, car 90% du codage de ces applications se fait par glisser-déposer des nœuds sur une palette. Cela ne laisse que 10% du codage effectué par le développeur Message Flow. En passant, WebSphere ESB a été abandonné par IBM et nombre de produits concurrents d’IBM Integration Bus n’ont plus connu de développement depuis plusieurs années. Une liste des différentes offres de produits ESB peut être consultée sur soabus.org.