Mit Enterprise Service Bus (ESB) bezeichnet man in der Informationstechnik (IT) eine Netzwerkarchitektur, die die Integration verteilter Dienste () in der Anwendungslandschaft eines Unternehmens (engl. ) unterstützt.
Teilweise bezeichnet man mit Enterprise Service Bus auch die Infrastruktur, die ein bestimmtes Unternehmen für die Integration der Dienste in seiner Anwendungslandschaft aufbaut. einen Architekturstil der Integration, der die Kommunikation über einen gemeinsam genutzten Kommunikationsbus einer Vielzahl von Punkt-Zu-Punkt-Verbindungen zwischen Anbietern und Nutzern von Softwarediensten vorzieht. Softwareprodukte, die das Konzept des ESB implementieren.
Begriff Ein Enterprise Service Bus dient dazu, „Dienste mittels eines Datenbusses in einem Unternehmensnetzwerk zur Verfügung zu stellen“.Hiekel 2007, S. 11 Im deutschen Sprachraum hat sich jedoch keine Übersetzung durchgesetzt. Enterprise Service Bus ist heute als Begriff der deutschen Fachsprache allgemein akzeptiert. Auch wenn der Name anderes suggeriert, ist das Prinzip auch außerhalb der Anwendungslandschaft eines Unternehmens (engl. enterprise) gültig.
Der Begriff Enterprise Service Bus wurde 2002 durch die Firma Gartner geprägt.Schulte2002 Der Analyst Roy W. Schulte führte ihn ein, um eine Kategorie von Softwareprodukten zu beschreiben, die nach seiner Beobachtung ab 2002 auf dem Markt erhältlich waren. Andere Quellen heben hervor, dass der Begriff im Jahr 2002 durch die Firma Sonic für eines ihrer Softwareprodukte geprägt und anschließend durch Analysten übernommen wurde.Microsoft 2005
Durch das Buch von David A. Chappell mit dem gleichnamigen Titel (publiziert 2004) wurde er einem breiteren Fachpublikum bekannt.Chappell 2004
Bedeutungen Der Gartner-Report aus dem Jahr 2002 verwendet den Begriff im Sinn einer Kategorie von Softwareprodukten. Sowohl Produzenten von frei verfügbarer SoftwareApache ServiceMix wie auch kommerzielle AnbieterSun Enterprise Service Bus(ESB) SuiteWebSphere Enterprise Service Bus bezeichnen ihre Produkte als Enterprise Service Bus.
Monographien und Kommentare zum Thema Enterprise Service Bus verwenden den Begriff auch im Sinn eines Architekturkonzepts.Chappell 2004, S. 101 ffChappell 2005: „Myth #4: Pattern or Product: The term ‚Enterprise Service Bus‘ (ESB) is not really a product category; it is simply an abstract concept that can be applied toward a coupling of an existing application server and integration middleware.“Wilkes 2005 Softwarehersteller folgen in einigen Fällen dieser Interpretation, vor allem wenn sie auf die Möglichkeit hinweisen, das Konzept eines Enterprise Service Bus mit einer Palette ihrer Produkte realisieren zu können.
Weitere Quellen verwenden den Begriff im Sinn der konkreten Infrastruktur, die ein Unternehmen für Anwendungsintegration aufbaut.Chappell 2005: „An ESB is an infrastructure for building an enterprise SOA, …“ So verfügte das Finanzinstitut Credit Suisse 2005 über drei Instanzen eines Enterprise Service Bus: den CS Integration Bus für die synchrone Kommunikation, die Event Bus Infrastructure für die asynchrone Kommunikation und die Bulk Integration Infrastructure für die Übermittlung von Massendaten.Krafzig et al. 2005 Auch David A. Chappell weist in seinem Buch darauf hin, dass die konkrete Infrastruktur als Enterprise Service Bus bezeichnet werden kann.Chappell 2004, S. 116: „In some sense, the container is the ESB - more so than the underlying middleware that connects the containers together.“
Aufbau und Konzepte Integration in einer Anwendungslandschaft Die Anwendungslandschaft einer Organisation unterstützt deren Geschäftsprozesse mit Informationstechnik. Ist sie im Stil einer Serviceorientierten Architektur gestaltet, kann sie in so genannte Dienste (engl. services) gegliedert werden. Ein Dienst umfasst eine fachlich und/oder technisch zusammengehörende Teilmenge der Funktionalität, mit der IT die Geschäftsprozesse unterstützt.
Dienstanbieter bieten ihre Funktionalität über Dienstschnittstellen (engl. service interfaces) so an, dass sie von Dienstnutzern in der Anwendungslandschaft angesprochen werden können. Je nach Unternehmen und konkreter Gestaltung einer Anwendungslandschaft kommen als Dienstnutzer neben anderen Diensten auch weitere Arten von Elementen einer Anwendungslandschaft in Frage, zum Beispiel Domänen, Anwendungen oder Komponenten.
Nutzt ein Dienstnutzer den Funktionsumfang eines Dienstanbieters, werden die beiden Elemente voneinander abhängig. Es entsteht eine logische Kopplung, die physisch zu realisieren ist. Die Gesamtheit der physischen KopplungenEngels et al. 2008, S. 202 bildet die IntegrationsarchitekturEngels et al. 2008, S. 207 einer Anwendungslandschaft.
mini|hochkant=2|Schematischer Aufbau eines ESB nach ChappellChappell 2004, S. 105
mini|hochkant=2|Use Case Schaubild eines ESB (Angeli, 2009)
Bus und Endpunkte Mit Bus bezeichnet man in der Daten- und Elektrotechnik ein Untersystem, das Daten oder Energie zwischen Teilen des Systems durch ein standardisiertes Format überträgt. Das Konzept des Enterprise Service Bus überträgt diesen Ansatz auf das Gebiet der unternehmensweiten IT-Architektur. Er ersetzt das komplizierte Netz der direkten physischen Kopplungen in einer Anwendungslandschaft durch eine Kommunikationsinfrastruktur, die gemeinsam durch alle Dienstanbieter und Dienstnutzer verwendet wird.
Ein Enterprise Service Bus besteht im Kern aus einem Kommunikationsbus, über den Nachrichten (engl. messages) ausgetauscht werden können. Dienste verbinden ihre Dienstschnittstellen über Endpunkte (engl. endpoints) mit dem Bus. Dienstnutzer kommunizieren nun mit einem Dienstanbieter, indem sie mit dem Dienstanbieter über den Bus Nachrichten austauschen.
Adapter Die technischen Eigenschaften von Dienstanbietern und Dienstnutzern unterscheiden sich in heterogenen Anwendungslandschaften beträchtlich. Weder die verwendeten Softwareplattformen, noch die unterstützten Kommunikationsprotokolle, Datenformate und Datenstrukturen sind im Allgemeinen unmittelbar kompatibel. Ist die Integrationsarchitektur einer Anwendungslandschaft vor allem durch Punkt-Zu-Punkt-Verbindungen geprägt, werden die entsprechenden Unterschiede jeweils bilateral überbrückt. Es entstehen komplizierte Netze von physischen Kopplungen, weil tendenziell jede logische Kopplung durch eine eigene physische Kopplung unterstützt wird.
Eine Integrationsarchitektur, die eine Integrationsplattform als Middleware nutzt, achtet darauf, dass sowohl Dienstanbieter wie Dienstnutzer mit der Middleware verbunden werden, wenn nötig mit überbrückenden Elementen, die als Adapter bezeichnet werden. Adapter als Teil der physischen Kopplung zwischen Dienstanbietern und Dienstnutzern können dabei für mehrere logische Kopplungen wiederverwendet werden. Es sind weniger auf genau eine logische Kopplung ausgerichtete physische Kopplungen nötig.
Das Konzept des Enterprise Service Bus folgt diesem Ansatz. Es unterscheidet sich in dieser Hinsicht nicht von anderen, zum Teil älteren Konzepten der Anwendungsintegration.
mini|hochkant=2|Integrationsdienste sind in einem Enterprise Service Bus ebenfalls verteilt und mit dem zentralen Message Bus verbunden (angelehnt an ChappellChappell 2004, S. 110)
Integrationsdienste und -fähigkeiten Funktionen, die die Integration von verteilten Diensten unterstützen, sind in einem ESB in so genannten Integrationsdiensten (engl. integration service) gekapselt.Chappell 2004, S. 109 Das Konzept des Enterprise Service Bus geht davon aus, dass Integrationsdienste ähnlich wie Geschäftsdienste in der Anwendungslandschaft verteilt sein können. Es setzt keinen zentralen Knoten voraus, der alle Integrationsdienste anbietet und über den Nachrichten laufen müssen, die diese Dienste nutzen. Dies ist eines der Merkmale, die das Konzept des Enterprise Service Bus von früheren Konzepten der Anwendungsintegration unterscheiden.Chappell 2005: „An ESB provides the same base functionality as an EAI broker - connectivity, application adapters, routing of messages based on rules, and data transformation engine - yet, in an ESB, these capabilities are themselves SOA based in that they are spread out across the bus in a highly distributed fashion and hosted in separately deployable service containers.“
Die beiden wichtigsten Integrationsdienste sind die Transformations- und die Routingdienste: TransformationsdienstePercival 2006 Ein Transformationsdienst transformiert Daten von einem Format und einem Modell in ein anderes Format und ein anderes Modell. Er überbrückt Unterschiede in den Datenformaten und Datenmodellen zwischen Dienstanbietern und Dienstnutzern. Routingdienste Ein Routingdienst nimmt eine Nachricht über den ESB entgegen und leitet sie nach vordefinierten Regeln an die richtigen Empfänger weiter. Routingdienste können unterschiedliche Routingansätze unterstützen. Sie können zum Beispiel Routingentscheidungen basierend auf einer vorgegebenen Sequenz von Empfängern, die eine Nachricht erreichen soll, treffen. Dieses Konzept wird als Routing basierend auf Reisewegen (engl. itinerary-based routing) bezeichnet.Chappell 2004, S. 127 Sie können ferner Routingentscheidungen basierend auf dem Inhalt einer Nachricht treffen. Dieses Konzept wird als inhaltsbasiertes Routing (engl. , CBR) bezeichnet.Chappell 2004, S. 129
Für weitere Integrationsdienste ist umstritten, ob sie ebenfalls zu den Standarddiensten eines ESB gehören: OrchestrierungsdiensteChappell 2004, S. 140 Ein Orchestrierungsdienst kann den Fluss von Nachrichten zwischen Dienstnutzern und Dienstanbietern basierend auf vordefinierten Prozessmodellen steuern.
Protokoll- und API-getriebene ESBs Ein protokollgetriebener ESB (protocol driven ESB) definiert ein Protokoll, das Anbieter und Nutzer zu erfüllen haben, um Services aufrufen zu können. Der ESB stellt hier keine Tools und Bibliotheken zur Verfügung, jedoch erzwingen Protokolländerungen bei jedem Anbieter und Nutzer entsprechende Anpassungen. Web-Services (bzw. SOAP) verwenden diesen Ansatz.
Ein API-getriebener ESB (API driven ESB) stellt Anbietern und Nutzern plattformspezifische Schnittstellen (z. B. Java-Schnittstellen) zur Verfügung, um Services zu implementieren und aufzurufen.Josuttis 2008, S. 71ff
Anwendbarkeit und Nutzen Das Konzept des Enterprise Service Bus ist anwendbar, wenn es gilt, eine genügend große Anzahl von eigenständigen Diensten für einen übergreifenden Zweck zu integrieren. Trotz des Namensbestandteils Enterprise (engl. für Unternehmen) kann das Konzept eines Enterprise Service Bus auch in einem enger gefassten Kontext sinnvoll angewendet werden, zum Beispiel innerhalb einer bestimmten fachlichen Domäne, innerhalb einer Abteilung oder im Kontext eines Projekts, in dem isolierte Dienste integriert werden, um ein bestimmtes Projektziel zu erreichen. Es wird empfohlen, einen Enterprise Service Bus nicht als IT-Infrastruktur zu verstehen, die eine IT-Abteilung in Analogie zur Verkabelung in Bürogebäuden unabhängig von konkreten Geschäftsbedürfnissen bereitstellt. Vielversprechend sei vielmehr, mit Hilfe eines Enterprise Service Bus konkrete, lokale Probleme zu lösen und aufbauend darauf übergreifende Integrationslösungen im Sinne eines Enterprise Service Bus aufzubauen.Chappell 2004, S. 18
Das Konzept des Enterprise Service Bus ist unabhängig von der Branche in allen Organisationen anwendbar, die in hohem Maß durch IT unterstützt werden. Hervorzuheben sind dabei die Finanz- und Versicherungsbranche, die Telekommunikationsbranche, Detailhandel, Industrie und öffentliche Verwaltung.Chappell 2004, S. 19–20