Let it flow!

Nachrichtenfluss in einer SOA

Kristian Köhler

SOA-Lösungen sollen lose gekoppelt und flexibel sein. Das primäre Ziel ist, auf neue Geschäftsanforderungen schnell reagieren zu können. Ein starrer Nachrichtenfluss, also die feste und aufwändige Verdrahtung von einzelnen Diensten, ist hierbei allerdings kontraproduktiv. Die eingesetzte Routing Engine zur Steuerung des Nachrichtenflusses muss dementsprechend möglichst einfach konfigurierbar und flexibel sein.

Mit dem Begriff der serviceorientierten Architektur (SOA) wird ein Architekturstil beschrieben, mit dem einzelne Dienste möglichst lose gekoppelt werden. Komplette Geschäftsprozesse lassen sich über Interaktionen dieser Dienste abbilden. Ziel ist es, möglichst schnell auf neue Anforderungen durch Erstellen oder Anpassen der entsprechenden Geschäftsprozesse reagieren zu können. Eine Veröffentlichung dieser Prozessdienste ermöglicht mehreren Anwendungen darauf zuzugreifen und diese entsprechend zu nutzen. So  kann z.B. eine Verfügbarkeitsprüfung sowohl innerhalb eines Webshops als auch in einer Rich-Client-Anwendungen im Kundencenter verwendet werden.

Die Kommunikation der einzelnen Dienste untereinander erfolgt über Nachrichten, für deren Nachrichtenfluss so genannte Routing Engines eingesetzt werden. Sie besitzen die Aufgabe, die Nachrichten zwischen den einzelnen Diensten zu vermitteln. Mit ihrer Hilfe lassen sich auch einfache Geschäftsprozesse abbilden. Grundanforderung an eine solche Engine sollte sein, dass sie leicht konfigurierbar und flexibel im Einsatz ist. Schließlich möchte man nicht schon durch die Infrastruktur die Flexibilität einer SOA verlieren.

Nachrichtenfluss als Prozessabbildung?

In der Regel handelt es sich bei den ausgetauschten Nachrichten um Informationen im XML-Format, und in den einfachsten Fällen besteht die Abbildung eines Geschäftsprozesses darin, den reinen Nachrichtenfluss zwischen den Diensten zu steuern. Eventuell muss das Format der übermittelten Nachrichten noch an das Format des Zieldienstes angepasst werden. In den von Gregor Hohpe und Bobby Woolf beschriebenen Enterprise Integration Patterns finden sich hierzu einige so genannte Message Routing Patterns, die für diese Aufgaben herangezogen werden können. Ein einfaches Beispiel ist das „Content-Based Router“ Pattern, bei dem eine Nachricht abhängig vom Inhalt an verschiedene Empfänger übermittelt wird. So kann z.B. bei der oben genannten Verfügbarkeitsprüfung anhand des Nachrichteninhalts ermittelt werden, welches System angefragt werden soll. In diesem Fall kann eine einfache Nummernkreiszuordnung für die einzelnen Systeme völlig ausreichen.

Abb. 1: Content-Based Router

Für einfache Anforderungen ist eine solche reine Datenflusskontrolle ausreichend und wird in vielen Produkten bereits von Haus aus über Konfiguration angeboten. Bei dem JBI-basierten ESB Apache ServiceMix wird z.B. die servicemix-eip-Komponente mitgeliefert, in der die gängigsten Patterns bereits umgesetzt sind und nur noch an die eigenen Anforderungen angepasst werden müssen.

Die Konfiguration für einen Content-Based Router mit der ServiceMix-Komponente können Sie in Listing 1 sehen. In diesem Beispiel wird über den XPath-Ausdruck /art/articleNumber aus der Nachricht die Artikelnummer gelesen und auf einen Prefix geprüft. Beginnt die Nummer mit ‚xx‘ wird die Nachricht an den Dienst ‚dmc:lieferant1‘ weitergeleitet, anderenfalls wird die Nachricht an den Standardlieferanten, hier ‚dmc:lieferant2‘, versendet. Ein aufrufendes System müsste seine Nachricht an den Prozessdienst ‚dmc:router‘ senden.

Bei komplexeren Szenarien stoßen diese „statischen“ Konfigurationen allerdings rasch an ihre Grenzen und werden schnell unübersichtlich. Eine zusätzliche Transformation der Nachricht pro Zielsystem würde jeweils einen weiteren Serviceeintrag erfordern und die Konfiguration zusätzlich weiter verkomplizieren. Mag die Abbildung von Geschäftsrozessen mittels ESB-Bordmitteln in kleineren Szenarien noch sinnvoll erscheinen, so ist es bei steigenden Anforderungen meist nicht mehr praktikabel. Klar muss sein, dass bei einem solchen Ansatz Bus-Funktionalität zur Abbildung von Prozessen „missbraucht“ wird. Weitergehende Prozessfunktionalität sollte bei JBI-basierten ESBs, z.B. innerhalb von so genannten Service Engines, durchgeführt werden.

Geschrieben von
Kristian Köhler
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.