Architektur eines ESBs zur Unterstützung von EAI Patterns

Transkript

1 Institut für Architektur von Anwendungssystemen (IAAS) Arbeitsbereich: Service Environment Universität Stuttgart Universitätsstraße Stuttgart Diplomarbeit Nr Architektur eines ESBs zur Unterstützung von EAI Patterns Christof Mierzwa Studiengang: Informatik Prüfer: Betreuer: Prof. Dr. Frank Leymann Dipl.-Inf. Thorsten Scheibler Dipl.-Inf. Tammo van Lessen begonnen am: beendet am: CR-Klassifikation: C.2.4, D.2.11, H.4.m

2

3 Inhaltsverzeichnis Abbildungsverzeichnis... V Tabellenverzeichnis... VI Verzeichnis der Listings... VII 1 Einführung Aufgabenstellung Aufbau der Arbeit Grundlagen Enterprise Application Integration (EAI) Herausforderungen einer Integration Integrationstopologien Ansätze für eine Anwendungsintegration Message oriented Middleware (MOM) Messaging Lose Kopplung MOM Konzept Channels Grundprinzipien einer MOM Enterprise Service Bus (ESB) ESB Funktionalitäten Architektur eines ESBs Abstrakte Endpunkte Messaging Service Container Directory Service Abgrenzung ESB zu anderen EAI-Technologien Patterns Enterprise Integration Pattern (EIP) Parametrisierte EAI Patterns I

4 3 ESB Architektur zur Unterstützung von EIPs Patterns Message Construction Messaging Endpoints Polling Consumer Event-Driven Consumer Competing Consumer Message Dispatcher Selective Consumer Durable Subscriber Messaging Channels Point-to-Point Channel Publish-Subscribe Channel Invalid Message Channel Dead Letter Channel Guaranteed Delivery Channel Adapter Messaging Bridge Message Routing Content-Based Router (CBR) Message Filter Dynamic Router Recipient List Splitter Aggregator Message Transformation Message Translator Envelope Wrapper Content Enricher Content Filter Claim Check System Management Control Bus Detour II

5 Wire Tap Zusammengesetzte Patterns Composed Message Processor Scatter-Gather Implementierung verwendete Technologien Apache ServiceMix Java Business Integration (JBI) Wichtige ServiceMix Komponenten Kommunikation zwischen Komponenten Loan Broker Beispiel Get Credit Score (Content Enricher) Recipient List Aggregator Message Translator Wire Tap Detour Übersicht der erstellten Komponenten Deployment Administration Bemerkungen und Ausblick Inhalte der beigefügten CD Zusammenfassung und Ausblick Literaturverzeichnis A Anhang A.1 Service Unit Konfigurationsdateien (xbean.xml) A.1.1 Pipeline Komponente Get Credit Score Dienst A.1.2 Check Service A.1.3 Pipeline Komponente BankService A.1.4 Pipeline Komponente BankService A.1.5 Pipeline Komponente BankService A.1.6 BankService III

6 A.1.7 BankService A.1.8 BankService A.1.9 Pipeline Komponente Message Translator A.1.10 Message Translator A.1.11 ResultService A.1.12 Wire Tap A.1.13 AuditService A.2 Credit.wsdl IV

7 Abbildungsverzeichnis Abb. 1: Integrationstopologien Point-to-Point (Quelle: [17])... 5 Abb. 2: Integrationstopologien Hub & Spoke (Quelle: [17])... 5 Abb. 3: Integrationstopologien Bus (Quelle: [17])... 6 Abb. 4: Nachrichtenbasierte Kommunikation (Quelle:[1])... 7 Abb. 5: Beispiel einer Topic Hierarchie... 9 Abb. 6: Publish-Subscribe Channel (Quelle: In Anlehnung an [35])... 9 Abb. 7: Point-Point-Channel (Quelle: [3]) Abb. 8: Store and Forward Prinzip Abb. 9: vereinfachte Darstellung eines ESB (Quelle: [8]) Abb. 10a: generischer ESB Endpunkt (Quelle: [1]) Abb. 10b: Web Service Endpunkt (Quelle: [1]) Abb. 11: Kernkomponente des ESB Enterprise Messaging (Quelle: [1]) Abb. 12: Endpunkte eines Service Containers (Quelle: [1]) Abb. 13: Service Container Funktionalitäten (Quelle: [1]) Abb. 14: Service Container Management (Quelle: [1]) Abb. 15: Service Container Skalierbarkeit (Quelle: [1]) Abb. 16: Pattern Hierarchie (Quelle: In Anlehnung an [2]) Abb. 17: Service Container mit Messaging Client (Quelle: [16]) Abb. 18: Messaging Bridge (Quelle: [1]) Abb. 19: Zustandsbehafteter Message Filter mit Nachrichtenfluss Abb. 20: Recipient List Variante 1 mit Nachrichtenfluss und Empfängern Abb. 21: Recipient List Variante 3 mit Nachrichtenfluss Abb. 22: Splitter mit mehreren Transformationsdiensten und 3 Empfängern Abb. 23: Envelope Wrapper mit Nachrichtenfluss Abb. 24: Claim Check mit Nachrichtenfluss Abb. 25: Beispielanwendung für einen Composed Message Processor Abb. 26: Composed Message Processor Abb. 27: Scatter Gather mit Nachrichtenfluss Abb. 28: Loan Broker (Quelle: In Anlehnung an [2]) Abb. 29: Architektur ServiceMix (Quelle: [40]) Abb. 30: JBI Architektur (Quelle: [40]) Abb. 31: Pipeline Komponente Abb. 32: Ausschnitt Nachrichtenfluss Loan Broker Abb. 33: JConsole V

8 Tabellenverzeichnis Tabelle 1: Mindestanforderungen eines ESBs Tabelle 2: JBI Standard Message Exchange Patterns VI

9 Verzeichnis der Listings Listing 1: Nachrichtenüberprüfung per JavaScript Listing 2: Beispiel einer Control Message Listing 3: JBI Deskriptor (jbi.xml) Listing 4: Konfiguration HTTP Komponente Listing 5: Konfiguration Get Credit Score Komponente Listing 6: Konfiguration der Recipient List Listing 7: Konfiguration des Aggregators Listing 8: XSL Stylesheet - Message Translator Listing 9: Konfiguration Detour Listing 10: dynamische Konfiguration Detour Listing 11: pom.xml - Loan Broker Projekt VII

10 1 Einführung Damit Unternehmen heutzutage wettbewerbsfähig bleiben, müssen sie ihre Prozesse immer mehr automatisieren. Um auf die Änderungen am Markt reagieren zu können, ist es unabdingbar, diese Prozesse ständig zu überwachen und zu überprüfen. Dadurch können Einsparmöglichkeiten rechtzeitig erkannt und umgesetzt werden. Die Anforderungen der IT innerhalb eines Unternehmens haben sich durch die zunehmende Globalisierung stark verändert. Die Aufgaben der IT bestehen darin, Unternehmen aktiv im globalen Wettbewerb zu unterstützen. Dazu gehören die Bereitstellung von Geschäftsfunktionen und Informationen im gesamten Unternehmen, sowie die Integration mit anderen Unternehmen. Ziel ist, die IT so flexibel wie möglich zu gestalten, damit die oft geforderten Veränderungen ohne größeren Aufwand umgesetzt werden können. Die Funktionen und Informationen dieser Softwaresysteme müssen innerhalb eines Unternehmens auch anderen Anwendungen zur Verfügung gestellt werden, damit maximale Effektivität, durch Vermeidung von doppelter Datenhaltung und Wiederverwendbarkeit der Geschäftsfunktionen, erreicht wird. Mit dieser Problematik befasst sich die Enterprise Application Integration (EAI). Um den Anforderungen einer EAI gerecht zu werden, verwenden viele Unternehmen den Ansatz einer Service Oriented Architecture (SOA). Innerhalb einer SOA werden Geschäftsfunktionen als lose gekoppelte Dienste zur Verfügung gestellt. Diese werden durch Kombination dazu verwendet, komplexe Geschäftsprozesse abzubilden. Durch die Unabhängigkeit können die einzelnen Dienste in beliebig vielen Prozessen wieder verwendet werden. Die Technologie zur Implementierung dieser Dienste, sowie die Plattform, sind frei wählbar. Ein Enterprise Service Bus (ESB) stellt die Infrastruktur für eine SOA dar. Mit Hilfe eines ESBs ist es möglich, Dienste in einer einfachen Art miteinander zu kombinieren. Durch den Einsatz eines ESBs werden EAI Projekte stark vereinfacht, da isolierte Anwendungen nach und nach durch eine standardbasierte Integration in eine SOA Umgebung eingebunden werden können. 1

11 Einführung - Aufgabenstellung 1.1 Aufgabenstellung Betrachtet man die Anforderungen von Integrationsszenarien, erkennt man, dass diese zum Teil direkt mit einem ESB umgesetzt werden können. Aus diesem Grund liegt es nahe Enterprise Integration Patterns (EIP) [2] mit der ESB-Technologie genauer zu vergleichen. Ziel der vorliegenden Arbeit ist es herauszufinden, inwieweit sich Enterprise Integration Patterns mit einem ESB umsetzen lassen. Es wird untersucht, welche Patterns bereits mit den Grundfunktionalitäten eines ESBs abgedeckt werden und welche mit Hilfe der vorhandenen Funktionalitäten entwickelt werden können. Überlegungen aus früheren Arbeiten von Bettina Druckenmüller [4] und Xin Yuan [5] zur Parametrisierung von EIPs sollen in die Untersuchung mit einbezogen werden. Die Ergebnisse des Vergleiches, sollen anhand eines praktischen Beispiels mit Hilfe eines Open-Source ESBs in die Praxis umgesetzt werden. Gleichzeitig soll diese Umsetzung als Grundlage für die Entwicklung eines Editors dienen, mit dem der ESB-Konfigurationscode für EIPs generiert werden kann. 1.2 Aufbau der Arbeit Die vorliegende Arbeit gliedert sich folgendermaßen: Kapitel 2 erläutert die erforderlichen Grundlagen. Enterprise Application Integration, das Konzept einer Message Oriented Middleware und die Architektur eines ESBs werden darin näher erläutert. Kapitel 3 beinhaltet die theoretischen Überlegungen. Auf Basis der in Kapitel 2 definierten Architektur eines ESBs, werden einzelne Patterns aus unterschiedlichen Bereichen genauer betrachtet und mit den ESB Funktionalitäten verglichen. Dabei werden die Parameter aus [4] und [5] in die Betrachtung miteinbezogen. Kapitel 4 bietet zunächst eine kurze Einführung in den verwendeten ESB und dessen integrierte Technologie. Anschließend steht die Umsetzung eines konkreten Beispiels, das Loan Broker Szenario, im Mittelpunkt. Dabei wird die Umsetzung jedes einzelnen Patterns, sowie die Gesamtlösung genauer betrachtet. Ebenfalls beinhaltet es Überlegungen für die automatische Generierung der ESB-Konfigurationen der Patterns. Abgerundet wird das Kapitel mit einem kurzen Abschnitt über das Deployment sowie die Administration des ESBs. Kapitel 5 bietet eine Zusammenfassung, sowie einen Ausblick auf weitere interessante Untersuchungen. Zusätzlich wird ein kurzer Vergleich zwischen der theoretischen Architektur und dem verwendeten ESB-Produkt aufgeführt. 2

12 2 Grundlagen Ziel dieses Kapitel ist es, die erforderlichen Grundlagen zu vermitteln, welche für die folgenden Abschnitte notwendig sind. Dabei wird zuerst eine kurze Einführung in Enterprise Application Integration gegeben und das Konzept einer Message Oriented Middleware erläutert. Der abschließende Teil des Grundlagen Kapitels zeigt eine im Detail erläuterte Architektur eines ESBs. 2.1 Enterprise Application Integration (EAI) Als Grundlage für dieses Kapitel diente hauptsächlich das Buch Enterprise Integration Patterns von Hohpe und Woolf [2]. In großen Unternehmen findet man heutzutage sehr viele unterschiedliche Anwendungen. Darunter gibt es Standardanwendungen, wie ERP (Enterprise Resource Planning) oder CRM (Customer Relationship Management) Systeme, selbst entwickelte Anwendungen bzw. Erweiterungen von Anwendungen oder erworbene Software von Drittanbietern. Alle laufen meist auf unterschiedlichen Plattformen und sind nicht darauf ausgelegt, mit anderen Anwendungen zu kommunizieren. Eine Ursache für eine nach Hohpe genannte Spaghetti Architecture [2] ist die Vielzahl an Funktionalität, die innerhalb eines Unternehmens benötigt wird. Es ist unmöglich, eine große Anwendung zu erstellen, welche alle benötigten Funktionalitäten abdeckt. Zudem ist es für Unternehmen wichtig, bei der Auswahl einer Anwendung nicht nur beispielsweise an einen Hersteller gebunden zu sein, sondern die beste auf das Unternehmen passende Software für jeden Bereich wählen zu können. Wenn Geschäftsprozesse abgebildet werden sollen, ist es nicht einfach alle benötigten Anwendungen zu koordinieren. Am Beispiel eines Buchungssystems, bei dem man Flüge, Mietwagen und Unterkunft buchen kann, werden nach Erhalt eines Buchungsauftrages verschiedene, beteiligte Systemen angesprochen. Dazu gehört die Überprüfung der Kundendaten, die Buchung der Flüge, der Hotels und Mietwägen, das Versenden der Bestätigung sowie das Erstellen der Rechnung, usw. Die bei diesem Prozess beteiligten Systeme sind zum einen innerhalb des Unternehmens bereitgestellt, welches die Anfragen verarbeitet, zum andern werden diese aber auch von anderen Unternehmen bereitgestellt. 3

13 Grundlagen - Enterprise Application Integration (EAI) An dieser Stelle sieht man deutlich den Bedarf von Integrationslösungen. Ein weiterer Grund für eine Integrationslösung ist, dass viele Funktionen, wie zum Beispiel Abrechnungsfunktionalitäten oder Kundenverwaltung in mehreren Anwendungen implementiert sind und gepflegt werden müssen. Ebenso werden Daten doppelt gepflegt, da es keine gemeinsame Datenbasis gibt Herausforderungen einer Integration Bei der Umsetzung einer Integrationslösung nimmt die technische Seite nur einen kleinen Teil ein. Auf dem Markt gibt es EAI-Suites von vielen Herstellern, welche bereits von Haus aus große Softwareprodukte unterstützen. Trotzdem darf man diesen Teil nicht unterschätzen, da es in den meisten Unternehmen viele sogenannte Legacy Anwendungen gibt, die oft nicht ohne großen Aufwand verändert werden können. Zudem gibt es weitere Schwierigkeiten, wie zum Beispiel politischer Art, da bei einer Integration nicht nur Computer miteinander verbunden werden, sondern auch Geschäftsbereiche und IT-Abteilungen. Die Anwendungen sind nach einer Integration Teil eines übergreifenden Geschäftsprozesses und dadurch haben die einzelnen Abteilungen oder Gruppen nicht mehr die volle Kontrolle über ihre Anwendungen. Ebenfalls bringt eine Integration ein hohes Maß an Risiko mit sich, da bei Fehlern, wie zum Beispiel falsch durchgeführte Zahlungen oder untergegangene Bestellungen, hohe Kosten entstehen können. Weitere Probleme sind die Fehlersuche, sowie die Überwachung. Anhand jahrelanger praktischer Erfahrung und zahlreichen EAI-Projekten zeichneten sich sechs Arten von Integrationstechniken ab: Informationsportale Datenreplikation Geteilte Geschäftsfunktionen Service Oriented Architecture (SOA) Verteilte Geschäftsprozesse Business-to-Business Integration Diese Liste kann natürlich nicht alle EAI-Projekte abdecken, doch bei einem Großteil der Projekte findet eine dieser Techniken oder eine Kombination von mehreren ihre Anwendung Integrationstopologien Bei der Umsetzung einer Integrationslösung gibt es drei verschiedene Möglichkeiten [17]. Eine davon ist die Point-to-Point Architektur (Abbildung 1). Bei dieser Variante werden alle Anwendungen direkt miteinander verbunden. Dies funktioniert aber nur bei einer sehr geringen Menge an Anwendungen, da sonst die Anzahl und somit der Wartungsaufwand der Schnittstellen schnell zu groß werden. Für die Anzahl der benötigten Schnittstellen gilt die Formel 4

14 Grundlagen - Enterprise Application Integration (EAI) (n*(n-1))/2, wobei n für die Anzahl der Anwendungen steht. Dadurch erschwert sich auch der Austausch von Anwendungen. Diese Lösung ist bei kleinen Umgebungen interessant, da sie geringe Startkosten hat. Die Folgekosten können unter Umständen aber immens hoch werden. Applikation 1 Applikation 3 Applikation 2 Applikation 4 Applikation 5 Abb. 1: Integrationstopologien Point-to-Point (Quelle: [17]) Abbildung 2 zeigt die zweite Variante, die Hub & Spoke Architektur. Hier gibt es eine zentrale Komponente (den Hub), welche sämtliche Informationen, die zwischen den Anwendungen ausgetauscht werden, empfängt, transformiert und weiterleitet. Die meisten erhältlichen EAI-Produkte basieren auf dieser Architektur mit einem zentralen EAI-Broker. Bei dieser Architektur kann bei sehr hohem Aufkommen der Hub zum Flaschenhals werden. Um diesem entgegenzuwirken, kann man mit mehreren Brokern die Last verteilen, wodurch aber die Administrationskosten steigen. Der Vorteil einer Hub & Spoke Architektur liegt darin, dass die Anzahl der Transformationen im Vergleich zur ersten Variante weniger ist, da man für jede Anwendung nur eine Transformation benötigt. Zudem können Anwendungen recht einfach ausgetauscht werden. Jede Anwendung wird über einen Adapter mit dem Broker verbunden, der die Daten der Anwendung an den Broker weiterleitet. Applikation 1 Applikation 3 Applikation 2 EAI Applikation 4 Applikation 5 Abb. 2: Integrationstopologien Hub & Spoke (Quelle: [17]) Bei der dritten Variante (Abbildung 3) werden die Anwendungen über einen Bus miteinander verbunden. Wie schon bei der Hub & Spoke Architektur erfolgt die Anbindung über einen Adapter. Der Hauptunterschied zur Hub & Spoke Architektur liegt darin, dass die Transformation und Weiterleitung der Daten von den Adaptern erledigt wird. Dadurch erhält man eine sehr verteilte Architektur, die dementsprechend auch schwieriger zu administrieren ist, aber dafür sehr 5

15 Grundlagen - Enterprise Application Integration (EAI) gut skaliert. Um die Daten zu transportieren, liegt der Bus Architektur ein zentrales Messaging System, welches den Bus darstellt, zugrunde. Diese Technologie wird im folgenden Kapitel erklärt. Applikation 1 Applikation 3 Applikation 2 Bus Applikation 4 Applikation 5 Abb. 3: Integrationstopologien Bus (Quelle: [17]) Ansätze für eine Anwendungsintegration In den letzten Jahren haben sich vier Ansätze zur Anwendungsintegration herausgebildet [2]: Dateitransfer Eine Anwendung erstellt eine Datei, welche eine andere Anwendung zu einem späteren Zeitpunkt liest. Beide müssen sich vorher über den Dateinamen, den Speicherort, das Format sowie den Zeitpunkt usw. einig sein. Gemeinsam verwendete Datenbank Mehrere Anwendungen einigen sich auf ein Datenbankschema und arbeiten auf einer physikalischen Datenbank. Remote Procedure Invocation Eine Anwendung stellt eine Funktionalität so zur Verfügung, dass andere Anwendungen diese in Echtzeit und synchron in Anspruch nehmen können. Messaging Eine Anwendung sendet eine Nachricht an einen Channel, die andere Anwendungen aus diesem Channel lesen können. Dabei müssen sie sich nur auf den Channel einigen. Die Kommunikation findet asynchron statt. Da einem ESB die Messaging-Technologie zugrunde liegt, wird in dieser Arbeit nur auf diesen Ansatz der Anwendungsintegration eingegangen. Im folgenden Kapitel werden die Funktionsweise und die dabei verwendete Technologie genauer erläutert. 6

16 Grundlagen - Message Oriented Middleware (MOM) 2.2 Message Oriented Middleware (MOM) Die Message Oriented Middleware stellt die Basis für einen ESB dar. Doch was ist eigentlich Messaging? Das folgende Kapitel geht genau dieser Frage nach und beleuchtet zudem die Technik Messaging Anhand eines Beispiels aus dem Bereich Telefonie [2] kann Messaging besser verstanden werden: Telefonieren ist eine synchrone Form der Kommunikation, dies bedeutet man kann nur mit jemand Anderem telefonieren, wenn dieser zur gleichen Zeit an seinem Telefon ist. Im Gegensatz dazu kann ein Anrufer, falls er den Empfänger nicht erreicht, eine Nachricht auf dem Anrufbeantworter hinterlassen. Bis diese Nachricht später vom Empfänger abgehört wird, bleibt sie auf dem Anrufbeantworter gespeichert. Bei einer synchronen Kommunikation müssen also Sender und Empfänger zur gleichen Zeit verfügbar sein, bei einer asynchronen nicht. Durch Messaging ist es möglich, Nachrichten zu versenden und weiterzuarbeiten, ohne auf eine Antwort des Empfängers zu warten (wenn das Weiterarbeiten nicht von der Antwort abhängig ist). Sender und Empfänger tauschen Informationen über Nachrichten (Messages) aus. Diese Nachrichten bestehen aus einem Header, der Meta-Informationen enthält und einem Body, der den eigentlichen Inhalt enthält. Für die Zustellung der Nachrichten an die richtigen Empfänger ist die MOM zuständig. Die Anwendungen kommunizieren mit dem Messaging System über einen vom Hersteller bereitgestellten Messaging Client. Für die Anbindung an den Messaging Client wird eine API verwendet. Dieser Gesamtzusammenhang wird in Abbildung 4 dargestellt. Was im dargestellten Beispiel der Anrufbeantworter ist, ist beim Messaging ein Channel. Ein Channel ist eine logische Adresse innerhalb eines Messaging Systems über den die beteiligten Anwendungen miteinander verbunden sind. Der Channel verhält sich ähnlich wie ein Array mit Nachrichten, welches aber von mehreren Anwendungen gleichzeitig verwendet werden kann und über mehrere Computer verteilt ist [2]. Ein wichtiger Aspekt innerhalb einer Messaging-Umgebung ist die lose Kopplung. Dieses Prinzip wird im Folgenden erklärt. Abb. 4: Nachrichtenbasierte Kommunikation (Quelle:[1]) 7

17 Grundlagen - Message Oriented Middleware (MOM) Lose Kopplung In einer Messaging Umgebung brauchen Anwendungen keine Details anderer, beteiligter Anwendungen zu kennen. Sie besitzen keine Kenntnis darüber, wie sie die Anwendung erreichen können oder mit welchen Parametern sie aufgerufen werden müssen. Aus diesem Grund bezeichnet man Anwendungen in einer solchen Umgebung auch als lose gekoppelt. Die Kommunikation zwischen eng gekoppelten Anwendungen ist dadurch, dass sie sehr viele Annahmen machen, sehr effizient und schnell, jedoch nicht robust. Remote Procedure Call (RPC) wurde lange Jahre in der Industrie verwendet, um Anwendungen zu integrieren. Bei der RPC-basierten Kommunikation ruft eine Anwendung eine Funktion einer anderen entfernten Anwendung auf. Dadurch ist klar, dass die RPC-basierte Kommunikation synchron stattfinden muss. In einer verteilten RPC-basierten Umgebung kann ein Funktionsaufruf innerhalb eines Prozesses mehrere Folgeaufrufe anderer Funktionen auslösen. Nur wenn alle Aufrufe erfolgreich waren, ist der gesamte Prozess erfolgreich, schlägt aber nur ein Aufruf fehl, ist der gesamte Prozess fehlgeschlagen. Dieses Szenario ist bei verteilten Anwendungen nicht ungewöhnlich. Sobald eine beteiligte Partei nicht erreichbar ist, kann keine Kommunikation stattfinden und die gesamte Aufrufkette schlägt fehl. Um in einem solchen Fall durchgeführte Änderungen wieder rückgängig machen zu können, muss jede Anwendung eine Fehlerbehandlung und Wiederherstellungs-Logik implementiert haben. Hierbei zeigt sich der große Vorteil von lose gekoppelten Anwendungen, denn dort kann bei einem Ausfall eine Anwendung den Aufruf zu einem späteren Zeitpunkt ausführen. Ebenfalls ist die Fehlerbehandlung und Wiederherstellungs-Logik zentral im Messaging System implementiert. Ein weiteres Problem der RPC-basierten Kommunikation ist die Anzahl der benötigten Schnittstellen. Da die Anwendungen direkt miteinander verbunden sind, benötigt man, um alle n Anwendungen miteinander zu verbinden, mindestens (n*(n-1))/2 Schnittstellen. Diese Anzahl verbessert sich bei der Kommunikation in einer Messaging Umgebung zu n und reduziert dabei den Aufwand und die Wartung der Schnittstellen enorm. Dadurch ist es auch wesentlich einfacher, Anwendungen zu entfernen oder neue hinzuzufügen MOM Konzept Wie bereits beschrieben, gibt es innerhalb einer Messaging Umgebung Sender und Empfänger von Nachrichten. Anwendungen können sowohl als Sender, als auch als Empfänger fungieren. Verbunden sind Sender und Empfänger über virtuelle Channels, für die es zwei Arten gibt, den Publish-Subscribe Channel und den Point-to-Point Channel. Diese werden im Folgenden genauer erläutert Channels Channels sind logische Adressen innerhalb des Messaging Systems. In einem Channel werden Nachrichten gespeichert und anderen Anwendungen zur Verfügung gestellt. 8

18 Grundlagen - Message Oriented Middleware (MOM) 1) Publish-Subscribe Channel Bei einem Publish-Subscribe Channel gibt es beliebig viele Empfänger einer Nachricht, also eine 1-Viele Semantik. Der Sender einer Nachricht weiß nicht, wie viele Empfänger seine Nachricht erhalten. Die Nachrichten werden über sogenannte Topics ausgetauscht. Ein Topic steht für ein bestimmtes Themengebiet oder einen bestimmten Bereich. Meist werden Topics hierarchisch aufgebaut, wenn die beteiligte MOM dies unterstützt. Abbildung 5 zeigt eine (unvollständige) Beispielhierarchie zum Thema Sport. Sport Fußball Basketball Tennis 1. Bundesliga 2. Bundesliga NBA BBL Abb. 5: Beispiel einer Topic Hierarchie Die Konsumenten registrieren sich für ein bestimmtes Topic, zu welchem sie Nachrichten empfangen möchten. Registriert sich zum Beispiel ein Konsument für das Topic Fußball aus Abbildung 5, erhält er alle Nachrichten zum Thema Fußball und alle Nachrichten zu den Themen 1. Bundesliga und 2. Bundesliga. Anwendung kann ein Publish-Subscribe Channel zum Beispiel bei einem Online-Versandhandel finden. Bei einer Bestellanfrage könnte das Versandhaus über einen Publish-Subscribe Channel allen verfügbaren Lieferanten eine Anfrage zu Verfügbarkeit und Lieferzeit zukommen lassen und auf Basis der Antworten den passenden Lieferanten auswählen. In Abbildung 6 ist der logische Aufbau eines Publish-Subscribe Channels grafisch dargestellt. Receiver Sender Topic Receiver Receiver Abb. 6: Publish-Subscribe Channel (Quelle: In Anlehnung an [35]) 2) Point-to-Point Channel Im Gegensatz zum Publish-Subscribe Channel, gibt es beim Point-to-Point Channel jeweils nur einen Empfänger. Es besteht also eine 1-1 Semantik. Diese Art von Channel wird verwendet, um Nachrichten nur an bestimmte Empfänger zu versenden. Die Nachrichten werden in sogenannten Queues zwischengespeichert und dem entsprechenden Empfänger zur Verfügung 9

19 Grundlagen - Message Oriented Middleware (MOM) gestellt. Ein Point-to-Point Channel ist logisch gesehen eine direkte Kopplung zweier Anwendungen. Abbildung 7 zeigt den Aufbau eines Point-to-Point Channels. Sender Point-to-Point Channel Receiver Abb. 7: Point-Point-Channel (Quelle: [3]) Grundprinzipien einer MOM Innerhalb einer Messaging Umgebung gibt es für die Kommunikation zwei Grundprinzipien: 1) Send and Forget Eine Anwendung, welche eine Nachricht an eine andere Anwendung versendet, kann nachdem sie die Nachricht an das Messaging System erfolgreich übergeben hat, die Nachricht vergessen. Das heißt, sie muss sich nicht mehr darum kümmern, dass die Nachricht den Empfänger erreicht, da die Zustellung das Messaging System übernimmt. Zudem braucht sie nicht zu warten, bis die Nachricht an den Empfänger übermittelt wurde und kann direkt weiterarbeiten. 2) Store and Forward Ein weiteres wichtiges Prinzip ist das sogenannte Store and Forward Prinzip. Dieses findet innerhalb des Messaging Systems statt, wie in Abbildung 8 zu sehen ist. Erhält das System eine Nachricht, wird diese zuerst (meistens in einem persistenten) Speicher gespeichert. Erst daraufhin wird dem Sender der Erhalt der Nachricht bestätigt. Dann wird die Nachricht an den Empfänger weitergeleitet und erst wenn dieser den Erhalt bestätigt, wird die Nachricht aus dem Speicher gelöscht. Dabei können zwischen Sender und Empfänger auch mehrere Messaging Server liegen, bei denen allen dieses Prinzip angewendet wird. In Abbildung 8 durchläuft die Nachricht zwei Messaging Systeme auf dem Weg zum Empfänger. Das Store and Forward Prinzip ist wichtig, da es garantiert, dass alle Nachrichten die gewünschten Empfänger erreichen. Meistens gibt es bei Messaging Systemen verschiedene Optionen für die Zustellung einer Nachricht, da es manche Nachrichten gibt, bei denen es nicht schlimm ist, wenn sie mal verloren gehen. Sender Messaging System Forward Messaging System Forward Receiver Store Store Abb. 8: Store and Forward Prinzip 10

20 Grundlagen - Enterprise Service Bus (ESB) 2.3 Enterprise Service Bus (ESB) Seit Aufkommen des Begriffes Enterprise Service Bus gab es viele Diskussionen darüber, wie genau ein ESB definiert wird. Ist es eine Architektur? Ein Produkt? Eine Hardware? Die Antwort auf alle drei Fragen ist vermutlich ja, da es keine eindeutige Definition für einen ESB gibt. Auf dem Markt sind tatsächlich schon Hardware-Produkte erhältlich, welche sehr viele der geforderten Funktionalitäten an einen ESB erfüllen. Die WebSphere DataPower SOA Appliances [21] von IBM zum Beispiel sind hauptsächlich für den Einsatz als XML und Web Service-Security Gateway gedacht [22]. Durch die begrenzte Erweiterbarkeit der Hardware-Funktionen sind sie für eine klassische Integration jedoch nicht geeignet. Aufgrund der großen Geschwindigkeit bei Transformationen und Routing, kann die Appliance auch als Co-Prozessor eingesetzt werden und den Durchsatz dadurch erhöhen [22]. Ein ESB bildet die Infrastruktur für eine SOA-Umgebung und steuert und kontrolliert die Kommunikation zwischen den einzelnen Diensten. Ebenfalls ist es die Aufgabe des ESBs Geschäftsdienste, zum Beispiel Buche Reise von implementierten Diensten, wie überprüfe Verfügbarkeit Hotel, überprüfe Kunde, usw. zu trennen [18]. Viele große Analystenhäuser entwickelten Definitionen für einen ESB, welche aber recht ungenau ausfielen. Nachfolgend werden zwei Beispiele solcher Definitionen dargestellt: 1) Forrester: Infrastructure software that makes reusable business services widely available to users, applications, business processes, and other services. ESBs achieve this goal by mediating between services. An ESB helps enterprises obtain the value of SOA by increasing connectivity, speeding change, and providing greater control over use of the important resources it binds [23]. 2) Gartner: An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow. (Source: Roy Schulte, Gartner) [18] Da es für einen ESB offensichtlich keine eindeutige Definition gibt, wird dieser über seine Fähigkeiten definiert. Dabei unterscheidet man zwischen Grundfunktionalitäten, die jeder ESB beinhalten muss und erweiterten Funktionalitäten, welche ein ESB beinhalten kann. Alle Funktionalitäten, sowie eine Übersicht der Grundanforderungen eines ESBs werden im folgenden Abschnitt aufgezeigt. 11

21 Grundlagen - Enterprise Service Bus (ESB) ESB Funktionalitäten Message Oriented Middleware (MOM) Einem ESB liegt ein robustes Messaging System zugrunde, welches dafür sorgt, dass die Nachrichten schnell und zuverlässig zwischen den Anwendungen übertragen werden. Die Konzepte einer MOM wurden bereits in 2.2 genauer erläutert. Eine MOM sollte mehrere Kommunikationsarten unterstützen. Dies können je nach Anforderung zum Beispiel ereignisbasiertes Publish-Subscribe, synchrone und asynchrone Dienstaufrufe sein [10]. Intelligentes Routing Das Routen von Nachrichten mit deklarativen Regeln, basierend auf dem Inhalt und dem Kontext der Nachrichten, muss vollständig vom ESB übernommen werden. Dadurch ist es auch möglich, dass ein ESB im Fehlerfall die Routingregeln dynamisch ändert und Nachrichten anders weiterleitet [11]. Ebenfalls sollte ein sogenanntes itinerary-based-routing unterstützt werden. Diese Art von Routing ist zu vergleichen mit einer Reiseroute, auf der alle Stationen der Route vermerkt sind. Die Nachricht wird anhand der Route weitergeleitet [1]. Message Transformation Da jede Anwendung andere Anforderungen an das Datenformat stellt, ist es erforderlich, die Nachrichten zu transformieren. Ein bekanntes Beispiel ist der Unterschied zwischen dem Datumsformat in Europa und in den USA. Dadurch kann gewährleistet werden, dass jede Anwendung Daten so erhält, wie sie es verlangt, ohne sich selbst darum kümmern zu müssen. Für XML basierte Nachrichten kann bei einfachen Transformationen zum Beispiel die Sprache XSL Transformation (XSLT) [30] verwendet werden. In [12] wird dazu angemerkt, dass bei komplexen, zeitkritischen Transformationen zusätzliche Transformationsmöglichkeiten nötig sind. Ebenfalls müssen oft 1-zu-viele und viele-zu-1 Transformationen von XML Nachrichten unterstützt werden, was aber seit XSLT 2.0 ebenfalls möglich ist. Protokoll-Transformation Eine wichtige Funktionalität eines ESBs ist die Fähigkeit, von einem Transportprotokoll in ein anderes, zu übersetzen. Zum Beispiel kann eine Anwendung mit dem ESB via Simple Object Access Protocol (SOAP) über HTTP kommunizieren, um eine andere Anwendung aufzurufen. Der ESB kann die Zielanwendung zum Beispiel über Java Message Service (JMS) [33] ansprechen [7]. Welche und wie viele verschiedene Protokolle unterstützt werden, hängt vom jeweiligen Hersteller und dem Einsatzgebet eines ESBs ab. Es sollten aber die gängigsten Standardprotokolle unterstützt werden. Sicherheit In einer SOA-Umgebung sollte es natürlich auch die Möglichkeit geben, die Nutzung gewisser Dienste einzuschränken. Dies bedeutet, es muss 12

22 Grundlagen - Enterprise Service Bus (ESB) eine Möglichkeit geben, Richtlinien zu definieren und zu verwalten [10]. Dies kann entweder über eine zusätzliche Komponente geschehen oder der ESB wird in eine bestehende Sicherheits-Infrastruktur eingebunden. Es muss in jedem Fall die Möglichkeit einer Authentifizierung und Autorisierung von Diensten gegeben sein. Quality of Service Um kritische Geschäftsfunktionen in einer SOA-Umgebung verwenden zu können, muss gewährleistet sein, dass zum einen alle Nachrichten bei den Empfängern ankommen und nicht verloren gehen können. Dies wird durch die darunterliegende MOM garantiert. Zum andern muss ein ESB zum Beispiel beim Ausfall eines Dienstes Anfragen auch an andere redundante Dienste umleiten können. Diese benötigten Fähigkeiten sind vor allem im Rahmen von Service Level Agreements (SLA) unabdingbar [10]. Transaktionen Da Standards für Transaktionen in einer SOA-Umgebung nicht vollständig ausgereift sind, ist dieser Bereich bei ESBs immer noch in der Entwicklungsphase. Ein ESB wird nicht die volle Funktionalität eines TP- Monitors oder Application Servers erreichen, kann jedoch ein Framework bereitstellen, um beispielsweise fehlgeschlagene Transaktionen wieder rückgängig zu machen [10]. Management Innerhalb des Managements eines ESBs gibt es drei wichtige Bereiche [11]: Administration / Deployment Überwachung Systemaktionen Das Management umfasst die Administration und das Deployment der Dienste, die über einen ESB kommunizieren möchten. Die Überwachung und auch die Protokollierung sind ebenfalls ein wichtiger Bestandteil der Management-Funktionalität. Dabei kann die Performance der Dienste überprüft werden, aber auch ob SLAs zwischen den verschiedenen Diensten eingehalten werden. Zusätzlich bietet das Management die Möglichkeit, die Dienste beispielsweise neu zu starten oder zurückzusetzen. Das Management ist eine sehr wichtige Komponente, da eine so verteilte Infrastruktur sehr komplex und schwierig zu verwalten ist und die Fehlersuche ansonsten fast unmöglich wäre. Service Orchestrierung Um komplexe Prozesse abbilden zu können, benötigt man innerhalb eines ESBs die Möglichkeit, mehrere Dienste miteinander zu verbinden. Die zusammengesetzten Dienste stellen dann wieder einen neuen 13

23 Grundlagen - Enterprise Service Bus (ESB) Dienst dar. Die populärste Form dieser Funktionalität ist eine Erweiterung des ESBs um eine BPEL basierte Laufzeitumgebung. Ein ESB muss nicht alle Funktionalitäten beinhalten und auch nicht in vollem Funktionsumfang. Zusätzlich kann er weitere Fähigkeiten besitzen, welche hier nicht aufgezählt wurden. Aus diesem Grund gibt es gewisse Mindestanforderungen, die ein ESB erfüllen muss. Diese sind in der folgenden Tabelle dargestellt: Kommunikation Routing Adressierung von Diensten Mindestens ein Messaging- Paradigma (z.b. request/response oder publish/subscribe) Unterstützung für mindestens ein Transportprotokoll, welches größtenteils verfügbar ist oder verfügbar gemacht werden kann Integration Unterstützung vieler Integrationsarten für die Dienstanbieter, wie zum Beispiel Web Services, Adapter, Java 2 Konnektoren, usw. Ermöglicht Ortstransparenz und den Austausch von Diensten Dienst-Interaktion Unterstützung eines Interface- Beschreibungsformats und dem dazugehörigen Messaging Modell (z.b. Web Service Description Language (WSDL) und SOAP), um den Anwendungscode von der Dienst-Interaktion zu trennen. Management Administrationsmöglichkeit über die gesamte verteilte Infrastruktur, um Routing, Transformationen, Adressierung, usw. zu konfigurieren. ermöglicht ebenfalls den Austausch von Dienst-Implementierungen. Tabelle 1: Mindestanforderungen eines ESBs (Quelle: In Anlehnung an [13] u. [14]) Architektur eines ESBs Nachdem im letzten Abschnitt die Funktionalitäten eines ESBs definiert wurden, werden in diesem Kapitel die einzelnen Komponenten einer ESB Architektur genauer erklärt. Ein ESB ist ein auf offenen Standards basierender Messaging Backbone, der designt wurde, die Implementierung, das Deployment und Management von SOA-basierten Lösungen zu ermöglichen [8]. Die Architektur eines ESBs konzentriert sich auf den Bus. Der Bus unterstützt die Nachrichtenübermittlung 14

24 Grundlagen - Enterprise Service Bus (ESB) auf Basis vorhandener Standards, wie SOAP, HTTP oder JMS. Er ist auf einen hohen Durchsatz ausgelegt und garantiert die Zustellung aller Nachrichten. Dies ermöglicht die in Kapitel 2 vorgestellte Messaging Middleware, die dem ESB zugrundeliegt. Ein ESB sollte aus diesem Grund auch mit unterschiedlichen Messaging Systemen kompatibel sein, da oftmals vor der Einführung eines ESBs, bereits ein Messaging System vorhanden ist oder das mitgelieferte System nicht die gewünschte Funktionalität bietet. Ferner ermöglicht ein ESB die Nutzung mehrerer Protokolle (synchron, wie auch asynchron) und führt Transformationen und Routingoperationen auf den Dienstanfragen durch [14]. Dabei unterstützt ein ESB eine Menge unterschiedlicher Standards, wie SOAP, XML, WSDL, JMS, J2EE, JAX-RPC, usw. In Abbildung 9 ist eine vereinfachte Darstellung eines ESBs zu sehen, welcher unterschiedliche Anwendungen mit unterschiedlichen Technologien miteinander verbindet. Abb. 9: vereinfachte Darstellung eines ESB (Quelle: [8]) Die Hauptfunktion eines ESBs ist die Virtualisierung, wie in [9] für einen Service Bus im Web Service Umfeld beschrieben ist. Da alle Dienste mit einer Interfacebeschreibungssprache wie WSDL beschrieben sind, versteckt der ESB die Implementierungsdetails eines Dienstes vor den Konsumenten. Dies umfasst Dinge wie die Programmiersprache, den Applikations-Server, der den Dienst hostet oder das darunterliegende Betriebssystem. Um eine Anfrage an einen Dienst zu senden, muss man sich dadurch nur an die entsprechende Interfacebeschreibung halten und die erforderlichen Daten senden. Der ESB kümmert sich dann darum, den angeforderten Dienst aufzurufen und die Daten zu übergeben [9]. Die wichtigste Eigenschaft eines ESBs ist seine Fähigkeit, als höchst verteilte Infrastruktur agieren zu können. Die drei Komponenten, welche am meisten dazu beitragen, dass der ESB so verteilt ist, sind der Gebrauch abstrakter Endpunkte, die internetfähige MOM und ein verteilter leichtgewichtiger Service Container. Diese drei Komponenten werden in den nächsten Abschnitten genau beschrieben. Die folgenden Abschnitte wurden größtenteils auf Basis des Buches Enterprise Service Bus von David A. Chappell [1] erstellt. 15

25 Grundlagen - Enterprise Service Bus (ESB) Abstrakte Endpunkte Aus der Sicht eines Integrationsarchitekten werden alle Anwendungen und Dienste als abstrakte Endpunkte gesehen. Ein Endpunkt kann zum Beispiel eine Operation zur Berechnung von Versandkosten darstellen. Die Implementierung des Endpunktes kann ein lokales Binding an einen Anwendungsadapter oder der Aufruf eines externen Web Services sein. Durch diese Abstraktion ist es für einen Architekten möglich, auf einer höheren Ebene die Dienst-Endpunkte miteinander zu verbinden, um Prozesse zu modellieren. Dabei kann ein Endpunkt zum Beispiel eine eigenständige, monolithische Anwendung sein, eine Anwendungssuite oder ein ERP System. Es kann ebenso eine vorhandene Integrationslösung auf Basis eines Brokers oder ein Interface zu einem Geschäftspartner (Business to Business (B2B)) sein. Alles, was mit dem ESB verbunden ist, wird als abstrakter Endpunkt angesehen. Um die im weiteren Verlauf der Arbeit verwendeten Diagramme und Zeichnungen zu verstehen, zeigt Abbildung 10a die Darstellungsweise eines generischen Endpunktes mit den einzelnen Bestandteilen. Abbildung 10b stellt einen Web Service Endpunkt dar. Abb. 10a: generischer ESB Endpunkt (Quelle: [1]) Abb. 10b: Web Service Endpunkt (Quelle: [1]) Messaging Einem ESB liegt ein hochgradig skalierbarer Messaging Backbone zugrunde, der Nachrichten sicher und zuverlässig in asynchroner Form transportiert. Die Details eines solchen Messaging Systems wurden bereits in Kapitel 2.2 genauer beschrieben. Als Messaging System kann eine proprietäre MOM, eine MOM basierend auf JMS oder WS-Reliability [37] und WS-ReliableMessaging 16

26 Grundlagen - Enterprise Service Bus (ESB) [38] dienen. Alternativ kann es auch eine generische Messaging-Engine sein, welche eine Kombination aus den oben genannten darstellt. Abbildung 11 zeigt den Zusammenhang noch einmal grafisch. Ein ESB erlaubt es, das darunterliegende Protokoll zu variieren, abhängig vom Deployment und den Quality of Services Anforderungen. Als Protokoll kann zum Beispiel das unzuverlässige HTTP oder WS-Rel* oder ein proprietäres MOM Protokoll verwendet werden. Durch die Abstraktionsschicht eines Dienst- Endpunktes ist es ohne weiteres möglich, dass darunterliegende Protokoll im Laufe der Zeit zu ändern. Es ist die Aufgabe des ESBs die, auf höherer Ebene vom Integrationsarchitekten erstellten, Prozesse auf die einzelnen Dienstaufrufe abzubilden. Da ein ESB die Möglichkeit bieten muss, dass Anwendungen sich auf mehrere verschiedene Arten mit ihm verbinden können, müssen meist keine großen Änderungen an der Anwendung vorgenommen werden. Dies wäre ohnehin nicht möglich, wenn man die Anzahl der, in einem Unternehmen vorherrschenden und ständig neuentwickelten, Anwendungen bedenkt. Daher ist das Motto für eine ESB Anbindung: If you can t bring the application to the bus, bring the bus to the application [1]. Abb. 11: Kernkomponente des ESB Enterprise Messaging (Quelle: [1]) 17

27 Grundlagen - Enterprise Service Bus (ESB) Service Container Eine der wichtigsten Eigenschaften eines ESBs ist die Verwendung des Service Container Modells. Ein Service Container ist die physikalische Erscheinung eines abstrakten Endpunkts und beinhaltet ebenfalls die Interfacebeschreibung des Dienstes. Der Service Container regelt den Nachrichtenfluss zu einem Dienst hin und von ihm weg. Dafür gibt es einen sogenannten Entry und einen Exit Endpunkt. Zusätzlich bietet er die Möglichkeit eines Auditing und einer Protokollierung als Teil der in Kapitel beschriebenen Management Funktionalität. Durch diese Funktionalität ist es möglich, verschiedene Systeminformationen, zum Beispiel über den Zustand des Dienstes oder die Art des Nachrichtenflusses, zu erhalten. Um zusätzlich eine Überwachung und Protokollierung auf Anwendungsebene durchzuführen, bietet der Service Container weitere Endpunkte an: einen Tracking, einen Fault und einen Rejected Message Endpunkt. Diese sind in Abbildung 12 dargestellt. Ein Dienst erhält eine Nachricht über den Entry Endpunkt und nachdem er mit der Bearbeitung fertig ist, wandert die Ausgangsnachricht einfach in den Exit Endpunkt. Von dort aus wird sie dann an das nächste Ziel transportiert. Um die Ausgangsnachrichten einer Anwendung zum Beispiel auf Korrektheit zu überprüfen, kann man den Tracking Endpunkt so konfigurieren, dass jede Ausgangsnachricht nicht nur in den Exit Endpunkt, sondern auch in den Tracking Endpunkt wandert. Von dort aus kann sie zur Kontrolle an einen Kontrolldienst weitergeleitet werden. Der Rejected Message Endpunkt wird dafür benutzt, Systemfehler, wie zum Beispiel ein ungültiges XML Dokument, an einen zuständigen Dienst weiterzuleiten. Dies betrifft hauptsächlich Nachrichten, welche vom Messaging System zugestellt werden können, aber bei der Verarbeitung durch den Dienst einen Fehler verursachen. Der Fault Ausgang dient dazu, alle auf Anwendungsebene auftretende Fehlermeldungen oder sonstige Fehler weiterzuleiten. Entry Exit Rejected message Fault Tracking Tracking Abb. 12: Endpunkte eines Service Containers (Quelle: [1]) Folglich lässt sich feststellen, dass der Service Container der ESB ist, denn dieser beinhaltet fast alle Funktionalitäten, die in Kapitel beschrieben wurden, wie in Abbildung 13 zu sehen ist. 18

28 Grundlagen - Enterprise Service Bus (ESB) Abb. 13: Service Container Funktionalitäten (Quelle: [1]) In diesem Framework ist zum Beispiel das Kommunikations-Management enthalten, in welchem die Protokolle usw. zur Anbindung an die MOM definiert sind. Ebenso gibt es das Lifecycle Management, über welches das Herunterfahren oder Hochfahren der Dienste initiiert werden kann. Um die Fähigkeit, Dienste zu finden, Nachrichten zu routen oder andere Dienste aufrufen zu können, braucht sich ein Dienst nicht selbst zu kümmern. Dies wird ebenfalls vom Service Container übernommen. Auch können über den Service Container Quality of Service Anforderungen festgesetzt werden, wobei diese meistens an die darunterliegende MOM delegiert werden. In [8] werden folgende Hauptfunktionen des Service Containers aufgeführt: Aufbau einer Verbindung und Unterstützung von Message Exchange Patterns (MEP) Unterstützung und Bereitstellung von Werkzeugen für Transaktionen, Sicherheit, Leistungsmessung, usw. in deklarativer Form Unterstützung einer dynamischen Konfiguration Möglichkeit Überwachungs-Daten des Systemverhaltens und Statusmeldungen an ein Management-System weiterzuleiten Durchführen von Daten- und Protokoll-Anpassungen Unterstützung für das Auffinden von Diensten Ein Service Container muss eine Management Schnittstelle implementieren, um die jeweiligen Funktionalitäten konfigurieren zu können. Unterstützt der ESB Java, kann diese Schnittstelle zum Beispiel mit Hilfe der Java Management extensions (JMX) [36] implementiert werden. 19

29 Grundlagen - Enterprise Service Bus (ESB) Um einen Service Container zu administrieren, wird vom jeweiligen Hersteller meistens ein Administrationstool mitgeliefert. Dieses kann eine grafische Oberfläche, ein kommandozeilenbasiertes Tool oder auch eine administrative API sein. Dies hängt vom jeweiligen Hersteller ab. Es ist nicht möglich zu sagen, dass eine Methode besser als eine andere ist, da es immer auf den geplanten Einsatz ankommt. Die Möglichkeit der Administration per Kommandozeile kann zum Beispiel eine gute Wahl bei der Automatisierung von Prozessen mit Hilfe von Skripten sein. Eine API ist hilfreich, wenn man einen ESB in eine vorhandene Umgebung integriert, in der es schon Administrationstools gibt. Die vollständige Darstellung eines Service Containers mit seinen Administrations- und Konfigurationsmöglichkeiten zeigt Abbildung 14. Abb. 14: Service Container Management (Quelle: [1]) Der Service Container hat eine gewisse Ähnlichkeit mit einem Application Server Container, da beide die Basis bilden, um Software-Komponenten darin zu deployen. Im Gegensatz zu Integrationslösungen mit Application Servern muss bei einem ESB jedoch nur der Service Container und nicht ein vollständiger Server installiert werden. Dabei kann ein Service Container entweder einen einzelnen Dienst oder mehrere Dienste zusammen hosten. Durch mehrere Dienste in einzelnen Containern und mehreren Containern mit mehreren Diensten in einer ESB Umgebung, besitzt ein ESB eine sehr flexible Möglichkeit zu skalieren, um große Datenmengen schnell verarbeiten zu können (Abbildung 15). 20

30 Grundlagen - Enterprise Service Bus (ESB) Abb. 15: Service Container Skalierbarkeit (Quelle: [1]) Das Service Container Modell ist ein rein abstraktes Modell und kann auf viele verschiedene Art und Weisen umgesetzt werden. Für die Darstellung der einzelnen Funktionalitäten eines ESBs ist es jedoch gut geeignet. Nahezu detailgetreu wurde der SonicESB von Progress Software umgesetzt. Dies liegt aber auch daran, dass David A. Chappell der Vizepräsident und Chefarchitekt im Bereich SOA bei Progress Software ist. Viele andere Produkte weisen dieselben Möglichkeiten auf, basieren jedoch auf einer völlig unterschiedlichen Architektur Directory Service In Abbildung 14 sieht man noch eine weitere Komponente, welche eine wichtige Rolle innerhalb eines ESBs spielt, nämlich den Directory Service, auch Registry genannt. Der Directory Service beinhaltet zum einen sämtliche Metadaten der Dienste, also die Konfiguration, die Funktionalität, die Art, wie ein Dienst aufgerufen werden kann und wer ihn aufrufen darf. Zum andern werden dort Transformationsregeln, Routingregeln usw. gespeichert. Ein Service Container kann zusätzlich noch Zugriff auf einen lokalen Directory Cache haben, in welchem immer die aktuellsten Konfigurationsparameter gespeichert sind. Dadurch kann ein Dienst weiterarbeiten, auch wenn kurzfristig der Directory Service nicht mehr erreichbar sein sollte. [15] geht bei der Anforderung an eine Registry noch einen Schritt weiter, indem er in der Registry ein Domänen Modell hinterlegt. In einem Domänen Modell werden alle Objekte innerhalb eines bestimmten Bereichs zusammen mit ihren Beziehungen zueinander beschrieben. Dadurch wird der ESB um eine Semantik-Komponente erweitert. Dadurch können auch komplexere Ontologien, zum Beispiel in der Web Ontology Language (OWL) beschrieben, abgebildet werden. 21

31 Grundlagen - Patterns Nach [15] sollte eine Registry zum Beispiel folgende Fähigkeiten beinhalten: Such- und Management-Funktionalität für Metainformationen über Interfaces und Funktionalitäten existierender Anwendungen, welche in einer Integrationslösung verwendet werden können. Management-Funktionalität von Metainformationen der Dienste. Dies beinhaltet WSDL- und WS-Policy-Deklarationen, sowie in der Business Process Execution Language (BPEL) definierte Prozesse im Web Service Umfeld. Management von Domänenmodellen Abgrenzung ESB zu anderen EAI-Technologien Hinter dem ESB Ansatz stecken zwei grundsätzliche Ideen: die lose Kopplung der Systeme, die in einem Integrationsszenario beteiligt sind und das Aufbrechen der Integrationslogik in klare, einfach zu verwaltende Teile [25]. Traditionelle EAI-Broker verwenden meistens eine Hub-and-Spoke Architektur. Diese hat den Vorteil, dass sich sämtliche Funktionen, wie Management, Routing-Logik, Regeln, usw. an einer zentralen Stelle befinden. Dadurch vereinfacht sich die Verwaltung einer solchen Software immens, jedoch skaliert diese Lösung nicht sehr gut. Wird die Menge an Nachrichten und verbundenen Anwendungen zu groß, hat man nur die Möglichkeit, die darunterliegende Hardware zu erweitern. Durch den Einsatz von mehreren miteinander verbundenen Brokern kann dem entgegengewirkt werden, wobei man aber an einen Hersteller gebunden ist, da man unterschiedliche Broker nicht ohne weiteres miteinander verbinden kann. Dies ist ebenfalls ein großes Problem bei unternehmensübergreifenden Integrationen. Der Großteil der heute verfügbaren EAI-Broker wurde zu einer Zeit entwickelt, in der es noch recht wenige Standards gab. Aus diesem Grund sind diese Lösungen nach heutigem Stand sehr proprietär [1]. Dies verursacht größere Kosten und längere Entwicklungszeiten. Im Unterschied zu einem EAI-Broker mit seiner zentralisierten, monolithischen und proprietären Architektur, stellt der ESB eine höchst verteilte, standardbasierte Lösung dar [1]. 2.4 Patterns Das Konzept der Patterns wurde 1977 von dem richtigen Architekten Christopher Alexander eingeführt. In Büchern, wie Design Patterns [26], Pattern Oriented Software Architecture [27], J2EE Patterns [28] und Enterprise Application Architecture [29] wurde das Konzept der Patterns auf Programmiertechniken abgebildet und dadurch bekannt gemacht. Grundsätzlich ist es nicht neu in Patterns zu denken, denn dies wird im realen Leben recht oft gemacht, was sich am Beispiel eines Fußballspiels zeigen lässt. Jedes Bewegungspattern eines einzelnen Spielers ist wieder Teil eines großen übergreifenden Patterns, welches alle Spieler einer Mannschaft enthält. Dieses 22

32 Grundlagen - Patterns übergreifende Pattern dient der Orchestrierung der Spieler, darin hat jeder Spieler klar definierte Verantwortungen und Bereiche. Diese unterschiedlichen Patterns machen ein Fußballspiel erst interessant [24]. Ein Pattern dokumentiert die Lösung einer bestimmten Klasse von Problemen. Dabei ist anzumerken, dass die Lösungsbeschreibungen keine Copy-and-Paste Beispiele sind [3]. Vielmehr beschreibt ein Pattern, warum ein Problem schwierig ist, welche Lösungsansätze nicht funktionieren, weshalb diese nicht funktionieren und warum die vorgeschlagene Lösung die beste ist. Außerdem sollten Patterns auch aufeinander verweisen, um von Problem zu Problem zu wandern. Dadurch ist es möglich, Lösungen zu finden, die anfangs noch nicht berücksichtigt wurden [2]. Ein Pattern sollte wie folgt aufgebaut sein [2]: Name Icon Um mehrere Patterns in einem Diagramm miteinander zu verbinden Context Beschreibt welche Art von Aufgabe das Problem ausgelöst hat Problem Schwierigkeiten des Problems in Frageform Forces Erklärt warum das Problem so schwierig ist Solution Beschreibt, was zu tun ist, um das Problem zu lösen Sketch Stellt die Lösung des Problems grafisch dar Results Beschreibt im Detail, wie die Lösung umgesetzt wird Next Beziehungen zu anderen Patterns Sidebars Variationen des Patterns Examples Enterprise Integration Pattern (EIP) Enterprise Integration Patterns wurden definiert, um bei zukünftigen EAI- Projekten darauf zurückgreifen zu können. Die Patterns entstanden direkt aus den Erfahrungen der durchgeführten Integrationsprojekte. Das wahrscheinlich bekannteste Buch ist von Gregor Hohpe und Bobby Woolf mit dem Titel Enterprise Integration Patterns [2]. Dieses Buch hat sich zum Standardwerk für EIPs entwickelt. Die darin enthaltenen Patterns bauen hierarchisch aufeinander auf, wie in Abbildung 16 zu sehen ist. Je tiefer man in dieser Hierarchie geht, 23

33 Grundlagen - Patterns desto detailliertere Patterns findet man. Die weiter oben liegenden Patterns bilden die Grundlage für die weiter unten liegenden Patterns. Wie man in Abbildung 16 sieht, basieren alle Patterns auf der Messaging Technologie. In dieser Arbeit werden die Patterns auf der untersten Ebene verwendet. Aus jedem Teilbereich, bis auf Message Construction werden mehrere Patterns in den Vergleich in Kapitel 3 mit einbezogen. Abb. 16: Pattern Hierarchie (Quelle: In Anlehnung an [2]) Parametrisierte EAI Patterns Um aus Patterns, wie in beschrieben, ausführbare Patterns zu erhalten, müssen diese parametrisiert werden. In [6] wird ein Framework zur Konfiguration von EAI Patterns eingeführt, um darauf aufbauend ein Mapping zwischen den Patterns und verschiedenen Technologien erstellen zu können. Ziel ist es, die Patterns auszuführen. Ein Mapping auf BPEL und Web Services wurde bereits in [4] und [5] ausgearbeitet und umgesetzt. Dadurch kann aus einigen EIPs automatisiert BPEL Code erzeugt werden. Innerhalb dieser Arbeit soll das Mapping der Patterns auf einen ESB untersucht werden und ebenfalls die Grundlage für eine weitere Ausarbeitung eines automatisierten Mappings geschaffen werden. 24

34 3 ESB Architektur zur Unterstützung von EIPs In diesem Kapitel wird, auf Basis der in Kapitel 2 beschriebenen Architektur eines ESBs untersucht, in wie weit die Patterns aus [2] mit einem ESB umgesetzt werden können. Dabei wird unterschieden, ob es sich mit den vorhandenen Funktionalitäten eines ESBs umsetzen lässt oder der ESB erweitert werden muss. Es wird zuerst die Funktionsweise der Patterns erklärt und anschließend, wie das jeweilige Pattern mit einem ESB umgesetzt werden kann. Danach wird ein kurzes Fazit zur Umsetzung gegeben. Für die benötigten Parameter der einzelnen Patterns wurden die Arbeiten [4] und [5] als Grundlage verwendet. Darin wurde ein Großteil der Patterns aus [2] auf abstrakter Ebene parametrisiert. 3.1 Patterns Die im Folgenden untersuchten Patterns sind nach verschiedenen Bereichen aufgeteilt. Hierbei wird zwischen Messaging Endpoints, Messaging Channels, Message Routing, Message Transformation und System Management Patterns unterschieden. Da die Betrachtung aller Patterns aus [2] den Rahmen dieser Arbeit gesprengt hätte, wurde versucht, aus jedem Bereich die wichtigsten und interessantesten Patterns auszuwählen. Die Auswahl aus [4] ist als Grundlage herangezogen worden, da die dort definierten Parameter mit in die Betrachtung einfließen sollten Message Construction Die Patterns aus diesem Bereich beziehen sich alle auf den Aufbau und den Inhalt einer Nachricht. Da es bei der Arbeit mit einem ESB egal ist, welcher Nachrichtentyp verwendet wird, sind diese Patterns hier nicht von Interesse. Innerhalb des ESB muss lediglich der jeweils verwendete Nachrichtentyp definiert werden. Mehr über die einzelnen Patterns kann bei Interesse in [2] nachgelesen werden. 25

35 ESB Architektur zur Unterstützung von EIPs - Patterns Messaging Endpoints Die Patterns aus dem Bereich Messaging Endpoints sind fast alle von der verwendeten ESB Implementierung und dem verwendeten Messaging System abhängig. Dabei sind zum einen die Integrationsmöglichkeiten des Messaging Systems, sowie die Implementierung des Messaging Clients entscheidend. Basieren beide auf Standards, sollte es problemlos möglich sein, zwei Produkte von unterschiedlichen Herstellern miteinander zu verwenden. Um die Kommunikation zwischen ESB und Messaging System kümmert sich, wie bereits in Kapitel 2 erwähnt, der Service Container. Dies bedeutet, dass innerhalb des Service Containers in irgendeiner Form ein Messaging Client implementiert sein muss. Martin Breest hat in seiner Arbeit [16] einen Service Container um diese Komponente grafisch erweitert, wie in Abbildung 17 zu sehen ist. In diesem Abschnitt werden also hauptsächlich Anforderungen an das Messaging System und den Messaging Client definiert. Abb. 17: Service Container mit Messaging Client (Quelle: [16]) Polling Consumer Ein Polling Consumer dient dazu, den Channel auf neue Nachrichten zu überprüfen. Aufgrund des Blockierens des Polling Consumer Prozesses, solange auf eine Nachricht gewartet wird, nennt man ihn auch einen synchronen Empfänger. Der Einsatz eines Polling Consumers empfiehlt sich bei Anwendungen, welche sehr viele Nachrichten erhalten. Durch die Verwendung können diese die Anzahl der gleichzeitig zu verarbeitenden Nachrichten steuern. Ist die Anwendung bereit für eine neue Nachricht, überprüft der Polling Consumer den Channel. Dabei wird entweder eine Nachricht empfangen oder die Abfrage durch einen Timeout abgebrochen. Dadurch wird gewährleistet, dass Nachrichten nur verarbeitet werden, wenn die Anwendung es fordert. 26

36 ESB Architektur zur Unterstützung von EIPs - Patterns ESB Um einen Polling Consumer zu verwenden, muss der im Service Container implementierte Messaging Client dies unterstützen. Ist dieser zum Beispiel in JMS implementiert, gibt es drei Methoden Nachrichten synchron abzufragen: receive () Wartet solange bis eine Nachricht vorhanden ist receivenowait () Überprüft einmal den Channel und gibt entweder die Nachricht oder null zurück receive (long) gleich wie receive (), nur mit einem Timeout Bei der Konfiguration des Service Containers muss es die Möglichkeit geben, die synchrone Abfrage auszuwählen. Zusätzlich muss die Auswahl der Methode mit Parametern zur Verfügung stehen. Für dieses Pattern gibt es demnach nur einen allgemeinen Parameter, die Methodenauswahl. Fazit Die Umsetzung eines Polling Consumers hängt gänzlich vom integrierten Messaging Client ab, der diese Variante der Nachrichtenverarbeitung unterstützen sollte Event-Driven Consumer Im Gegensatz zum Polling Consumer wird der Event-Driven Consumer vom Messaging System aufgerufen, sobald eine Nachricht vorhanden ist. Daher bezeichnet man diese Art von Empfänger auch als asynchron. Der Code eines Event-Driven Consumers besteht aus zwei Teilen: Initialisierung Wurde dieser Teil einmal ausgeführt, ist der Consumer bereit, Nachrichten zu empfangen. Verarbeitung Dieser Teil ist dafür zuständig, die Nachricht an die Anwendung weiterzuleiten. ESB Die Umsetzung innerhalb des ESBs ist abhängig vom implementierten Messaging Client, der den asynchronen Empfang unterstützen muss. Diese Art ist bei einem Großteil der ESB Produkte standardmäßig implementiert. Ebenfalls muss das Messaging System den Aufruf des Consumers unterstützen, sobald eine passende Nachricht auf dem Channel verfügbar ist. In JMS, wie auch in.net, gibt es Klassen mit zugehörigen Methoden, mit deren Hilfe genau diese Art der asynchronen Nachrichtenverarbeitung umgesetzt werden kann. 27

37 ESB Architektur zur Unterstützung von EIPs - Patterns Fazit Die Umsetzung des Event-Driven Consumers hängt ebenfalls vom Messaging Client ab. Dieser muss bei diesem Pattern die asynchrone Nachrichtenverarbeitung unterstützen Competing Consumer Um Nachrichten nicht nur sequentiell verarbeiten zu können, benötigt man die Möglichkeit mehrere Consumer gleichzeitig einzusetzen. Dadurch kann der Nachrichtendurchsatz einer Anwendung an einem Channel erhöht werden. Einsatz findet dieses Pattern meist nur bei Point-to-Point Channeln, da bei einem Publish-Subscribe Channel jeder Consumer eine Kopie jeder Nachricht erhalten würde. In [4] werden zwei Parameter für dieses Pattern definiert: die Verteilungslogik sowie die Anzahl der Filter-Kopien. Für die Verteilung gibt es zwei mögliche Varianten. Falls das Messaging System erkennt, dass mehrere Consumer verbunden sind, übernimmt es das Aufteilen der Nachrichten durch die Verwendung eines internen Message Dispatchers ( ). Beinhaltet das verwendete Messaging System keinen Message Dispatcher, lässt es vermutlich zu, dass mehrere Consumer die gleiche Nachricht verarbeiten können. Dies kann unter Umständen zu doppelter Bearbeitung einer Nachricht durch mehrere Consumer führen, woraus sich schnell Konflikte ergeben. Zur Vermeidung könnte ein eigener Message Dispatcher ( ) eingesetzt werden. ESB Die Umsetzung des Competing Consumer Patterns hängt von dem integrierten Messaging Client ab. Dieser muss für einen Dienst mehrere Consumer (synchrone oder asynchrone), welche am Channel hören, unterstützen. Dabei sollte jeder Consumer in seinem eigenen Thread laufen, mit dem er am Channel hören kann. Bietet die MOM eine Message Dispatcher Funktionalität, erkennt sie automatisch, dass mehrere Consumer am Channel hören und übernimmt die Verteilung. Soll jedoch die Anwendung auf mehrere Prozesse verteilt werden, müssen mehrere Service Container verwendet werden, welche ebenfalls wieder mehrere Consumer enthalten können. Der Parameter Verteilungslogik wird für die Konfiguration des eigenen oder des in der MOM integrierten Message Dispatchers verwendet, der Parameter Anzahl der Filter-Kopien wird bei der Konfiguration des Messaging Clients benötigt. Als dritter Parameter wäre noch ein Flag denkbar, mit welchem definiert wird, ob mehrere Prozesse verwendet werden sollen. Fazit Die Umsetzung hängt sehr vom verwendeten Messaging Client und Messaging System ab. Gibt es die Möglichkeit, mehrere Consumer zu definieren, ist es problemlos möglich dieses Pattern umzusetzen. Ein Beispiel für einen solchen ESB, bei dem mehrere Listener für einen Dienst definiert werden können, ist der Sonic ESB von Progress Software [39]. 28

38 ESB Architektur zur Unterstützung von EIPs - Patterns Enthält das Messaging System keinen eigenen Message Dispatcher, sollte ein eigener implementiert werden Message Dispatcher Ein Message Dispatcher dient dazu mehrere Consumer eines Channels, genauer gesagt, die in beschriebenen Competing Consumer, zu koordinieren. Diese Consumer werden bei diesem Pattern Performer genannt. Der Message Dispatcher verteilt die auf dem Channel ankommenden Nachrichten auf Basis einer vorgegebenen Logik an die jeweiligen Performer. Dies ist zum einen sinnvoll, wenn es für bestimmte Nachrichten spezielle Performer gibt, zum andern kann aber auch geregelt werden, dass Nachrichten immer nur an verfügbare Performer weitergeleitet werden. Erhält der Dispatcher eine Nachricht, wählt er einen Performer entweder aus einem Pool von Performern aus oder er erstellt dynamisch einen neuen Performer. Die Logik des Dispatchers reicht von zufallsgesteuert bis zur integrierten Prüfung der Verfügbarkeit eines Performers. ESB Da laut [2] der Dispatcher mit den jeweiligen Performern in einem Prozess läuft, wird bei der Umsetzung des Patterns innerhalb eines ESB nur ein Service Container verwendet. Dadurch laufen der Dispatcher und alle Performer jeweils in einem eigenen Thread. Für den Dispatcher jedoch wird, im Gegensatz zum Competing Consumer Pattern aus , ein Listener eingerichtet, der auf dem Channel hört. Gibt es einen Pool von Performern, das heißt alle Performer laufen bereits und soll vorher nicht überprüft werden, ob ein Performer empfangsbereit ist, kann der Dispatcher auch mit einem Content-Based Router (CBR) ( ) umgesetzt werden. Dies empfiehlt sich nur, wenn die Logik rein auf Eigenschaften der Nachrichten basiert. Dabei müssen die Regeln des CBRs definiert werden und die Ausgänge auf die möglichen Performer zeigen. Die Kommunikation findet dabei direkt innerhalb des Service Containers statt. Die Performer müssen manuell implementiert werden, da die vorhandene Funktion des Messaging Clients nicht verwendet werden kann, weil die Nachrichten direkt vom Dispatcher kommen. Soll der Dispatcher neue Performer erstellen können oder eine komplexere Logik verwenden, so muss dieser ebenfalls manuell implementiert werden. Die dabei benötigten Parameter aus [4] sind zum einen die Verteilungslogik, zum Beispiel zufallsgesteuert oder vorherige Überprüfung auf Bereitschaft des Empfängers und zum andern die Anzahl der Filter-Kopien, also die zu erstellenden Performer. Diese wird entweder beim Deployment der Empfangsdienste festgesetzt oder innerhalb des Message Dispatchers, der sie dann zur Laufzeit erstellt. Wie sich das dynamische Erstellen der Performer innerhalb eines Containers verhält und ob es überhaupt möglich ist, hängt von der Implementierung des ESBs ab. Fazit Das Message Dispatcher Pattern kann mit einem ESB umgesetzt werden. Dabei wird die vorhandene Möglichkeit eines Service Containers verwendet, 29

39 ESB Architektur zur Unterstützung von EIPs - Patterns mehrere Dienste auf einmal zu hosten. Ob der Dispatcher manuell implementiert oder der vorhandene CBR verwendet wird, hängt von den Anforderungen ab, die an den Dispatcher gestellt werden. Die Performer müssen in jedem Fall manuell implementiert werden Selective Consumer Damit ausschließlich Nachrichten, welche bestimmte Kriterien erfüllen, empfangen werden können, muss ein Selective Consumer verwendet werden. Dieser erhält als Parameter verschiedene Attribut / Wert Paare, welche mit den ankommenden Nachrichten verglichen werden [4]. Nur wenn alle Kriterien übereinstimmen wird die Nachricht an den Empfänger weitergeleitet. Mit einem Selective Consumer kann zum Beispiel das Kreditvergabeszenario umgesetzt werden. Ein Empfänger erhält über den Parameter Kreditsumme > alle Kreditanfragen, die übersteigen, ein anderer Empfänger setzt den Parameter auf Kreditsumme <= , um die restlichen Anfragen zu erhalten. ESB Die Umsetzung eines Selective Consumers hängt ebenfalls von dem integrierten Messaging Client und dem Messaging System ab. Unterstützten beide die Angabe eines Filters, kann ein Selective Consumer problemlos umgesetzt werden. Handelt es sich zum Beispiel um einen JMS Client, kann dies ein einfacher Parameter vom Typ String sein. Die Syntax kann zum Beispiel eine Untermenge des SQL-92 Standards sein, wie sie bei manchen Messaging Systemen verwendet wird. Der definierte Ausdruck kann sich auf Header oder Eigenschaften einer Nachricht beziehen und wird aus den Attribut / Wert Paaren erstellt. Ein Selective Consumer kann ebenfalls über einen CBR simuliert werden. Dabei werden der CBR und der Empfänger wieder in einem Service Container gehostet, damit beide in einem Prozess laufen. Die beiden Dienste kommunizieren wieder über die interne Kommunikationsmöglichkeit eines Service Containers. Der CBR entscheidet, ob eine Nachricht an den Empfänger weitergeleitet oder verworfen wird. Die von einem Selective Consumer benötigten Parameter, in Form von Attribut / Wert Paaren, werden in Routingregeln für den CBR transformiert. Fazit Das Selective Consumer Pattern kann mit einem ESB umgesetzt werden. Dabei kann die Funktionalität bereits vorhanden sein, wenn dies von dem Messaging Client und dem Messaging System unterstützt wird. Ist dies nicht der Fall wird der Selective Consumer mit Hilfe eines CBR simuliert Durable Subscriber Das Problem eines Publish-Subscribe Channels ist, dass Nachrichten, die darüber versendet werden, nur die Empfänger erreichen, die zu diesem Zeitpunkt am Channel angemeldet sind. Ist ein Empfänger zu diesem Zeitpunkt 30

40 ESB Architektur zur Unterstützung von EIPs - Patterns nicht angemeldet, so erhält er die Nachricht nicht. Bei einem Point-to-Point Channel dagegen wird die Nachricht so lange aufbewahrt bis der Empfänger wieder erreichbar ist. Um dieses Verhalten bei einem Publish-Subscribe Channel zu erreichen wird das Durable Subscriber Pattern verwendet. Ein Durable Subscriber speichert Nachrichten so lange zwischen, bis der Empfänger wieder erreichbar ist. Ist der Durable Subscriber nicht erreichbar, sollte der Channel Nachrichten so lange speichern, bis dieser wieder verfügbar ist. Es wird sozusagen ein dritter Zustand eingeführt, den ein Subscriber haben kann. Bisher gab es subscribed und unsubscribed, hinzu kommt mit diesem Pattern der Zustand inaktiv. Dies bedeutet, dass ein Messaging System die Möglichkeit bieten muss, bei der Verbindung mit einem Publish-Subscribe Channel auszuwählen, ob der Subscriber durable oder non-durable ist. Im Falle des Durable Subscribers nimmt bei einem Verbindungsabbruch das Messaging System an, dass der Subscriber inaktiv ist und speichert die Nachrichten. Ein Durable Subscriber muss seine Subscription selbst auflösen, möchte er keine Nachrichten mehr erhalten. Ansonsten verbleiben die gespeicherten Nachrichten ewig im Messaging System. Um dies zu vermeiden, gibt es zum Beispiel die Möglichkeit, innerhalb einer Nachricht ein Ablaufdatum zu definieren, ab dem die Nachricht ungültig ist und gelöscht werden kann. ESB Die Umsetzung des Durable Subscriber Patterns hängt wieder von dem integrierten Messaging Client und dem verbundenen Messaging System ab. Die Parameter aus [4] beziehen sich auf die Eigenschaften des Messaging Systems. In [4] wird ebenfalls eine Nachricht des Durable Subscribers an das Messaging System eingeführt, in welcher er den Status inaktiv mitteilt, sobald dieser offline geht. Dies entspricht meiner Ansicht nach nicht dem Pattern nach [2], denn danach erhält der Durable Subscriber automatisch den Status inaktiv, sobald dieser die Verbindung trennt. Das Messaging System besitzt in dem Fall also bereits die Information, dass der Subscriber inaktiv ist und speichert die Nachrichten. Die Verwaltung liegt also beim Messaging System und nicht beim Subscriber, denn dieser könnte ja auch unerwartet in den Status inaktiv wechseln, ohne vorher eine Nachricht senden zu können. Fazit Unterstützt das Messaging System und der implementierte Messaging Client die geforderten Eigenschaften, ist es kein Problem dieses Pattern in einem ESB umzusetzen Messaging Channels Die in diesem Bereich festgelegten Patterns hängen fast alle von der Funktionalität des Messaging Systems ab. Nach der Konfiguration innerhalb des Messaging Systems kann auf diese über einen Service Container zugegriffen werden. Das heißt der integrierte Messaging Client (siehe 3.1.2) muss ebenfalls diese Patterns unterstützen. Die meisten der untersuchten Patterns werden von den heutzutage verfügbaren Messaging Systemen unterstützt. 31

41 ESB Architektur zur Unterstützung von EIPs - Patterns Der in [4] bei diesen und auch anderen Patterns häufig definierte Parameter Nachrichtentyp, wird bei einer Umsetzung innerhalb eines ESBs mit zugehörigem Messaging System für ein einzelnes Pattern nicht direkt gesetzt. Meist gibt es innerhalb einer ESB Implementierung einen definierten Nachrichtentyp. In dieses Format müssen alle Nachrichten, die innerhalb des ESBs versendet werden, umgewandelt werden. Solch eine Nachricht enthält normalerweise einen Body mit dem Inhalt der ursprünglichen Nachricht, sowie einen Header mit weiteren Informationen. Zum Beispiel wird innerhalb des Sonic ESB von Progress Software das XQMessage-Format verwendet, bei IBM das SMO (Service Message Objects) Format. Aufgrund dessen muss der Nachrichtentyp bei manchen Patterns nicht definiert werden, bei anderen wird dieser indirekt definiert. Darauf wird an den betreffenden Stellen noch mal verwiesen Point-to-Point Channel Die Funktionsweise eines Point-to-Point Channels wurde bereits in genau erläutert. Dieser wird dazu verwendet, Nachrichten an genau einen Empfänger zu senden. ESB Point-to-Point Channels werden von einem Messaging System in Form von Queues bereitgestellt. Dies stellt einen Standard im Bereich Messaging dar und wird deshalb auch durch das dem ESB zugrundeliegende Messaging System unterstützt. Eine Queue wird direkt im Messaging System eingerichtet. Der im Service Container integrierte Messaging Client muss ebenfalls diese Form von Channels unterstützen und entsprechend konfiguriert werden. Die Parameter aus [4], Quality of Services, Puffergröße, logische Adresse, maximale Nachrichtengröße und Dead Letter Channel Konfiguration werden alle beim Erstellen und Konfigurieren des Channels innerhalb des Messaging Systems verwendet. Fazit Da der ESB über eine MOM kommuniziert, wird ein Point-to-Point Channel direkt unterstützt und muss lediglich innerhalb des Messaging Systems eingerichtet werden Publish-Subscribe Channel Ein Publish-Subscribe Channel dient dazu, Nachrichten an mehrere Empfänger zu senden. Dieser wurde bereits in im Detail beschrieben. ESB Auch dieser Channel wird direkt vom Messaging System des ESBs unterstützt und auch dort eingerichtet. Der Messaging Client muss ebenfalls konfiguriert werden. Dafür gibt es verschiedene Möglichkeiten, wie in beschrieben. Welche davon verwendet werden können, hängt vom Messaging Client ab, zum Beispiel sollte der Client das Durable Subscriber Pattern (siehe ) 32

42 ESB Architektur zur Unterstützung von EIPs - Patterns unterstützen, damit der Channel Nachrichten zwischenspeichert, falls der Client mal nicht erreichbar ist. Die Parameter aus [4], Quality of Services, Puffergröße, logische Adresse, maximale Nachrichtengröße und Dead Letter Channel Konfiguration beziehen sich ebenfalls wieder auf die Konfiguration des Channels innerhalb des Messaging Systems. Control Nachrichtentyp und Subscribe/Unsubscribe-Logik werden bei der Implementierung des Messaging Clients verwendet. Fazit Das Publish-Subscribe Channel Pattern wird im Normalfall von allen Messaging Systemen unterstützt. Dadurch muss dieser Channel nur in der MOM des ESBs eingerichtet werden Invalid Message Channel Ein Invalid Message Channel dient als Speicherort für ungültige Nachrichten. Eine Nachricht ist ungültig, wenn sie einem Empfänger zugestellt, aber von diesem nicht verarbeitet werden konnte. Dies bedeutet, die Eigenschaften für die Zustellung einer Nachricht, normalerweise im Header angegeben, sind korrekt. Das Problem liegt am eigentlichen Inhalt der Nachricht, beispielsweise fehlende Elemente oder semantische Unkorrektheit können die Verarbeitung scheitern lassen. Damit diese Nachrichten analysiert werden können, leitet der Empfänger diese an den Invalid Message Channel weiter. Dieser Channel hat meistens ebenfalls einen Empfänger, der die eingehenden Nachrichten untersucht. ESB Das Invalid Message Channel Pattern wird normal direkt von Messaging Systemen unterstützt. Dadurch ist der erstellte Channel bereits darauf ausgelegt, ungültige Nachrichten zu empfangen. Die Parameter aus [4], wie Puffergröße, Nachrichtengröße und persistenter Speicher sind bereits optimiert bzw. werden bei der Konfiguration des Systems angegeben. Damit ein Dienst eine ungültige Nachricht an diesen Channel versenden kann, wird der Rejected- Message Endpunkt eines Service Containers auf diesen Channel eingestellt. Ebenfalls kann auch ein normaler Point-to-Point Channel verwendet werden, wenn das Messaging System die Möglichkeit nicht direkt anbietet. Über den Rejected Message Endpunkt eines Service Containers können ungültige Nachrichten auch direkt an andere Dienste, externe Web Services oder Topics gesendet werden. Wirft ein Dienst bei der Verarbeitung einer Nachricht einen Fehler, so wird diese automatisch über den Rejected Message Endpunkt an den konfigurierten Channel weitergeleitet. Die in [4] angegeben Parameter beziehen sich auf die Einstellungen bei der Erstellung des Channels im Messaging System. Dabei werden Angaben zu gewünschten Quality of Services, die Persistenz der Nachrichten, die Puffergröße usw. gemacht. Als Parameter für den Filter ist in [4] eine Ungültigkeitsbedingung angegeben. Diese muss in der jeweiligen Anwendung oder dem verwendeten Adapter integriert sein, so dass bei einem Fehler eine Ausnahmebehandlung erfolgt. 33

43 ESB Architektur zur Unterstützung von EIPs - Patterns Fazit Ein Invalid Message Channel wird normalerweise von allen Messaging Systemen unterstützt und kann somit auch mit einem ESB umgesetzt werden. Ein Service Container besitzt dafür bereits einen vorgesehenen Endpunkt, der dementsprechend konfiguriert werden muss. Unterstützt das Messaging System keinen Invalid Message Channel, so kann im Fehlerfall die Nachricht an einen beliebigen Dienst gesendet werden Dead Letter Channel Im Gegensatz zum Invalid Message Channel wird der Dead Letter Channel für Nachrichten verwendet, die vom Messaging System nicht zugestellt werden können. Dies kann mehrere Gründe haben. Zum Beispiel wenn im Header Informationen fehlen oder der Header falsche Informationen enthält. Genauso kann eine Nachricht bereits abgelaufen sein. Das heißt, der Dead Letter Channel wird nur vom Messaging System verwendet. Messaging Clients können im Normalfall keine Nachrichten an diesen Channel weiterleiten. Um diese Nachrichten ebenfalls zu analysieren, gibt es meistens einen Empfänger, der auf diesem Channel hört. ESB Die Umsetzung eines Dead Letter Channels hängt nur vom verwendeten Messaging System ab. Auf welche Art und Weise dieser im System umgesetzt ist, kommt auf den jeweiligen Hersteller an. Die in [4] definierten Parameter beziehen sich auf die Eigenschaften des Channels, wie Quality of Services Eigenschaften oder persistente Nachrichtenverwaltung. Die Unterstützung dieser Parameter hängt ebenfalls vom verwendeten Messaging System ab. Die Bedingung für einen dead letter muss dadurch auch innerhalb des Messaging Systems festgelegt werden. Fazit Die Umsetzung eines Dead Letter Channels ist vollkommen von dem verwendeten Messaging System abhängig. Die Implementierung kann von Hersteller zu Hersteller variieren. Innerhalb der Konfiguration des ESBs muss für dieses Pattern nichts berücksichtigt werden Guaranteed Delivery Wenn über ein Messaging System Nachrichten versendet werden, speichert das System diese solange zwischen, bis der Empfänger die Nachricht erfolgreich erhalten hat. Dies ist das in Kapitel 2 beschriebene Store-and- Forward Prinzip. Normalerweise speichert das Messaging System die Nachrichten in seinem Arbeitsspeicher. Das kann dazu führen, dass alle Nachrichten im Falle eines Ausfalls des Messaging Systems, weg sind. Das Guaranteed Delivery Pattern zeigt eine Möglichkeit auf dies zu vermeiden. Dafür müssen die Messaging Systeme jeweils Zugriff auf einen persistenten Datenspeicher haben. In diesem müssen alle Nachrichten gespeichert werden, damit sie bei einem Ausfall wieder aus diesem Speicher gelesen und 34

44 ESB Architektur zur Unterstützung von EIPs - Patterns weiterverarbeitet werden können. Eine Nachricht wird aus dem Datenspeicher erst wieder entfernt, wenn entweder vom Client der Empfang bestätigt wurde oder ein anderes Messaging System bestätigt hat, dass die Nachricht ebenfalls in dessen Datenspeicher gespeichert ist. ESB Die Umsetzung des Guaranteed Delivery Pattern hängt hauptsächlich von dem verwendeten Messaging System ab. Dieses muss die Möglichkeit bieten Nachrichten persistent zu speichern. Der in [4] definierte Parameter Speicherlogik ist bereits innerhalb des Messaging Systems umgesetzt. Je nach Implementierung wird die Nachricht in einer Datenbank, im Dateisystem, o.ä. gespeichert. Bei der Konfiguration der Endpunkte muss angegeben werden, ob die verwendeten Channels das Guaranteed Delivery aktivieren sollen. Dies bedeutet, dass der integrierte Messaging Client die Konfiguration ebenfalls unterstützten muss. Die hier beschriebene Umsetzung beschränkt sich nur auf die Kommunikation direkt über das Messaging System bis zum Service Container. Um bei der Anbindung der Dienste ebenfalls ein Guaranteed Delivery zu erreichen, kommt es auf das verwendete Protokoll an. Wird ein externer Web Service angebunden, so muss der ESB zum Beispiel WS-ReliableMessaging unterstützen. Wird ein Dienst über HTTP direkt angesprochen, so kann ein Guaranteed Delivery nicht umgesetzt werden. Fazit Wird Guaranteed Delivery von dem verwendeten Messaging System und dem integrierten Messaging Client unterstützt, kann dieses Pattern mit einem ESB für die interne Kommunikation umgesetzt werden. Bei der Anbindung der Dienste kommt es auf das jeweils verwendete Protokoll an, ob ein Guaranteed Delivery umgesetzt werden kann oder nicht Channel Adapter Da die meisten vorhandenen Anwendungen in einem Unternehmen nicht darauf ausgelegt sind eine nachrichtenbasierte Kommunikation zu verwenden, wird ein sogenannter Channel Adapter benötigt. Dieser dient dazu eine Anwendung, an eine Messaging Umgebung anzubinden. Dabei fungiert der Channel Adapter, wie ein Messaging Client, der aber gleichzeitig Funktionen der angebundenen Anwendung aufruft. Ein Channel Adapter kann auf drei unterschiedlichen Ebenen einer Anwendungsarchitektur angebunden werden. 1) User Interface Adapter Dieser Adapter kommt meist zum Einsatz, wenn es keine Möglichkeit gibt einen Adapter direkt in die Anwendungsumgebung einzubinden. Ein Grund hierfür kann zum Beispiel eine vom Messaging System nicht direkt unterstützte Anwendung sein. Ebenfalls wird diese Art von Channel Adaptern oft bei web-basierten Anwendungen eingesetzt. Zum Beispiel können bei HTML-basierten Interfaces sehr einfach die gewünschten 35

45 ESB Architektur zur Unterstützung von EIPs - Patterns Daten per HTTP angefordert werden. Nachteile dieser Art von Adaptern sind die Geschwindigkeit und die Tatsache, dass sich meistens User Interfaces sehr oft ändern können. 2) Business Logic Adapter Bietet eine Anwendung ihre Funktionen anderen Anwendungen über eine API an, ist die Verwendung dieses Adapters zu empfehlen. Durch den direkten Aufruf der über die API einer Anwendung zur Verfügung gestellten Funktionen macht diese Art von Channel Adapter sehr effizient. 3) Database Adapter Bei dieser Art von Adaptern werden die Informationen direkt aus einer Datenbank extrahiert. Die Anwendung, welche in die Datenbank hineinschreibt, ist davon nicht betroffen. Damit auch neue Daten sofort zur Verfügung stehen, könnten relevante Tabellen getriggert werden und sobald es Änderungen gibt, sendet der Adapter diese wieder in Form von Nachrichten. Durch diesen Adapter kann zu vielen verschiedenen Anwendungen eine Verbindung hergestellt werden. Dazu benötigt man genaue Informationen über das jeweilige Datenbankschema, welches manche Hersteller nicht preisgeben. Ebenfalls geht man ein hohes Risiko ein, wenn man Daten über diesen Adapter aktualisieren möchte. ESB Bei der Integration mit Hilfe eines ESB wird ebenfalls dieses Adapter Pattern eingesetzt. Dabei enthalten die ESB Produkte bereits eine große Menge an Adaptern zum Beispiel für Standardsoftware, wie SAP oder Oracle Software. Ebenfalls werden diverse Mainframe Anwendungen und Messaging Systeme, sowie B2B Szenarien durch verfügbare Adapter unterstützt. Natürlich ist es auch jederzeit möglich eigene Adapter für einen ESB zu entwickeln. Fazit Das Channel Adapter Pattern wird genau in dieser Form von einem ESB verwendet, da die interne Kommunikation eines ESBs ebenfalls über Messaging abläuft und die Anwendungen über Adapter an den ESB angebunden werden Messaging Bridge In den meisten Unternehmen findet man mehrere Messaging Systeme vor. Dies hat zum einen die Ursache, dass unterschiedliche Anwendungen unterschiedliche Anforderungen an das Messaging System stellen. Zum andern müssen in B2B Szenarien oder durch Übernahme anderer Unternehmen oft verschiedene Messaging Systeme integriert werden. Der Aufwand für jede Anwendung einen Adapter zur Anbindung an jedes Messaging System zu entwickeln wäre viel zu groß. Deshalb wird hierfür eine Messaging Bridge eingesetzt, welche als Vermittler zwischen mehreren Messaging Systemen fungiert. Die Messaging Bridge agiert auf beiden Systemen als Client. 36

46 ESB Architektur zur Unterstützung von EIPs - Patterns Nachrichten werden von der Messaging Bridge transformiert und vom einen System zum anderen weitergeleitet. ESB Ein ESB kann direkt als Messaging Bridge verwendet werden, da ebenfalls andere Messaging Systeme mit dem ESB über Adapter verbunden werden können. Für die gängigsten Messaging Systeme liefern die meisten ESB Anbieter bereits die benötigten Adapter mit. Der ESB vermittelt dadurch zwischen den verbundenen Messaging Systemen und dem zugrundeliegenden Messaging System. Abbildung 18 stellt diesen Zusammenhang noch einmal grafisch dar. Hier werden drei Messaging Systeme miteinander verbunden: das dem ESB zugrundeliegende System, zum Beispiel SonicMQ, TIBCO RV und WebspehereMQ. Durch die Verwendung von Spezifikationen, wie Java Business Integration (JBI) (4.2.1) oder WS-Rel* ist es möglich die Messaging Systeme auch direkt anzusprechen. Abb. 18: Messaging Bridge (Quelle: [1]) Fazit Ein ESB kann das Messaging Bridge Pattern problemlos umsetzen. Es ist dazu lediglich ein Channel Adapter für das zu integrierende Messaging System oder die Verwendung von Standards notwendig Message Routing Die im vorliegenden Kapitel vorgestellten Patterns dienen alle der Weiterleitung von Nachrichten, damit diese die jeweils zuständigen Dienste erreichen. Teile dieser Patterns sind bereits in einem ESB verfügbar, so dass diese Funktionalität direkt verwendet werden kann. Die anderen Patterns können ebenfalls ganz oder teilweise mit Hilfe dieser Funktionalität umgesetzt werden Content-Based Router (CBR) Ein CBR dient dazu, Nachrichten regelbasiert an unterschiedliche Empfänger weiterzuleiten, das heißt, er besitzt einen Eingang und beliebig viele Ausgänge. Die Regeln basieren auf dem Inhalt einer Nachricht. Nachrichten werden 37

47 ESB Architektur zur Unterstützung von EIPs - Patterns innerhalb des CBRs nicht verändert. Die Anzahl der möglichen Empfänger wird zur Entwurfszeit festgelegt und ist somit statisch. Ein CBR kann zum Beispiel dazu verwendet werden, unterschiedliche Anfragen innerhalb einer Bank zu unterscheiden. Ist die Anfrage eine Kreditanfrage, wird sie an die Kreditabteilung weitergeleitet. Handelt es sich um eine Baufinanzierung, wird die Nachricht an die entsprechend zuständige Abteilung weitergeleitet. ESB Ein CBR gehört zur Grundfunktionalität eines ESBs. Diese Anforderung muss jeder ESB erfüllen. Dabei kann es unterschiedliche Arten der Implementierung der Regeln geben, dies hängt vom jeweiligen Hersteller ab. Regeln können zum Beispiel in JavaScript, XPath, BPEL oder in Kombination verfasst sein und beziehen sich auf den Header und den Body einer Nachricht. Dadurch können auch sehr komplexe Regeln definiert werden. Die in [4] definierten Parameter Routing-Logik und Else-Ausgang werden direkt innerhalb der definierten Regeln umgesetzt. Die Nachrichten des Else-Zweiges werden entweder an einen definierten Empfänger weitergeleitet, der diese dann überprüfen kann oder sie werden verworfen. Zuerst müssen die Entry und Exit Endpunkte des Service Containers mit den zugehörigen Verbindungen definiert werden. Dabei bildet der Entry Endpunkt den Eingang der weiter zu leitenden Nachricht und die Exit Endpunkte dienen dem Weiterleiten an die festgelegten Empfänger. Innerhalb dieser Konfiguration wird der Parameter Anzahl der Ausgänge aus [4] festgelegt. Der Parameter Nachrichtentyp wird nur indirekt definiert, innerhalb der Regeldefinition, da diese Regeln auf einer bestimmten Nachrichtenstruktur basieren. Die Tabelle mit den Mappings wird automatisch bei der Konfiguration erstellt und direkt vom ESB verwaltet. Listing 1 zeigt ein Beispiel für eine JavaScript basierte Funktion einer Nachrichtenüberprüfung. Dieser Code verwendet eine Hilfsfunktion getxpath(), mit welcher überprüft wird, ob eine Nachricht auf der dritten Ebene vom Wurzelelement aus ein Element mit dem Namen PurchaseOrder besitzt. Außerdem wird überprüft, ob der richtige Namespace verwendet wird. // // Function returns "true" if this contains a PurchaseOrder document. // function ispo( ) { // Get the elements that would be at: /Envelope/Body/PurchaseOrder. nodeset = getxpath("*/*/test:purchaseorder", "xmlns:test=' if (nodeset = = null nodeset.getcount( ) < 1) { return false; } return true; } Listing 1: Nachrichtenüberprüfung per JavaScript 38

48 ESB Architektur zur Unterstützung von EIPs - Patterns Fazit Das CBR Pattern lässt sich vollständig mit einem ESB umsetzen. Dabei sind keine manuellen Erweiterungen des ESBs nötig, da diese Funktionalität jeder ESB standardmäßig besitzt Message Filter Mit Hilfe eines Message Filters können Nachrichten schon vor dem Erhalt gefiltert werden. Dadurch werden nur die, für einen mit dem Message Filter verbundenen Dienst, relevanten Nachrichten weitergeleitet. Ein Message Filter ist im Grunde ein CBR mit nur einem Ausgang. Nachrichten, die nicht den Anforderungen entsprechen, werden einfach gelöscht. Message Filter werden meistens in Verbindung mit einem Publish-Subscribe Channel verwendet, um die passenden Nachrichten herauszufiltern. ESB Da, wie bereits oben erwähnt, ein Message Filter nichts anderes ist, als ein CBR mit nur einem Ausgang, kann dieser ebenfalls ohne Probleme mit einem ESB umgesetzt werden. Es wird eben nur ein Entry und ein Exit Endpunkt definiert. Für das Erstellen der Regeln gelten die gleichen Bedingungen wie beim CBR. Die Regeln werden so definiert, dass alle Nachrichten welche keinen Anforderungen entsprechen, einfach gelöscht werden. Die dafür in [4] definierten Parameter, Nachrichtentyp und Filterlogik werden wieder bei der Erstellung der Regeln verwendet. Zustandsbehafteter Message Filter Standardmäßig ist ein Message Filter zustandslos, das heißt er speichert keine Informationen über die verarbeiteten Nachrichten. Oftmals ist es aber sinnvoll diese Informationen zu speichern. Damit könnte man zum Beispiel verhindern, dass Nachrichten mehrmals zugestellt werden. Um solche zustandsbehafteten Message Filter in einem ESB umzusetzen, benötigt man einen zusätzlichen Dienst, der das Verwalten der Nachrichten übernimmt. Dieser Dienst kann zum Beispiel mit einer Datenbank verbunden sein, in der die benötigten Informationen gespeichert werden. Er sitzt zwischen dem Message Filter und dem eigentlichen Empfänger, wie in Abbildung 19 dargestellt. Der Message Filter sendet einfach alle Nachrichten an diesen zusätzlichen Dienst. Dieser vergleicht die Nachricht mit seinen Daten aus der Datenbank und sendet sie entweder weiter oder löscht sie. Als Parameter benötigt dieser Dienst ein oder mehrere eindeutige Merkmale, anhand dieser er die Nachrichten vergleichen soll. Um das beschriebene Beispiel, doppelte Nachrichten zu vermeiden, umzusetzen, muss die Datenbank persistent sein, damit nach einem Ausfall immer noch gewährleistet ist, dass keine Nachricht mehrfach zugestellt wird. 39

49 Custom Service Database Service ESB Architektur zur Unterstützung von EIPs - Patterns Abb. 19: Zustandsbehafteter Message Filter mit Nachrichtenfluss Fazit Ein zustandsloser Message Filter kann direkt mit einem ESB durch die Funktionalität des CBRs umgesetzt werden. Um über alle bereits zugestellten Nachrichten einen Überblick zu haben, wird ein zusätzlicher Dienst benötigt. Dieser muss manuell implementiert werden und am besten mit einer persistenten Datenbank verbunden sein Dynamic Router Ein Dynamic Router erweitert einen CBR um eine dynamische Regelbasis. Das heißt Routingregeln können zur Laufzeit dynamisch geändert werden. Dafür besitzt der Dynamic Router einen zweiten Eingang, den Control Channel. Darüber können, die mit dem Router verbundenen Empfänger, dem Router ihre Regelpräferenzen mitteilen. Diese speichert der Dynamic Router dann in seiner Regelbasis. Zusätzlich können sich die Empfänger beim Router an- und abmelden. Dies hat den Vorteil, dass der Router immer den Überblick darüber hat, welcher Dienst gerade verfügbar ist (außer bei technischen Ausfällen von Diensten). Wenn ein Dienst zum Beispiel zu Wartungszwecken heruntergefahren wird, kann vorher noch eine Nachricht an den Router gesendet werden, damit dieser weiß, dass dieser Dienst nicht verfügbar ist. Ist der Dienst wieder verfügbar, wird einfach über eine Nachricht dem Router mitgeteilt, dass er wieder Nachrichten an diesen senden kann. Für die Erstellung der Regeln und Sammeln der Daten über die Dienste gibt es zwei verschiedene Ansätze: 1) Die Dienste melden sich beim Router an und senden ihm ihre Regelwünsche direkt nach dem Hochfahren. Dies führt dazu, dass der Router seine Regelbasis persistent halten sollte, um nach einem Absturz alle aktuellen Regeln und verfügbaren Dienste wieder im Zugriff zu haben. 2) Der Dynamic Router sendet eine Broadcast Nachricht an alle potentiellen Empfänger, damit diese ihm die Verfügbarkeit und ihre Regelwünsche mitteilen. Für diese Variante ist keine persistente Datenbank nötig. 40

50 ESB Architektur zur Unterstützung von EIPs - Patterns Die Empfänger stehen, wie auch beim CBR schon zur Entwurfszeit fest, es können also keine neuen Empfänger hinzugefügt werden. In [4] wurde für das Erstellen der Regelbasis noch eine dritte Strategie definiert, welche besagt, dass die Dienste sich an- und abmelden können. Dies ist meiner Meinung nach als ein zusätzlicher Parameter zu sehen, da es nicht direkt mit dem Erstellen der Regelbasis zu tun hat. Dadurch kann sich die Regelbasis zur Laufzeit entsprechend ändern. Da die Regeln von den jeweiligen Diensten beeinflusst werden, kann es bei mehreren Diensten immer zu Konflikten kommen, in denen eine Nachricht laut Regeln, an zwei Empfänger gesendet werden müsste. Dies beruht darauf, dass die Empfänger unabhängig voneinander agieren und nichts über die Existenz der anderen Empfänger wissen. Für die Konfliktlösung werden in [2] drei Strategien vorgeschlagen: 1) Control Messages, welche mit den bestehenden Regeln in Konflikt stehen, werden ignoriert. 2) Nachrichten werden an den ersten Empfänger gesendet, dessen Kriterien auf die jeweilige Nachricht zutreffen. 3) Nachrichten werden an alle Empfänger gesendet, deren Kriterien auf die jeweilige Nachricht zutreffen. Diese Strategie verletzt die Eigenschaft, dass ein CBR jede Nachricht nur an einen Empfänger weiterleitet. Setzt man diese Strategie um, erhält man eine Recipient List ( ). ESB Für die Umsetzung eines Dynamic Routers in einem ESB benötigt man die oben beschriebene Routingfunktionalität auf Basis von deklarativen Regeln. Unterstützt der ESB keine deklarativen Regeln, muss der Dynamic Router vollständig von Hand implementiert werden. Die meisten verfügbaren ESB Produkte unterstützen jedoch deklarative Regeln, manche ebenfalls die dynamische Änderung der Regeln zur Laufzeit. Ist dies nicht der Fall muss diese Funktionalität manuell implementiert werden. Um den Dynamic Router umzusetzen, benötigt man aber in jedem Fall einen zusätzlichen Dienst. Dieser übernimmt die Verarbeitung der Control Messages der Empfänger. Auf Basis dieser Nachrichten erstellt er die Regeln für den mit ihm verbundenen CBR. Die Regeln werden dann zur Laufzeit dem CBR übergeben. Das heißt der Parameter Anzahl der Ausgänge aus [4] wird bei der Konfiguration des CBRs verwendet. Der Parameter Nachrichtentyp findet wieder eine indirekte Verwendung innerhalb der Regeln. Der Typ der Kontrollnachricht muss bei der Implementierung des zusätzlichen Dienstes angegeben werden. Falls die erste Konfliktlösungsstrategie gewählt wird, muss diese ebenfalls im zusätzlichen Dienst implementiert werden, da sie schon während der Regelerstellung zum Einsatz kommt. Die zweite und dritte Variante hängen ebenfalls wieder von der Implementierung des ESBs ab. Da es im Grunde keine feste Definition für die Routingfunktionalität innerhalb eines ESBs gibt, kann hier nicht definitiv gesagt werden, ob diese Varianten umgesetzt werden können oder nicht. Ist es möglich, innerhalb des CBR die Regelverarbeitung zu 41

51 ESB Architektur zur Unterstützung von EIPs - Patterns beeinflussen, was bedeutet Auswertungsstrategien, wie nach erstem Treffer aufhören oder immer alle Regeln durchlaufen, festzulegen, kann die zweite Strategie ebenfalls umgesetzt werden. Unterstützt die Routingfunktionalität zusätzlich noch das Versenden einer Nachricht an mehrere Empfänger, kann Variante drei ebenfalls problemlos umgesetzt werden. Der Parameter Konfliktlösungsstrategie aus [4] aktiviert also entweder die Strategie 1 in unserem zusätzlichen Dienst oder er ändert das Verhalten des CBR. Die beiden Varianten zum Sammeln der Daten und Erstellen der Regeln, der in [4] definierte Parameter Regelbasis-Strategie, muss in unserem Zusatzdienst und den Empfängern implementiert sein. Ebenfalls ist es erforderlich zu definieren, ob sich die Empfänger an- und abmelden können. Dies muss der zusätzlich erstellte Dienst unterstützen, um es bei der Regelerstellung zu berücksichtigen. Die Control Messages für den zusätzlichen Dienst können also Parameter für das An- oder Abmelden beinhalten, sowie ihre Nachrichtenpräferenzen, zum Beispiel in Form eines xpath Ausdrucks. Der Inhalt einer solchen Nachricht könnte wie folgt aussehen: <subscribe>yes</subscribe> <preference> <xpath>*/*/crm:newcustomer</xpath> <namespace>crm= </preference> Listing 2: Beispiel einer Control Message Fazit Die Umsetzung eines Dynamic Routers innerhalb eines ESB kann nur mit Hilfe mindestens eines Zusatzdienstes erfolgen. Je nach ESB Implementierung muss unter Umständen der gesamte Dynamic Router manuell implementiert werden Recipient List Mit Hilfe des Patterns Recipient List ist es möglich eine Nachricht an mehrere Empfänger zu senden. Dabei liegt der Vorteil im Gegensatz zum Publish- Subscribe Channel darin, dass die Nachricht auch nur an die Empfänger gesendet wird, die diese auch empfangen dürfen. Dies kann bei einem Publish- Subscribe Channel nicht sichergestellt werden, da der Sender nicht weiß, wer auf dem Channel hört. Die Recipient List hat Kenntnis über alle möglichen Empfänger einer Nachricht zusammen mit den zugehörigen Channels. Für das Erstellen und Verarbeiten der Liste der Empfänger gibt es drei Möglichkeiten: 1) Liste ist bereits in der Nachricht enthalten 2) Liste wird anhand der Nachricht und Regeln direkt bestimmt 3) Liste befindet sich an einer externen Quelle 42

52 ESB Architektur zur Unterstützung von EIPs - Patterns ESB Die Umsetzung des Recipient List Patterns hängt wieder von der Funktionalität des verwendeten ESBs ab. Im Folgenden werden die drei Möglichkeiten, welche es für den Parameter Bestimmungslogik aus [4] gibt, einzeln betrachtet. Die restlichen Parameter, Nachrichtentyp und Anzahl der Ausgänge werden bei der Konfiguration des CBRs oder des eigenen Routingdienstes direkt bzw. indirekt verwendet. Liste ist in der Nachricht bereits enthalten: Bietet der CBR eines ESBs die Möglichkeit, eine Nachricht an mehrere Empfänger zu senden, kann diese Variante problemlos umgesetzt werden. Dazu müssen einfach die Regeln auf das Format der in der Nachricht enthaltenen Liste angepasst und auf die jeweiligen Empfänger gemappt werden. Um die Liste aus der Nachricht vor dem Versand zu entfernen, kann diese zuerst noch an einen Transformationsdienst gesendet werden. Unterstützt der CBR nicht den Versand an mehrere Empfänger, muss ein eigener Dienst vollständig implementiert werden, der das Routing übernimmt. In beiden Fällen gibt es einen Dienst, der sich um das Routing der Nachrichten kümmert, wie in Abbildung 20 zu sehen. Je nach Implementierung des Transformationsdienstes, ist es unter Umständen nötig nach diesem noch mal einen CBR einzusetzen, der die Nachricht an die Empfänger weiterleitet. Abb. 20: Recipient List Variante 1 mit Nachrichtenfluss und Empfängern Liste wird anhand der Nachricht und Regeln direkt bestimmt: Für die Umsetzung dieser Möglichkeit kommt es wieder darauf an, ob der CBR eines ESBs den Versand einer Nachricht an mehrere Empfänger unterstützt. Mit Hilfe definierter Regeln ermittelt dieser die Empfänger und leitet die 43

53 ESB Architektur zur Unterstützung von EIPs - Patterns Nachricht dementsprechend weiter. Je nach Implementierung können die Regeln entweder deklarativ oder direkt im Quellcode angegeben werden. Der einzige Unterschied zu Variante 1 besteht darin, dass die Nachricht vor dem Versand nicht mehr verändert werden muss, da keine Liste enthalten ist. Liste befindet sich an einer externen Quelle: Um diese Variante umzusetzen, benötigt man einen zusätzlichen Dienst, der die Empfänger-Liste erstellt und, zusammen mit der Nachricht, an den unter eins beschriebenen Dienst weiterleitet. Ebenfalls denkbar wäre die Möglichkeit, die Routing Regeln eines CBRs, wie in der zweiten Variante beschrieben, entsprechend dynamisch anzupassen. Beide Varianten werden in Abbildung 21 mit dem möglichen Nachrichtenfluss dargestellt. Wird die Recipient List manuell erstellt, könnte die Liste der Empfänger von einem externen Dienst auch direkt angefragt werden. Dynamic Recipient List Eine Erweiterung dieses Pattern ist die Dynamic Recipient List, bei der die Empfänger die Möglichkeit haben ihre Nachricht-Präferenzen dem zuständigen Dienst über einen speziellen Control-Channel mitzuteilen. Dadurch werden die Regeln der Recipient List aktualisiert. Um diese dynamische Liste umzusetzen, kann der unter behandelte Dynamic Router verwendet werden. Abb. 21: Recipient List Variante 3 mit Nachrichtenfluss Fazit Falls der ESB die Funktionalität wie gefordert bietet, kann die Recipient List in der Variante eins und zwei ohne Probleme umgesetzt werden. Bei der dritten Variante kommt lediglich ein zusätzlicher Dienst dazu, der die Empfängerliste in die Nachrichten einfügt. 44

54 ESB Architektur zur Unterstützung von EIPs - Patterns Splitter Ein Splitter dient dazu, eine Nachricht in mehrere kleinere Nachrichten aufzuteilen. Grund dafür kann zum Beispiel sein, dass die unterschiedlichen Teile einer Nachricht an verschiedenen Stellen weiter verarbeitet werden müssen. Die eingehende Nachricht kann beispielsweise eine Bestellung sein, welche unterschiedliche Artikel enthält. Hier könnte man mit Hilfe des Splitters die Artikel nach Warengruppen in eigene Nachrichten aufteilen und an die zuständigen Dienste weiterleiten. In [2] gibt es zwei Arten von Splittern, den iterativen und den statischen Splitter. Bei der iterativen Variante wird von einer Baumstruktur der eingehenden Nachricht ausgegangen. Jeder Kindknoten bildet wieder die Wurzel eines Unterbaumes. Bei einem iterativen Splitter wird durch diese Baumstruktur der Nachricht iteriert und jeder Unterbaum in einer eigenen Nachricht weitergeleitet. Die statische Variante eines Splitters teilt eine Nachricht in festvorgegebene Teile auf. Diese können oft auch von unterschiedlichem Typus sein und über verschiedene Channels gesendet werden. ESB Die Umsetzung eines Splitters mit einem ESB hängt wieder von der Funktionalität der integrierten Komponenten ab. Unterstützt der Transformationsdienst Transformationen mit mehreren Ausgangsnachrichten, kann der Splitter mit Hilfe des Transformationsdienstes und des CBRs umgesetzt werden. Ab XSLT 2.0 [30] ist es zum Beispiel möglich, mehrere Ausgangsnachrichten zu erzeugen. Ist dies innerhalb des Transformationsdienstes nicht möglich, kann mit Hilfe von mehreren Transformationen der Splitter umgesetzt werden. Dabei ist ein CBR nötig der die Nachricht an alle Transformationsdienste weiterleitet (Dieser muss, wie bereits oben erwähnt, eine Nachricht an mehrere Dienste weiterleiten können). Jeder Transformationsdienst erstellt daraufhin eine neue Nachricht. Diese Variante ist in Abbildung 22 mit drei Empfängern dargestellt. Wie schon bei der Recipient List befindet sich nach den Transformationsdiensten meistens ein CBR, der die Nachrichten an die Empfänger weiterleitet. Die Umsetzung der beiden Splitter Varianten hängt von der Funktionsweise des Transformationsdienstes ab. Mit Hilfe von XSLT in Verbindung mit XPath kann sowohl ein iterativer, als auch ein statischer Splitter umgesetzt werden. Der Parameter Aufteilungslogik aus [4] findet sich also in der Transformationsvorschrift des oder der Transformationsdienste(s) wieder. Die beiden anderen Parameter, Eingangs- und Ausgangsnachrichtentyp, werden ebenfalls innerhalb der Transformationsvorschrift indirekt definiert. Zwei weitere wichtige Parameter sind der Correlation Identifier und die Anzahl der Nachrichten, welche alle Nachrichten enthalten müssen, damit diese später wieder zusammengesetzt werden können. Viele ESB Produkte haben heutzutage die Funktionalität eines Splitters bereits standardmäßig implementiert. 45

55 ESB Architektur zur Unterstützung von EIPs - Patterns Fazit Ein Splitter sollte mit jedem ESB umgesetzt werden können, da Routing und Transformationen zum Standard eines ESBs gehören. Die Art und Weise der Umsetzung hängt von der Funktionsweise dieser beiden Funktionalitäten ab. Abb. 22: Splitter mit mehreren Transformationsdiensten und 3 Empfängern Aggregator Das Aggregator Pattern dient dazu die Nachrichten mehrerer Sender zu einer Nachricht zusammenzufügen. Dabei ist die Anzahl der zu verarbeitenden Nachrichten unbekannt. Der Aggregator sammelt die eingehenden Nachrichten und wertet sie aus. Ist eine bestimmte Bedingung erfüllt, erstellt er daraufhin aus den eingegangenen Nachrichten eine neue Nachricht. Für einen Aggregator gibt es drei wichtige Eigenschaften, die definiert werden müssen: 1) Correlation 2) Completeness Condition 3) Kombinationslogik Die erste Eigenschaft definiert ein bestimmtes Merkmal von Nachrichten, anhand diesem herausgefunden werden kann, welche Nachrichten zusammengehören. Dieses gewählte Merkmal nennt man Correlation Identifier. Innerhalb der zweiten Eigenschaft muss eine Bedingung definiert werden, welche festlegt, wann die Ausgangsnachricht erstellt werden soll. Dafür gibt es 46

56 ESB Architektur zur Unterstützung von EIPs - Patterns unterschiedliche Strategien, wie zum Beispiel Timeout, nur auf die erste Nachricht warten oder auf alle Nachrichten warten. Genaueres kann in [2] nachgelesen werden. Die dritte Eigenschaft beschreibt die Logik, wie die eingegangen Nachrichten zusammengefügt werden sollen. Der Aggregator könnte zum Beispiel die beste Antwort aus allen Nachrichten heraussuchen oder einen Durchschnitt der empfangenen Nachrichten bilden. Weiter könnte er auch alle Inhalte aller Nachrichten in einer Nachricht zusammenfügen. Bei einem Aggregator könnten, wenn es die Implementierung erlaubt, auch zur Laufzeit die Parameter angepasst werden. Dabei besitzt der Aggregator einen zusätzlichen Eingang, über den die Änderungen zugestellt werden können. Dadurch kann zum Beispiel im Vorfeld bereits die Menge der Nachrichten angegeben, auf die der Aggregator warten muss, oder das Zusammensetzen der Nachricht definiert werden. Ein Beispiel für den Einsatz eines Aggregators ist ein Versandhaus. Erhält dieses eine Bestellanfrage, könnte eine Nachricht mit dem gewünschten Produkt über einen Publish-Subscribe Channel an alle verfügbaren Lieferanten versendet werden. Die Antworten der Lieferanten werden dann von einem Aggregator ausgewertet, zum Beispiel nach Kriterien wie Preis oder Verfügbarkeit und dementsprechend weitergeleitet. ESB Um einen Aggregator mit einem ESB umzusetzen, muss dieser manuell implementiert werden. Dafür wird eine Datenbasis benötigt, welche alle benötigten Informationen beinhaltet. Die für einen Aggregator benötigten Parameter aus [4] werden zum einen innerhalb des ESBs, zum anderen über die Implementierung oder die Datenbasis festgelegt. Die Anzahl der Eingänge werden innerhalb des Service Containers konfiguriert. Dabei wird für jeden Eingang ein Entry Endpunkt mit dem zugehörigen Channel definiert. Für die Änderungen der Konfiguration zur Laufzeit kann entweder ebenfalls ein Entry Endpunkt definiert werden oder die Kontrollnachrichten werden zum Beispiel an einen Managementdienst gesendet, der die Parameter direkt über eine API ändert. Dies kommt auf die jeweiligen Möglichkeiten des ESBs an. Die zu unterstützenden Completeness Conditions müssen direkt im Aggregator implementiert werden. Die Umsetzung der Kombinationslogik hängt von den Fähigkeiten des integrierten Transformationsdienstes eines ESBs ab. Unterstützt dieser die Verarbeitung mehrerer Eingabenachrichten, wie es zum Beispiel mit XSLT möglich ist, kann die Kombinationslogik auch innerhalb des Transformationsdienstes umgesetzt werden. Dabei sendet der erstellte Aggregator-Dienst einfach die zu verarbeitenden Nachrichten an den Transformationsdienst weiter. Eine andere Möglichkeit wäre den erstellten Dienst und den Transformationsdienst in einem Service Container zu hosten, dann könnten die Nachrichten auch direkt weitergeleitet oder über eine gemeinsame Datenbasis ausgetauscht werden. Die Parameter Eingangs- und Ausgangsnachrichtentyp aus [4] werden indirekt über die implementierte Strategie definiert. Ein weiterer wichtiger Parameter, der in [4] nicht erwähnt wird, ist die Angabe eines Correlation Identifiers. Dieser ist sehr wichtig, da nur anhand von diesem 47

57 ESB Architektur zur Unterstützung von EIPs - Patterns der Aggregator in der Lage ist, die zusammengehörigen Nachrichten zu erkennen. Fazit Die Umsetzung des Aggregators muss fast vollständig manuell implementiert werden, da ein ESB standardmäßig keine Funktionalität dafür bietet. Je nach Implementierung des Transformationsdienstes kann man sich unter Umständen die manuelle Umsetzung der Nachrichtenkombination sparen. Viele ESB Produkte haben heutzutage einen Aggregator bereits implementiert. Welche Parameter von diesen Produkten unterstützt werden und in welcher Form, hängt vom jeweiligen Hersteller ab Message Transformation Um Nachrichten für die weitere Verarbeitung in das richtige Format mit den richtigen Inhalten zu bringen, werden Nachrichtentransformationen benötigt. Die Patterns in diesem Abschnitt beschäftigen sich genau damit. Ein ESB besitzt für diese Patterns ebenfalls wieder die Grundfunktionalität, die für fast alle Patterns zumindest teilweise zur Hilfe genommen werden kann Message Translator Damit ein Empfänger eine Nachricht verarbeiten kann, muss diese oftmals vorher transformiert werden. Diese Transformation kann auf vier verschiedenen Ebenen stattfinden, auf der Transport-, der Datendarstellungs-, der Datentypund der Datenstrukturebene. Genaueres kann in [2] nachgelesen werden. Für den hier betrachteten Message Translator sind lediglich die Datentypebene und die Datendarstellungsebene von Interesse. Der Großteil der benötigten Transformationen findet auf der Datentypebene statt, da sich Formate von Daten ändern oder Werte zusammengefasst werden. ESB Für einen Message Translator reicht im Normalfall der vorhandene Transformationsdienst eines ESBs aus. Die Parameter Eingangs- und Ausgangsnachrichtentyp aus [4] werden wieder indirekt über die Transformationsvorschrift definiert. Der dritte Parameter, die Transformationslogik, wird entweder deklarativ oder direkt im Quellcode definiert. Ebenfalls ist es auch möglich einen vollständig eigenen Transformationsdienst zu entwickeln, sollte die vorhandene Möglichkeit nicht ausreichen. Fazit Die Möglichkeit zur Umsetzung eines Message Translators ist in allen ESBs enthalten, da eine Transformationsmöglichkeit zu den Grundanforderungen gehört. Unterschiede gibt es lediglich in der Mächtigkeit der jeweiligen Transformationsdienste und der geforderten Funktionalität. 48

58 ESB Architektur zur Unterstützung von EIPs - Patterns Envelope Wrapper Damit eine Nachricht von einem Nachrichtensystem verarbeitet und weitergeleitet werden kann, muss sie bestimmte Struktur- oder Informations- Anforderungen erfüllen. Ein Envelope Wrapper sorgt dafür, dass eine Nachricht weiterverarbeitet werden kann, in dem er zum Beispiel Header-Felder hinzufügt, die Nachricht verschlüsselt oder Sicherheitsinformationen einfügt. Die Eingangsnachricht eines Message Wrappers befindet sich im Rohformat und kommt meistens direkt von der zugehörigen Anwendung. Am anderen Ende des Nachrichtensystems befindet sich ebenfalls ein Message Wrapper, der zum Beispiel die Header-Felder wieder entfernt, die Nachricht entschlüsselt oder Sicherheitsangaben überprüft. ESB Um dieses Pattern in einem ESB umzusetzen, gibt es zwei Möglichkeiten, welche von den jeweiligen Anforderungen abhängen: Statische Nachrichtenerweiterung: Dies kann mit dem vorhandenen Transformationsdienst eines ESBs umgesetzt werden. Bei einer XML-Nachricht ist es möglich zum Beispiel mit Hilfe eines XSLT-Stylesheets die Nachricht um zusätzliche Felder zu erweitern. Ein Beispiel ist die Erweiterung einer SOAP-Nachricht um den SOAP-Envelope. Dynamische Nachrichtenerweiterung: Sollen dynamische Inhalte, zum Beispiel aus einer Datenbank, in die Nachricht eingefügt werden, benötigt man einen zusätzlichen Dienst. Dieser Dienst kann entweder die Änderungen direkt vornehmen oder die Transformationsvorschrift (zum Beispiel ein XSLT-Stylesheet) eines Transformationsdienstes anpassen. Dazu müssen die Transformationsregeln deklarativ und zur Laufzeit änderbar sein. Ebenfalls benötigt man einen zusätzlichen Dienst, falls man Nachrichten verschlüsseln möchte. Benötigte Parameter für einen Envelope Wrapper sind Eingangs- und Ausgangsnachrichtentyp, sowie Transformationslogik. Diese drei werden wieder innerhalb der Transformationsvorschrift direkt bzw. indirekt definiert. Fazit Für die statische Nachrichtenerweiterung kann man die Transformationsfunktionalität eines ESBs verwenden. Möchte man Datenbankabfragen oder wie oben beschrieben andere Funktionen, wie das Verschlüsseln von Daten verwenden, benötigt man zusätzlich entwickelte Dienste. Die unterschiedlichen Möglichkeiten sind in Abbildung 23 dargestellt. 49

59 Encrypt Service Database Service ESB Architektur zur Unterstützung von EIPs - Patterns Transf. Rules Directory Cache Abb. 23: Envelope Wrapper mit Nachrichtenfluss Content Enricher Das Ziel eines Content Enrichers ist es eine Nachricht mit fehlendem Inhalt zu ergänzen. Dabei wird der Nachrichtentyp im Normalfall nicht verändert, die Nachricht wird lediglich um zusätzliche Informationen erweitert. Der Content Enricher kann entweder selbst die zusätzlichen Informationen verwalten oder diese an einer externen Quelle abfragen. Das heißt, entweder ist der Content Enricher selbst mit einer Datenquelle verbunden, oder er fragt die erforderlichen Daten bei einem anderen Dienst an. Zum Einsatz könnte ein Content Enricher zum Beispiel innerhalb eines Online- Versandsystems kommen. Möchte ein Kunde angebotene Artikel innerhalb einer gewissen Produktgruppe aufgelistet bekommen, können zum Beispiel über einen Content Enricher zusätzliche Informationen des Herstellers zur Produktbeschreibung hinzugefügt werden. ESB Die Umsetzung eines Content Enrichers hängt davon ab, in welcher Form die zusätzlichen Daten vorliegen. Handelt es sich um statische Daten, kann dieser problemlos mit dem vorhandenen Transformationsdienst umgesetzt werden. Beinhaltet die Erweiterung dynamische Daten, muss der Content Enricher manuell implementiert werden, da entweder eine Datenbankanbindung benötigt wird oder ein externer Dienst angesprochen werden muss. Zusätzlich zu diesem manuell erstellten Dienst, kann auch der Transformationsdienst verwendet werden. Dabei passt der erstellte Dienst dynamisch die Transformationsregeln an. Hierbei kommt es ebenfalls wieder auf den 50

60 ESB Architektur zur Unterstützung von EIPs - Patterns implementierten Transformationsdienst an, ob dessen Konfiguration dynamisch zur Laufzeit angepasst werden kann. Die zwei in [4] beschriebenen Parameter für einen Content Enricher, Eingangs-, Ausgangsnachrichtentyp, werden wieder indirekt definiert. Der dritte Parameter Anreicherungslogik muss entweder manuell implementiert oder innerhalb des Transformationsdienstes konfiguriert werden. Fazit Um einen Content Enricher in einem ESB umzusetzen, wird man in den meisten Fällen einen manuellen Dienst implementieren und entweder das Hinzufügen der Informationen direkt machen oder mit Hilfe des vorhandenen Transformationsdienstes. Dies liegt daran, dass die fehlenden Daten ebenfalls dynamisch sind und an anderer Stelle gepflegt werden. Handelt es sich nur um eine statische Erweiterung, wie zum Beispiel das Hinzufügen der Firmenadresse, kann dies problemlos mit dem Transformationsdienst umgesetzt werden Content Filter Ein Content Filter dient dazu, nicht benötigte Daten aus Nachrichten zu entfernen. Dadurch kann eine Nachricht sehr vereinfacht und damit die weitere Verarbeitung beschleunigen werden. Daten, welche zu entfernen sind, können zum Beispiel sicherheitskritische Daten, die nicht jeder Dienst einsehen darf, sein. Ebenfalls können es auch einfach unwichtige Daten sein, die für die weitere Verarbeitung durch nachfolgende Dienste irrelevant sind. Ein Content Filter kann auch dafür eingesetzt werden, die Struktur einer Nachricht zu verändern. Dadurch können Nachrichten stark vereinfacht werden, weil wichtige Daten, die weiter unten in der Struktur stehen, zum Beispiel ganz nach oben geholt werden können und eine flache Struktur entsteht. Demzufolge brauchen nachfolgende Dienste nicht durch eine komplexe Struktur parsen, sondern haben direkten Zugriff auf erforderliche Daten. ESB Die Umsetzung eines Content Filters sollte mit jedem ESB problemlos möglich sein, weil mit Hilfe des Transformationsdienstes sowohl Informationen entfernt werden können, als auch die Struktur von Nachrichten problemlos geändert werden kann. Da die meisten Transformationsdienste deklarative Regeln verwenden, wie zum Beispiel mit Hilfe von XSLT, könnten diese je nach Implementierung auch zur Laufzeit angepasst werden. In [4] werden für einen Content Filter drei Parameter definiert: die beiden Nachrichtentypen, einmal eingehend und einmal ausgehend und die Filterlogik. Die Nachrichtentypen werden wieder indirekt über die Transformationsregeln definiert, die Filterlogik wird direkt in Transformationsregeln für den Transformationsdienst umgesetzt. Fazit Ein Content Filter kann problemlos mit einem ESB umgesetzt werden. Dazu muss lediglich der integrierte Transformationsdienst entsprechend konfiguriert werden. 51

61 ESB Architektur zur Unterstützung von EIPs - Patterns Claim Check Das Claim Check Pattern erweitert einen Content Filter dahingehend, dass Nachrichteninhalte nicht nur entfernt, sondern temporär zwischengespeichert werden. Dadurch können diese zu einem späteren Zeitpunkt wieder in die Nachricht eingefügt werden. Dies hat den Vorteil, dass das Datenvolumen verringert werden kann, aber keine wichtigen Informationen verloren gehen. Ebenfalls kann das Pattern dazu benutzt werden, sicherheitskritische Daten zu schützen, zum Beispiel vor externen Diensten. Die Funktionsweise ist relativ einfach, aus einer Nachricht werden die nicht benötigten Daten entfernt und in einem persistenten Speicher gespeichert. Um den Bezug zur Nachricht nicht zu verlieren, muss ein eindeutiger Schlüssel erstellt werden, der mit den Daten zusammen gespeichert wird. Danach wird dieser Schlüssel ebenfalls der Nachricht hinzugefügt. Zu einem späteren Zeitpunkt können mit Hilfe des Content Enrichers aus die Informationen aus der Datenbank wieder der Nachricht hinzugefügt werden. Dabei kann der Content Enricher über den in der Nachricht enthaltenen Schlüssel die richtigen Daten aus der Datenbank auswählen. ESB Um das Claim Check Pattern mit einem ESB umzusetzen, benötigt man einen manuell erstellten Dienst, der die zu entfernenden Daten aus der Nachricht in einer Datenbank speichert. Danach kann die Nachricht an einen Transformationsdienst weitergeleitet werden, der diese Informationen entfernt. Der erstellte Dienst erzeugt ebenfalls den eindeutigen Schlüssel, der mit den Daten in der Datenbank gespeichert wird. Damit dieser in die Nachricht eingefügt wird, wird er zur Laufzeit an den Transformationsdienst übergeben. Dies kann zum Beispiel direkt über die Manipulation der Transformationsregeln geschehen. Für diese Umsetzung muss der Transformationsdienst deklarative Regeln unterstützen und zur Laufzeit angepasst werden können. Diese Umsetzungsvariante ist in Abbildung 24 dargestellt. Wird dies nicht unterstützt muss das Pattern vollständig manuell implementiert werden. Für das Claim Check Pattern werden in [4] drei Parameter definiert: der Nachrichtentyp der Eingangs- und Ausgangsnachricht und die Filterlogik. Die Nachrichtentypen befinden sich wieder indirekt innerhalb der Transformationslogik. Die Filterlogik muss bei der verteilten Implementierung in beiden Diensten konfiguriert sein, wobei die Nachricht nur im Transformationsdienst verändert wird. Ein zusätzlicher Parameter, der in [4] nicht genannt wurde, ist die Methode zum Erstellen des eindeutigen Schlüssels. Dieser muss ebenfalls innerhalb des manuell erstellten Dienstes konfiguriert werden. 52

62 Claim Check Service ESB Architektur zur Unterstützung von EIPs - Patterns Datastore Add data + key Transf. Rules Directory Cache Change Tranformation Rules 1 2 Abb. 24: Claim Check mit Nachrichtenfluss Fazit Die Umsetzung des Claim Check Patterns ist mit einem ESB möglich. Je nach Implementierung des ESBs kann entweder die Funktionalität auf einen manuell erstellten Dienst und den integrierten Transformationsdienst verteilt werden oder das gesamte Pattern in einem vollständig, manuell erstellten Dienst umgesetzt werden System Management Die in diesem Abschnitt untersuchten Patterns dienen alle dazu, ein Messaging System im Betrieb auf korrekte Arbeitsweise zu überprüfen und zu überwachen. Ebenfalls kann anhand dieser Patterns die korrekte Funktionsweise der verbundenen Anwendungen überprüft werden. Die in [5] definierten Parameter wurden in die Betrachtung der einzelnen Patterns mit einbezogen Control Bus In einer verteilten Infrastruktur mit lose gekoppelten Diensten ist es nicht einfach, das gesamte System zu administrieren und zu überwachen. Daher liegt es nahe, die vorhandene Messaging Umgebung zu verwenden, um die angebundenen Komponenten mit Hilfe von Nachrichten zu konfigurieren und zu überwachen. Dies können zum Beispiel Nachrichten, welche eine neue Konfiguration enthalten, oder Testnachrichten sein. Auf der anderen Seite können die Komponenten regelmäßig Nachrichten versenden, um dadurch zu signalisieren, dass sie noch verfügbar sind. Würden diese Nachrichten über die gleichen Channels versendet werden, wie normale Anwendungsnachrichten, könnten sie unter Umständen verloren gehen oder verspätet zugestellt werden. Eine vollgelaufene Queue könnte beispielsweise hierfür der Grund sein. Deshalb wird für diese Art der Nachrichten ein eigener Channel, der Control Bus verwendet. Dadurch ist jede Komponente mit zwei Channeln, einmal für Anwendungsnachrichten und einmal für Kontrollnachrichten, verbunden. 53

63 ESB Architektur zur Unterstützung von EIPs - Patterns ESB Jeder Service Container besitzt eine Managementschnittstelle, über die dieser verwaltet wird. Diese kann wie in Abbildung 14 zu sehen ist, zum Beispiel mit Hilfe von JMX implementiert sein. Über diese Schnittstelle ist es möglich von einer Management Konsole aus Anweisungen, wie Starten, Stoppen oder Herunterfahren von Komponenten an den Service Container zu übergeben. Aber auch Statusmeldungen oder Fehlernachrichten können darüber von intern an die Konsole gesendet werden. Ebenfalls ist es möglich Konfigurationsdaten, wie Routingregeln, Transformationsvorschriften, usw. direkt im Directory Service zu ändern. Dies kann entweder auch direkt über eine implementierte Schnittstelle geschehen oder aber zum Beispiel durch einen direkten Dateizugriff. Dies hängt von der jeweiligen Implementierung ab. Darüberhinaus kann trotzdem auch ein zusätzlicher Channel für diesen Zweck verwendet werden. Dazu muss zuerst ein neuer Channel, zum Beispiel eine Queue im Messaging System eingerichtet werden. Dann wird bei der Konfiguration des Service Containers ein weiterer Entry Endpunkt eingerichtet, der mit diesem Channel verbunden ist. Der Dienst muss dementsprechend angepasst werden, damit die Nachrichten auch verarbeitet werden können. Die vier Parameter aus [5] kommen bei dieser zweiten Variante bei der Erstellung des Channels zum Einsatz, da diese direkt die Eigenschaften des Channels definieren, wie Quality of Service Eigenschaften, Buffergröße oder die logische Adresse. Für interne Nachrichten, wie Statusnachrichten die von intern gesendet werden, muss ein zusätzlicher Exit Endpunkt eingerichtet werden. Wird eine Managementschnittstelle verwendet, können die Parameter je nach Technologie trotzdem definiert werden. Bei JMX zum Beispiel wird für die Kommunikation ein JChannel, Implementierung eines Channels in Java, verwendet. Dieser kann ebenfalls unterschiedlich konfiguriert werden. Fazit Ein ESB bietet bereits die Möglichkeit, Konfigurationsänderungen direkt vorzunehmen oder die angebundenen Komponenten zu verwalten. Meist sind diese Schnittstellen durch Verwendung von Standards wie JMX implementiert. Aber die Umsetzung kann ebenfalls, wie beschrieben, mit einem zusätzlichen Channel erfolgen, falls die vorhandenen Möglichkeiten nicht ausreichen Detour Um Nachrichten auf Korrektheit zu überprüfen, ist es zum Teil notwendig, zwischen den beteiligten Komponenten zusätzliche Dienste einzubinden, welche die Nachrichten validieren. Diese zusätzlichen Arbeitsschritte sind im Normalfall aber nicht ständig notwendig und können unter Umständen auch das Gesamtsystem verlangsamen. Deshalb wird bei einem Detour ein Context- Based Router verwendet, der je nach Konfiguration eine Nachricht an den Validierungsdienst oder direkt an den nächsten Anwendungsdienst weiterleitet. ESB Das Detour Pattern kann mit dem integrierten CBR umgesetzt werden. Dieser wird so konfiguriert, dass alle Nachrichten nur an einen Dienst weitergeleitet 54

64 ESB Architektur zur Unterstützung von EIPs - Patterns werden. Das heißt, es wird nur eine Routingregel konfiguriert und diese auch nicht auf Basis des Inhalts der Nachrichten. Möchte man die Nachrichten über einen Validierungsdienst leiten, muss die Routingregel entsprechend geändert werden. Diese muss zum Beispiel bei deklarativen Regeln nur im Directory Service geändert werden. Dazu ist es notwendig, dass der ESB Änderungen zur Laufzeit unterstützt. Andernfalls müsste der CBR heruntergefahren und wieder neuinitialisiert werden, wodurch dieser für kurze Zeit nicht verfügbar ist. Die in [5] beschriebenen Parameter werden direkt innerhalb der Konfiguration des CBR benötigt, wie die Routing-Logik und die Anzahl der Ausgänge. Der Nachrichtentyp für die Konfigurationsnachricht wird bei der Verwendung des CBR für die Änderung innerhalb des Service Directorys definiert. Die Queue- Nachricht wird nicht benötigt, da der CBR die Konfiguration immer direkt aus seinem Directory Cache oder dem Directory Service erhält. Der Parameter Nachrichtentyp wird ebenfalls nicht verwendet, da der CBR alle Nachrichten weiterleitet, ohne eine typspezifische Prüfung. Fazit Ein Detour kann mit einem ESB durch die Verwendung des integrierten CBR umgesetzt werden. Je nach Implementierung kann die Routingregel zur Laufzeit geändert werden oder die Änderung muss durch Neuinitialisierung des CBRs erfolgen Wire Tap In Point-to-Point Channeln gibt es immer genau einen Empfänger, der eine Nachricht verarbeitet. Oft ist es aber nötig, alle Nachrichten, welche über einen Channel gesendet werden, an einen zusätzlichen Empfänger weiterzuleiten. Dies ist bei Problembehebungen oder zu Testzwecken sehr hilfreich. Um dies zu erreichen, muss eine Komponente sämtliche Nachrichten verdoppeln und auf zwei verschiedene Channels weiterleiten. Dazu kann zum Beispiel eine simple Recipient List ( ) verwendet werden. Diese besitzt zwei Ausgangschannels, einen für den eigentlichen Empfänger und einen für den Empfänger, der die Nachricht überprüfen soll. Für das Wire Tap Pattern wird daher ein zusätzlicher Channel benötigt, auf den die Empfänger angepasst werden müssen. ESB Ein Wire Tap kann mit einem ESB ohne Probleme umgesetzt werden. Es kann dafür entweder die Recipient List aus verwendet werden oder die Nachricht wird direkt innerhalb des Service Containers verdoppelt. Für die Umsetzung wird ein zusätzlicher Channel innerhalb des Messaging Systems eingerichtet. Auf diesen müssen die Entry Endpunkte der Empfänger konfiguriert werden. Der Entry Endpunkt der Recipient List wird auf den ursprünglichen Channel konfiguriert. Zusätzlich werden zwei Exit Endpunkte eingerichtet, wobei einer auf den neuangelegten Channel konfiguriert wird, der andere auf den Channel, an dem der zusätzliche Empfänger lauscht. Bei der Recipient List gibt es im Prinzip keine Auswertung, wie es normalerweise der Fall ist, sondern die Nachricht wird einfach stupide auf beiden Channeln weitergeleitet. 55

65 ESB Architektur zur Unterstützung von EIPs - Zusammengesetzte Patterns Die andere Möglichkeit ist, bei den Sendern den Tracking Endpunkt des jeweiligen Service Containers zu verwenden. Dieser kann so eingerichtet werden, dass alle Nachrichten zusätzlich über diesen Endpunkt an den konfigurierten Channel versendet werden. Diese Lösung spiegelt zwar nicht genau das Pattern wieder, aber das dabei erzielte Ergebnis ist dasselbe. Der Parameter Mapping-Tabelle aus [5] wird direkt entweder von der Recipient List verwaltet oder durch den Service Container. Der Query-Nachrichtentyp wird, wie beim Detour Pattern, nicht benötigt, da entweder die Recipient List ihre Konfiguration direkt im Zugriff hat oder schon der Service Container konfiguriert wird. Beim Parameter Konfigurationsnachrichtentyp verhält es sich ebenfalls gleich wie beim Detour Pattern, sowohl für die Recipient List Variante, als auch für die Service Container Umsetzung. Der Parameter Nachrichtentyp ist auch, wie schon beim Detour Pattern, uninteressant, da die Komponente alle Nachrichten ohne Prüfung weiterleitet. Fazit Möchte man die Konfiguration nur an einer Stelle vornehmen, so empfiehlt sich die Verwendung einer Recipient List. Ansonsten kann man die integrierte Möglichkeit eines Service Containers verwenden. Dazu muss an jedem auf dem gewählten Channel sendenden Dienst der Tracking Endpunkt des zugehörigen Service Containers eingerichtet werden. Egal welche Möglichkeit gewählt wird, die Umsetzung des Patterns funktioniert mit einem ESB. 3.2 Zusammengesetzte Patterns Um mit Hilfe der in 3.1 untersuchten Patterns komplexere Lösungen umzusetzen, ist es nötig diese miteinander zu kombinieren. Dabei kann fast jedes Pattern mit einem anderen kombiniert werden. Dies ist jedoch nicht immer sinnvoll und laut der verwendeten Pipes und Filters Architektur werden Filter und Pipes immer abwechselnd miteinander verbunden. Die Filter sind in unserem Fall die Patterns aus dem Bereich Message Routing und Messaging Transformation. Die Pipes sind die Patterns aus dem Bereich Messaging Channels. Patterns aus dem Bereich Messaging Endpoints werden direkt mit einem Channel und Filter kombiniert. Bei der Kombination von Patterns gibt es auch viele unsinnige Kombinationsmöglichkeiten, wie zum Beispiel ein Competing Consumer mit einem Publish-Subscribe Channel. Genauere Details über die einzelnen Kombinationsmöglichkeiten der unterschiedlichen Patterns können in [2] nachgelesen werden. Im Folgenden werden zwei zusammengesetzte Patterns aus dem Bereich Message Routing genauer untersucht Composed Message Processor Müssen Teile einer Nachricht von unterschiedlichen Diensten bearbeitet werden, kann die Nachricht von einem Splitter in mehrere Nachrichten aufgeteilt werden. Daraufhin können die neu erstellten Nachrichten mit Hilfe eines CBR an die jeweiligen Empfänger weitergeleitet werden. Sobald diese mit der Bearbeitung fertig sind, senden sie ihre Nachricht an einen Aggregator, der alle 56

66 ESB Architektur zur Unterstützung von EIPs - Zusammengesetzte Patterns Ergebnisnachrichten wieder zu einer Nachricht zusammenfügt und diese versendet. Die Kombination aus diesen drei Patterns bildet einen Composed Message Processor. Die Funktionsweise ist in Abbildung 25 noch einmal grafisch mit einem Beispiel aus einem Buchungssystem dargestellt. Da dieses Pattern nach außen als ein einzelner Filter agiert, kann es mit anderen Patterns ebenfalls wieder direkt kombiniert werden. Abb. 25: Beispielanwendung für einen Composed Message Processor ESB Für die Umsetzung des Composed Message Processors mit einem ESB können die in Kapitel umgesetzten Patterns verwendet werden. Die Parameter des Composed Message Processor entsprechen den Parametern der einzelnen Patterns. Die in [5] definierten allgemeinen Parameter für dieses Pattern, wie Eingangs- und Ausgangsnachricht oder Anzahl der Empfänger, werden jeweils bei den einzelnen Patterns definiert. Zum Beispiel wird die Anzahl der Empfänger innerhalb des CBR verwendet. Kommt bei der Umsetzung des Splitters ein CBR mit mehreren Transformationsdiensten zum Einsatz, weil der Transformationsdienst keine multiplen Ausgabenachrichten unterstützt, kann je nach Implementierung auf den Router nach der Aufteilung der Nachrichten verzichtet werden. In dem Fall können die Transformationsdienste die Nachrichten direkt weiterleiten, wie in Abbildung 22 zu sehen ist. Andernfalls benötigt man einen zusätzlichen CBR, der die Nachrichten nach der Transformation verteilt. In Abbildung 26 ist diese Lösung grafisch mit drei Empfängern und einem Aggregator dargestellt. Hinter einem dargestellten Empfänger könnten natürlich auch wieder mehrere Empfänger stecken, wenn die Nachricht zum Beispiel über einen Publish- Subscribe Channel versendet wird. Fazit Da der Composed Message Processor nur eine Kombination vorhandener Patterns ist, kann dieser problemlos mit einem ESB umgesetzt werden. Die einzelnen Patterns müssen lediglich miteinander verbunden und ihre Parameter aufeinander abgestimmt werden. 57

67 ESB Architektur zur Unterstützung von EIPs - Zusammengesetzte Patterns Abb. 26: Composed Message Processor mit Nachrichtenfluss und 3 Empfängern Scatter-Gather Bei diesem Pattern wird, im Gegensatz zum Composed Message Processor, die Nachricht komplett an mehrere Empfänger gesendet. Diese ist vergleichbar mit einem Broadcast. Die Antworten der Empfänger werden daraufhin von einem Aggregator ausgewertet und das Ergebnis weitergeleitet. Das Versenden der Nachricht kann dabei entweder über eine Recipient List stattfinden, dabei sind alle Empfänger bekannt oder mit einem Publish-Subscribe Channel. Die Auswahl kommt auf den jeweiligen Einsatzzweck an. Möchte man nur von bestimmten Empfängern eine Antwort erhalten, empfiehlt sich die Recipient List. Ein Publish-Subscribe Channel kann zum Beispiel bei einer Produktanfrage an Lieferanten hilfreich sein. Da sich die Lieferanten selbständig mit dem Publish-Subscribe Channel verbinden, muss der Scatter- Gather nicht die Informationen beinhalten. Dadurch ist gewährleistet, dass immer alle verfügbaren Lieferanten die Nachricht erhalten. ESB Innerhalb eines ESBs kann ein Scatter Gather sowohl mit einer Recipient List, als auch mit einem Publish-Subscribe Channel umgesetzt werden. Die Parameter des Scatter Gathers sind die Parameter der einzelnen verwendeten Patterns. Die unterschiedlichen Ansätze, abhängig von der verwendeten ESB Implementierung, wurden bereits in Kapitel genau diskutiert. Die Umsetzung mit Hilfe einer Recipient List, bei der der CBR die Auswahl der Empfänger übernimmt, ist in Abbildung 27 dargestellt. 58

68 ESB Architektur zur Unterstützung von EIPs - Zusammengesetzte Patterns Fazit Das Scatter Gather Pattern kann in einem ESB problemlos umgesetzt werden. Dabei müssen lediglich die verwendeten Komponenten aufeinander abgestimmt werden. Abb. 27: Scatter Gather mit Nachrichtenfluss 59

69 4 Implementierung Die Praxistauglichkeit der gewonnenen Erkenntnisse aus Kapitel 3 sollte anhand eines Beispielszenarios überprüft werden. Dabei wurde versucht, die in Kapitel 3 gemachten Überlegungen mit einem Open-Source ESB an einem konkreten Beispiel aus [2], dem Loan Broker Beispiel, umzusetzen. Ebenfalls soll dieses Kapitel als Grundlage für weitere Arbeiten zur automatischen Generierung der Konfigurationsdateien eines ESBs aus den Patterns dienen. Dazu gibt es zu jedem Pattern einen kurzen Abschnitt, der benötigte Parameter für die verwendeten Komponenten sowie weitere Überlegungen enthält. Der Loan Broker ist für die Verarbeitung von Kreditanfragen und das Herausfinden des günstigsten Kreditzinses zuständig. Er erhält eine Anfrage für einen Kredit für eine bestimmte Person. Darauf holt er sich Informationen über die Kreditwürdigkeit, sowie passende Banken ein und sendet den gefundenen Banken eine Anfrage. Danach wertet er die, von den Banken erhaltenen, Antworten aus und sendet eine Antwortnachricht mit dem besten Zinssatz zurück an den Anfragenden. Der Loan Broker setzt sich aus verschiedenen Patterns zusammen, wie in Abbildung 28 zu sehen ist. Abb. 28: Loan Broker (Quelle: In Anlehnung an [2]) 60

70 Implementierung - verwendete Technologien Erweitert wurde das Szenario noch um zwei Patterns aus dem Bereich des System Management, das Wire Tap ( ) und das Detour Pattern ( ). Auf alle Patterns wird bei der Beschreibung der Umsetzung genauer eingegangen. 4.1 verwendete Technologien Für die Umsetzung des Loan Broker Beispiels wurden folgende Technologien verwendet: Apache ServiceMix [40] + Apache ActiveMQ [41] Apache Maven [42] JDK 6.0 JConsole 1.6.0_04-b12 [34] Apache Tomcat 6.0 [44] XPath [31] XSLT [30] Im nächsten Abschnitt wird genauer auf die Architektur und Funktionsweise des Apache ServiceMix eingegangen, um die darauf folgende Beschreibung der Umsetzung besser zu verstehen. 4.2 Apache ServiceMix Apache ServiceMix basiert vollständig auf der JBI Spezifikation [32]. Das Projekt entstand aus der Not heraus, da es aus Sicht des Projektteams keinen ESB gab, der die benötigten Grundanforderungen erfüllte. Alle Produkte waren entweder zu überdimensioniert oder zu speziell. Daher wurde bei der Entwicklung stets darauf geachtet, dass lediglich die benötigten Anforderungen umgesetzt wurden. Dazu zählen Kriterien, wie standardbasiert, Flexibilität, Zuverlässigkeit und eine Vielzahl an Kommunikationsmöglichkeiten. Abbildung 29 zeigt die ServiceMix-Architektur. 61

71 Implementierung - Apache ServiceMix Abb. 29: Architektur ServiceMix (Quelle: [40]) Um diese Architektur und die Funktionsweise von ServiceMix besser zu verstehen, gibt der nächste Abschnitt einen kurzen Einblick in JBI Java Business Integration (JBI) JBI ist ein Java-basierter Standard der beschreibt, wie Integrationssysteme durch den Einsatz von Komponenten via Plug-in umgesetzt werden können. Dabei bietet die JBI-Umgebung Interfaces, die von den Plug-in Komponenten genutzt werden. Die lose Kopplung steht bei diesem Integrationsmodell im Vordergrund, daher kommunizieren die Komponenten nicht direkt miteinander, sondern JBI dient als Vermittler zwischen den Komponenten. Dadurch können Dienst-Anbieter und Konsumenten voneinander getrennt werden. Die Funktionen der Dienst-Anbieter werden als WSDL 2.0 Operationen mit den zugehörigen Nachrichten modelliert. Ebenfalls wird der Nachrichtenaustausch auf Basis der vier WSDL-definierten Message Exchange Patterns (MEP) beschrieben. Diese werden in der folgenden Tabelle dargestellt: Pattern-Name Nachrichten Sequenz Fault Route WSDL 1.1 Operation In-Only in none One-way Robust In-Only in on in - In-Out in, out replaces out Request-response In Optional-Out in, out on in or out - Tabelle 2: JBI Standard Message Exchange Patterns (Quelle: [32]) Innerhalb der JBI-Umgebung findet der Nachrichtenaustausch nur über Normalized Messages statt. Eine solche Nachricht besteht aus zwei Teilen, dem eigentlichen Inhalt der Nachricht, also dem Content und Metadaten (Nachrichten-Kontext). Metadaten können zum Beispiel Sicherheits- oder Transaktionsinformationen sein. 62

72 Implementierung - Apache ServiceMix Die JBI Architektur lässt sich in drei verschiedene Bereiche aufteilen: Deployment-, sowie Kontroll- und Überwachungsmöglichkeiten durch JMX basierte Administrations-Tools. Der Normalized Message Router (NMR), der für das Routing der Nachrichten sowie unterschiedliche Quality of Services zuständig ist. Komponenten Die Komponenten sind in zwei Kategorien aufgeteilt: 1) Service Engines (SE): SEs beinhalten die Geschäftslogik innerhalb einer JBI Umgebung. Dies kann zum Beispiel ein Transformationsdienst oder ein Routingdienst sein. SEs sind in der Lage miteinander kombiniert werden, um wieder neue Dienste zu erhalten. Ebenfalls agieren SEs als Anbieter sowie als Konsumenten. 2) Binding Components (BC): BCs bieten die Konnektivität zu Diensten außerhalb der JBI Umgebung. Sie werden dafür benutzt, Nachrichten über ein bestimmtes Protokoll zu senden und empfangen. BCs dienen dazu, die Trennung zwischen der JBI Umgebung und den verwendeten Protokollen zu erhalten. Die BCs sind ebenfalls dafür zuständig, Nachrichten zu normalisieren und denormalisieren. Dies bedeutet sie vollziehen die Transformation in eine Normalized Message und wieder zurück. Die Trennung der Komponenten in SEs und BCs ist rein pragmatischer Art. Technisch gesehen gibt es keinen Unterschied zwischen diesen Komponenten. Abbildung 30 stellt die JBI Architektur noch einmal grafisch dar. JBI Komponenten fungieren als Container, in die Artefakte deployed werden können, um einen solchen Container entsprechend zu konfigurieren. Installiert werden JBI Komponenten (SEs und BCs) über Standard Management Mechanismen, sowie einem definierten Packaging Verfahren. Dadurch ist gewährleistet, dass Komponenten portabel sind und auch auf andere JBI Implementierungen portiert werden können. 63

73 Implementierung - Apache ServiceMix Abb. 30: JBI Architektur (Quelle: [40]) Artefakte werden durch ein Archiv-Paket (.zip-datei) deployed. Dieses Paket nennt man Service Unit (SU). In einer SU sind hauptsächlich Informationen enthalten, die nur für die verwendete Komponente von Wichtigkeit sind. Darin können zum Beispiel XSLT Stylesheets oder BPEL Prozesse sein. Zusätzlich enthält eine SU noch einen JBI Deskriptor. Dieser befindet sich im Verzeichnis META-INF und heißt jbi.xml. Er enthält Informationen über die statischen Dienste, welche bereitgestellt oder verwendet werden. Das folgende Listing zeigt einen JBI Deskriptor für eine Recipient List. <?xml version="1.0" encoding="utf-8"?> <jbi xmlns=" version="1.0"> <services binding-component="false" xmlns:trav=" xmlns:loan=" <provides service-name="loan:recplist" endpoint-name="endpoint"/> <consumes service-name="loan:pipe_bank2"/> <consumes service-name="loan:pipe_bank1"/> <consumes service-name="loan:pipe_bank3"/> <consumes service-name="loan:pipe_bank_standard "/> </services> </jbi> Listing 3: JBI Deskriptor (jbi.xml) Innerhalb des Deskriptors wird zum einen der Provider Service-Name, also der Name, unter dem dieser Dienst später erreichbar ist, definiert und zum anderen, alle mit ihm verbundenen Dienste, die Konsumenten. Da die SUs nicht direkt deployed werden können, werden sie in ein Service Assembly (SA) gepackt. Ein SA ist ebenfalls wieder eine.zip-datei und kann mit einer Enterprise ARchive (EAR) Datei aus der J2EE Welt verglichen werden. In einem SA sind zum einen die.zip Dateien der SUs enthalten, zum anderen ebenfalls ein JBI Deskriptor. Dieser beinhaltet Informationen darüber, 64

74 Implementierung - Apache ServiceMix wo welche SU deployed werden soll und welche Verbindungen zwischen SUs und anderen SUs oder externen Diensten bestehen Wichtige ServiceMix Komponenten ServiceMix beinhaltet bereits standardmäßig verschiedene SEs und BCs. Zu den wichtigsten SEs gehören folgende Komponenten: servicemix-saxon Transformationsmöglichkeit / unterstützt XSLT 2.0, XQuery 1.0 und XPath 2.0. servicemix-drools Routingmöglichkeit auf Basis der Drools Rule Engine [45]. servicemix-jsr181 Möglichkeit, POJOs (Plain old Java Objects) als Dienste auf dem JBI Bus bereitzustellen mit speziellen Features, wie WSDL Autogenerierung. servicemix-bean Möglichkeit, Java Beans (POJOs) auf dem JBI Bus zu verwenden, um Nachrichten auszutauschen. servicemix-eip enthält verschiedene umgesetzte Patterns aus [2], die direkt verwendet werden können. Apache ODE BPEL engine [43] Möglichkeit, BPEL Prozesse in ServiceMix einzubinden. Zu den wichtigsten BCs gehören folgende: servicemix-http HTTP/SOAP BC mit integriertem HTTP Server / SSL SOAP 1.1, SOAP 1.2, WS-Addressing und WS-Security Unterstützung u.a. servicemix-jms JMS BC mit SOAP 1.1, SOAP 1.2 und WS-Addressing Unterstützung u.a. servicemix-ftp BC, zum Lesen und Schreiben von Dateien auf einem FTP-Server servicemix-file BC, zum Lesen und Schreiben von Dateien im lokalen Dateisystem oder Verzeichnisse regelmäßig auf neue Dateien zu überprüfen ServiceMix bietet ein mächtiges Apache Maven [42] Plug-in für die Paketierung und das Erstellen des JBI Deskriptors an. Mit Hilfe von Maven erspart man sich viel Zeit. Ebenfalls werden sogenannte Maven Archetypes für JBI Komponenten und SUs angeboten, mit deren Hilfe es möglich ist, mit nur einer Zeile ein neues Projekt zu erstellen. Das Deployment wird in ServiceMix durch ein sogenanntes 65

75 Implementierung - Apache ServiceMix HotDeploy nochmals vereinfacht. Dadurch muss das SA lediglich in den vorgesehenen Ordner kopiert werden. Daraufhin startet das Deployment automatisch ohne weiteres Zutun. Eine wichtige Hilfskomponente, die noch näher erklärt werden sollte, ist die Pipeline Komponente. Viele der von ServiceMix bereitgestellten Komponenten unterstützen nur das In-Out MEP, was bedeutet, dass die Antwortnachricht direkt an den Anfragenden zurückgesendet wird. Oft müssen aber Nachrichten nach dem Reply-Forward Pattern [1] verarbeitet werden, sprich, die Antwortnachricht muss an eine andere Komponente gesendet werden. Dies kann mit Hilfe der Pipeline Komponente erreicht werden. Zur Konfiguration müssen lediglich der Dienst, welcher nur das In-Out MEP unterstützt, und der Zieldienst, welcher die Antwort erhalten soll, angegeben werden. Die Pipeline Komponente sendet die Anfrage an die erste Komponente und leitet die Antwortnachricht dann als In-Only Nachricht an die Zielkomponente weiter. Der beschriebene Zusammenhang wird in Abbildung 31 noch einmal grafisch dargestellt. Pipeline 1 2 Dienst 1 (In-Out) 3 Dienst 2 Abb. 31: Pipeline Komponente Kommunikation zwischen Komponenten Für die Kommunikationsart zwischen Komponenten gibt es in ServiceMix vier verschiedene Möglichkeiten. Die Art wird über die Auswahl einer der sogenannten Flows getroffen. Diese werden im Folgenden kurz vorgestellt: STFlow (Straight Through) Bei dieser Art findet die Kommunikation zwischen den Komponenten direkt statt. Es wird kein Zwischenspeichern oder Puffern verwendet. Dieser Flow eignet sich dazu, Verzögerungen so gering wie möglich zu halten und den Durchsatz der Nachrichten zu erhöhen. Jedoch kommt es im Fehlerfall zum Verlust von Nachrichten. SedaFlow (Staged Event Driven Architecture) Dieser Flow basiert auf Konzepten aus einem Paper der Harvard Universität [20]. Durch das Zwischenspeichern und Puffern mit Hilfe einer Queue ist dieser Flow sehr effizient und skaliert auch sehr gut. Der SedaFlow wird in ServiceMix standardmäßig verwendet. JMSFlow Der JMSFlow wird hauptsächlich dazu verwendet, mehrere JBI- Container miteinander zu verbinden. Mehrere JBI-Container werden zum Beispiel benötigt, um die Skalierbarkeit zu erhöhen oder ein fail-over 66

76 Implementierung - Loan Broker Beispiel Szenario zu erhalten. Bei diesem Flow wird für jede Komponente eine eigene Queue verwendet. Bei der Konfiguration von ServiceMix kann die Option persistent aktiviert werden. Ist diese aktiviert wird ebenfalls, auch bei nur einem JBI-Container, der JMSFlow verwendet. JCAFlow Mit Hilfe des JCAFlows können ebenso mehrere JBI-Container miteinander verbunden werden. Dabei werden JCA Adapter verwendet, welche ebenfalls direkt mit ActiveMQ verbunden sind und JMS nutzen. Der Hauptunterschied zum JMSFlow liegt darin, dass JCA die Unterstützung für XA-Transaktionen bietet. Um detailliertere Informationen zu den Flows zu erhalten, wird an dieser Stelle auf [40] verwiesen. Nach der Einführung in ServiceMix und JBI zeigt das nächste Kapitel die Umsetzung des Loan Broker Beispiels. 4.3 Loan Broker Beispiel Die Umsetzung des Loan Broker Szenarios erfolgte anhand des Modells aus Abbildung 28. Die bei diesem Beispiel umgesetzten Patterns sind also Content Enricher, Recipient List, Aggregator, Message Translator Wire Tap, sowie Detour. Die Funktionalität des Message Translators hätte ebenfalls auch der Aggregator übernehmen können. Dies wurde bewusst nicht gemacht, da dadurch auch mehrere unterschiedliche Message Translator verwendet werden können, um unterschiedliche Empfänger zu bedienen. Die drei Bankdienste wurden der Einfachheit halber als einfache Content Enricher umgesetzt. Der in Abbildung 28 gezeigt Audit Dienst wurde mit Hilfe der servicemix-bean Komponente umgesetzt. Die Funktion dieses Dienstes liegt im Moment aber nur darin, die empfangene Nachricht auszugeben. Der ebenfalls in Abbildung 28 zu sehende Check Message Dienst basiert auch auf der servicemix-bean Komponente. Dieser gibt die Nachricht erst aus und leitet sie dann an die Recipient List weiter. Um eine LoanRequest Nachricht entgegen zu nehmen, wurde eine servicemixhttp BC verwendet. Diese wurde als Consumer mit aktivierter SOAP Unterstützung konfiguriert. Die Konfiguration dieser Komponente zeigt das folgende Listing. <beans xmlns:http=" xmlns:loan=" < service="loan:http" endpoint="soap" targetservice="loan:pipe_credit" role="consumer" locationuri=" defaultmep=" soap="true" /> </beans> Listing 4: Konfiguration HTTP Komponente 67

77 Implementierung - Loan Broker Beispiel Konfiguriert werden muss der Service-Name, sowie der Zieldienst, an den die Nachricht weitergeleitet werden soll. Ebenfalls muss die URI, über die die Komponente erreichbar ist, sowie das MEP definiert werden. Diese Komponente leitet die Anfrage einfach an den Get Credit Score Dienst weiter, genauer gesagt an die vor diesen Dienst gesetzte Pipeline Komponente. In den folgenden Abschnitten wird die Umsetzung der einzelnen Patterns genauer erläutert Get Credit Score (Content Enricher) Für die Umsetzung eines Content Enrichers gibt es, wie in Kapitel beschrieben, zwei verschiedene Möglichkeiten. Werden nur statische Informationen einer Nachricht hinzugefügt, kann die Umsetzung mit der servicemix-saxon Komponente erfolgen. Diese Komponente wird in Abschnitt für den Message Translator verwendet. Der Content Enricher in diesem Fall beinhaltet jedoch dynamische Informationen, die in den meisten Fällen aus einer Datenbank stammen. Da es leider innerhalb von ServiceMix nicht vorgesehen ist, die Transformationsregeln zur Laufzeit ändern zu können, konnte die servicemix-saxon Komponente nicht verwendet werden. Daher wurde der Content Enricher als externer Web Service entwickelt. Dieser enthält die in betrachteten Parameter Anreicherungslogik, sowie Eingangs- und Ausgangsnachrichtentyp. Um diesen Web Service an ServiceMix anzubinden, wird die servicemix-http Komponente benötigt. Diese ist dafür zuständig, die Anfrage an den Web Service weiterzuleiten und die Antwort wieder in den Bus weiterzugeben. Deshalb muss die Komponente als Provider konfiguriert werden, welche ihre Anfragen über den Bus erhält. Das folgende Listing zeigt die Konfiguration dieser BC. <beans xmlns:http=" xmlns:loan=" < service="loan:creditscoreservice" endpoint="soap" role="provider" locationuri=" wsdlresource="classpath:credit.wsdl" soap="true"/> </beans> Listing 5: Konfiguration Get Credit Score Komponente Die Service und Endpoint Definition müssen dem Service und Port Namen aus der zugehörigen WSDL Datei entsprechen. Die locationuri gibt die Adresse des aufzurufenden Web Services an. Ebenfalls muss die Rolle, in diesem Fall Provider und der Pfad zur zugehörigen WSDL Datei angegeben werden. Da die Anfrage eine In-only Nachricht ist, wurde vor den Content Enricher eine Pipeline Komponente gesetzt, welche die Nachricht an die BC weiterleitet und die Antwortnachricht an die Recipient List sendet. 68

78 Implementierung - Loan Broker Beispiel Überlegungen zur automatischen Generierung Um einen Content Enricher automatisch zu generieren, müssen vorher die gewünschten Implementierungen, welche unterstützt werden sollen, definiert werden. Ein Content Enricher kann, wie oben beschrieben, ein externer Web Service sein, der über HTTP angesprochen wird. Dabei befindet sich die Logik im Web Service und es muss lediglich noch die BC konfiguriert werden. Der Content Enricher könnte aber auch eine SE sein, die es vielleicht erlaubt, die Erweiterungslogik in irgendeiner Form bei der Konfiguration mit anzugeben. Ein externer Dienst kann ebenfalls auch über andere Protokolle erreichbar sein, was aber auch eine vorhandene BC voraussetzt. In diesem Fall muss, wie bei der hier gewählten Variante, die BC konfiguriert werden. Dies bedeutet für einen Content Enricher muss es einen Parameter geben, über den der Content Enricher statisch oder dynamisch konfiguriert werden kann. Im statischen Fall gelten die gleichen Parameter, wie in beschrieben. Im dynamischen Fall sind die Parameter von der jeweiligen Umsetzung des Dienstes abhängig Recipient List Für die Umsetzung einer Recipient List wurden in Kapitel drei verschiedene Möglichkeiten aufgezeigt. Hier wurde sich für die zweite Variante entschieden, bei der die Empfänger direkt ausgewertet werden. Leider konnte die beschriebene theoretische Umsetzung nicht direkt in ServiceMix umgesetzt werden. Weder die servicemix-drools Komponente, noch der innerhalb der servicemix-eip Komponente enthaltene CBR unterstützten den Versand einer Nachricht an mehrere Empfänger. Die verfügbare StaticRecipient List konnte auch nicht verwendet werden, da diese rein statisch agiert. Aus diesem Grund wurde auf Basis des CBR und der StaticRecipient List eine eigene SE mit der Funktionalität einer regelbasierten Recipient List erstellt. Die Regeln für die Auswahl der Empfänger werden beim Deployment der SU durch XPath Ausdrücke definiert. Die Recipient List funktioniert nur mit dem In-Only oder Robust-In-Only MEP. Von dieser Recipient List Komponente wird jeder einzelne XPath Ausdruck ausgewertet und bei erfolgreicher Auswertung die Nachricht an den jeweiligen Empfänger gesendet. Dabei werden bei jeder Nachricht drei Eigenschaften gesetzt: die Anzahl der gültigen Empfänger, die Nachrichten-Id, welche durch die Reihenfolge der Nachrichten definiert ist und eine eindeutige CorrelationId. Diese drei Eigenschaften werden später vom Aggregator benötigt, um die Nachrichten wieder zusammenzufügen. Listing 6 zeigt die Konfiguration für die verwendete Recipient List. Die Konfiguration enthält drei mögliche Empfänger, welche den drei Bankdiensten entsprechen. Ob eine Bank eine Nachricht erhält, hängt von der Auswertung des jeweils definierten XPath Ausdrucks ab. Trifft kein Ausdruck auf die Nachricht zu, so wird diese an den zuletzt definierten Dienst gesendet. Dieser entspricht dem Else-Channel eines CBR. Der definierte Namespace-Context wird für die Verwendung von Namespaces in XPath-Ausdrücken benötigt. 69

79 Implementierung - Loan Broker Beispiel <beans xmlns:eip=" xmlns:loan= <eip:namespace-context id="nscontext"> <eip:namespaces> <eip:namespace prefix="typens"> </eip:namespace> </eip:namespaces> </eip:namespace-context> <eip:recipient-list service="loan:recplist" endpoint="endpoint"> <eip:rules> <eip:routing-rule> <eip:predicate> <eip:xpath-predicate xpath="/typens:loancredit/typens:creditscore/text() = 500" namespacecontext="#nscontext" /> </eip:predicate> <eip:target> <eip:exchange-target service="loan:pipe_bank2" /> </eip:target> </eip:routing-rule> <eip:routing-rule> <eip:predicate> <eip:xpath-predicate xpath="/typens:loancredit/typens:loan/text() = " namespacecontext="#nscontext" /> </eip:predicate> <eip:target> <eip:exchange-target service="loan:pipe_bank1" /> </eip:target> </eip:routing-rule> <eip:routing-rule> <eip:predicate> <eip:xpath-predicate xpath="/typens:loancredit/typens:name/text() = 'Doe'" namespacecontext="#nscontext" /> </eip:predicate> <eip:target> <eip:exchange-target service="loan:pipe_bank3" /> </eip:target> </eip:routing-rule> <eip:routing-rule> <!-- there is no predicate, so this is the default destination --> <eip:target> <eip:exchange-target service="loan:pipe_bank_standard" /> </eip:target> </eip:routing-rule> </eip:rules> </eip:recipient-list> </beans> Listing 6: Konfiguration der Recipient List Die in diskutierten Parameter, Anzahl der Ausgänge und die Tabelle mit Mapping werden innerhalb der Konfiguration (Listing 6) definiert. Der Nachrichtentyp wird nicht explizit, sondern nur über die XPath Ausdrücke indirekt definiert. Die Logik der RecipientList befindet sich direkt im implementierten Dienst. 70

80 Implementierung - Loan Broker Beispiel Da es sich bei den hier verwendeten Bankdiensten um servicemix-saxon Komponenten handelt wurde vor jeden Dienst eine Pipeline Komponente platziert, welche die Antwort einer Bank an den Aggregator weiterleitet. Die Recipient List sendet also genau genommen die Nachricht an die drei Pipeline Komponenten. Überlegungen zur automatischen Generierung Wird diese Art der Umsetzung einer Recipient List gewählt, kann die erstellte Recipient List Komponente verwendet werden. Zum Erzeugen der Konfigurationsdatei sind folgende Parameter nötig: Service-Name der Recipient List + zugehöriger Namespace Namespace(s) für die Verwendung in den XPath Ausdrücken Empfängerdienst in einer der folgenden Formen: o QName des Dienstes o QName des Interface o URI Optional: Operation und Endpoint Angabe XPath Ausdrücke zu jedem definierten Empfängerdienst Optional: Dienst für den Else-Fall in einer der oben genannten Formen Für die Variante bei der die Liste bereits in der Nachricht enthalten ist, kann ebenfalls die erstellte Komponente verwendet werden. Dabei muss einfach der XPath Ausdruck auf die enthaltene Liste und den jeweiligen Empfängerdienst angepasst werden. Möchte man die Liste vor dem Versand entfernen, so muss man entweder für jeden Empfänger eine eigene Pipeline Komponente verwenden und die Nachricht zuerst an einen Transformationsdienst senden oder die Recipient List direkt anpassen. Für die dritte Variante, bei der sich die Liste an einer externen Quelle befindet, kann ein zusätzlicher Content Enricher verwendet werden, der die Nachricht zuerst um die Liste der Empfänger erweitert und dann an die erstellte Recipient List Komponente weiterleitet. Ebenfalls könnte der Recipient List Komponente eine weitere Dienstabfrage hinzugefügt werden. Diese Abfrage könnte synchron stattfinden, da erst nach Erhalt der Liste die Verarbeitung fortgesetzt werden kann Aggregator Die Umsetzung des Aggregators wurde manuell vorgenommen. ServiceMix bietet aber bereits eine Aggregator Komponente an. Sie beinhaltet die Verwaltung der ankommenden Nachrichten. Dazu wird als Completeness Condition die Anzahl der Empfänger definiert, welche die Recipient List eingefügt hat. Sobald alle Nachrichten erhalten wurden, beginnt die 71

81 Implementierung - Loan Broker Beispiel Verarbeitung. Eine Timeout-Funktionalität ist ebenfalls bereits implementiert, um nicht ewig auf nicht mehr ankommende Nachrichten zu warten. Auf Basis dieser abstrakten Klasse kann ein Aggregator recht einfach erstellt werden, der die gewünschte Kombinationslogik enthält. Innerhalb der umgesetzten Kombinationslogik wird der niedrigste Wert ausgewählt und diese Nachricht dann weitergeleitet. Wie in Listing 7 zu sehen ist besteht die Konfiguration des Aggregators lediglich aus der Definition des Service und Endpunkt Namens und dem Empfängerdienst der aggregierten Nachricht. Da der folgende Translator Dienst eine servicemix-saxon Komponente ist, wird die Nachricht wieder an eine Pipeline Komponente gesendet. <beans xmlns:eip=" xmlns:loan=" <eip:recipient-list-loan-aggregator service="loan:aggregator" endpoint="endpoint"> <eip:target> <eip:exchange-target service="loan:pipe_translator" /> </eip:target> </eip:recipient-list-loan-aggregator> </beans> Listing 7: Konfiguration des Aggregators Die andere Variante ist die Verwendung eines generischen Aggregators, der zum Beispiel alle Nachrichten zu einer zusammenfügt und diese dann an einen Transformationsdienst weiterleitet. Dieser müsste dann die Kombinationslogik beinhalten und die Nachricht entsprechend verarbeiten. Die Parameter aus werden alle innerhalb des Aggregator Dienstes konfiguriert. Dabei wird die Anzahl der Eingänge nicht direkt festgelegt, denn den Aggregator Dienst interessieren nur die Anzahl der zusammenhängenden Nachrichten. Diese Anzahl wird in der vorliegenden Implementierung auch für die Completeness Condition verwendet. Diesen Parameter enthält jede Nachricht als Eigenschaft. Ebenfalls besitzt jede Nachricht eine CorrelationID. Damit der Aggregator weiß, wo sich die CorrelationID befindet, muss dieser Parameter ebenfalls definiert sein. Überlegungen zur automatischen Generierung Um die Konfiguration für einen Aggregator automatisch umzusetzen, werden somit folgende Parameter benötigt: Service-Name des Aggregators + zugehöriger Namespace Empfängerdienst in einer der oben genannten Formen + zugehöriger Namespace Message Translator Für die Umsetzung des Message Translators wurde die servicemix-saxon Komponente verwendet. Diese basiert auf dem Saxon XSLT Prozessor. Die Transformationsvorschrift wird in Form eines XSL Stylesheets definiert. Bei der 72

82 Implementierung - Loan Broker Beispiel Transformation wird die ankommende Nachricht des Aggregators in eine BestQuote Nachricht transformiert. Die in beschriebenen Parameter werden alle im verwendeten Stylesheet konfiguriert, die Transformationslogik direkt, sowie die Eingans- und Ausgangsnachrichtentypen indirekt. Das folgende Listing zeigt das verwendete Stylesheet. <xsl:stylesheet xmlns:xsl=' version='2.0' xmlns:typens=" <xsl:output method="xml" indent="yes" encoding="iso "/> <xsl:template match="/"> <typens:bestquote> <xsl:apply-templates select="aggregate/typens:quoteresponse"/> </typens:bestquote> </xsl:template> <xsl:template match="aggregate/typens:quoteresponse"> <typens:personid><xsl:value-of select="typens:personid"/></typens:personid> <typens:name><xsl:value-of select="typens:name"/></typens:name> <typens:birthdate><xsl:value-of select="typens:birthdate"/></typens:birthdate> <typens:loan><xsl:value-of select="typens:loan"/></typens:loan> <typens:quote><xsl:value-of select="typens:quote"/></typens:quote> </xsl:template> </xsl:stylesheet> Listing 8: XSL Stylesheet - Message Translator Der Translator ist so konfiguriert (siehe Anhang), dass die transformierte Nachricht an die Wire Tap Komponente weitergeleitet wird. Überlegungen zur automatischen Generierung Für die automatische Umsetzung eines Message Translators mit Hilfe der servicemix-saxon Komponente werden diese Parameter benötigt: Service-Name des Message Translators + zugehöriger Namespace Name und Ort der Stylesheet Datei Wire Tap Die Umsetzung des Wire Tap Patterns erfolgte mit Hilfe der Static Recipient List, welche in der servicemix-eip Komponente enthalten ist. Die Konfiguration dieser Komponente ist simpel, es müssen lediglich die beiden Dienste als Ziele angegeben werden. Dadurch wird jede eingehende Nachricht an beide Dienste weitergeleitet. Leider kann die Komponente keine Parameter zur Laufzeit verarbeiten, so dass die SU neu deployed werden muss, wenn man die Konfiguration ändern möchte. Da bei der Umsetzung des Szenarios für die Kommunikation zwischen den einzelnen Diensten der SedaFlow verwendet wird, wurde aus dem Wire Tap eine aktive Komponente gemacht. Aus diesem 73

83 Implementierung - Loan Broker Beispiel Grund muss die Nachricht direkt an diesen gesendet werden, da die Kommunikation nur indirekt über eine Queue läuft. Ebenso ist die Umsetzung, wie in beschrieben, unter Verwendung des Service Containers mit ServiceMix leider nicht möglich. Diese Funktionalität müsste innerhalb jeder Komponente manuell implementiert werden. Überlegungen zur automatischen Generierung Für die automatische Generierung mit Hilfe der Static Recipient List werden folgende Parameter benötigt: Name des Wire Tap Dienstes + zugehöriger Namespace Empfängerdienste in einer der in genannten Formen + zugehöriger Namespace Detour Das Detour Pattern wurde nicht wie in beschrieben mit einem CBR umgesetzt, da dieser innerhalb ServiceMix, wie bereits erwähnt, keine dynamische Änderung der Routingregeln zur Laufzeit erlaubt. Daher wurde eine eigene SE entwickelt, welche eine Änderung des Empfängerdienstes zur Laufzeit über eine Konfigurationsdatei zulässt. Beim Deployment der SU muss der Pfad zu dieser Datei angegeben werden, wie das folgende Listing beispielhaft zeigt: <beans xmlns:eip=" xmlns:loan=" <eip:detour service="loan:detourservice" endpoint="endpoint"> <path> <eip:path-config config="d:\\detour_config\\config.xml"></eip:path-config> </path> </eip:detour> </beans> Listing 9: Konfiguration Detour In diesem Fall liest die SE bei jeder Nachricht den Empfänger aus der Datei config.xml und leitet die Nachricht an diesen weiter. Auf diese Weise kann der Detour Dienst recht einfach administriert werden. Innerhalb der Konfigurationsdatei müssen der Service-Name, der Endpoint und der zugehörige Namespace definiert sein, wie in Listing 10 zu sehen. Über die Änderung der Konfiguration können die Nachrichten entweder direkt an die Recipient List gesendet werden oder zur Überprüfung an den Check Message Dienst. 74

84 Implementierung - Loan Broker Beispiel <?xml version="1.0" encoding="iso "?> <configuration> <detour> <target-namespace> <target-service>checkservice</target-service> <target-endpoint>endpoint</target-endpoint> </detour> </configuration> Listing 10: dynamische Konfiguration Detour Überlegungen zur automatischen Generierung Um diese SE für die automatische Generierung zu verwenden, werden die folgenden Parameter benötigt: Name des Detour Dienstes + zugehöriger Namespace Pfad zur Konfigurationsdatei für den Empfängerdienst Übersicht der erstellten Komponenten Die folgende Aufstellung gibt noch einmal einen Gesamtüberblick über alle, bei der Umsetzung der einzelnen Patterns, erstellten SUs mit zugehörigen Komponenten und Service-Namen. Pattern SU Name Komponente Service-Name Content Enricher loan-pipe_credit-su loan-http_credit-su servicemix-eip servicemix-http Pipe_Credit CreditScoreService Recipient List loan-rcpl-su loan-eip-se RecpListService Aggregator loan-agg-su loan-eip-se AggregatorService Message Translator loan-pipe_translator-su loan-translator-su servicemix-eip servicemix-saxon Pipe_Translator TranslatorService Wire Tap audit-wire_tap-su servicemix-eip Wire_TapService Detour loan-detour-su loan-eip-se DetourService Ein Teil der erstellten Konfigurationen dieser SUs wurde bereits in den vorherigen Abschnitten genau betrachtet. Die noch Fehlenden finden sich im Anhang wieder. Ebenfalls werden dort die für das Loan Broker Szenario zusätzlich erstellten Dienste mit den jeweiligen Konfigurationen aufgelistet. 75

85 Implementierung - Deployment 4.4 Deployment Um ein neues Maven Projekt anzulegen, muss lediglich ein Ordner erstellt werden und darin eine XML-Datei (pom.xml). Diese Datei repräsentiert das Project Object Model (POM). Darin sind Projekt-Informationen, wie der Name, die zugehörige Gruppe und Version enthalten. Zusätzlich enthält die Datei noch eine Auflistung aller in diesem Projekt vorhandenen Module. Das folgende Listing zeigt die pom.xml des umgesetzten Loan Broker Projekts: <project xmlns=" xmlns:xsi= xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>org.apache.servicemix.samples</groupid> <artifactid>loan</artifactid> <packaging>pom</packaging> <version>1.0-snapshot</version> <name>loan EIP</name> <modules> <module>loan-sa</module> <module>loan-rcpl-su</module> <module>loan-http-su</module> <module>loan-http_credit-su</module> <module>loan-pipe_credit-su</module> <module>loan-agg-su</module> <module>loan-bank1-su</module> <module>loan-pipe_bank1-su</module> <module>loan-bank2-su</module> <module>loan-pipe_bank2-su</module> <module>loan-bank3-su</module> <module>loan-pipe_bank3-su</module> <module>loan-translator-su</module> <module>loan-pipe_translator-su</module> </modules> </project> Listing 11: pom.xml - Loan Broker Projekt Innerhalb des Projektordners wird nun für jede SU ein eigener Ordner angelegt, in dem sich ebenfalls wieder eine pom.xml befindet. Diese enthält zum einen Informationen für die Paketierung der Komponente, wie den Komponentennamen, die Version, die Paketierungsart und die zugehörige Gruppe. Zum andern enthält die Datei Informationen über die Orte der Repositories, auf die während der Paketierung zugegriffen wird, sowie das zu verwendende Plug-in (in unserem Fall das jbi-maven-plugin) und abhängige Komponenten. Ebenfalls befinden sich Konfigurationsdateien und sonstige benötigte Dateien der einzelnen Komponenten in diesen Ordnern. Die dabei verwendete Ordnerstruktur muss auch in der pom.xml angegeben werden. Das Anlegen der Ordner und pom.xml Dateien kann über die Kommandozeile 76

86 Implementierung - Administration erfolgen. Hierbei werden sogenannte Archetypes verwendet, welche von ServiceMix bereitgestellt werden. Ein Archetype ist ein Template, mithilfe dessen neue SUs und SAs schnell und einfach erstellt werden können. Für das SA befindet sich ebenfalls ein Ordner innerhalb des Projektordners. Die darin enthaltene pom.xml enthält Abhängigkeiten zu allen SUs, die nachher mit dieser SA deployed werden sollen. Der Projektordner mit allen Unterordnern kann auf der beiliegenden CD im Detail betrachtet werden. Für die Paketierung wird einfach auf der obersten Ebene des Projekts der Befehl mvn:install ausgeführt. Dadurch erhält man im von Maven angelegten Repository für jede SU eine.zip Datei sowie eine.jar Datei. Beide enthalten dieselben Dateien, den JBI-Deskriptor, die Konfigurations- und zusätzlich noch benötigten Dateien, wie zum Beispiel ein XSLT Stylesheet. Die Struktur innerhalb des Repositories ist dieselbe, wie die eigentliche Projektstruktur. Ebenfalls wird durch die Ausführung des Befehls für das SA ebenfalls eine.zip Datei im Repository angelegt, welche alle erstellten.zip Dateien der SUs beinhaltet. Diese Datei wird daraufhin einfach in den HotDeploy Ordner von ServiceMix kopiert, wodurch ServiceMix sofort mit dem Deployment anfängt. Danach sind die einzelnen SUs innerhalb von ServiceMix verfügbar. 4.5 Administration Um eine Übersicht der installierten Komponenten und deployten Artefakte zu erhalten, kann die von ServiceMix bereitgestellte Web-Oberfläche verwendet werden [40]. Mit Hilfe dieser Konsole bekommt man schnell einen Überblick über die derzeit deployten SUs mit den zugehörigen Komponenten. Ebenfalls ist es möglich, Komponenten und SAs zu starten bzw. zu stoppen. Zusätzlich erhält man eine Übersicht der erstellten Endpunkte mit Typ und Interface Angaben. Ein weiterer Punkt ist die grafische Darstellung der SUs mit den zugehörigen Komponenten sowie des Nachrichtenflusses zwischen den einzelnen SUs. Leider funktionierte die integrierte Anzeige dieser Konsole nicht, so dass der grafische Editor GVedit [45] hierfür verwendet wurde. Abbildung 32 zeigt einen Ausschnitt der erstellten Grafik für den Nachrichtenfluss in unserem Loan Broker Beispiel. 77

87 Implementierung - Administration Abb. 32: Ausschnitt Nachrichtenfluss Loan Broker Eine bessere Alternative für die Administration von ServiceMix bietet die JConsole. Dieses Monitoring Tool ist im JDK seit der Version 5 verfügbar. Sie gibt ebenfalls eine Übersicht aller Komponenten und Artefakte, aber mit detaillierteren Informationen, zum Beispiel auch über den JBI Container. Ein wichtiger Punkt ist die Statistik-Übersicht. Anhand dieser kann man Informationen über die Anzahl der eingehenden und ausgehenden Nachrichten jedes Endpunktes sowie den Durchsatz pro Sekunde erhalten. Mit Hilfe dieser Übersicht kann man bei der Problemsuche schnell feststellen, bei welchem Endpunkt eine Nachricht hängen geblieben ist. Abbildung 33 zeigt einen Screenshot der JConsole. Zusätzlich erhält man ebenfalls Informationen über die verwendete ActiveMQ, wie in Abbildung 33 zu sehen ist. Dabei können zum Beispiel Informationen über die angelegten Queues und Topics abgerufen werden. 78

88 Implementierung - Bemerkungen und Ausblick Abb. 33: JConsole 4.6 Bemerkungen und Ausblick Die Arbeit mir ServiceMix stellte sich am Anfang schwieriger als gedacht heraus, da die Anleitungen und Dokumentationen teilweise sehr veraltet waren. Dies liegt hauptsächlich daran, dass ServiceMix ständig erweitert wird und deshalb leider oft die Dokumentation zu kurz kommt. Außerdem funktionierten oft die angegebenen Links zu Beispielen usw. nicht. Sobald man sich aber zurecht gefunden hat, können mit Hilfe der Mailing Liste alle auftretenden Probleme bewältigt werden. Für die Entwicklung eigener Komponenten gibt es leider keine Dokumentationen. Daher konnte nur mit Hilfe des Quellcodes der vorhandenen Komponenten die Umsetzung erfolgen, was den benötigten Zeitaufwand erheblich erhöhte. Die, innerhalb des Loan Broker Beispiels umgesetzten, Patterns stellen lediglich eine Anwendungsmöglichkeit dar. Um als Grundlage für einen Editor zu dienen, könnten diese noch wie folgt erweitert werden: Weitere Varianten des Content Enrichers, zum Beispiel durch Aufruf eines Web Services oder Abfrage einer Datenbank. 79