Die neu entfachte Diskussion um Service-orientierte Architekturen (SOA) und durchwachsene Erfahrungen in vielen Integrationsprojekten mit Software für Enterprise Application Integration (EAI) haben eine Reihe von Herstellern bewogen, nach neuen Ansätzen zur Anwendungsintegration zu suchen. Deren Integrations-Tools sollen mit den Limitationen ihrer Vorgänger aufräumen und werden gerade mit den Eigenschaften beworben, an denen es den EAI-Produkten (Integration Broker) oftmals mangelt: So lassen sich die Produkte universell einsetzen, können also prinzipiell jedes System und jede Anwendung integrieren (any-to-any), unabhängig von der Plattform, Sprache, Datenformat, den Programmierschnittstellen und vielen mehr.

Weiter erlauben sie ein inkrementelles Vorgehen bei der Anwendungsintegration, so dass Unternehmen klein anfangen können, aber auch unternehmensweite Projekte oder Projekte mit externen Partnern umsetzen können. Dabei sollen die Produkte der neuen Generation zugleich kostengünstiger sein als traditionelle Integration Broker, deren hohe Lizenzkosten es praktisch nur Großunternehmen erlauben, umfassende Integrationsprojekte zu finanzieren. Noch viel mehr Geld hat aber spezielles Wissen von Consultants über die proprietären EAI-Tools gekostet. Künftig soll Integration nun auch für den Mittelstand bezahlbar sein.

Kein zentraler Broker erforderlich

Weiter verheißen die Tools eine hochgradige Verteilung von Services, so dass diese nicht (nur) auf einem zentralen Broker laufen müssen, sondern sich auch an oder nahe den Endpunkten der zu integrierenden Systeme/Anwendungen befinden können. Letztlich muss das Produkt also den Aufbau eines verteilten Servicenetzes unterstützen. Dabei soll die Verwaltungsinstanz für die Services leicht- gewichtig sein und für diese Aufgaben keine Installation umfassender und schwergewichtiger Applikations-Server oder Integration Broker an den Endpunkten erfordern.

Den Analysten von Gartner ist dieser Trend nicht entgangen. So beschrieben sie bereits im Dezember 2002 in der Research Note "Predicts 2003: Enterprise Service Buses Emerge" ESBs als Kategorie von Produkten, die solch eine grundlegende Integrationsinfrastruktur stellen können. Neben der grundsätzlichen Forderung, so weit wie möglich Standards zu nutzen, müssen entsprechende Produkte laut Gartner zumindest eine Kommunikation über den Java Messaging Service (JMS) oder an- dere Messaging-Middleware (MOM) bereitstellen. Unbedingt nötig sind ferner eine Konnektivität mit Hilfe von Web-Services, JMS oder anderer MOM sowie Funktionen für die Mediation zwischen den Diensten (Transformation von XML- und Soap-Nachrichten, Routing). Diese Eigenschaften befähigen solche Produkte zum Aufbau einer Service-oriented Architecture.

Service Bus sorgt für lose Systemkopplung

Näher betrachtet geht es bei der Basiseigenschaft "Kommunikation" des ESB darum, dass ein entsprechendes Produkt Systeme in die Lage versetzen soll, miteinander in einer lose gekoppelten Weise durch Austausch von Nachrichten über ein Netzwerk zu interagieren. Dazu ist eine MOM nötig, die asynchrones Messaging, Publish/Subscribe und besonders auch Store-and-Forward für die zuverlässige Zustellung von Nachrichten unterstützt. Da der Einsatz von Standards wünschenswert ist, sind JMS-basierend oder Systeme, die "Web Services Reliable Messaging" verwenden, gegenüber bisherigen MOMs wie "IBM MQ Series" oder "Tibco Rendezvous" vorzuziehen.

Die Verwendung einer MOM garantiert auch, dass der Nachrichtenaustausch über Standardprotokolle (TCP/IP, HTTP) gegeben ist. Mit dem Begriff "Bus" im ESB ist eben diese MOM gemeint, und nicht wie oft missverständlich zu lesen eine verteilte Architektur. Die meisten MOMs sind heute noch Hub-and-Spoke-Lösungen, bei denen ein zentraler Message Broker (Hub) für die Zustellung von Nachrichten an die Systeme/Anwendungen (Spokes) zuständig ist. Nachrichten fließen also in der Regel nicht direkt von System zu System, sondern nehmen den Weg über einen Message Broker.

In der zweiten von Gartner genannten Eigenschaft, Konnektivität, muss ein ESB Web-Services unterstützen. Zu integrierende Systeme interagieren dann miteinander per Web-Services oder JMS (oder einer anderen MOM). Web-Services sollen demnach das "S" in Service-oriented Architecture verwirklichen. Ihr großer Vorteil besteht bekanntermaßen darin, dass die Schnittstellen unabhängig von Betriebssystem und Programmiersprache sind und selbst in einem speziellen XML-"Dialekt" (WSDL) spezifiziert werden.

Transformation und Routing an den Endpunkten

Was schließlich das dritte Gartner-Kriterium der Mediation betrifft, so sind Transformation und Routing zu verstehen. Allerdings genügt es nach Ansicht der Analysten schon, wenn XML-Nachrichten per XSLT transformiert werden können und dass Web-Services-Aktivierungen per Soap auch ihr Ziel finden. Die Transformation und das Routing müssen aber an den Endpunkten (dezentral) erfolgen, also bevor Nachrichten zum endgültigen Transport an den Message Bus übergeben werden.

Die genannten Basiseigenschaften mögen für eine Integration mit Web-Services ausreichen. Um in den gewachsenen IT-Landschaften von heute erfolgreich zu sein, braucht es aber schon etwas mehr. In seinem White Paper "Best-of-Breed ESBs" führt Steve Craggs, Vice Chairman des Integration Consortium, weitere unverzichtbare Eigenschaften auf. Erster Knackpunkt ist die Konnektivität zwischen den Diensten. Nicht nur weil Web-Services noch relativ neu sind, besitzt nicht jedes heute betriebene und potentiell zu integrierende System eine Web-Services-Schnittstelle. Manches System wird eine solche Schnittstelle auch in Zukunft nicht erhalten, weil es nur schwer möglich ist oder weil es keine wirklich überzeugenden Gründe gibt, die den Aufwand rechtfertigen.

JCA-Adapter überwinden Integrationshürden

Für diese Systeme werden künftig Adapter benötigt, wie sie der Java-Standard J2EE Connector Architecture (JCA) mittlerweile spezifiziert. Es ist sehr wichtig, dass sich künftig mit ESBs auf JCA basierende Adapter ohne die Hilfe durch externe Software sofort einsetzen lassen. Ein kleiner Nachteil von JCA besteht allerdings darin, dass es sich um einen Java-Standard handelt. Ein sprachneutraler Standard für Adapter existiert jedoch bisher nicht.

Geografisch verteilte Systeme anbinden

Auch muss ein ESB Systeme und Anwendungen integrieren können, die an geografisch verteilten Orten laufen. Es ist daher notwendig, dass Ausführungsumgebungen für Services (der Anbieter Sonic Software spricht hier von "Service-Containern", Fiorano von "Peer-Servern") als verteilte Deployments an oder in der Nähe von Endpunkten installiert werden. Das sowie Aufgaben wie asynchrones Messaging machen die Verwaltung eines ESB komplex.

Leistungsfähige Tools sind daher ein absolutes Muss, um Aufgaben zu bewältigen wie das Deployment und Update von Prozessen und Services, die Überwachung aller Aktivitäten, das Erkennen von Engpässen, Start und Stop von Servern, Prozessen, Services, das Aufzeichnen von Vorgängen zur Nachverfolgung sowie das Ändern und Umlenken von Nachrichten. Es ist von großem Vorteil, wenn sich ein auf einem ESB basierendes System zentral verwalten lässt. Ein solcher "Single Point of Control" sollte beliebig wählbar sein und dennoch auch entfernte Systemteile über das Netzwerk erreichen können. Protokolle wie SNMP, aber auch neue Spezifikationen wie JMX sind dabei einzusetzen.

Produkte bieten oft mehr als nur Basisfunktion

Wenn eine Middleware die genannten Eigenschaften im Wesentlichen erfüllt, so kann diese Infrastruktur als ESB bezeichnet werden. Heutige Angebote sind meist Komplettprodukte eines Herstellers, die sich künftig auch vermehrt als Teil einer umfassenderen Integrationsplattform wieder finden werden. Eine bestimmte ESB-Architektur ist nicht vorgeschrieben. Da aber hochgradig verteilte Deployments unterstützt werden müssen, kann sich eine rein zentralistisch ausgelegte Middleware kaum als ESB qualifizieren. Auch bieten moderne ESBs heute schon mehr als die genannten Basiseigenschaften. Fortgeschrittene Fähigkeiten betreffen:

- Sicherheit (Verschlüsselung, Authentifizierung etc.),

- Robustheit (Verfügbarkeit, Fehlertoleranz etc.),

- Skalierbarkeit (Parallelität, Lastverteilung etc.),

- Konnektivität: mehr Adapter, Daten-Bridges zu MOMs, die nicht auf XML basieren oder nativ sind (Multiprotokoll-ESB),

- Transaktionen (kompensierend, XA, WS-Transaction),

- inhaltsbasierendes Routing (Xpath, Xquery), Business Rules,

- Entwicklungs-Tools (Data Mapper, Service Development Kit),

- Workflow (Human Intervention) und

- Business-Process-Management, zum Beispiel die Orchestrierung von Diensten mit Hilfe der Business Process Execution Language (BPEL).

Obschon ESBs weitestgehend auf Standards setzen, sind die ESB-Service-APIs heute noch proprietär und können nur notdürftig per "Messaging Bridges" oder Web-Services zusammenarbeiten. Ein Service, der auf der Basis eines ESB entwickelt wurde, läuft ohne eine Änderung nicht auf einem anderen Produkt. Hier setzt innerhalb des Java-Lagers die Initiative "Java Business Integration" (JBI) an. Sie beschreibt, wie Integrationskomponenten als Services auf herstellerneutrale und protokollunabhängige Art und Weise interagieren können. Ziel ist, die architektonischen Elemente eines ESB für die Java-Plattform als JBI-Container zu standardisieren. Was JCA heute für Konnektoren ist, könnte JBI morgen für Integrations-Services sein.

Einige kleine ESB-Hersteller haben bereits viele der genannten Features implementiert und bauen ihr Angebot kontinuierlich aus. Umgekehrt haben manche EAI-Anbieter klassischer Integration Broker wie Webmethods und Seebeyond kostengünstigere Einstiegsprodukte auf den Markt gebracht. Es wird bald schwierig werden, Highend-ESBs von Einsteigerversionen ihrer EAI-Plattformen zu unterscheiden. Diese Kategorien von Middleware konvergieren. Zudem wollen Hersteller wie IBM, Oracle, Microsoft und SAP Applikations-Server (J2EE, .NET, Corba) um Integrations-Features erweitern. Dieser zentralistische und schwer skalierbare Ansatz ist problematisch, da es unökonomisch ist, einen kompletten Applikations-Server zu installieren, nur um einen einzigen Integrationsservice darin laufen zu lassen. Letzterer kommt mit einer weit schlankeren (und kostengünstigeren) Ausführungsumgebung aus. Kritisch ist auch, dass beim Ansatz via Appserver die entsprechende Logik entwickelt, kompiliert und später aufwändig gepflegt werden muss. Die ESB-Hersteller versuchen dagegen, ihre Produkte möglichst unabhängig von Programmcode zu halten. Prozessänderungen erfolgen weitgehend per Rekonfiguration (anstatt Rekompilierung).

ESB können den Weg zur SOA verkürzen

Führt nun der Weg zur SOA ausschließlich über einen ESB? Nein, Anwender könnten beispielsweise allein mit Web-Services im Eigenbau Dienste kombinieren. Aber die meisten ESBs enthalten in einem Produkt bereits viele der benötigten Funktionen und verheißen so einen schnellen und kostengünstigen Weg zu SOA. Man könnte sagen, SOA ist ein Auto und ein ESB ist eine Straße, auf der das Auto fährt. (as)