ESB Produkte in.net. MSE Vertiefungsmodul II. Marko Marković. Student. Jörg Hofstetter. Advisor. André Rogger (HSLU, Wirtschaft) Experte

Transkript

1 ESB Produkte in.net Student Advisor Experte Marko Marković Jörg Hofstetter André Rogger (HSLU, Wirtschaft) Kompetenzzentrum Distributed Secure Software Systems (D3S)

2 3 Das Enterprise Service Bus SOA Pattern Das Enterprise Service Bus SOA Pattern [2] ist auf die Einrichtung einer einheitlichen Kommunikationsplattform für verschiedene Systemdienste ausgerichtet. Es unterstütz wichtige Funktionen wie Skalierung, zuverlässige Verbindungen und verschlüsselte Datenübertragung. Das Pattern setzt sich fundamental aus mehreren anderen wichtigen SOA Patterns zusammen. Dazu gehören Asynchronous Queuing, Intermediate Routing sowie das Service Broker Pattern. Weiter kann das ESB Pattern um die Entwurfsmuster Reliable Messaging, Policy Centralization, Rules Centralization sowie Even Driven Messaging erweitert werden. Eine Übersicht über alle Komponenten ist in der Abbildung 1 dargestellt. Enterprise Service Bus Asynchronous Queuing Intermediate Routing Policy Centralization Event Driven Messaging Service Broker Reliable Messaging Rules Centralization Data Model Transformation Data Format Transformation Protocol Briding Abbildung 1: Komponenten des Enterprise Service Bus SOA Patterns Die einzelnen Komponenten des ESB werden in den nachfolgenden Abschnitten kurz vorgestellt. Dadurch soll ein besserer Einblick in die theoretischen Möglichkeiten eines ESB verdeutlicht werden. 3.1 Asynchronous Queuing Beim Asynchronous Queuing Entwurfsmuster stellt sich die Frage, wie ein Dienst und seine Nutzer möglichst lose gekoppelt voneinander zusammenarbeiten können. Wenn die Nutzung eines Dienstes es erfordert, dass alle seine Anwender synchron mit diesem interagieren, entsteht automatisch eine starke Abhängigkeit. Ein Prozessverarbeitungsschritt wird bei einer synchronen Kommunikation erst dann weitergeführt, wenn eine Antwort auf eine Anfrage eintrifft. Bis dahin bleibt der Status des Dienstes blockiert und die Leistung wird dadurch automatisch gehemmt. Um diesem Problem entgegenzuwirken wird ein Buffer in Form einer Message Queue zwischen dem Dienstanbieter und den Dienstnutzer zwischengeschaltet (vgl. Abbildung 2). Dieser ermöglicht eine unabhängigere, asynchrone Kommunikation. Die Message Queue bringt weitere positive Nebeneffekte mit sich. Beispielsweise ist der Dienstnutzer so in der Lage Anfragen an mehrere Dienste parallel zu versenden und die eintreffenden Antworten nacheinander zu verarbeiten. Die Verarbeitungsgeschwindigkeit der einzelnen Parteien wird entkoppelt. Ein schneller Dienstnutzer kann während er auf die Antwort eines langsamen Dienstanbieters wartet in der Zwischenzeit anderen Tätigkeiten nachgehen. Student: Marko Marković Seite 10 von 95

3 Abbildung 2: Einsatz einer Message Queue Auch wenn eine Queue verwendet wird, bedeutet das nicht, dass schlecht programmierte, synchrone Dienste nun ebenfalls ohne weiteres asynchron laufen können. Durch die Einbindung der Message Queue erhöht sich sogar der Entwicklungsaufwand für Services, damit diese asynchron betrieben werden können. Doch diese Investition zahlt sich für den gewonnen Nutzen durchaus aus. 3.2 Service Broker Die Brokerarchitektur hat sich als ein bewehrtes Konzept der Middleware Plattformen für die Integration von entfernten Systemen etabliert. Mitunter ist dies auch der Grund, weshalb der Service Broker eines der Kernstücke eines ESB bildet. Das Service Broker Entwurfsmuster setzt sich essentiell aus den Mustern Data Model Transformation, Data Format Transformation und Protocol Briding zusammen (vgl. Abbildung 3). Service Broker Data Model Transformation Data Format Transformation Protocol Briding Abbildung 3: Service Broker Die eingebundenen Muster sind in den nachfolgenden Unterabschnitten genauer beschrieben Data Model Transformation Wie sollen Dienste miteinander kommunizieren, wenn diese für dieselben Daten unterschiedliche Datenformate verwenden? Diese Frage soll mit dem Data Model Transformation Pattern beantwortet werden. Jeder Dienst verwendet ein vordefiniertes Format für seine Datenparameter. In der SOA Welt sind diese meist im XML Format und besitzen auch eine XSD Datei, welche die Formatierung festlegt. Idealerweise orientieren sich diese an vordefinierten Normen. Doch in der Praxis sind die Eingangsparameter für einen Dienst meist ohne grosse Rücksicht auf mögliche Änderungen oder Erweiterungen festgelegt worden. Über das Data Model Transformation Pattern wird beim Datenaustausch zwischen zwei Diensten ein Zwischenschritt durchgeführt, welcher die Datentransformation an das jeweilige Datenmodell übernimmt. Dieser Zwischenschicht verhindert, dass Änderungen an den bestehenden Dienstschnittstellenmodellformaten vorgenommen werden müssen. Ein Beispiel einer solchen Datenmodelltransformation ist in Abbildung 4 dargestellt. Dabei wird das Format einer Allgemeinen Anfragen in das Format einer expliziten Versicherungsanfrage konvertiert. Student: Marko Marković Seite 11 von 95

4 Abbildung 4: Data Model Transformation Data Format Transformation Je nach Anwendungsfall ist es sehr wahrscheinlich, dass nicht nur das Datenmodell, sondern auch das gesamte Datenformat zwischen zwei Diensten unterschiedlich ist. Während der eine Dienst über XML Nachrichten kommuniziert, ist der andere auf die Entgegennahme von CSV Dateien eingerichtet. In einem solchen Fall kann das Data Format Transformation Pattern angewendet werden, das die Einschaltung eines Adapters vorsieht. Dieser Adapter übernimmt die Konvertierung der Nachrichten für einen reibungslosen Kommunikationsübergang. Dadurch müssen vorhandenen Dienstschnittstellen nicht mehr neu angepasst werden. Ein möglicher Anwendungsfall ist in Abbildung 5 beispielhaft verdeutlicht. Hier werden XML Nachrichten über einen Konvertierungsdienst in CSV Dateien transformiert und einer Legacy System API für die weitere Prozessverarbeitung übergeben. Abbildung 5: Data Format Transformation Der wesentliche Nachteil dieses Vorgehens besteht darin, dass für jede Konvertierung ein entsprechender Adapter entwickelt werden muss. Dies kann unter Umständen sehr schnell zu einer komplexen Systemarchitektur führen. Zudem führt die Zwischenschaltung weiterer Programmlogik automatisch zu einer Performancedämpfung. Je grösser die zu konvertierende Nachrichten, umso länger braucht die Transformation. Student: Marko Marković Seite 12 von 95

5 3.2.3 Protocol Briding Neben der Modell und Format Transformation spielt das Protocol Briding ebenfalls eine wichtige Rolle für die Realisierung einer flexiblen Systemkommunikation. Dienste müssen ebenfalls in der Lage sein unterschiedliche Portadressen ansprechen zu können. Dies ist vor allem dann der Fall, wenn ein Dienst von einem unverschlüsselten Port (z.b. 8080) auf einen verschlüsselten wechseln möchte (z.b. 443 für SSL). Weiter kann es vorkommen, dass vom selben Netzwerkprotokoll mehrere Versionen vorhanden sind und der Dienstnutzer eine andere Version verwendet als der Dienstanbieter (vgl. Abbildung 6). Abbildung 6: Protocol Briding Auch hier kann es je nach Nachrichtengrösse zu merkbaren Performanceeinbussen kommen. Ebenfalls gilt es zu berücksichtigen, dass je nach Hersteller nicht alle Protokollüberbrückungen unterstützt werden (Bsp. JMS kann i.d.r. nur von Java Applikationen empfangen werden). 3.3 Intermediate Routing Das Intermediate Routing deckt gleich mehrere, wichtige Funktionen für SOA Systemen ab: Regelbasiertes Routing Load Balancing 1 zu 1 Routing Bei der inhaltsabhängigen Nachrichtenweiterleitung steht vor allem das dynamische Routen von Nachrichten aufgrund ihres Inhaltes im Vordergrund. Je grösser und komplexer ein SOA System ist, umso schwieriger wird es, diese von Anfang an so zu konzipieren, dass alle möglichen Fälle abgedeckt werden. Die meisten Anforderungen werden erst dann präzisiert, wenn das System eine erste, stabile Struktur angenommen hat. Zudem kommen mit der Zeit immer neue Anforderungen hinzu, weshalb die Komplexität sowie der Umfang der SOA Systemen stetig steigen, da diese ständigen Veränderungen ausgesetzt sind. Damit die Handhabung von SOA Dienste trotzdem in einem vernünftigen Rahmen durchgeführt werden kann, können in bestimmten Fällen Sammelpunkte definiert werden, welche als eine Art Fassade für eintreffende Nachrichten fungieren. Diese Sammelpunkte untersuchen den Inhalt der Nachricht und leiten diese automatisch anhand ihres Inhaltes an den richtigen Zieldienst weiter (vgl. Abbildung Student: Marko Marković Seite 13 von 95

6 7). Abbildung 7: Regelbasiertes Routing Dadurch ist es auch möglich, bestehende Sammelpunkte zur Laufzeit um weitere Dienstanbieter zu ergänzen, ohne Anpassungen an den jeweiligen Dienstnutzer vornehmen zu müssen. Dies wird dank dem Einsatz einer Business Rules Engine möglich. Diese untersucht nicht nur den Inhalt einer eingehenden Nachricht, sondern kümmert sich neben der Nachrichtenverarbeitung ebenfalls um die Ausnahmebehandlung. Der genaue Verarbeitungsablauf wird in einem Business Rules Repository abgelegt, auf welches die Business Rules Engine Zugriff hat. Ein weiterer, sehr wichtiger Aspekt der Nachrichtenweiterleitung ist das Load Balancing. Um hochverfügbare Dienste überhaupt anbieten zu können, müssen diese redundant vorhanden sein. Das heisst, dass mehrere Serviceinstanzen vorhanden sind, die ein und denselben Dienst anbieten. Je nach Auslastung der bestehenden Dienstinstanzen muss eine Dienstanfrage der einen oder anderen Instanz weitergeleitet werden können. So können viele Anfragen parallel und somit auch schneller bearbeitet werden. Für diesen Zweck wird ein Load Balancing Router vor den jeweiligen Dienstinstanzen zwischengeschaltet. Dieser kann über einen Performance Monitor den Auslastungsgrad einer Dienstinstanz überprüfen und so eine eintreffende Anfrage an die passende Instanz weiterleiten. Falls eine der Dienstinstanzen ausfällt, wird die Anfragelast auf die übrigen verteilt. So bleibt der Dienst als solcher gesamthaft verfügbar, obwohl im Hintergrund vereinzelte Komponenten ausfallen können. Bleibt hingegen nur eine einzige aktive Dienstinstanz übrig, verkommt der Load Balancing Router unweigerlich zu einem Durchlauferhitzer, da dieser nun eintreffende Nachrichten immer nur an ein und dieselbe Schnittstelle weiterleitet. In diesem Fall spricht man auch von einem 1 zu 1 Routing, da der Router nun mehr als eine Art Wegweiser fungiert. Der Funktionsumfang, den das Intermediate Routing mit sich bringt, ist in der Abbildung 8 zusammengefasst. Student: Marko Marković Seite 14 von 95

7 Abbildung 8: Intermediate Routing 3.4 Reliable Messaging Durch das Reliable Messaging soll eine zuverlässige Kommunikation in einem unzuverlässigen Umfeld realisiert werden können. Da zur jeder Zeit ein Dienst ausfallen könnte oder sehr lange für die Beantwortung von Anfragen brauchen könnte, müssen die Nachrichten vor der eigentlichen Verarbeitung zwischengespeichert werden. Hierfür wird ein Message Repository verwendet, welches den Nachrichtenverkehr in einer Datenbank festhält. Damit der Dienstnutzer auch sicher sein kann, dass seine Nachricht den entsprechenden Dienstanbieter erreicht hat, wird zu jeder erfolgreich übermittelten Anfrage auch eine Bestätigungsmeldung (ACK für Acknowledge) zurückgegeben (vgl. Abbildung 9). Abbildung 9: Reliable Messaging Ein weiterer Vorteil der Message Repository besteht darin, dass nun der Kommunikationsverkehr nachvollziehbar zurückverfolgt werden kann. Alle übermittelten Nachrichten können nun von aussen Student: Marko Marković Seite 15 von 95

8 dank dem Message Repository einfach eingesehen und untersucht werden. Für allfällige Fehlerbehandlungen und Performanceanalysen ist diese Eigenschaft unersetzbar. Leider erweitert der Einsatz der Message Repository hingegen auch die Anforderungen an die zu verwendete Serverhardware der SOA Landschaft. Bei ungenügenden Systemressourcen könnte sich diese schnell als Flaschenhals entpuppen. Zudem muss die Message Repository zwecks Speichernutzung auch regelmässig gewartet werden. 3.5 Policy Centralization In einer SOA können alle möglichen Arten von Diensten angeboten werden. Für einige dieser Dienste möchte man Nutzungsrichtlinien festlegen. Bei Web Services wird dies mit einer sogenannten WS- Policy bewerkstelligt. Diese legt fest, unter welchen Bedingungen (wie z.b. Protokoll, Verschlüsselung usw.) ein Web Service aufgerufen werden darf. Die WS-Policy wird in der Regel innerhalb der WSDL des Web Services Verlink. Als anschauliches Beispiel soll ein Pizzabestelldienst dienen (vgl. Abbildung 10). Abbildung 10: Pizzabestellservice mit integrierter WS-Policy Die Bestellung einer Pizza über den Web Service soll nur mit einem verschlüsselten Aufruf gestattet werden. Es dürfen lediglich zwei Verschlüsselungsmethoden verwendet werden: Basic256 und 3DES. Hierfür wird eine entsprechende Policy Datei SichereBestellung.xml mit folgendem Inhalt vorbereitet: <wsp:policy xmlns:wsp="sicherebestellung"> <sp:transportbinding> <wsp:policy> <sp:algorithmsuite> <wsp:policy> <wsp:exactlyone> <!-- Nur diese Verschlüsselungsmethoden werden gestattet --> <sp:basic256rsa15 /> <sp:tripledesrsa15 /> </wsp:exactlyone> </wsp:policy> </sp:algorithmsuite> <sp:transporttoken> <wsp:policy> <!-- Web Service darf nur über HTTPS aufgerufen werden --> <sp:httpstoken> <wsp:policy/> </sp:httpstoken> </wsp:policy> </sp:transporttoken> Student: Marko Marković Seite 16 von 95

9 </wsp:policy> </sp:transportbinding> </wsp:policy> Auf die genaue Spezifikation von WS-Policy Dateien wird hier nicht weiter Bezug genommen. Die nun soeben erstellte Richtlinie soll nun in die WSDL Datei des Web Services Eingebunden werden. Dafür reicht bereits eine einfache Zeile: <definitions targetnamespace=" <!-- Einbindung der WS-Policy Datei --> <porttype name="ptpizzabestellen" ws:policyuris="pol:sicherebestellung.xml"> <operation name="pizzabestellen"> <input message="tns:msgpizzabestellenrequest"></input> <output message="tns:msgpizzabestellenresponse"></output> </operation> </porttype>... </definitions> Somit ist der Pizzabestelldienst soweit geschützt, dass er nur über verschlüsselte Verbindungen aufgerufen werden darf. Das entscheidende dabei ist, dass dieselbe WS-Policy Datei und die darin enthaltenen Richtlinien auch für andere Web Services wiederverwendet werden können. In einer Unternehmung gibt es Richtlinien, die für alle Dienste gelten. Andere wiederum gelten nur für einzelne Unternehmenssparten. Ein Dienst muss somit unter Umständen mehrere Richtlinien einhalten können. Mittels WS-Polcy Dateien spezifizierte Richtlinien können auch auf andere Richtliniendateien angewandt werden. Somit ist eine hierarchische Strukturierung der Unternehmensrichtlinien für Services möglich (vgl. Abbildung 11). Abbildung 11: Richtlinienhierarchie Dieser Umstand kann zu verschiedenen Problemen führen. Da alle Dienste die vorgeschriebenen Richtlinien einhalten müssen, kann es bei der Implementation zu Inkonsistenzen und Redundanzen kommen, da je nach Service Standort die Richtlinien kopiert werden müssen. Um die Übersicht über Student: Marko Marković Seite 17 von 95

10 die verschiedenen Richtlinien eines SOA Systems nicht zu verlieren, sollten diese global oder subsystemspezifisch an einem zentralen Ort definiert sein. Von diesem Ort aus sollen diese auf alle Services angewandt werden können. Die Rede ist von einer zentralen Richtlinenverwaltung. Um eine zentrale Richtlinienverwaltung einführen zu können, muss ein entsprechendes Framework bereitgestellt werden. Dieses soll bei der Entwicklung eines Dienstes genutzt werden um die Firmenrichtlinien einhalten zu können. Das Framework soll eine gewisse Flexibilität anbieten können, die es erlaubt, neue Richtlinienspezifikationen zur Laufzeit anfügen oder bestehende anpassen zu können. Sind die Unternehmensrichtlinien einmal festgelegt, können diese von Middle Tier Plattformen in Form von ESBs eingebunden werden (vgl. Abbildung 12). Abbildung 12: Durchsetzung der Unternehmensrichtlinien mit Hilfe von WS-Policies 3.6 Rules Centralization Neben den Geschäftsrichtlinien muss sich eine SOA Plattform auch an vordefinierte Geschäftsregeln halten können. Geschäftsregeln legen z.b. fest welche Mitarbeiter oder Dienste welche Aufgaben wahrnehmen dürfen. Man spricht in diesem Zusammenhang auch vom Rules Centralization Pattern. Das Rules Centralization Pattern hat vergleichbare Anforderungen wie die Policy Centralization. Wie bei der Policy Centralization muss die Rules Centralization ebenfalls zentral gehalten werden. Dies kann durch einen zentralen Dienst realisiert werden, der innerhalb der SOA Plattform angeboten wird und die entsprechenden Geschäftsregeln für die anderen Dienste verwaltet. Alle Dienste, welche regelspezifische Sicherheitsinformationen benötigen, beziehen diese von diesem zentralen Regeldienst (vgl. Abbildung 13). Abbildung 13: SOA Plattform Student: Marko Marković Seite 18 von 95

11 Dies bringt zwar die entscheidenden Vorteile, dass alle Regeln an einem Ort zur Laufzeit definiert und Redundanzen vermieden werden können, birgt aber auch viele Nachteile. Neben einer Reduktion der Performance entsteht zwangsläufig ebenfalls eine grosse Abhängigkeit vom Regeldienst. Diese Abhängigkeit stellt ein grosses Risiko dar, falls dieser ausfallen sollte. Eine Möglichkeit um das Risiko zu minimieren, wäre die Bildung von mehreren Regeldienstinstanzen. Dies ist dank dem bereits vorgestellten Intermediate Routing Pattern auch machbar. Unglücklicherweise vergrössert sich dadurch automatisch wiederum die Komplexität des SOA Systems, was sich negativ auf die Wartung auswirkt. 3.7 Event-Driven Messaging Für einige Anwendungsfälle ist es wichtig, dass ein oder mehrere Dienste über bestimmte Änderungen automatisch informiert werden. Dies kann zum Beispiel dann der Fall sein, wenn ein Firmenkunde seine Adresse ändert, ein Mitarbeiter nach vollzogener Heirat seinen Nachnamen ändert oder sich infolge geänderter Gesetzgebung der Mehrwertsteuersatz geändert hat. In allen beschriebenen Fällen sind Systeme betroffen, welche aus diversen Gründen aktuelle Daten für den Betrieb benötigen. Im Idealfall werden diese Daten, welche Änderungen unterzogen sind, an zentralen Orten aufbewahrt und administriert. Da sich im heutigen Zeitalter Unternehmungen in einem schnelllebigen Umfeld behaupten müssen, müssen auch ihre SOA Systeme flexibel auf Erweiterungen sowie Änderungen reagieren können. Neue Dienste müssen einfach der bestehenden SOA Plattform hinzugefügt werden können, ohne dass dafür grosser Aufwand betrieben werden muss. Diesen Herausforderungen stellt sich das Event-Driven Messaging Pattern. Um Polling zu vermeiden werden Änderungen über das Publish-Subscribe Prinzip propagiert. Ein Publisher Dienst ist mit einer Anwendung gekoppelt, welche die unternehmensweite Datenhaltung geschäftsbezogener Daten eines bestimmten Geschäftssegmentes abdeckt. Dies könnte z.b. ein ERP System oder ein Kundenverwaltungssystem sein. Der Publisher meldet diese Änderungen einem Event Manager Dienst. Der Event Manager führt eine interne Liste mit allen registrierten Subscriber Diensten. Sobald dieser eine Nachricht vom Publisher erhält, leitet er diese an die Subscriber weiter. Dieser Sachverhalt wurde in der nachfolgenden Abbildung 14 grafisch dargestellt. Service A (Subscriber) Event Manager Service X (Publisher) Applikation X DB Service B (Subscriber) Service C (Subscriber) Geändert Abbildung 14: Event-Driven Massaging Der Event Manager übernimmt in vielerlei Hinsicht eine massgebende Rolle. Bei Änderungen an den Subscriber muss nur die interne Liste des Event Manager angepasst werden. Auf den Publisher haben diese keinen Einfluss. Ändert sich beim Publisher die Adresse, muss auch diese Änderung lediglich nur im Event Manager nachgetragen werden. Die Subscriber bleiben unverändert. In SOA Systemen ist der Event Manager typischerweise eine Komponente des ESB. Student: Marko Marković Seite 19 von 95

12 Zur Realisation des Event Managers werden das Asynchronous Queuing sowie das Reliable Messaging Pattern implementiert. Mit deren Hilfe wird die zuverlässige Nachrichtenweiterleitung sichergestellt. Student: Marko Marković Seite 20 von 95