Unterschied zwischen einem Message Broker und einem ESB

Ich habe verschiedene Fragen / Artikel zu Message Brokers und ESBs (auch zum Stackoverflow) durchgesehen. Immer noch kein Hinweis darauf, was der klare Unterschied zwischen einem Message Broker und einem ESB ist. Jetzt versuche ich hier Produkte, Websphere Broker und Mule ESB zu vergleichen !!

Ist (jede Version) Webshere Broker ein ESB? Unsere IBM-Produktleute behaupten, es sei ein ESB! (Das überrascht mich nicht).

Meine begrenzten Informationen sagen mir, dass ein Message Broker an einem HUB-SPOKE-Modell arbeitet. Der ESB arbeitet jedoch an einer Busarchitektur. Was um alles in der Welt soll das heißen? Ich habe gelesen, dass der Broker vollständig ausfällt, wenn der HUB ausfällt (ich denke, er ist nicht verfügbar). Was bei einem ESB nicht der Fall ist (sagen die Leute). Was ich hier nicht verstehe, ist "Was ist, wenn der BUS ausfällt?"

Das Übliche an ESBs und Brokern ist, dass sie Routing, Transformation, Orchestrierung usw. bereitstellen. Wenn also beide dies bereitstellen, warum sollte ich dann eines über das andere wählen?

Ein weiterer Konfliktbereich betrifft die TRANSFORMATION. Ermöglichen ESBs dies auf andere Weise als Message Brokers? Ich würde wirklich gerne einen Einblick in diese Sache bekommen.

Sprechen wir jetzt über die horizontale Skalierung. Wer übertrifft wen? Oder sind beide hinsichtlich der Komplexität (oder anderer Faktoren) gleich skalierbar. Natürlich kostet Webshpere Broker Ihnen für jede Box (geschweige denn für jede CPU). Ich glaube, selbst der kommerzielle MULE ESB macht das nicht. Abgesehen vom Kostenteil, welche Auswirkungen hat die ESB-Skalierung und die Message Broker-Skalierung? Ich weiß zufällig, dass Sie in ESB auf Service Level skalieren können. Ist dies in einem Message Broker möglich?

Sie können einen Transformationsbroker ohne Servicebus verwenden und umgekehrt. In Bezug auf bestimmte Produkte denke ich nicht, dass eines nur das eine oder andere ist, weil jedes das andere ergänzt. Einige Produkte sind in einem Bereich stärker, andere in einem anderen. Möglicherweise muss eine Auswahl getroffen werden, die darauf basiert, welche Funktion ein individuelles Problem am besten abdeckt.

Ein Broker verfügt möglicherweise über besser eingebaute "Legoblöcke" zum Aufbau einer Transformationskette als ein ESB-Produkt. Ein als ESB in Dienst gestellter Broker kann unter Last zerquetscht werden und nicht gut skaliert werden, oder es fehlen möglicherweise robuste Journale und Tools für den Umgang mit Journalen.

Bei einigen ESBs können Datenbankaktualisierungen zurückgesetzt und Warteschlangen in einer korrigierten Anwendung wiedergegeben werden, sobald ein schwerwiegender Fehler in der Logik aufgedeckt und behoben wurde. Ich glaube nicht, dass die meisten Broker diese Ebene der Transaktionsunterstützung integrieren. Damit dies bei all Ihren "Transaktionen" funktioniert, müssen es sich fast um Geschäftsereignisse (Verkauf, Erneuerung, Eigentümerwechsel usw.) und nicht um RPCish-Datenbankaktualisierungen handeln.

Haftungsausschluss: Ich bin IBM-Berater und auf WebSphere ESB spezialisiert. Dieser Kommentar wird in keiner offiziellen Funktion hinterlassen.

Ein ESB ist eher ein architektonisches Muster oder Konzept als ein Produkt - im Großen und Ganzen eine serviceorientierte Methode zur Konstruktion loser Kopplungen. Seine Definition ist umstritten und nicht genau in Stein gemeißelt. Im Allgemeinen besteht ein ESB aus nicht verwandten (im technischen Sinne) Diensten - sie legen Schnittstellen offen und verbrauchen sie von anderen Diensten. Im Allgemeinen handelt es sich nicht um eine Hub-and-Spoke-Architektur, obwohl dies möglich ist.

IBM vermarktet sowohl WebSphere Message Broker als auch WebSphere ESB als Produkte, die das Erstellen eines ESB (zusammen mit der DataPower-Hardware-Appliance) vereinfachen. Sie haben unterschiedliche technologische Wurzeln, aber einige Überschneidungen im Zweck. Das heißt auch nicht, dass Sie keinen ESB mit vielen anderen Dingen erstellen können, die nicht als "ESB-Produkt" gekennzeichnet sind.

Das beantwortet nicht alle Ihre Fragen, spricht aber hoffentlich den IBM-Teil an.

Der Unterschied zwischen einem Message Broker und einem ESB (Enterprise Service Bus) ist hauptsächlich das Wort "Bus".

Für mich ist ein Message Broker ein (normalerweise großer) Prozess, der Daten von einer Struktur in eine andere Struktur transformiert oder Inhalte ändert.

Ein ESB ist eine nachrichtenorientierte Middleware (MOM) sowie zusätzliche Dienste, von denen einer ein Message Broker sein kann. Ein ESB kann also einen Message Broker als eine seiner Komponenten enthalten. Ein Bus besteht aus mehr als einem Prozess, sonst würde ich ihn nicht als "Bus" bezeichnen. Die Natur eines Busses besteht darin, dass es mehrere Komponenten gibt, die unterschiedliche Aufgaben erfüllen, wobei jede über eine MOM kommuniziert und sich an eine Art „gemeinsames Datenformat“ hält. Ein Bus würde bestehen aus: Anwendungen, die Daten an das MOM senden, Datenbankadaptern, Message Brokern, MOM-Bridges usw.

Die Trennung erfolgt etwas schrittweise, aber der größte Unterschied zwischen einer Message Broker-Architektur und einem Bus besteht in der Granularität . Wenn Sie die Anwendungen A, B, .., Z und einige Datenbanken integrieren möchten, können Sie dies mit einem großen Message Broker tun, der alle miteinander verbindet. Oder mit einem ESB, bei dem mehrere kleine Komponenten nur kleine Aufgaben übernehmen. Zum Beispiel verbindet sich ein Adapter mit A, ein anderer mit B (aber sie transformieren nicht), dann sendet jeder seine Daten an einen (oder mehrere) Message Broker, von denen jeder so einfach wie möglich gehalten werden sollte - z. B. nicht über das Datenmodell von 'A' oder 'B' Bescheid wissen müssen. Ein guter ESB sollte eine gemeinsame Datendefinition auf dem Bus haben, die von der „Verschiedenartigkeit“ einzelner Anwendungen abstrahiert.

TRANSFORMATION: Ein ESB hilft nicht bei der Transformation, es sei denn, er wird mit einem Message Broker geliefert. Aber jeder gute ESB sollte sowieso einen Message Broker enthalten. Der Message Broker sollte der Experte Ihres Busses für Transformationen sein, aber sonst nichts.

HORIZONTALE Skalierung: Wenn Sie nur drei Dinge verbinden müssen (jetzt und für immer), lohnt es sich wahrscheinlich nicht, einen vollständigen ESB zu erhalten. Ein Message Broker hat den Vorteil, nur ein großer Prozess zu sein. Sie können dort alles konfigurieren und haben einen zentralen Ort für alle Ihre Datenzuordnungen, Filter und Routing.

Wenn Sie jedoch 30 Anwendungen zum Verbinden haben, würde wahrscheinlich ein Message Broker zum Stillstand kommen. Natürlich können Sie mehr Instanzen kaufen, redundante Dinge ausführen usw., aber Sie sollten Ihre Strategie ändern, um Jobs zu lokalisieren. Der Adapter jeder Anwendung (kann jeweils eine kleine Message Broker-Instanz sein) sollte in der Lage sein, ein abstrahiertes gemeinsames Datenmodell (z. B. XML mit einer gemeinsam genutzten XSD) zu generieren und / oder zu empfangen. Es könnte auch einen zentralen Nachrichtenbroker für Transformationsaufgaben geben, aber diese Instanz sollte das Datenmodell A oder B nicht kennen. Daher sollte ein ESB die Verarbeitung auf die Expertenkomponente verschieben, anstatt alles an einem zentralen Ort zu halten.

Ich habe gerade diesen Artikel von Udi Dahan vor ein paar Tagen gelesen, der Ihnen einen klareren Überblick darüber geben könnte, was meiner Meinung nach ein grundlegender Unterschied ist.

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

Zitat:

Die Regel, dass es für einen bestimmten Ereignistyp nur einen einzigen Publisher geben kann, unterscheidet Busse von Brokern, obwohl Sie in beiden Fällen offensichtlich mehrere Abonnenten haben können

...

Leider gibt es viele Technologien im Broker-Stil, die unter dem Banner des Enterprise Service Bus vermarktet werden. Während einige Produkte sowohl zentral als auch verteilt bereitgestellt werden können (manchmal als "Verbund" - oder "eingebetteter" Modus bezeichnet), erzwingen viele nicht die Regel "Einzelpublikationsendpunkt pro Ereignistyp".

Ohne diese Einschränkung ist es einfach zu leicht, Fehler zu machen.

Ich hoffe es hilft.

Ein Enterprise Service Bus bietet dem Unternehmen drei Schlüsselwerte:

1. Kontext- oder inhaltsbasiertes Routing von Transaktionen;
2. Umwandlung von einer Nachrichtendomäne oder einem Transport in eine andere Nachrichtendomäne oder einen anderen Transport;
3. Viele-zu-Viele-Service-Konnektivität.

ESBs bieten eine lose Kopplung von Diensten, ermöglichen die Wiederherstellung von Diensten in völlig andere Anwendungskontexte als bei der ersten Vorstellung oder Entwicklung der Dienste und fördern die Wiederverwendung von Anwendungen, ohne dass Anwendungen neu codiert werden müssen. WebSphere Message Broker (oder jetzt IBM Integration Bus genannt) ist ein Paradebeispiel für einen Enterprise Service Bus. Ein Beispiel für die Einfachheit des Codes, der in wenigen Zeilen große Wirkung entfaltet, finden Sie in meinem Beitrag hier: http://soabus.org/viewtopic.php?f=3&t=13 . Das grundlegende Konstrukt innerhalb der IIB-Laufzeit wird als logischer Nachrichtenbaum bezeichnet(LMT). Alles, was der Entwickler tun möchte, ist eine Operation auf dem LMT. ESQL ist die effizienteste Sprache, die ein Entwickler verwenden kann, um diese Vorgänge auf dem LMT auszuführen, obwohl viele andere Sprachen unterstützt werden (z. B. Java, PHP, Python usw.). Kein anderes Produkt kommt der Effizienz und Einfachheit der Entwicklung von ESB nahe Anwendungen als IBM Integration Bus, da 90 Prozent der Codierung dieser Anwendungen durch Ziehen und Ablegen von Knoten auf eine Palette erfolgt. Damit müssen nur noch 10 Prozent der Codierung vom Message Flow-Entwickler durchgeführt werden. Übrigens wurde WebSphere ESB von IBM eingestellt, und viele der Konkurrenzprodukte zu IBM Integration Bus wurden seit mehreren Jahren nicht mehr weiterentwickelt. Eine Liste verschiedener ESB-Produktangebote finden Sie unter soabus.org.

IBM hat seitdem die Namen seines ESB-Angebots geändert, sodass ich nicht auf die Namen oder Anbieter eingehen würde.

Mit ESB können Geschäftsinformationen zwischen unterschiedlichen Anwendungen auf mehreren Hardware- und Softwareplattformen übertragen werden. ESB ist eher eine Middleware-Schicht, die Anwendungskonnektivitätslogik und minimale bis KEINE Geschäftslogik enthält. Auf diese Weise können Anwendungen das tun, was sie am besten können, ohne sich Gedanken über die Einbettung einer Konnektivitätslogik für die Interaktion mit anderen N Anwendungen machen zu müssen, für die die Daten erforderlich sind. Die ESB-Architektur versucht, das Punkt-zu-Punkt-Spaghetti-Chaos in einem Unternehmen zu lösen.

ESB und Message Broker sind eine Art Synonym für einander. In einer der obigen Antworten wurde jedoch hervorgehoben, dass das Messages Broker-Muster ein Teil der größeren ESB-Domäne ist. Der Buchstabe "B" in ESB ist analog zum Bus (Hardware) in der Computerarchitektur. Der Bus auf der Hauptplatine oder in einem Computer verbindet verschiedene Komponenten für die Funktion des Computers. ESB ist ein softwarebasierter Bus, der verschiedene Dienste in einem Unternehmen verbindet. Hub and Spoke ist eines der Muster, die von der ESB-Architektur unterstützt werden. In der monolithischen Welt verfügt jeder Anbieter über eine eigene Hochverfügbarkeitsbereitstellungsarchitektur, um sicherzustellen, dass der ESB verfügbar ist. Die jüngsten Angebote eines ESB-Anbieters beziehen sich auf ein auf Microservices basierendes Bereitstellungsmodell oder werden in einer eigenen Cloud namens iPAAS gehostet. Auf diese Weise wird sichergestellt, dass der Bus niemals ausfällt oder vorübergehend ausfällt, wenn die Selbstheilung basierend auf dem ausgewählten Bereitstellungsmodell erfolgt. Mit Microservices-basierter Bereitstellung oder iPAAS verfügen ESBs jetzt über automatische Skalierungsfunktionen (horizontal oder vertikal), wobei die Funktionen je nach ausgewähltem Anbieter variieren.

Informationen zu den von ESB bereitgestellten Funktionen auf sehr hohem Niveau erhalten Sie über den folgenden Link:> https://en.wikipedia.org/wiki/Enterprise_service_bus