J'ai parcouru différentes questions / articles sur les courtiers de messages et les ESB (même sur stackoverflow). Vous ne savez toujours pas quelle est la différence de démarcation CLEAR entre un courtier de messages et un ESB? J'essaye maintenant de comparer les produits, Websphere Broker et Mule ESB !!
Premièrement, est-ce que (toute version) Webshere Broker est un ESB? Nos produits IBM prétendent qu'il s'agit d'un ESB! (Cela ne m'étonne pas).
Mes informations limitées m'indiquent qu'un courtier de messages fonctionne sur un modèle HUB-SPOKE. Cependant l'ESB fonctionne sur une architecture de bus. Maintenant qu'est-ce que ça veut dire? J'ai lu que si le HUB échoue (indisponible je suppose), le courtier échoue complètement. Ce qui n'est pas le cas d'un ESB (comme disent ces gars-là). Ce que je ne comprends pas ici, c'est "Et si le BUS" échoue?
Maintenant, le truc habituel à propos des ESB et des courtiers est que, ils fournissent le routage, la transformation, l'orchestration, etc. Donc, si les deux fournissent cela, alors pourquoi choisirais-je l'un plutôt que l'autre.
Un autre domaine de conflit concerne la TRANSFORMATION. Les ESB le facilitent-ils différemment par rapport aux courtiers en messages? J'aimerais vraiment avoir un aperçu de cela.
Parlons maintenant de la mise à l'échelle HORIZONTALE. Qui surpasse le qui? Ou les deux sont-ils également évolutifs en termes de complexité (ou de tout autre facteur). Bien sûr, en termes de coût, Webshpere Broker vous facturera pour chaque boîte (sans parler de chaque processeur). 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 la mise à l'échelle de Message Broker. Je sais que vous pouvez passer au niveau de service dans ESB. Est-ce possible dans un courtier de messages?
la source
Réponses:
Vous pouvez utiliser un courtier de transformation sans bus de service, et vice versa. En ce qui concerne les produits spécifiques, je ne pense pas que l'un d'entre eux soit purement l'un ou l'autre en raison de la façon dont chacun se complète l'autre. Certains produits sont plus solides dans un domaine, d'autres plus solides 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 mis en service en tant qu'ESB peut être écrasé sous la charge et ne pas évoluer correctement, ou peut manquer de journalisation et d'outils robustes 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 support 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 des «mises à jour de la base de données» RPCish.
la source
Clause de non-responsabilité: Je suis consultant IBM et je suis spécialisé 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 - en gros, une manière basée sur les services de concevoir un couplage lâche. Sa définition est disputée et pas exactement gravée dans le marbre. En général, un ESB est un ensemble de services non liés (au 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 qu'il puisse y en avoir.
IBM commercialise certainement WebSphere Message Broker et WebSphere ESB en tant que 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. De plus, cela ne veut pas dire que vous ne pouvez pas construire 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 j'espère qu'il répond à la partie IBM.
la source
La différence entre un courtier de messages et un ESB (Enterprise Service Bus) est principalement le mot «bus».
Pour moi, un courtier de messages est un processus (généralement gros) qui transforme les données d'une structure en une autre structure ou modifie le contenu.
Un ESB est un middleware orienté message (MOM) ainsi que des services supplémentaires, dont l'un pourrait être un courtier de messages. Ainsi, un ESB peut inclure un courtier de messages comme l'un de ses composants. Un bus se compose 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 via un MOM et adhérant à une forme de «format de données commun». Un bus comprendrait: des applications envoyant des données au MOM, des adaptateurs de base de données, 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 seul grand courtier de messages qui connecte tout le monde. Ou avec un ESB où plusieurs petits composants ne prennent en charge que 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 trucs à un (ou plusieurs) courtier de messages, chacun d'entre eux devant être aussi simple que possible - par exemple non avoir à connaître le modèle de données de «A» ou «B». Un bon ESB doit avoir une définition de données commune sur le bus, en faisant abstraction de la «différence» des applications individuelles.
TRANSFORMATION: un ESB n'aide pas à la transformation, à moins qu'il ne soit livré avec un courtier de messages. Mais chaque bon ESB devrait de toute façon 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 n'avez que 3 éléments à connecter (maintenant et pour toujours), cela ne vaut probablement pas la peine d'obtenir un ESB à part entière. Un courtier de messages a l'avantage de n'être qu'un gros processus. Vous pouvez tout configurer et disposer d'un emplacement central pour tous vos mappages de données, filtrage et routage.
Mais si vous avez 30 applications à connecter, un courtier de messages s'arrêterait probablement. Bien sûr, vous pouvez acheter plus d'instances, exécuter des tâches de manière redondante, etc., mais vous devez modifier votre stratégie pour «localiser» les tâches. L'adaptateur de chaque application (qui peut être une petite instance de Message Broker chacun) doit ê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 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. Ainsi, un ESB devrait déplacer le traitement vers le composant expert au lieu de tout garder dans un endroit central.
la source
Je viens de lire cet article d'Udi Dahan il y a quelques jours, qui pourrait vous donner une vision plus claire de ce que je ressens comme une différence fondamentale.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
Citant:
...
J'espère que ça aide.
la source
Un bus de service d'entreprise fournit trois valeurs clés à l'entreprise:
Les ESB offrent un couplage lâche des services, permettent de reconstituer les services dans des contextes d'application entièrement différents de ceux lors de la première conception ou développement des services, et favorisent la réutilisation des applications sans qu'il soit nécessaire de recoder les applications. WebSphere Message Broker (ou s'appelle désormais IBM Integration Bus) est un excellent exemple d'Enterprise Service Bus. 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 du runtime IIB est appelée l' arbre logique des messages(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 ne se rapproche de l'efficacité et de la facilité de développement d'ESB applications qu'IBM Integration Bus puisque 90% du codage de ces applications se fait par glisser-déposer de nœuds sur une palette. Cela ne laisse que 10% du codage à faire par le développeur du flux de messages. Soit dit en passant, 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 des différentes offres de produits ESB peut être consultée sur soabus.org.
la source
Depuis, IBM a changé les noms de son offre ESB, donc je n'entrerai pas dans les noms ou les fournisseurs.
ESB permet aux informations commerciales de circuler entre des applications disparates sur plusieurs plates-formes matérielles et logicielles. ESB est davantage une couche middleware qui contient une logique de connectivité d'application et une logique métier minimale ou nulle. Cela permet aux applications de faire ce qu'elles font de mieux sans se soucier d'incorporer une logique de connectivité sur la façon d'interagir avec d'autres N nombre d'applications qui en nécessitent les données. L'architecture ESB tente de résoudre le désordre de spaghetti point à point dans une entreprise.
ESB et Message Broker sont en quelque sorte des synonymes l'un de l'autre, cependant, comme l'une des réponses ci-dessus l'a souligné, le modèle Messages 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 relie divers composants pour le fonctionnement de l'ordinateur. ESB est un bus basé sur logiciel reliant divers services dans une entreprise. Hub and spoke est l'un des modèles pris en charge par l'architecture ESB. Dans le monde monolithique, chaque fournisseur dispose de sa propre architecture de déploiement haute disponibilité pour garantir la disponibilité de l'ESB. Les offres récentes de tout fournisseur ESB sont en termes de modèle de déploiement basé sur des microservices ou hébergées dans leur propre cloud appelé iPAAS. Ainsi, cela garantit que Bus ne tombera jamais en panne ou échouera temporairement avec l'auto-réparation en fonction de votre modèle de déploiement sélectionné. Avec le déploiement basé sur des microservices ou iPAAS, les ESB ont désormais des capacités de mise à l'échelle automatique (horizontalement ou verticalement) avec des fonctionnalités variant en fonction du fournisseur sélectionné.
Pour les fonctionnalités de très haut niveau fournies par ESB, vous pouvez passer par le lien suivant => https://en.wikipedia.org/wiki/Enterprise_service_bus
la source