Enterprise Service Bus

aus Wikipedia, der freien Enzyklopädie

Wechseln zu: Navigation, Suche

Mit Enterprise Service Bus (ESB) bezeichnet man in der Informationstechnik(IT) eine Kategorie von Softwareprodukten, die die Integration verteilter Dienste (engl. service) in der Anwendungslandschaft eines Unternehmens (engl. enterprise) auf unten noch näher zu definierende Weise unterstützen.

Teilweise bezeichnet man mit Enterprise Service Bus auch

  • die konkrete Infrastruktur, die ein bestimmtes Unternehmen für die Integration der Dienste in seiner Anwendungslandschaft aufbaut
  • einen bestimmten 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

Wörtlich übersetzt dient ein Enterprise Service Bus also dazu, „mittels eines Datenbusses Dienste für ein Unternehmen zur Verfügung zu stellen“ [1]. Im deutschen Sprachraum hat sich jedoch keine Übersetzung durchgesetzt. Enterprise Service Bus ist heute als Begriff der deutschen Fachsprache allgemein akzeptiert.


Inhaltsverzeichnis

[Bearbeiten] Begriff

Der Begriff Enterprise Service Bus wurde 2002 durch die Firma Gartner geprägt[2]. 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 [3].

Durch das Buch von David A. Chappel mit dem gleichnamigen Titel (publiziert 2004) wurde er einem breiteren Fachpublikum bekannt[4].

Eine Sammlung von weiteren Begriffsdefinitionen findet man in Hiekel2007 und Microsoft2005.

[Bearbeiten] Bedeutungen

Der Gartner-Report aus dem Jahr 2002 [2] führte den Begriff im Sinn einer Kategorie von Softwareprodukten ein. Hersteller von Softwareprodukten verwenden ihn auch heute mehrheitlich so. Sowohl Produzenten von frei verfügbarer Software[5][6] wie auch kommerzielle Anbieter [7][8] bezeichnen ihre Produkte als Enterprise Service Bus.

Monographien und Kommentare zum Thema Enterprise Service Bus verwenden den Begriff auch im Sinn eines Architekturkonzepts[9][10][11]. Softwarehersteller folgen in einigen Fällen dieser Interpretation [3], 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[12]. 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 [13]. Auch David A. Chappell weist in seinem Buch darauf hin, dass die konkrete Infrastruktur als Enterprise Service Bus bezeichnet werden kann [14].

[Bearbeiten] Aufbau und Konzepte

[Bearbeiten] 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.

Als Dienstanbieter bieten sie ihre Funktionalität über Dienstschnittstellen (engl. service interfaces) so an, dass sie von Elementen der Anwendungslandschaft in ihrer Rolle als Dienstnutzer 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 Kopplungen [15] bildet die Integrationsarchitektur [16] einer Anwendungslandschaft.

Schematischer Aufbau eines ESB nach [17]

[Bearbeiten] Bus und Endpunkte

Mit Bus bezeichnet man in der Daten- und Elektrotechnik ein Untersystem, das Daten oder Energie zwischen Teilen des Systems ü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.

[Bearbeiten] 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.

Integrationsdienste sind in einem Enterprise Service Bus ebenfalls verteilt und mit dem zentralen Message Bus verbunden (angelehnt an [18])

[Bearbeiten] Integrationsdienste und -fähigkeiten

Funktionen, die die Integration von verteilten Diensten unterstützten, sind in einem ESB in so genannten Integrationsdiensten (engl. integration service) gekapselt[19]. 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[20].

Die beiden wichtigsten Integrationsdienste sind die Transformations- und die Routingdienste:

  • Transformationsdienste[21][22]. 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[23][22]. 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 Routingentscheide 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[24]. Sie können ferner Routingentscheide basierend auf dem Inhalt einer Nachricht treffen. Dieses Konzept wird als inhaltsbasiertes Routing (engl. Content-Based Routing, CBR) bezeichnet [25].

Für weitere Integrationsdienste ist umstritten, ob sie ebenfalls zu den Standarddiensten eines ESB gehören:

  • Orchestrierungsdienste[26][22]. Ein Orchestrierungsdienst kann den Fluss von Nachrichten zwischen Dienstnutzern und Dienstanbietern basierend auf vordefinierten Prozessmodellen steuern.

[Bearbeiten] 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 bereit stellt[27]. 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[28].

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[29].

Ein Enterprise Service Bus allein generiert insofern keinen Geschäftsnutzen[30] als er in fachlich motivierten IT-Lösungen immer nur Mittel und nicht Zweck ist. Indirekt kann der Einsatz eines Enterprise Service Bus Geschäftsnutzen erzeugen, weil er dazu beitragen kann, die Anwendungslandschaft eines Unternehmens kosteneffizienter und agiler zu gestalten:

  • Ein ESB kann ermöglichen, dass isolierte Dienste schneller und kosteneffizienter integriert werden können.
  • Integrationslösungen, die auf einem ESB basieren, können normalerweise schneller und kosteneffizienter an veränderte Anforderungen angepasst werden.

Dem IT-Architekten bietet das Konzept eines Enterprise Service Bus zusätzlich folgende Vorteile:

  • Integrationsaufgaben lassen sich außerhalb der zu integrierenden Dienste implementieren. Diese Trennung der Geschäftslogik von der Integrationslogik trägt zur Reduktion der Komplexität und damit zu deren Beherrschung bei.
  • Das Konzept geht von einem modularen, verteilten Aufbau des ESB aus und kann deshalb in unterschiedlichen Konfigurationen in einer breiten Palette von Lösungen sinnvoll eingesetzt werden.
  • Auf dem Markt verfügbare ESB-Produkte bringen vorgefertigte Bausteine (Routingdienste, Transformationsdienste, etc.) mit, die in einer Lösung mit geringem Zusatzaufwand wiederverwendet werden können.

[Bearbeiten] Abgrenzung und Einordnung

Enterprise Application Integration (EAI) ist eine Disziplin der Informationstechnik, die sich mit der Gestaltung von physischen Kopplungen zwischen Elementen einer Anwendungslandschaft beschäftigt. Das Konzept des Enterprise Service Bus ist kein Ersatz für EAI, sondern einerseits ein möglicher Architekturstil für die Gestaltung von Integrationsarchitektur und andererseits ein mögliches Mittel, um physische Kopplungen im Rahmen von EAI konkret zu realisieren[31].

Service-orientierte Architektur (SOA) ist ein Architekturstil für die Gestaltung von Anwendungslandschaften. Der Integration von verteilten Diensten kommt dabei besondere Bedeutung zu und die Integrationsarchitektur dieser Anwendungslandschaften profitiert vom Einsatz von Integrations-Middleware. Integrationsaufgaben in einer nach SOA-Prinzipien gestalteten Anwendungslandschaft können grundsätzlich aber auch ohne Integrations-Middleware bzw. seit den 90er Jahren des 20sten Jahrhunderts bekannten Werkzeugen der Anwendungsintegration gelöst werden. ESB ist in diesem Sinn keine Voraussetzung für SOA, sondern allenfalls zeitgemäße Unterstützung. Es gibt namentlich keinen zwingenden Grund, Integrationsaufgaben in einer SOA mit einem Werkzeug zu unterstützen, das auf dem Markt als ESB angeboten wird.

Message Oriented Middleware (MOM) bezeichnet eine Klasse von Softwareprodukten, die als Kommunikationsinfrastruktur in Anwendungslandschaften eingesetzt wird. MOM-Produkte dienen der sicheren, robusten und skalierbaren Übertragung von Nachrichten zwischen verteilten Diensten. Mehrere Autoren weisen darauf hin, dass eine Instanz eines MOM das Fundament eines Enterprise Service Bus bildet.

[Bearbeiten] Standards und Technologien

[Bearbeiten] XML

Die Auszeichnungssprache XML ist heute in der Informationstechnik weit verbreitet und wird in zahlreichen Anwendungsgebieten eingesetzt. Sie ist keine konzeptionelle Voraussetzung für einen Enterprise Service Bus, wird aber in der Mehrheit der ESB-Produkte und der realisierten ESBs in Anwendungslandschaften vielfältig eingesetzt. Sie dient häufig als vereinheitlichtes Datenformat, in dem Nachrichten über den Message Bus im Kern eines ESB übermittelt werden, aber auch als Format für den Austausch von Nachrichten zwischen Diensten und dem Message Bus über die entsprechenden Endpunkte und Adapter. Weiter findet sie Verwendung in der Beschreibung von Schnittstellen, zum Beispiel mit der Schnittstellenspezifikationssprache WSDL.

[Bearbeiten] XPath und XQuery

XPath und XQuery sind Abfragesprachen, mit denen Teile von XML-Dokumente abgefragt und extrahiert werden können. Sie sind keine Voraussetzung für einen ESB, werden aber in ESBs häufig im Kontext der Routingdienste eingesetzt. Routingregeln, die auf Steuerdaten oder Inhalten von Nachrichten beruhen, sind oft als XPath- bzw. XQuery-Ausdrücke über diese Nachrichten formuliert.

[Bearbeiten] XSLT

XSLT ist eine Programmiersprache zur Transformation von XML-Dokumenten. XSLT ist keine technologische Voraussetzung für einen ESB. Die Sprache wird aber häufig in Transformationsdiensten verwendet, namentlich wenn ein ESB XML als vereinheitlichtes Datenformat nutzt.

[Bearbeiten] JMS

JMS ist eine standardisierte Programmierschnittstelle, um aus Java-basierten Anwendungen Nachrichten über einen Message Bus versenden und empfangen zu können. Sie ist keine Voraussetzung für einen ESB. ESBs, die stark in der Java-Welt verankert sind, zum Beispiel, weil sie selbst in Java implementiert sind, bieten oft Standard-Adapter und Standard-Endpunkte an, damit Dienste den ESB über JMS nutzen können.

[Bearbeiten] SOAP

SOAP ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Dienstschnittstellen von entfernten Diensten genutzt werden können. SOAP basiert auf weiteren weit verbreiteten Technologien, zum Beispiel HTTP und SMTP als Protokolle, XML als Datenformat oder WSDL als Sprache für die Schnittstellenspezifikation. Dienste, die ihre Schnittstellen mit Hilfe dieser Technologien zugänglich machen, nennt man Webdienste oder Webservices. Das Konzept des Enterprise Service Bus ist nicht auf Webdienste oder die Technologie SOAP beschränkt. In der Praxis integriert ein ESB aber oft verteilte Webdienste, indem es sie mit SOAP-Adaptern an den zentralen Message Bus anbindet.

[Bearbeiten] JBI

Mit Java Business Integration (JBI) bezeichnet man einen Standard, der im Rahmen des Java Community Process (JCP) unter der Nummer JSR 208 veröffentlicht wurde[32]. Das Dokument standardisiert einen Teil der Architektur eines Enterprise Service Bus für ein bestimmtes technisches Umfeld, nämlich Softwareentwicklung und IT-Architektur basierend auf der Java Platform, Enterprise Edition (JEE). Es detailliert namentlich die Architektur des Subsystems eines ESB, das Chappell[33] als service container bezeichnet hat[34].

[Bearbeiten] Kritik

Bereits Schulte wies darauf hin, dass Enterprise Service Bus kein neues Konzept darstelle. Der Zweck eines Enterprise Service Bus sei dem Zweck der seit den 90er Jahren des 20. Jahrhunderts verbreiteten Integration Brokern sehr ähnlich [35]. Im gleichen Zusammenhang wird kritisiert, dass es sich beim Begriff Enterprise Service Bus um einen leicht einprägsamen und durch Modeströmungen in der Informationstechnologie beeinflussten Marketingbegriff handle, der zu unscharf geblieben sei, um ihn in der Lösungsbeschreibung für konkrete Probleme der IT-Architektur verwenden zu können [3][36].

Das Konzept des Enterprise Service Bus sei ferner ungeeignet als Produktkategorie in der Softwareindustrie. Er sei zu wenig scharf umrissen, um eine homogene Gruppe von Softwareprodukten zu beschreiben.

Die Art und Weise, wie Unternehmen ESBs in ihre Anwendungslandschaften einführen, stößt ebenfalls auf Kritik[27]. Die Namenskomponente Enterprise und Service würden wörtlich genommen, so dass Unternehmen Gefahr liefen, überdimensionierte und zu generische Infrastruktur einzuführen, für die es zum Zeitpunkt der Realisierung keine ausreichende Geschäftsbedürfnisse gebe.

IT-Abteilungen gehen teilweise davon aus, dass die Beschaffung und Installation eines Enterprise Service Bus (im Sinne eines Softwareprodukts) eine wesentliche Voraussetzung und der kritische Erfolgsfaktor für die Lösung ihrer Integrationsprobleme sei. Kritische Stimmen merken an, dass die Gestaltung und der Betrieb einer kosteneffizienten, korrekten und flexiblen Integrationsarchitektur in erster Linie eine konzeptionelle und steuernde Aufgabe sei. Die Auswahl und der Einsatz eines bestimmten Werkzeugs sei im Vergleich dazu eher nebensächlich.

Physische Kopplungen zwischen Diensten oder Anwendungen können in drei Gruppen eingeteilt werden: physischen Kopplungen der Präsentationsintegration auf der Ebene von Benutzerschnittstellen, physische Kopplungen der Logikintegration auf der Ebene der Geschäftsfunktionen einer Anwendung und physische Kopplungen der Datenintegration auf der Ebene des direkten Zugriffs auf persistente Daten[37]. In hinreichend komplexen Anwendungslandschaften gibt es physische Kopplungen auf allen drei Ebenen, während das Konzept des Enterprise Service Bus hauptsächlich auf die Ebene der Logikintegration ausgerichtet ist. Weder das Konzept noch darauf aufbauende Softwareprodukte unterstützen Präsentationsintegration wie sie zum Beispiel in Portalen und in Rich Clients vorkommt. ESBs stellen zudem ein Lösungsmuster dar, um direkte physische Kopplungen auf der Datenebene zu verhindern, nicht zu ermöglichen. Für im Einzelfall gerechtfertigte physische Kopplungen auf der Ebene Datenintegration bietet ein ESB deshalb keine Unterstützung. Zusammenfassend kann man festhalten, dass das Konzept des Enterprise Service Bus und der darauf aufbauenden Produkte nur auf eine Teilmenge der Integrationsaufgaben in hinreichend komplexen Anwendungslandschaften ausgerichtet sind.

[Bearbeiten] Implementierungen

Die folgende Tabelle listet Software-Produkte auf, die auf dem Markt als Enterprise Service Bus angeboten werden. Quellen sind Webpräsenzen der entsprechenden Hersteller beziehungsweise eine Zusammenstellung von Open Source ESBs in Rademakers2008[38].

Anbieter Name Art
Sun Microsystems Sun Java Composite Application Platform Suite (Java CAPS) kommerziell
Sun Microsystems Open ESB frei
IBM WebSphere Enterprise Service Bus kommerziell
Progress Software Progress Sonic ESB kommerziell
Microsoft Biztalk Server kommerziell
Oracle Oracle ESB kommerziell
Apache Software Foundation Apache Service Mix frei
MuleSource Mule frei
SAP Process Integration kommerziell
JBoss JBoss ESB frei
Software AG webMethods ESB-Plattform kommerziell
Apache Software Foundation Apache Synapse frei
Apache Software Foundation Apache Tuscany frei
Chain Builder ESB Integration Community ChainBuilder ESB frei
FUSE Open Source Community FUSE ESB frei
OpenAdapter OpenAdapter frei
OW2 Consortium PEtALS frei
Spring Source Spring Integration frei
WS02 WS02 ESB frei

[Bearbeiten] Literatur

  • [Chappell2004]:Dave Chappell: Enterprise Service Bus. O’Reilly. Juni 2004, ISBN 0-596-00675-6
  • [Engels2008]: Gregor Engels, Andreas Hess, Bernhard Humm, Oliver Juwig, Marc Lohman, Jan-Peter Richter, Markus Voß, Johannes Willkomm. Quasar Enterprise - Anwendungslandschaften serviceorientiert gestalten. dpunkt.verlag. 2008. ISBN 978-3-89864-506-5
  • [Krafzig2005]:Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA. Pearson Education, Inc. 2005. ISBN 0-13-146575-9
  • [Lohr2008]Stefan Lohr: Apache ServiceMix: Ein Enterprise Service Bus in derPraxis. VDM Verlag. Oktober 2008. ISBN 3-639-08536-1
  • [Pehnke2008]:Oliver Pehnke: Evaluierung: Enterprise Service Bus. VDM Verlag. September 2008. ISBN 3-639-05327-3
  • [Schulte2003]:Roy W. Schulte: Predicts 2003: Enterprise Service Buses Emerge. Gartner, 9. Dezember 2002. PDF, 52kB

[Bearbeiten] Einzelnachweise

  1. ↑ Hiekel2007. S. 11
  2. ↑ a b Schulte2002
  3. ↑ a b c Microsoft2005
  4. ↑ Chappell2004
  5. ↑ Apache ServiceMix
  6. ↑ Mule
  7. ↑ Sun Enterprise Service Bus(ESB) Suite
  8. ↑ WebSphere Enterprise Service Bus
  9. ↑ Chappell2004 S.101 ff
  10. ↑ Chappell2005 „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.“
  11. ↑ Wilkes2005
  12. ↑ Chappell2005 „An ESB is an infrastructure for building an enterprise SOA, …“
  13. ↑ Krafzig2005
  14. ↑ Chappell2004 S. 116: „In some sense, the container is the ESB - more so than the underlying middleware that connects the containers together.“
  15. ↑ Engels2008: S. 202
  16. ↑ Engels2008: S. 207
  17. ↑ Chappell2004. S. 105
  18. ↑ Chappell2004. S. 110
  19. ↑ Chappell2004: S. 109
  20. ↑ Chappell2005. „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.“
  21. ↑ Chappell2004: S. 109
  22. ↑ a b c Percival2006
  23. ↑ Chappell2004: S. 109
  24. ↑ Chappell2004: S. 127
  25. ↑ Chappell2004: S. 129
  26. ↑ Chappell2004: S. 140
  27. ↑ a b Woolf2007
  28. ↑ Chappell2004, S. 18
  29. ↑ Chappell2004, S. 19-20
  30. ↑ Woolf2007. „An ESB by itself produces no business value.“
  31. ↑ Linthicum2005. „…I defined the concept of ESBs in the EAI book, as what it is, an enabling technology for EAI.“
  32. ↑ #Ten-Hove2005
  33. ↑ Chappell2004
  34. ↑ Ten-Hove2005, S. 8. "JBI defines what is sometimes termed a “service container” in Enterprise Service Bus (ESB) systems."
  35. ↑ Schulte2002 S. 4. „Some [vendors] even deny that the ESBs are anything new, since the purpose of an ESB is so similar to that of a traditional integration broker suite.“
  36. ↑ Linthicum2006
  37. ↑ Engels2008. S. 201
  38. ↑ Rademakers2008, S. 29-30
Von „http://de.wikipedia.org/wiki/Enterprise_Service_Bus“
Persönliche Werkzeuge
Buch erstellen