it-swarm.com.de

Unterschied zwischen einem Message Broker und einem ESB

Ich habe verschiedene Fragen/Artikel zu Message Brokers und ESBs durchgesehen (auch zu Stackoverflow). Immer noch keine Ahnung, was ist der CLEAR-Unterschied zwischen einem Message Broker und einem ESB? Jetzt versuche ich hier Produkte zu vergleichen, Websphere Broker und Mule ESB !!

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

Meine begrenzten Informationen besagen, dass ein Message Broker auf einem HUB-SPOKE-Modell funktioniert. Der ESB arbeitet jedoch mit einer Busarchitektur. Was um alles in der Welt soll das heißen? Ich habe gelesen, dass der Broker komplett ausfällt, wenn der HUB ausfällt (nicht verfügbar, denke ich). Was bei einem ESB nicht der Fall ist (so sagen die Jungs). 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 eine der anderen vorziehen?.

Ein weiteres Konfliktfeld betrifft die TRANSFORMATION. Ermöglichen ESBs dies anders als Message Brokers? Ich würde wirklich gerne einen Einblick in diese Sache bekommen.

Sprechen Sie jetzt über die horizontale Skalierung. Wer übertrifft wen? Oder beide sind hinsichtlich ihrer Komplexität (oder anderer Faktoren) gleich skalierbar. Natürlich kostet Webshpere Broker Sie für jede Box (geschweige denn für jede CPU). Ich glaube, selbst der kommerzielle MULE ESB macht das nicht. Abgesehen von den Kosten, was sind die Auswirkungen der ESB-Skalierung und der 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?

121
Franklin

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

Ein Broker verfügt möglicherweise über bessere integrierte "Legoblöcke" zum Erstellen einer Transformationskette als ein ESB-Produkt. Ein Broker, der als ESB in Dienst gestellt wurde, kann unter Last zerdrückt werden und sich nicht gut skalieren lassen, oder es fehlen 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 denke nicht, dass die meisten Broker dieses Maß an Transaktionsunterstützung integrieren. Damit dies bei all Ihren "Transaktionen" funktioniert, müssen fast Geschäftsereignisse (ein Verkauf, eine Erneuerung, ein Eigentümerwechsel usw.) statt so etwas wie RPCish "Datenbankaktualisierungen" sein.

25
Bob77

Haftungsausschluss: Ich bin ein IBM-Berater und auf WebSphere ESB spezialisiert. Dieser Kommentar hat keine offizielle Funktion.

Ein ESB ist eher ein Architekturmuster oder -konzept als ein Produkt - im Allgemeinen eine serviceorientierte Methode zur Entwicklung 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 machen Schnittstellen verfügbar 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 die Erstellung eines ESB (zusammen mit der DataPower-Hardware-Appliance) vereinfachen. Sie haben unterschiedliche technologische Wurzeln, aber einige Überschneidungen im Zweck. Das soll nicht heißen, dass Sie keinen ESB mit vielen anderen Dingen bauen können, die nicht als "ESB-Produkt" gekennzeichnet sind.

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

21
Andrew Ferrier

Der Unterschied zwischen einem Message Broker und einem ESB besteht hauptsächlich im Wort "Bus".

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

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

Die Trennung erfolgt etwas allmählich, aber der größte Unterschied zwischen einer Message Broker-Architektur und einem Bus ist Granularität. Wenn Ihre Aufgabe darin besteht, die Anwendungen A, B, .., Z und einige Datenbanken zu integrieren, 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. Beispielsweise stellt ein Adapter eine Verbindung zu A her, ein anderer Adapter zu B (führt jedoch keine Transformation durch). Anschließend sendet jeder Adapter seine Daten an einen (oder mehrere) Message Broker, von denen jeder so einfach wie möglich gehalten werden sollte - z. Das Datenmodell von 'A' oder 'B' muss nicht bekannt sein. Ein guter ESB sollte eine gemeinsame Datendefinition auf dem Bus haben, die von der "Verschiedenartigkeit" der einzelnen Anwendungen abstrahiert.

TRANSFORMATION: Ein ESB hilft nicht bei der Transformation, es sei denn, es 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 miteinander 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, dass er nur ein einziger großer Prozess ist. Sie können dort alles konfigurieren und haben einen zentralen Speicherort für alle Ihre Datenzuordnungen, Filter und Routing.

Wenn Sie jedoch 30 Anwendungen verbinden müssen, kommt ein Message Broker wahrscheinlich zum Erliegen. Natürlich können Sie mehr Instanzen kaufen, Dinge redundant 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 verlagern, anstatt alles an einem zentralen Ort zu speichern.

17
Axel Podehl

Ich habe gerade vor ein paar Tagen diesen Artikel von Udi Dahan 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 Publisher geben kann, unterscheidet Busse von Brokern, obwohl beide offensichtlich mehrere Abonnenten zulassen

...

Leider gibt es viele brokerartige Technologien, die unter dem Markennamen 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 die Regel "Einzelner Veröffentlichungsendpunkt pro Ereignistyp" nicht.

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

Ich hoffe es hilft.

14
GR7

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

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

ESBs bieten eine lose Kopplung von Diensten, ermöglichen die Wiederherstellung von Diensten in völlig anderen Anwendungskontexten als zu dem Zeitpunkt, zu dem die Dienste erstmals vorgestellt oder entwickelt wurden, und fördern die Wiederverwendung von Anwendungen, ohne dass Anwendungen neu codiert werden müssen. WebSphere Message Broker (oder jetzt IBM Integration Bus) ist ein erstklassiges Beispiel für einen Enterprise Service Bus. Ein Beispiel für die Einfachheit von Code, die in wenigen Zeilen große Kraft entfaltet, finden Sie in meinem Beitrag hier: http://soabus.org/viewtopic.php?f=3&t=1 . Das grundlegende Konstrukt innerhalb der IIB-Laufzeit heißt Logical Message Tree (LMT). Alles, was der Entwickler tun möchte, ist eine Art Operation am LMT. ESQL ist die effizienteste Sprache, mit der ein Entwickler diese Vorgänge auf dem LMT ausführen kann, obwohl viele andere Sprachen unterstützt werden (z. B. Java, PHP, Python usw.). Kein anderes Produkt ist so effizient und einfach wie die Entwicklung von ESB Anwendungen als IBM Integration Bus, da die Codierung dieser Anwendungen zu 90 Prozent durch Ziehen und Ablegen von Knoten auf einer Palette erfolgt. Das bedeutet, dass nur 10 Prozent der Codierung vom Message Flow-Entwickler ausgeführt werden müssen. Übrigens wurde WebSphere ESB von IBM eingestellt, und viele der Konkurrenzprodukte für IBM Integration Bus wurden seit mehreren Jahren nicht mehr weiterentwickelt. Eine Liste der verschiedenen ESB-Produktangebote finden Sie auf soabus.org.

5
user3223466