Moderne IT Infrastrukturen zeichnen sich heutzutage nicht zuletzt durch ihre hohe Heterogenität aus. Häufig handelt es sich um gewachsene Strukturen, die verstärkt über öffentliche oder herstellerspezifische Protokolle miteinander verknüpft werden. Diese Integrationsaktivitäten machen nicht an Unternehmensgrenzen halt sondern greifen auch nach den Systemen der Kunden und Lieferanten, immer mit dem Ziel Prozesse weiter zu automatisieren und zu verbessern. Tragische Folge: Es entsteht ein Kommunikationswirrwarr, in dem keiner mehr genau abschätzen kann, welches System mit welchem kommuniziert und welche Folgen eine Änderung in diesem fragilen Kommunikationsgefüge nach sich zieht. Letztlich manövriert sich das Unternehmen selbst in eine Position, in der es die heutzutage notwendige Flexibilität bezüglich der unternehmerischen Prozeßgestaltung oftmals nur mit großen zeitlichen und finanziellen Mühen erbringen kann.
Hier setzt die Idee des ESB (Enterprise Service Bus) an (Abb. 1). Anstelle eines Kommunikationsnetzes mit individuellen Austauschprotokollen tritt ein genereller Kommunikationsbus. Dieser Bus transportiert als Mittler Nachrichten vom Sender zum Empfänger und sorgt gleichzeitig für eine lose Kopplung der beiden.
Inhaltsverzeichnis
Abbildungsverzeichnis
1 Der Enterprise Service Bus
1.1 Das Konzept des Enterprise Service Bus
1.2 Aufgaben eines Enterprise Service Bus
1.3 Probleme und Nachteile der Kopplung über ESB
2 ESB am Beispiel ServiceMix
2.1 Die Software ServiceMix
2.2 Das Beispielszenario
2.3 Die Realisierung
2.3.1 Generelles Vorgehen
2.3.2 Die Fileschnittstelle
2.3.3 Die JMS Schnittstelle
2.3.4 Der Distributor
2.3.5 Der Abrechnungsservice
2.3.6 Der Versandtransformator
2.3.7 Erstellen einer Service Assembly und Installation
2.3.8 Aufrufen der neu installierten Dienste
3 Fazit
4 Anhang
4.1 Installation von ServiceMix
4.2 Konfiguration: Service Unit File
4.2.1 Verzeichnisaufbau und –inhalt
4.2.2 Konfigurationsdatei „xbean.xml“:
4.2.3 Konfigurationsdatei “jbi.xml”
4.2.4 Beispieldatei
4.3 Konfiguration: Service Unit JMS
4.3.1 Verzeichnisaufbau und –inhalt
4.3.2 Konfigurationsdatei „xbean.xml“
4.3.3 Konfigurationsdatei “jbi.xml”
4.4 Konfiguration: Distributor
4.4.1 Verzeichnisaufbau und –inhalt
4.4.2 Konfigurationsdatei „xbean.xml“
4.4.3 Konfigurationsdatei “jbi.xml”
4.5 Konfiguration: Abrechnungsservice
4.5.1 Verzeichnisaufbau und –inhalt
4.5.2 Konfigurationsdatei „xbean.xml“
4.5.3 Konfigurationsdatei “jbi.xml”
4.5.4 Java Klasse “AbrechnungPojo.java”
4.6 Konfiguration: Versandtransformation
4.6.1 Verzeichnisaufbau und –inhalt
4.6.2 Konfigurationsdatei „xbean.xml“
4.6.3 Konfigurationsdatei “jbi.xml”
4.6.4 Stylesheet „transform.xsl“
4.7 Konfiguration: Service Assembly
4.7.1 Verzeichnisaufbau und –inhalt
4.7.2 Konfigurationsdatei “jbi.xml”
4.8 Der JMS Client
Literaturverzeichnis
Abbildungsverzeichnis
Abb. 1: Kommunikationsbus statt Punkt-zu-Punkt
Abb. 2: Aufbau einer JBI-Architektur
Abb. 3: Struktur des Beispielszenarios
Abb. 4: Aufbau des Distributors
Abb. 5: Verzeichnisstruktur ServiceMix
Abb. 6: Aufbau der Service Unit spitzi-file-su
Abb. 7: Aufbau der Service Unit spitzi-abrechnung-su
Abb. 8: Aufbau der Service Unit spitzi-transformer-su
Abb. 9: Aufbau der Service Assembly
1 Der Enterprise Service Bus
1.1 Das Konzept des Enterprise Service Bus
Moderne IT Infrastrukturen zeichnen sich heutzutage nicht zuletzt durch ihre hohe Heterogenität aus. Häufig handelt es sich um gewachsene Strukturen, die verstärkt über öffentliche oder herstellerspezifische Protokolle miteinander verknüpft werden. Diese Integrationsaktivitäten machen nicht an Unternehmensgrenzen halt sondern greifen auch nach den Systemen der Kunden und Lieferanten, immer mit dem Ziel Prozesse weiter zu automatisieren und zu verbessern. Tragische Folge: Es entsteht ein Kommunikationswirrwarr, in dem keiner mehr genau abschätzen kann, welches System mit welchem kommuniziert und welche Folgen eine Änderung in diesem fragilen Kommunikationsgefüge nach sich zieht. Letztlich manövriert sich das Unternehmen selbst in eine Position, in der es die heutzutage notwendige Flexibilität bezüglich der unternehmerischen Prozeßgestaltung oftmals nur mit großen zeitlichen und finanziellen Mühen erbringen kann.
Hier setzt die Idee des ESB (Enterprise Service Bus) an (Abb. 1). Anstelle eines Kommunikationsnetzes mit individuellen Austauschprotokollen tritt ein genereller Kommunikationsbus. Dieser Bus transportiert als Mittler Nachrichten vom Sender zum Empfänger und sorgt gleichzeitig für eine lose Kopplung der beiden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Kommunikationsbus statt Punkt-zu-Punkt
Quelle: In Anlehnung an [JBI2005]
1.2 Aufgaben eines Enterprise Service Bus
Bezüglich der konkreten Aufgaben eines ESB unterscheiden sich die Vorstellungen der Softwareanbieter - nicht zuletzt aufgrund der Funktionalitäten der eigenen Produktpalette. Allerdings sind folgende wesentliche Elemente des Busses in allen Beschreibungen anzutreffen (siehe [IBMSOA2004] S.84ff, [PTRSOA2004] S.187ff):
Transformation: Über Nachrichtentransformation kann der ESB verschiedene Formate unterstützen indem Nachrichten bei Bedarf in ihrer Struktur oder ihrem Inhalt verändert werden.
Routing: Die Kernaufgabe des ESB ist das Routing, das Weiterleiten von Nachrichten von einer Quelle (Service Consumer) zu dem gewünschten Serviceanbieter (Service Provider). Dabei sollte der Bus auch abhängig vom Nachrichteninhalt einen Serviceanbieter ermitteln können (content-based routing).
Nachrichtenbasierte Kommunikation: Der Bus kann synchrone und asynchrone Dienste ansprechen und besitzt die Möglichkeit, Nachrichten nach dem Publish/Subscribe Prinzip von einem Sender an viele Empfängern zu senden.
Sicherheit: Hierzu gehören die Identifizierung des Aufrufers (Authentifizierung), die Prüfung der Rechte des Aufrufers (Autorisierung) sowie die Möglichkeit zur Verschlüsselung der Kommunikationskanäle.
Zusätzlich zu den oben genannten Elementen erwartet man eine Vielzahl von verfügbaren Komponenten, mit denen bestehenden Dienste an den ESB gebunden werden können (Ftp, Http, Webservice usw.) sowie die Möglichkeit, gegebenenfalls eigene Komponenten zu entwickeln.
1.3 Probleme und Nachteile der Kopplung über ESB
Den unbestreitbaren Vorteilen eines ESB bei der Verknüpfung von Applikationssystemen stehen auch Nachteile gegenüber.
So verursacht der Einsatz eines ESB bei jedem Nachrichtenaustausch zwischen zwei Systemen eine zweimalige Konvertierung von und zu einem einheitlichen Nachrichtenformat. Dies verursacht einen signifikanten Zusatzaufwand, der bei einer hohen Anzahl auszutauschender Nachrichten zwischen zwei Systemen zu einer deutlichen Verlangsamung der Bearbeitung führen kann.
Auch verliert man durch den Einsatz von Nachrichten in der Regel eine übergreifende Transaktion. Kommt es zu einem Zurücksetzen in der zugehörigen Geschäftsoperation werden nicht automatisch die Änderungen in dem oder den anderen Systemen zurückgesetzt. Häufig sieht man als Lösung den Ansatz von Kompensationsbuchungen. Dieser Ansatz hat jedoch den Nachteil, daß einerseits die Behandlung eines Rollback nicht implizit aus Sicht der beteiligten Applikationen stattfindet und andererseits ein möglicher Ausfall von Systemen Kompensationsbuchungen verhindern kann – wodurch die Applikation in der Verantwortung ist, entsprechende Schritte einzuleiten (beispielsweise den Anwender zu informieren).
Auch ist ein ESB ist eigenständiges Stück Software, in der Regel installiert auf einer eigenen Hardware. Für die Konfiguration und den Betrieb des ESB ist zusätzliches Wissen erforderlich. Dies ist zunächst eine nicht unerhebliche Investition die sich nicht nach dem ersten erfolgreichen ESB Projekt bezahlt machen wird. Somit ist die Einführung eines ESB nicht im Kontext eines Projektes zu sehen ist sondern gesamthaft im Unternehmen zu planen und umzusetzen.
Letztlich gilt also auch hier analog zu allen anderen Technologien und Konzepten: je nach Fall ist abzuwägen, ob und wie stark ein ESB im Rahmen eines Projektes Sinn macht.
2 ESB am Beispiel ServiceMix
Die im ersten Kapitel dargestellten theoretischen Konzepte eines Enterprise Service Bus werden in diesem Kapitel anhand der frei verfügbaren Software „ServiceMix“ aufgezeigt.
2.1 Die Software ServiceMix
ServiceMix ist ein mit Java entwickelter opensource ESB unter der Apache Lizenz (siehe [SMIX]). Bis zum jetzigen Zeitpunkt findet man in der Literatur noch keine allgemein gültige Spezifikation eines Enterprise Service Bus. Allerdings wurde innerhalb der Java Community unter dem JSR (Java Specification Request) 208 mit der JBI (Java Business Integration, siehe [JBI2005]) ein Standard für die Integration von Komponenten spezifiziert, welcher von ServiceMix auch als Basis für deren ESB Implementierung verwendet wird.
Folgende Grafik (Abb. 2) veranschaulicht die Architektur der JBI. Komponenten werden in einem JBI konformen Container wie beispielsweise ServiceMix installiert und sind ab dann in der Lage nachrichtenorientiert miteinander zu kommunizieren.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Aufbau einer JBI-Architektur
Quelle: In Anlehnung an [JBI2005]
- Arbeit zitieren
- Dipl. Inf. FH Ulrich Biberger (Autor:in), 2008, Der Enterprise Service Bus in Theorie und Praxis, München, GRIN Verlag, https://www.grin.com/document/115029