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
Häufig gestellte Fragen
Was ist ein Enterprise Service Bus (ESB)?
Ein Enterprise Service Bus (ESB) ist ein Kommunikationsbus, der in modernen IT-Infrastrukturen eingesetzt wird, um verschiedene Applikationssysteme lose zu koppeln. Er transportiert Nachrichten vom Sender zum Empfänger und sorgt für eine Standardisierung der Kommunikation zwischen heterogenen Systemen.
Welche Aufgaben hat ein Enterprise Service Bus?
Zu den Hauptaufgaben eines ESB gehören Transformation von Nachrichtenformaten, Routing (Weiterleiten von Nachrichten), Nachrichtenbasierte Kommunikation (sowohl synchron als auch asynchron) und die Sicherstellung der Sicherheit durch Authentifizierung, Autorisierung und Verschlüsselung.
Was sind die Nachteile der Kopplung über einen ESB?
Nachteile sind der zusätzliche Aufwand durch die Konvertierung von Nachrichtenformaten, der Verlust übergreifender Transaktionen und der Bedarf an zusätzlichem Wissen und Ressourcen für die Konfiguration und den Betrieb des ESB.
Was ist ServiceMix?
ServiceMix ist ein Open-Source-ESB, der in Java entwickelt wurde und unter der Apache-Lizenz steht. Er basiert auf der JBI (Java Business Integration) Spezifikation.
Was ist JBI (Java Business Integration)?
JBI ist ein Standard innerhalb der Java Community (JSR 208) für die Integration von Komponenten in einem ESB. ServiceMix verwendet JBI als Basis für seine ESB-Implementierung.
Wie funktioniert die Architektur von JBI?
Komponenten werden in einem JBI-konformen Container (wie ServiceMix) installiert und können dann nachrichtenorientiert miteinander kommunizieren.
Was sind die wesentlichen Konfigurationsbestandteile einer Service Unit in ServiceMix?
Die wesentlichen Konfigurationsbestandteile sind der Verzeichnisaufbau, die xbean.xml (für die Definition der Beans) und die jbi.xml (für die Deployment-Deskriptoren).
Was ist eine Service Assembly?
Eine Service Assembly ist eine Gruppierung von Service Units, die zusammen als ein integriertes System bereitgestellt werden.
Was beinhaltet die Konfiguration einer Service Assembly?
Die Konfiguration einer Service Assembly umfasst den Verzeichnisaufbau und die jbi.xml-Datei, die die beteiligten Service Units definiert.
Welche Arten von Schnittstellen werden im Beispiel verwendet?
Im Beispiel werden Fileschnittstellen, JMS (Java Message Service) Schnittstellen und Transformationen (z.B. mit XSLT) verwendet.
Was ist Content-Based Routing?
Content-Based Routing bedeutet, dass der ESB die Entscheidung, an welchen Service die Nachricht weitergeleitet wird, auf Basis des Inhalts der Nachricht trifft.
Was sind Kompensationsbuchungen?
Kompensationsbuchungen sind ein Ansatz, um Änderungen in verschiedenen Systemen zurückzusetzen, wenn eine übergreifende Transaktion fehlschlägt. Sie sind notwendig, da der Einsatz von Nachrichten in der Regel keine automatische transaktionsübergreifende Konsistenz gewährleistet.
- Citar trabajo
- Dipl. Inf. FH Ulrich Biberger (Autor), 2008, Der Enterprise Service Bus in Theorie und Praxis, Múnich, GRIN Verlag, https://www.grin.com/document/115029
