Open-Source Enterprise Service Bus Lösungen im Vergleich

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einführung

2 Der Enterprise Service Bus
2.1 Definition
2.2 Anforderungen an einen Enterprise Service Bus
2.3 Java Business Integration

3 Rahmen der Untersuchung
3.1 Ziel der Untersuchung
3.2 Formulieren eines Beispielprozesses
3.2.1 Überblick über das Beispielszenario
3.2.2 Technische Realisierung
3.3 Bewertungskatalog

4 Untersuchung der Produkte
4.1 Die Open-Source-Lösung Mule
4.1.1 Architektur
4.1.2 Das Beispielszenario: Umsetzung und Erfahrungen
4.1.3 Bewertung der Kriterien
4.1.4 Fazit
4.2 Die Open-Source-Lösung ServiceMix
4.2.1 Architektur
4.2.2 Das Beispielszenario: Umsetzung und Erfahrungen
4.2.3 Bewertung der Kriterien
4.2.4 Fazit
4.3 Die Open-Source-Lösung Glassfish ESB
4.3.1 Architektur
4.3.2 Das Beispielszenario: Umsetzung und Erfahrungen
4.3.3 Bewertung der Kriterien
4.3.4 Fazit

5 Vergleich und Fazit

Glossar

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Zusammenspiel der Elemente der JBI-Spezifikation

Abbildung 2: Fachliche Sicht auf das Beispielszenario

Abbildung 3: Transportprotokolle im Beispielszenario

Abbildung 4: Beispiel für die Berechnung einer Bewertungskennzahl

Abbildung 5: Aufbau eines Mule-Service

Abbildung 6: Nachrichtenempfang in einem Mule Service

Abbildung 7: Servicekomponente mit Proxy Funktionalität

Abbildung 8: Ergebnisweiterleitung in einem Mule Service

Abbildung 9: Architekturübersicht Apache ServiceMix 3.3

Abbildung 10: Installation von Service Units auf Komponenten

Abbildung 11: Architekturübersicht Glassfish ESB

Abbildung 12: Erzeugen einer WSDL für eine Binding-Komponente

Abbildung 13: Die Bereiche des Netbeans CASA Editor

Abbildung 14: Mit Drag-and-Drop Routen definieren

Abbildung 15: Erstellen einer schreibenden Binding-Component

Abbildung 16: In Netbeans integrierte Glassfish-Administration

Tabellenverzeichnis

Tabelle 1: Bewertungskatalog

Tabelle 2: Ergebnis der Evaluierung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einführung

Applikationen miteinander zu verbinden ist eine der größten Herausforderungen heutiger Enterprise Netzwerke. Seit Jahren ausgereifte und stabile Systeme sollen und können nicht einfach durch moderne Varianten ersetzt werden - nicht zuletzt wären die Kosten hierfür einfach zu groß. Stattdessen müssen sie auf geeignete Art und Weise in das Unternehmensnetzwerk integriert und mit anderen Applikationen verknüpft werden. Neben der grundsätzlichen Inte-grationsproblematik spielt auch Flexibilität eine große Rolle. Aufgabe der IT ist es, Geschäftsprozesse zu unterstützen. Daher muss sie sich auch fortwährend an diesen Prozessen ausrichten. Im Zeitalter der Globalisierung ändern sich Pro-zesse aber sehr schnell, um das Unternehmen laufend an neue Marktsituationen anzupassen. Die IT steht vor der Herausforderung, hier Schritt zu halten und Anwendungssysteme schnell und flexibel miteinander zu verknüpfen.

Punkt-zu-Punkt Verknüpfungen, also Infrastrukturen, in denen jedes System mit jedem anderen vernetzt wird, sind hier offensichtlich nicht geeignet. Die schiere Menge an individuell zu erstellenden Kopplungen ist schlicht zu groß. Es bedarf Integrationslösungen, die Dienstnutzer und Dienstanbieter einerseits entkoppeln, andererseits aber die Kommunikation zwischen ihnen sicherstellen. Und genau dies ist Aufgabe des Enterprise Service Busses (Krafzig, Banke, Slama, 2004, S. 64). Mit der Geburt und Verbreitung des Begriffes gingen Hersteller dazu Ober, ihre bereits bestehenden Produkte etwas zu modifizieren und in „Enterprise Service Bus" Lösungen umzubenennen. Daneben entstanden neue Produkte, unter anderem auch auf Open-Source basierend, die speziell auf das Konzept eines Integrationsbusses hin entwickelt wurden. Gerade Open-Source-Lösungen stellen eine interessante Alternative zu kommerziellen Produkten dar. Sie setzen auf Offenheit, Standards und auf Unterstützung mit Community-Gedanken. Die Idee, ein Produkt frei verfügbar anzubieten, um in den späteren Phasen über Support und Beratung Einnahmen zu erzielen, führt zu einer großen Zahl an Erstanwendern (Raymond, 2000, S. 6ff.). Deren Erfahrungen werden offen kommuniziert und fließen in neue Produktreleases ein. Trotzdem scheuen Unter-nehmen den Einsatz dieser Produkte, da ihre Evaluierung oft zeitaufwendig ist und für Weiterentwicklung und Gewährleistung ein greifbarer Geschäftspartner fehlt. Im Rahmen der Arbeit werden verschiedene Open-Source Enterprise Service Bus Systeme beleuchtet und untersucht, inwieweit diese den Er-wartungen einer umfassenden Integrationslösung entsprechen. Dabei werden auch Themen wie Betrieb, Überwachung und Dokumentation beleuchtet, um ab-schließend eine Bewertung zur Praxistauglichkeit zu formulieren.

2 Der Enterprise Service Bus

Zunächst ist es zweckmäBig, den Begriff „Enterprise Service Bus" im Kontext dieser Arbeit geeignet einzugrenzen, bevor Anforderungen an ein derartiges Produkt formuliert werden. Abschließend wird mit der Java Busines Integration (JBI) ein Standard vorgestellt, der zunehmend Verbreitung in der Szene der Enterprise Service Bus Lösungen findet.

2.1 Definition

Obwohl der Begriff „Enterprise Service Bus" (ESB) seit dem Jahr 2002 Einzug in die IT gehalten hat (Schulte, 2002), bleibt seine Definition in der Literatur un-scharf. Einerseits umschreibt der Begriff die konzeptionelle Idee einer verteilten Architektur zur Integration heterogener Services basierend auf einer Bus-Topologie. Der ESB steht diesem Verständnis nach für eine Middleware-Schicht, über die Services verschiedenen Dienstnutzern bereitgestellt werden. Daneben bezeichnet der Begriff aber auch die konkrete Software, mit deren Hilfe die oben beschriebene konzeptionelle Idee realisiert wurde. Der ESB ist in diesem Fall die konkrete Middleware-Komponente, über die Dienstanbieter und Dienstnutzer lose gekoppelt miteinander kommunizieren (Masak, 2007, S. 146).

Im Folgenden wird der Begriff „Enterprise Service Bus" als konkrete Software-lösung verstanden. Die im Rahmen der Arbeit durchgeführte Evaluierung unter-sucht drei verbreitete Open-Source ESB-Produkte und prüft, inwieweit diese dem konzeptionellen Gedanken einer busorientierten Integrationslösung entsprechen und dem Anspruch einer unternehmensweiten Integrationslösung gerecht werden können.

2.2 Anforderungen an einen Enterprise Service Bus

Eine Folge der unscharfen Begriffsdefinition ist, dass Hersteller von Enterprise Service Bus Produkten immer auch gerne die generellen Anforderungen an einen Enterprise Service Bus selbst formulieren - und meist so, dass sich diese generellen Anforderungen optimal mit der eigenen angebotenen Lösung decken. Damit wird es schwierig, einzelne Lösungen miteinander zu vergleichen, ja sogar generell eine Aussage zu treffen, was ein Enterprise Service Bus nun letztlich können muss. Eine Studie der Anforderungslisten verschiedener Hersteller zeigt aber auch durchaus Ähnlichkeiten (Dunkel, Eberhart, Fischer, 2008, S. 110ff.). Anhand dieser Ähnlichkeiten können die im Folgenden ausformulierten An-forderungen an einen ESB gestellt werden. Im weiteren Verlauf der Arbeit ent- steht daraus ein Bewertungskatalog, auf Basis dessen die Evaluierung durch-geführt wird.

Nachrichtenweiterleitung

Kernaufgabe des Enterprise Service Bus ist die korrekte Weiterleitung von Nach-richten (Routing) an den oder die vorgesehenen Empfänger. Zur Umsetzung dieser Aufgabe stehen eine Reihe etablierter Mechanismen zur Verfügung, mit denen auf vielfältige Art und Weise der Nachrichtenfluss gesteuert werden kann (Hohpe Woolf, 2004, S. 208ff.).

- INHALTSBASIERTES ROUTING (content-based): Die Nachricht wird aufgrund ihres Inhalts an einen Empfänger geschickt. Da die Routing-Komponente dynamisch den korrekten Empfänger ermitteln kann, muss der Sender die Nachricht nicht mehr an einen speziellen Empfänger adressieren. Dies fördert die Entkopplung von Sender und Empfänger.
- FILTER: Eine Nachricht wird nur dann an einen Empfänger weiter-geleitet, wenn bestimmte Filterkriterien erfüllt sind. Auch hier muss die Routing-Komponente auf den Inhalt der ]Nachricht zugreifen können, um Filterkriterien zu prüfen.
- POINT-TO-POINT: Aufbau einer virtuellen eins-zu-eins Verbindung zwischen einem Dienstanbieter und Dienstnutzer. „Virtuell", da eine Entkopplung von Sender und Empfänger über den Bus stattfindet und sich die beiden nicht direkt kennen.
- PUBLISH/SUBSCRIBE: Beliebige Empfänger können sich für Nach-richten registrieren. Eine Nachricht wird parallel an alle interessierten Empfänger gesendet, die Empfänger sind voneinander unabhängig. Als Abgrenzung zum weiter unten genannten Typ „Empfangerliste" hat der Sender bei Publish/Subscribe keinen Einfluss darauf, wer die Nachricht erhalten wird.
- EMPFÄNGERLISTE (Recipient-List): Mit dem Prinzip der Empfängerliste wird eine Nachricht parallel an eine Menge von Empfängern geschickt. Wesentliches Merkmal ist, dass der Sender festlegt, an wen die Nach-richt geht. Der Versand der Nachricht erfolgt parallel.
- ROUTING-SLIP: Die Nachricht wird analog zur Empfängerliste an eine Menge von Empfängern geschickt, allerdings nacheinander. Damit können beispielsweise Validierungen nacheinander aufgerufen werden, oder auch ein Versuch-Irrtum Konzept zur Ermittlung des nächsten erreichbaren Dienstes umgesetzt werden.
- RESEQUENCER: Ein Resequencer ist in der Lage, eine Menge von Nachrichten wieder in die richtige Reihenfolge zu bringen. Dazu muss er zustandsbehaftet arbeiten können. Die Ordnung der Nachrichten ermittelt er anhand einer Ordnungsnummer, typischerweise ein Attri-but des Nachrichtenheaders.
- PROCESS-MANAGER: Ist zur Ermittlung eines nachfolgenden Empfän-gers umfangreiche Programmlogik erforderlich, so realisiert ein Process-Manager diese Logik.

Ortstransparenz

Der Enterprise Service Bus muss Applikationen eine Infrastruktur bieten, die es ihnen erlaubt, auf entfernte Schnittstellen zuzugreifen, ohne die tatsächliche Adresse des dahinter liegenden Dienstes zu kennen (Ortstransparenz, Location-Transparency). Als Mediator ist er die zentrale Anlaufstelle, um mit anderen Applikationen zu kommunizieren. Serviceanbieter und Servicenutzer werden voneinander entkoppelt und somit die Anzahl direkter Abhängigkeiten zwischen Applikationen reduziert.

Transformation

Grundsätzlicher Zweck der Transformation ist es, eine Nachricht eines Service-nutzers in das Format zu konvertieren, mit dem ein Serviceanbieter umgehen kann ± und umgekehrt eine Antwort im benötigten Format zurückzuliefern. Betrachtet man diese Anforderung genauer, so muss ein ESB in der Lage sein, die Struktur von Nachrichten zu ändern, Inhalte zu modifizieren und Nachrichten mit Zusatzinformationen anzureichern. Insbesondere sind auch das Aufteilen (Splitter) und das Zusammenführen (Aggregator) von Nachrichten besondere Formen einer Transformation.

Sicherheit

- AUTHENTIFIZIERUNG: Überprüfung der tatsächlichen Identität des Dienst-nutzers inklusive der Möglichkeit, die Client-Identität zwischen Services zu transportieren (Identity Management).
- AUTORISIERUNG: Definiert, welche Berechtigungen ein Dienstnutzer inner-halb des Service-Busses besitzt.
- VERTRAULICHKEIT: Den Nachrichtenaustausch dahin gehend absichern, dass nur der Empfänger einer Nachricht in der Lage ist, diese zu lesen. Zu unter- scheiden ist hier die Absicherung des Nachrichtenkanals (beispielsweise über Secure-Sockets oder Https) und die Verschlüsselung der Nachricht selbst. Ebenfalls zur Vertraulichkeit gehört eine Möglichkeit, Nachrichten zu signieren, um deren Inhalt gegenüber Änderungen Dritter abzusichern.
- AUDITING: Sammeln von Laufzeitinformationen um sicherheitsrelevante Ab-läufe rückwirkend überprüfen zu können.

Verlässliche Nachrichtenübertragung

- PERSISTENZ: die Möglichkeit, Nachrichten zwischen zu speichern, falls ein Empfänger nicht erreichbar ist.

- TRANSAKTIONSSICHERHEIT:

- Garantierte Nachrichtenzustellung, optimaler weise mit parametrier-baren Qualitätsmerkmalen (garantiert einmal, mindestens einmal, höchstens einmal).
- Unterstützung des Prinzips autonomer Nachrichten. Jede Operation eines Services an einer Nachricht ist eine eigene Transaktion.
- Unterstützung eines Transaktionsmonitors um verteilte Transaktionen zu realisieren
- Unterstützung des Setzens von Transaktionsklammern innerhalb des Verarbeitungspfades
- Unterstützung einer synchronen Verarbeitung von Nachrichten inner-halb einer Transaktion bei Verwendung geeigneter Kommunikations-protokolle.

- SKALIERBARKEIT / VERFÜGBARKEIT: Möglichkeiten, den Enterprise Service Bus über Clustering hochverfügbar zu realisieren oder bei hoher Last eine Verteilung der Anfragen auf mehrere Softwarekomponenten zu ermöglichen.

- FEHLERBEHANDLUNG

Administrations- und Überwachungsmöglichkeiten

Von einem Enterprise Service Bus wird erwartet, dass er Möglichkeiten zur Konfiguration seiner Komponenten anbietet, optimalerweise im laufenden Be-trieb. Essenziell sind Funktionen zur Überwachung des Betriebs, um proaktiv auf Situationen reagieren zu können. Verteilen sich die Komponenten eines Enterprise Service Busses über mehrere Installationen, so muss deren Ad­ministration über eine zentrale Stelle (Single Point Of Control) möglich sein.

Unterstützung von Kommunikationsstandards und Erweiterbarkeit

Damit Dienste und Nutzer über den Bus kommunizieren können, muss der ESB in der Lage sein, deren Kommunikationsprotokoll zu verstehen. Zum einen müssen Protokolladapter für proprietäre Protokolle in die ESB-Lösung integriert werden können. Zum anderen wird auch erwartet, dass der ESB standardisierte Protokolle wie File, JMS, FTP oder http direkt verstehen und einbinden kann. Entscheidend dabei ist eine hohe Vielfalt der Protokolle, die ein ESB direkt unter-stützt. Neben der Kopplung über offene Standardprotokolle ist auch die Ver-wendung von Standards innerhalb des Busses wünschenswert. Damit erreicht man eine möglichst geringe Abhängigkeit vom konkreten ESB-Produkt und kann unter Umstände Werkzeuge Dritter in den ESB integrieren ± beispielsweise Auditing-Werkzeuge.

2.3 Java Business Integration

Die Java Business Integration (JBI) ist eine im Rahmen des Java-Specification-Request 208 (JSR-208) entwickelter Standard um die Integration von Kompo-nente zu vereinheitlichen (Ten-Hove Walker, 2005). Der Standard beschreibt, wie Komponenten über einen Bus miteinander interagieren. Dabei wird ein Rahmenwerk definiert, das sich um die Installation, das Lifecycle-Management und um Elemente des Systemmanagements kümmert. Auch beschrieben ist der Normalized Message Router (NMR), der Bus, über den JBI-Komponenten in standardisierter Form und voneinander entkoppelt miteinander kommunizieren. Zentrale Begriffe der Spezifikation sind:

- Service-Engines: Komponenten, deren Dienste nur lokal innerhalb des JBI Containers genutzt werden können. Ein typisches Beispiel ist eine XML-Transformation.

- Binding-Components: Komponenten, die eine Verbindung mit externen Diensten herstellen. Sie agieren als Protokollumsetzer zwischen dem standardisierten Nachrichtenformat des Normalized Message Router und dem jeweiligen Format des externen Dienstes.
- Normalized Message Router: der Nachrichtenbus, der als Mediator standardisierte Nachrichten zwischen Service-Engines und Binding-Components austauscht.
- Delivery-Channel: die bidirektionale Verbindung zwischen den Komponenten und dem Nachrichtenbus.
- Service-Assembly / Service-Unit: Dies sind die Bezeichnungen für die Installationsartefakte, die im Zuge der Integrationstätigkeiten entstehen. Eine Service-Unit beinhaltet die Konfiguration einer oder mehrerer Tätig- keiten für eine Komponente. Ein Beispiel für eine Service-Unit ist das Ent-gegennehmen einer Bestellung von einem Browser. Ein oder mehrere Service-Units werden in eine Service-Assembly verpackt und als Paket im JBI-Container installiert. Eine Service-Assembly ist damit die fachliche Klammer um eine Menge von Service-Units.

Die folgende Grafik (siehe Abbildung 1) zeigt schematisch das Zusammenspiel der oben genannten JBI-Bausteine.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Zusammenspiel der Elemente der JBI-Spezifikation

3 Rahmen der Untersuchung

Um einen stimmigen Bewertungskatalog für die Evaluierung formulieren zu kön-nen, wird zunächst das Ziel der Untersuchung aus der Vogelperspektive be-schrieben. Darauf abgestimmt folgt ein Beispielszenario, welches als Teil der Untersuchung mit allen betrachteten ESB-Produkten realisiert wird.

3.1 Ziel der Untersuchung

Ziel der Arbeit ist es, ausgewählte Open-Source Lösungen in Hinblick auf die Idee des Enterprise Service Busses zu untersuchen. Im Vordergrund steht dabei, ob und inwieweit die drei Produkte die eingangs formulierten Anforderungen er-füllen (vgl. Kapitel 2.2). Daneben gilt es auch festzustellen, ob die Software-Lösungen reif sind für einen Einsatz im unternehmerischen Umfeld. Dies hängt ab von Rahmenbedingungen wie Support, Dokumentation und Betreibbarkeit.

Untersucht werden drei weitverbreitete, etablierte Open-Source ESB-Lösungen auf Java Basis, die sich bereits seit Längerem auf dem Markt befinden und deren Weiterentwicklung in der Vergangenheit kontinuierlich vorangetrieben wurde:

- Mule, bereitgestellt von MuleSource (Mulesource, 2009).

- ServiceMix, entwickelt unter der Apache Software Foundation (Snyder, 2008).

- OpenESB, eine Open-Source Lösung von Sun Microsystems (Microsystems, 2009)

3.2 Formulieren eines Beispielprozesses

Um die Handhabung der ESB-Lösungen auch in Bezug auf deren praktische Ver-wendung hin beurteilen zu können, wird hier ein typisches Szenario beschrieben und im weiteren Verlauf auf allen betrachteten Produkten realisiert. Das Szenario enthält eine Reihe von Anwendungsfällen aus dem Bereich Routing und Trans­formation, womit detaillierte Einblicke in die Funktionsweise der ESB-Lösungen möglich werden. Weiterhin hilft die Umsetzung des Szenarios dabei, die Lern-kurven der einzelnen Produkte miteinander zu vergleichen und Unterschiede zwischen den Lösungen aufzudecken. Zur deutlichen Abgrenzung sei hier er-wähnt, dass es nicht Ziel des Szenarios ist, die ESB-Komponenten funktional zu testen. Auch Aspekte der Performance, der Skalierung und des Failover-verhaltens liegen nicht im Fokus.

3.2.1 Überblick über das Beispielszenario

Inhaltlich beschäftigt sich das Szenario mit einem stark vereinfachten Fahrzeugbestellprozess eines Automobilherstellers (vgl. Abbildung 2). Fachliche Inhalte spielen bei der Betrachtung eine untergeordnete Rolle. Vielmehr geht es darum, im Folgenden verschiedene Integrationsanforderungen in einem stimmigen Kontext darzustellen. Die Kopplung des Fachprozesses an den ESB und die damit verbundenen Fragen wie Synchronität/Asynchronität und Umgang mit Latenzzeiten müssen von beiden Seiten angemessen unterstützt werden. Im Zuge der ESB-Bewertung fließen diese Fragen mit ein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Fachliche Sicht auf das Beispielszenario

Der Fahrzeugbestellprozess beginnt mit dem Eintreffen einer Bestellung beim Automobilhersteller und endet mit einer Ergebnisantwort. Jeder Prozessschritt interagiert mit entfernten Anwendungssystemen (siehe Abbildung 2, rechts). Die Integrationsschicht dazwischen wird von dem jeweilig untersuchten ESB-Produkt abgedeckt. Im Einzelnen besteht der Bestellprozess aus folgenden Schritten (vgl. Abbildung 2, links):

1. Entgegennehmen der Fahrzeugbestellung

Ein Händler gibt eine Fahrzeugbestellung beispielsweise über Web-formular oder als Datei ab. Der ESB nimmt die Bestellinformationen ent-gegen. Über eine Transformation wird die Bestellung innerhalb des ESB in ein XML-Format umgewandelt und an den nächsten Prozessschritt über-geben.

Aufgaben ESB: asynchrone Nachrichtenübertragung, Nachrichtentrans-formation, Lesen aus einer Quelle.

2. Prüfen des Händlers

Prozessschritt zwei stöl3t die Händlerprüfung an. Da es für Europa und USA unterschiedliche Prüfsysteme gibt, routet der ESB die Bestellung an den passenden Empfänger und die Antwort zurück an den Aufrufer. Aufgaben ESB: asynchrone Nachrichtenübertragung, inhaltsbasiertes Rou­ting

3. Belegen eines Produktionsplatzes

Nach der Händlerprüfung wird über das Produktionsmanagementsystem ein Produktionsplatz belegt. Der Vorgang wird synchron abgewickelt. Aufgaben ESB: synchrone Nachrichtenübertragung an einen Webservice.

4. Propagieren des Bestellergebnisses

Abschliel3end wird das Orderergebnis an interessierte Systeme geschickt. Dies ist einerseits der Händler, von dem die Bestellung ausging. Andererseits werden die finanziellen Daten (und nur die) an das Händler-provisionssystem geschickt, die Fahrzeugdaten der Bestellung werden im Datawarehouse Europa bzw. USA abgelegt.

Aufgaben ESB: asynchrone Nachrichtenübertragung, parallele Nachrich-tenauslieferung an eine Empfängerliste, Splitten von Nachrichten.

[...]