Die Konzepte

Enterprise Service Bus

Markus Demolsky

Heutige Softwaresysteme sind mit einer derartigen Komplexität behaftet, dass Themen wie Architektur, Wartung und Flexibilität eine beachtliche Rolle spielen. Die Nutzung von Softwarelösungen über Firmengrenzen hinweg wird durch den BPM-Gedanken immer wichtiger. Dabei nimmt die Integration eine fundamentale Rolle ein. Gerade in diesem Bereich wird heute noch sehr viel Aufwand in die Implementierung investiert. Warum soll man sich nicht einer Integrationsplattform bedienen, um den Implementierungsaufwand zu reduzieren?

Nachdem der Hype rund um SOA etwas nachgelassen hat, beginnt bereits der nächste. Die Rede ist vom Enterprise Service Bus (ESB). In diesem Artikel werden die Grundlagen eines ESB beschrieben und die wesentlichen Konzepte erläutert.

Integrationen von unterschiedlichen Softwaresystemen waren bereits in den 90er Jahren ein heiß diskutiertes Thema. Dabei haben sich in den letzten Jahren folgende Stile zur Integration durchgesetzt:

  • Integration über gemeinsame Dateien, d.h. eine Anwendung schreibt etwas in eine Datei, welche von einer anderen gelesen wird
  • Verwendung einer gemeinsamen Datenbank
  • Funktions- und Methodenaufrufe über Remote Procedure Call (RPC)
  • Integration über eine Message Oriented Middleware (MOM)

Die Idee hinter all diesen Konzepten ist immer gleich: Eine lose Koppelung von den zu integrierenden Systemen. Das Streben nach einer geeigneten Integrationsplattform war in den letzten Jahren sehr hoch und viele Faktoren, sowohl betriebswirtschaftlicher als auch technischer Natur hatten Einfluss auf die Architektur des ESB. Das Management möchte eine klare Abbildung des Geschäftsprozesses in der IT-Landschaft und dabei eine maximale Optimierung bei der Durchführung (man spricht dabei auch von „Straight Through Processing“). Betrachten wir einen Geschäftsprozess, so werden wir feststellen, dass ein solcher Prozess durch die gesamte IT-Landschaft laufen kann, d.h. dem Prozess ist es egal, woher die Informationen gelesen bzw. geschrieben werden. Dabei werden oft unterschiedlichste Systeme (Lager, Buchhaltung, Partnersysteme etc.) in Anspruch genommen. Auch die immer mehr genutzte Radio Frequency Identification (RFID) stellt neue Wege für die Gewinnung von Daten dar. Große Datenmengen müssen verarbeitet, transformiert und an viele unterschiedliche Konsumenten weitergeleitet werden. Diese Beispiele verdeutlichen, welche Komplexität Integrationen annehmen können.

Mit Hub and Spoke EAI Brokers hat man geglaubt, die Lösung gefunden zu haben, doch eine Studie der Forrester-Research-Gruppe hat gezeigt, dass EAI-Projekte nur maßgeblich Erfolg hatten. Vor allem die immensen Investionen und Durchlaufzeiten der Projekte trugen zu deren Misserfolg bei (es gibt aber durchaus auch gelungene Projekte).

Die Wissenschaft hat begonnen, nach einer vernünftigeren Lösung der Integration zu forschen und somit wurden die ersten Meilensteine des ESB gelegt. Zum Zeitpunkt der Entstehung des ESB haben sich bereits etablierte Standards und Technologien (JMS, XML, Web Service etc.), die neue Wege der Integration darstellen, am Markt durchgesetzt. Auf die bereits gesammelten Erfahrungen und vorhandenen Technologien baut der ESB auf. Mit dem ESB sollen etwa unternehmensweite, geografisch verteilte Anwendungen auf standardisiertem Weg integrierbar sein.

Der Enterprise Service Bus wurde zum ersten Mal im Jahr 2002 von namhaften Herstellern für ihre Middleware eingesetzt. Anerkannte Analystenfirmen wie etwa Gartner haben diese Wandlung der Integration verfolgt und eine erste Definition des ESB auf den Markt gebracht: „A new form of Enterprise Serivce Bus – combinbing message-oriented middleware, web services, transformation and routing intelligence […]“. Aus dieser Definition lassen sich auch schon Kernkomponenten eines ESB herauskristallisieren: MOM, Binding Komponenten (Web Service), Transformatoren und intelligentes Routing.

ESB-Kernaufgaben/-merkmale
  • Routing, Transformierung von Nachrichten
  • Protokolltransformierung
  • Integration mithilfe von Standards
  • Hochskalierbare und verteilte Integrationsplattform
  • Unabhängiges/verteiltes Deployment von Servicekomponenten
  • Unterstützung von Enterprise Integration Patterns
  • Quality of Service

Bei einem ESB handelt es sich nicht um eine Technologie, sondern um eine Integrationsinfrastruktur. Der ESB kann auch als Architekturparadigma gesehen werden. David A. Chappell definiert einen ESB wie folgt: „An Enterprise Service Bus is a standard-based integration platform that combines messaging, web services, data transformation and intelligent routing in a highly distributed, event-driven Service Oriented Architecture” [David E. Chappell: Enterprise Service Bus – Theory in Practic. O´Reilly, 2004]. In seiner Definition wird jene von Gartner noch um die Verbindung zwischen SOA und ESB erweitert. Abbildung 1 zeigt, dass der ESB als zentrale Kommunikationsplattform zwischen den Anwendungen eingesetzt wird, und dabei auch eine Menge an Protokollen unterstützt.

Abb. 1: Enterprise Service Bus als zentrale Kommunikationsplattform
Geschrieben von
Markus Demolsky
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.