Jan12
Das Wesen eines ESB

Was macht einen Enterprise Service Bus (ESB) zum Bus und wie unterscheidet er sich von einem Broker.

Definition des ESB

Abbildung 1: Schema ESB

Abbildung 1: Schema ESB

Der ESB ist zum einen ein Architekturkonzept, zum anderen eine Produktkategorie für Produkte die die Integration von Anwendungen und Services als Aufgabe haben. Dies führt gerne zu einem Missverständnis, insbesondere, wenn das Produkt selbst Enterprise Service Bus heißt, wie z.B. der WebSphere ESB. Aussagen wie „Das machen wir mit dem ESB“ ist damit unklar. Was ist gemeint? Das machen wir gemäß dem Architekturkonzept ESB, oder das machen wir mit dem Produkt ESB. Wenn vom ESB gesprochen wird, ist somit nicht klar, ob das Architekturkonzept oder das Produkt gemeint ist, oder es wird sogar das eine mit dem anderen gleich gesetzt.
Viele ESB Produkte sind als eine zentrale ESB Instanz installiert. Diese sind zwar als Cluster aufgebaut, bleiben jedoch eine zentrale Instanz, über die sämtliche Kommunikation läuft. Damit unterscheidet sich so ein ESB nicht von einem zentralen Broker, mit einer Hub&Spoke Architektur. Diese Art der Architektur gibt es schon länger als einen ESB und wird mit einem Message Broker umgesetzt.

Abbildung 2: Schema Broker

Abbildung 2: Schema Broker

Was ist also das Neue an einem ESB und was macht ihm zum Bus? Ein ESB ist von seiner Natur her eine verteilte Architektur und keine Hub&Spoke Architektur mit einem zentralen (monolithischen) Broker.

Abbildung 1 zeigt den schematischen Aufbau eines ESB gemäß dem Buch Enterprise Service Bus von David Chapell. Das Herz des ESB ist eine zentrale Kommunikations-Infrastruktur, der Message Bus. Dieser wird z.B. mit einer Message Orientierten Middleware, wie z.B. MQ Series oder Active MQ umgesetzt. Des weiteren besteht der ESB aus mehreren (leichtgewichtigen) ESB Containern oder Laufzeitumgebungen, die verteilt sind. In diesen ESB Container laufen Integrations-Komponenten wie z.B. eine Transformation. Diese können unabhängig voneinander deployed, betrieben und skaliert werden. Somit führt der Ausfall eines einzelnen ESB Containers nicht zum Ausfall des kompletten ESB und damit zum Ausfall der kompletten Kommunikation, wie dies bei einem zentralen Broker der Fall ist. Auch können die einzelnen ESB Container unabhängig voneinander skaliert werden, was unter dem Strich Kosten spart. So kann z.B. eine performanceintensive XSLT Transformation auf einem dedizierten Transformations-Container betrieben werden. Damit muss nur dieser eine Container hoch skaliert werden und nicht die komplette Broker Infrastruktur mit allen Integrations-Diensten.

Aufgaben des ESB

Services verbinden sich mit dem ESB über Endpunkte. Anwendungen, die keine standardisierten Services (z.B. Web Services über SOAP/HTTP) bereit stellen können werden über Adapter angebunden. Spezielle Adapter sind meist Bestandteil von ESB Produkten. Die Kommunikation zwischen Service Consumer und Service Provider läuft über den ESB. Dieser muss eine sichere Zustellung von Nachrichten gewährleisten. Dafür wird der Messsage Bus genutzt. Um (inkompatible) Consumer und Provider miteinander zu verbinden stellt der ESB Integrations-Dienste zur Verfügung. Die wichtigsten sind:

  • Routing-Dienste leiten Nachrichten an den richtigen Empfänger weiter. Z.B. über Regeln und basierend auf den Inhalt der Nachricht (Content Based Routing)
  • Transformations-Dienste transformieren Nachrichten und Datenmodelle von einem Format in ein anderes um inkompatible Kommunikationspartner miteinander zu verbinden. Aber auch die Transformation von einem Protokoll in ein anderes, z.B. MQ auf HTTP, gehört zu den Aufgaben des ESB.
  • Orchestrierungsdienste orchestrieren Services zu höherwertigen Diensten (Composite Services) und ganzen Prozessabläufe. Ob diese Dienste zum ESB gehören oder außerhalb des ESB laufen sollten, darüber kann gestritten werden. Die ESB Produktanbieter stellen eine ganze Reihe von Funktionen und Werkzeugen zur Verfügung um genau dies einfach, grafisch und modellgetrieben in einem ESB machen zu können. Dabei werden oft die Enterprise Integration Patterns umgesetzt. Man muss sich dabei bewusst machen, dass damit meist Fachlichkeit in den ESB wandert.
  • Security-Dienste prüfen, ob ein Consumer einen bestimmten Service aufrufen darf.

Laut Chapell sind die wichtigsten Funktionen und Eigenschaften eines ESB:

  • Eine verteilte Service Architektur mit leichtgewichtigen Container für das Hosting von Integrations Komponenten als Remote Services
  •  Eine Messsaging Infrastruktur für die Nachrichtenzustellung
  • XML Transformation
  • Service Orchestrierung und intelligentes Routing
  • Ein flexibles Security Framework
  • Eine Management Infrastruktur um Remote Services konfigurieren, deployen, Monitoren und managen zu können

Die englische Wikipedia-Seite stellt eine ganze Reihe von Eigenschaften eines ESB dar, die so meist von den Produktherstellern angeboten werden. Wenn aber ein Produkt alle diese Funktionen anbietet, führt dies schnell dazu, dass man nur eine ESB Instanz hat, und damit einen zentralen Broker. Es macht also Sinn mehrere ESB Instanzen zu haben und diesen entweder bestimmte Aufgaben zuzuweisen oder sie für dedizierte Szenarien oder Kommunikations-Strecken einzusetzen.

Fazit

Der Unterschied zwischen einem ESB und einem Broker liegt in der Architektur. Beim ESB handelt es sich um eine verteilte Bus Infrastruktur, beim Broker um eine Hub&Spoke Architektur mit einem zentralen Broker. Wird ein ESB Produkt als eine einzelne zentrale Instanz installiert, hat man eine Broker und nicht eine Bus Architektur. Es ist wichtig sich über die Architektur und den konkreten Aufbau des ESB (im Sinne des Architekturkonzeptes) Gedanken zu machen und nicht einfach nur ein Produkt zu installieren und zu glauben, dass man damit einen ESB hat.

weiterführende Informationen

Schreibe einen Kommentar

Anmelden um einen Kommentar abzugeben.

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*