Inhaltsverzeichnis I

Inhaltsverzeichnis   

Abbildungsverzeichnis   II

Tabellenverzeichnis   III

Abk  ürzungsverzeichnis  IV

1  Einführung  5

2  Der Enterprise Service Bus  6

2.1  Definition  6

2.2  Anforderungen an einen Enterprise Service Bus  6

2.3  Java Business Integration  10

3  Rahmen der Untersuchung  12

3.1  Ziel der Untersuchung  12

3.2  Formulieren eines Beispielprozesses  12

3.2.1  Überblick über das Beispielszenario  13

3.2.2  Technische Realisierung  15

3.3  Bewertungskatalog  16

4  Untersuchung der Produkte  20

4.1  Die Open-Source-Lösung Mule  20

4.1.1  Architektur  20

4.1.2  Das Beispielszenario: Umsetzung und Erfahrungen  24

4.1.3  Bewertung der Kriterien  25

4.1.4  Fazit  32

4.2  Die Open-Source-Lösung ServiceMix  32

4.2.1  Architektur  33

4.2.2  Das Beispielszenario: Umsetzung und Erfahrungen  37

4.2.3  Bewertung der Kriterien  38

4.2.4  Fazit  44

4.3  Die Open-Source-Lösung Glassfish ESB  44

4.3.1  Architektur  44

4.3.2  Das Beispielszenario: Umsetzung und Erfahrungen  50

4.3.3  Bewertung der Kriterien  52

4.3.4  Fazit  57

5  Vergleich und Fazit  58

Glossar   61

Literaturverzeichnis   64

Abbildungsverzeichnis   

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 III   

Tabellenverzeichnis   

Tabelle 1:  Bewertungskatalog  19

Tabelle 2:  Ergebnis der Evaluierung  60

Abk  ürzungsverzeichnis  IV

Abk  ürzungsverzeichnis  

BPEL  Business Process Execution Language  

DSL  Domain Specific Language  

EAI  Enterprise Application Integration  

ESB  Enterprise Service Bus  

EJB  Enterprise Java Bean  

JAAS  Java Authentication and Authorization Service  

JBI  Java Business Integration  

JMS.  Java Message Service  

JMX.  Java Management Extensions  

NMR  Normalized Message Router  

POM  Project Object Model  

REST  Representational State Transfer  

SEDA  Staged Event-Driven Architecture  

SOA  Service-orientierte Architektur  

UMO  Unified Message Object  

WSDL  Webservices Description Language  

XML  Extensible Markup Language  

XSLT  Extensible Stylesheet Language Transformation  

Einführung 5

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 Integrationsproblematik 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 Prozesse 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 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 Unternehmen 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 Erwartungen 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.

Der Enterprise Service Bus 6

2 Der Enterprise Service Bus

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

die IT gehalten hat (Schulte, 2002), bleibt seine Definition in der Literatur unscharf. 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).

e- lösungverstanden. Die im Rahmen der Arbeit durchgeführte Evaluierung untersucht 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-

Der Enterprise Service Bus 7

steht daraus ein Bewertungskatalog, auf Basis dessen die Evaluierung durchgeführt wird.

Nachrichtenweiterleitung

Kernaufgabe des Enterprise Service Bus ist die korrekte Weiterleitung von Nachrichten (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

FILTER: Eine Nachricht wird nur dann an einen Empfänger weiter-

POINT-TO-POINT: Aufbaueiner virtuellen eins-zu-eins Verbindung

PUBLISH/SUBSCRIBE: Beliebige Empfänger können sich für Nach-

EMPFÄNGERLISTE (Recipient-List):Mit dem Prinzip der Empfängerliste

ROUTING-SLIP: Die Nachricht wird analog zur Empfängerliste an eine

Der Enterprise Service Bus 8

RESEQUENCER: Ein Resequencer ist in der Lage, eine Menge von

PROCESS-MANAGER: Ist zur Ermittlung eines nachfolgenden Empfän-

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 Servicenutzers 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 Dienstnutzers inklusive der Möglichkeit, die Client-Identität zwischen Services zu transportieren (Identity Management).

AUTORISIERUNG: Definiert, welche Berechtigungen ein Dienstnutzer innerhalb 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-

Der Enterprise Service Bus 9

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 Ablä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:

o Garantierte Nachrichtenzustellung, optimaler weise mit parametrier-

o Unterstützungdes Prinzips autonomer Nachrichten. Jede Operation eines Services an einer Nachricht ist eine eigene Transaktion.

o Unterstützung eines Transaktionsmonitors um verteilte Transaktionen zu realisieren

o Unterstützung des Setzens von Transaktionsklammern innerhalb des Verarbeitungspfades

o Unterstützung einer synchronen Verarbeitung von Nachrichten inner-

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 Betrieb. 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.

Der Enterprise Service Bus 10

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 unterstützt. Neben der Kopplung über offene Standardprotokolle ist auch die Verwendung 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 Komponente 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. die Delivery-Channel: 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-

Der Enterprise Service Bus 11

keiten für eine Komponente. Ein Beispiel für eine Service-Unit ist das Entgegennehmen 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.

-Units definieren neue Endpunkte in den jeweiligen

Komponenten. Die Komponenten sind aus Sicht der Service-Units Container.

Abbildung 1: Zusammenspiel der Elemente der JBI-Spezifikation

Rahmen der Untersuchung 12

3 Rahmen der Untersuchung

Um einen stimmigen Bewertungskatalog für die Evaluierung formulieren zu können, wird zunächst das Ziel der Untersuchung aus der Vogelperspektive beschrieben. 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 erfü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 Verwendung 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 Lernkurven der einzelnen Produkte miteinander zu vergleichen und Unterschiede zwischen den Lösungen aufzudecken. Zur deutlichen Abgrenzung sei hier erwä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.