Suche
Business Process Service Architecture

Prozessmanagement in einer Microservices-Architektur – passt das zusammen?

Ralph Soika
shutterstock_276242615

© Shutterstock / bleakstar

Mit dem neuen Architekturansatz der Microservices lassen sich scheinbar ohne viel Aufwand monolithische Anwendungen in lose gekoppelte Services zerlegen. Aber was passiert eigentlich mit der Geschäftslogik? Wie können bestehende Geschäftsprozesse in einer Microservices-Architektur sinnvoll umgesetzt werden?

Wenn es heute in Diskussionen um moderne Softwarearchitektur geht, gehören Microservices längst zum guten Ton. Sie folgen einem leichtgewichtigen Lösungsansatz, der einen Gegenpol zu den meist über Jahre gewachsenen monolithischen Unternehmensanwendungen ist. In einer monolithischen Enterprise-Applikation werden die Businesslogik, die Datenbankschicht und auch das UI in einem gemeinsamen Kontext behandelt. Dieser umfasst in der Regel alle Aspekte des dahinterliegenden Geschäftsprozesses, z. B. einer Auftragsabwicklung. Mit zunehmender Komplexität wachsen aber meist auch die Probleme. Da große Softwaresysteme von Natur aus schwieriger zu managen sind, scheinen heute Microservices die passende Lösung zu sein, um Fehler aus der Vergangenheit zu umgehen und gewachsene Komplexität zu verringern. Aber ist es wirklich so einfach, eine Enterprise-Anwendung in lose gekoppelte Services aufzuteilen (Abb. 1)?

Auf den ersten Blick erscheint es zunächst naheliegend, die Geschäftslogik einer Enterprise-Anwendung in einzelne isolierte Services aufzuteilen. Doch häufig enden diese Projekte in einem verteilten System mit mehr oder weniger eng gekoppelten Serviceschichten. Der Grund hierfür ist häufig die Datenbankschicht, die als monolithischer Block in einer Microservices-Architektur überlebt und damit gegen das Konzept des Bounded Context verstößt – also einem Modell, das klare Grenzen zur Außenwelt zieht. Das führt dann in der Folge oft zu sehr komplexen Problemen bei der Synchronisation zwischen den unterschiedlichen Services und Teams. Eine Änderung in der Datenbankschicht betrifft dann schnell mehrere, eigentlich voneinander getrennte Services.

Abb. 1 Monolithische Enterprise-Applikation vs. Microservices mit gemeinsamer Datenbank

Abb. 1 Monolithische Enterprise-Applikation vs. Microservices mit gemeinsamer Datenbank

Ein möglicher Lösungsansatz ist hier eine konsequente Auftrennung in sogenannte Verticals. Hier werden die Geschäftslogik und die Datenbank jeweils in einen vertikalen Service zusammengefasst, um so die Abhängigkeiten über die gemeinsame Datenbank aufzulösen.

Abb. 2 Entkopplung über synchrone und asynchrone Events

Abb. 2 Entkopplung über synchrone und asynchrone Events

Typischerweise erfolgt die Kommunikation zwischen den Services hier über das Versenden von synchronen oder asynchronen Nachrichten. So kann die Businesslogik eines einzelnen Microservices von den übrigen Services entkoppelt werden (Abb. 2). Aber löst dieser Ansatz wirklich die Probleme eines monolithischen Anwendungssystems, oder entstehen dadurch Probleme von ganz neuer Qualität?

Was machen wir mit dem Geschäftsprozess?

Ein Problem, das durch die Auftrennung einer Geschäftsanwendung in einzelne Services entsteht, ist die Tatsache, dass auch das neue System immer noch eine übergreifende Businesslogik aufweisen muss, die als Geschäftsprozess bezeichnet wird. Schauen wir uns dazu einmal das System in Abbildung 2 an. Hier wurde eine Enterprise-Anwendung zur Auftragsabwicklung in die einzelnen Services Order Service, Invoice Service und Logistic Service aufgetrennt. Die Services sind sauber über ein Event-basiertes Nachrichtensystem voneinander entkoppelt. Doch was ist nun mit dem übergeordneten Geschäftsprozess passiert? War dieser in der monolithischen Enterprise-Anwendung noch als Code eng in die einzelnen Module eingeflochten, fehlt dieser Zusammenhang in der neuen Architektur, deren Ziel ja die Entkopplung ist.

Nehmen wir zum Beispiel an, dass ein bestellter Artikel erst dann an den Kunden ausgeliefert werden darf, nachdem eine Rechnung versendet wurde. Es ist also nicht ausreichend, wenn in unserem Beispiel der Invoice und Logistic Service unabhängig voneinander auf ein technisches Ereignis des Order Services (z. B. NEW-ORDER-CREATED) reagieren, ohne dabei den Zustand des übergreifenden Geschäftsprozesses zu beachten (Abb. 3).

Um das Problem zu lösen, können wir damit beginnen, die Nachrichten, die ein Service versendet, stärker an die Fachlichkeit zu binden. Dazu können wir unterschiedliche Events für jede Phase des Auftragsprozesses definieren, die dann von den einzelnen Serviceschichten versendet oder empfangen werden. In Abbildung 4 sendet nun der Order-Service eine Nachricht vom Typ ORDER-READY-FOR-INVOICING, die vom Invoice Service ausgewertet wird. Dieser wiederum sendet daraufhin eine Nachricht vom Typ ORDER-READY-FOR-SHIPMENT, um den Logistic Service die Freigabe für den Versand des Produktes zu signalisieren.

Abb. 3: Paralleler Nachrichtenversand

Abb. 3: Paralleler Nachrichtenversand

Abb. 4: Sequenzieller Nachrichtenversand

Abb. 4: Sequenzieller Nachrichtenversand

Doch was ist nun passiert? Die Prozesslogik ist nun über alle Serviceschichten verteilt, wodurch wir erneut das Problem einer engen Kopplung erschaffen haben. Das wollten wir eigentlich durch die Auftrennung der gemeinsamen Datenbank auflösen. Ändert sich der Geschäftsprozess, müssen unter Umständen weitere Nachrichtentypen eingeführt werden, die den entsprechenden neuen Zustand des Prozesses abbilden. Dies führt unweigerlich zu Änderungen in allen betroffenen Services. Es hat sich also lediglich die technische Ebene bei der Behandlung unserer Geschäftslogik verschoben.

Die Business-Process-Service-Architektur

Um den hier beschriebenen Effekt der engen Kopplung von Microservices über die Geschäftslogik zu vermeiden, besteht die Idee einer Business Process Service Architecture darin, den Geschäftsprozess selbst als eigenständigen Microservices umzusetzen. Die übergreifende Businesslogik wird dabei in einen Business Process Service ausgelagert, der als eigenständiger Service in die bestehende Architektur eingebunden wird (Abb. 5).

Abb. 5: Der Business Process Service

Abb. 5: Der Business Process Service

In dieser Architektur kommuniziert jeder Service lediglich mit dem Business Process Service und ist nur von diesem abhängig. Der Vorteil: Die Geschäftslogik wird nur noch von einem einzelnen Service behandelt, der hier in die Rolle des Central Coordinators schlüpft. Änderungen am Geschäftsprozess werden nur noch an einer einzigen Stelle abgebildet. Der Business Process Service stellt nach außen ein einheitliches REST-API zur Verfügung, das es den einzelnen Services erlaubt, den Status des Geschäftsprozesses abzufragen und Änderungen des eigenen Zustandes an diesen zu kommunizieren.

BPMN 2.0

Eine der heute am häufigsten verwendeten Technologien zur Beschreibung eines Geschäftsprozesses ist die Business Process Model and Notation – kurz BPMN 2.0. BPMN wurde ursprünglich entwickelt, um einen Geschäftsprozess fachlich, ohne die technischen Details eines Softwaresystems zu beschreiben. Ein BPMN-Diagramm ist daher leicht zu verstehen und ein guter Ausgangspunkt für Management und Entwickler, gemeinsam über einen Geschäftsprozess zu diskutieren. Neben der allgemeinen Beschreibung eines Geschäftsprozesses kann ein BPMN-Modell seit Version 2.0 auch von einer Prozess- oder Workflow-Engine ausgeführt werden. Ein Workflow-Managementsystem kann damit einen Prozess ausführen und überwachen. Damit eignet sich BPMN 2.0 sehr gut, um das Modell für einen Business Process Service zu beschreiben.

Microservices plus Business Process Services: das Vorgehensmodell

Um eine Microservices-Architektur mithilfe eines Business Process Services zu implementieren, muss zunächst der übergreifende Geschäftsprozess beschrieben werden. Dieser Geschäftsprozess bildet sämtliche Arbeitsabläufe innerhalb einer Organisation ab, die mit dem System implementiert werden sollen. Es können bei der Beschreibung des Prozesses neben den technischen Systemen auch sogenannte Human-centric Workflows betrachtet werden. Das sind Abläufe, die eine menschliche Interaktion erfordern und damit nicht vollständig durch einen technischen Service abbildbar sind. Ein Beispiel hierfür ist die Auslieferung eines Produkts, die in der Regel manuell durch einen Mitarbeiter erfolgt. Der Prozess wird dazu durch einen Human-Task zunächst unterbrochen. Meldet der Akteur, dass die Aufgabe abgeschlossen ist, wird der Prozessablauf fortgesetzt. Ein Workflow-Managementsystem überwacht einen manuellen Task und kann gegebenenfalls eine Eskalation auslösen, wenn die Bearbeitung nicht im festgelegten Bearbeitungszeitraum erfolgt (Eskalation). An diesem Beispiel wird deutlich, dass der Business Process Service eine weit umfangreichere Rolle in der Prozessarchitektur spielen kann als nur die Verwaltung von Zuständen. Abbildung 6 zeigt ein BPMN-Modell aus dem zuvor besprochenen Szenario einer Auftragsverwaltung. Das Modell bildet zum einen den übergreifenden Workflow Order Management ab und stellt zum anderen je einen Subprozess für jeden der drei Microservices bereit.

Abb. 6: BPMN-2.0-Diagramm

Abb. 6: BPMN-2.0-Diagramm

Das Modell ist sehr einfach gehalten und soll nur die wichtigsten Aspekte des hier vorgestellten Konzepts verdeutlichen. Das BPMN-Modell wurde mithilfe des Eclipse-Plug-ins Imixs-BPMN erstellt und kann über die Imixs-Workflow-Engine auch ausgeführt werden.

Starten einer neuen Prozessinstanz

Bevor ein einzelner Service innerhalb einer Microservices Architektur aufgerufen wird, muss in der Regel ein externes Ereignis eingetreten sein, das den Geschäftsprozess auslöst. In unserem Beispiel ist dies der Empfang einer neuen Bestellung. Eine neue Bestellung kann dabei entweder manuell durch einen Mitarbeiter ausgelöst werden, oder aber automatisiert durch ein anderes IT-System, z. B. einen Onlineshop, angestoßen werden.

Wird eine neue Bestellung manuell ausgelöst, kann diese z. B. über ein Web Frontend vom Mitarbeiter erfasst und an den Business Process Service gemeldet werden. Dadurch wird eine neue Instanz des Prozesses Order Management erzeugt. Fachliche Daten, z. B. eine Kundennummer, können dabei direkt an den Service übertragen werden. Das BPMN Event new Order Process löst nun automatisch den Subprozess Order aus. Dieser Subprozess ist einem konkreten Microservices zugewiesen – hier Order Service. Der Order Service wird nun über eine REST-Serviceschnittstelle durch den Business Process Service aufgerufen, um so den neuen Bestelldatensatz in einer Datenbank anzulegen.

Wird hingegen die Bestellung automatisiert ausgelöst, beispielsweise durch einen Onlineshop, wird der Geschäftsprozess direkt über einen entsprechenden REST Service Call ausgelöst. Auch hier wird dann der entsprechende Subprozess Order gestartet. Damit ist das Modell für unterschiedliche Ausgangssituationen geeignet. Der entscheidende Punkt ist hier, dass nach Erhalt einer neuen Bestellung immer sowohl eine neue Instanz des Prozesses Order Management gestartet wird, die den Gesamtzustand des Bestellvorgangs abbildet, sowie eine Prozessinstanz Order, die den Status innerhalb des Microservices Order Service abbildet. Dadurch erfolgt auch innerhalb des Prozessmodells eine Trennung analog zu unserer Microservices-Architektur. Auf der anderen Seite sind beide Prozesse innerhalb des Modells eng miteinander gekoppelt, wodurch das Geschäftsmodell konsistent und valide bleibt.

W-JAX
 
Christian Schneider

Schlimmer geht immer – eine Auswahl der Top-10-Hacks der letzten Jahre

mit Christian Schneider (Christian Schneider IT-Security)

Überwachung des Prozesses

Nachdem eine neue Prozessinstanz Order Management gestartet wurde, können wir nun den Prozess einschließlich seiner Subprozesse über den Business Process Service von außen überwachen, ohne dabei auf die einzelnen Microservices zugreifen zu müssen. So kann ein Workflow-Management-UI beispielsweise einem Vertriebsleiter Statusinformationen über aktuelle Aufträge zur Verfügung stellen. Diese Person hat in der Regel nur eine High-Level-Sicht auf den Prozess, die der Order-Management-Prozess vollständig abbildet. Auf der anderen Seite können Monitoring-Systeme detaillierte Informationen zu einzelnen Teilprozessen abfragen. So kann z. B. ein System die erwartete Last in unterschiedlichen Datenbanken überwachen, indem es die Anzahl der erwartenden Prozessinstanzen prüft. Das Modell kann leicht mit zusätzlichen Tasks oder Events erweitert werden, um unterschiedliche Eigenschaften eines komplexen Prozesses abzubilden.

Prozesse steuern

Neben der Überwachung eines Geschäftsprozesses bietet der Business-Process-Service auch die Möglichkeit, Prozesse zu steuern, ohne dabei die Prozesslogik in einem der Microservices abbilden zu müssen. Wie in Abbildung 6 gezeigt, wird für jeden Microservices ein eigener Subprozess modelliert. Nur der Service, der einem konkreten Subprozess zugeordnet wurde, kann die dort definierten Events aufrufen. Dazu validiert der Business Prozess Service sämtliche Aufrufe von außen anhand des BPMN-Modells. So kann zum Beispiel der Order Service ein entsprechendes Event an den Business Process Service senden, sobald die neue Bestellung in der Datenbank eingetragen wurde. Das Event wird mit dem übergreifenden Geschäftsprozess verknüpft, der daraufhin den Zustand des Gesamtprozesses aktualisiert. Das Workflow-Managementsystem stößt daraufhin automatisch den nächsten Subprozess Invoice an, der wiederum mit dem Microservices Invoice Service verknüpft ist. Es können nun von unserem Order Service keine weiteren Events mehr gesendet werden, da dessen Subprozess bereits beendet ist. Ein entsprechender Aufruf würde zu einer Exception führen. Umgekehrt kann jeder Microservices durch einen entsprechenden REST-Service-Aufruf an den Busines Process Service auch seinen eigenen Zustand überwachen und mögliche Events abfragen. Dadurch kann nun sogar die Businesslogik generisch für alle Service auf dieselbe Weise umgesetzt werden. Wie Abbildung 7 zeigt, können dazu für jeden Subprozess die Events success und error modelliert werden, die entweder im Erfolgs- oder Fehlerfall aufgerufen werden können.

Abb. 7: Generische Events

Abb. 7: Generische Events

Somit können wir jetzt den Prozess vollständig durch den Business Process Service steuern und haben damit die Geschäftslogik aus den einzelnen Microservices weitgehend entfernt. Gleichzeitig können auch einzelne Akteure über Human-Tasks in den Geschäftsprozess einbezogen werden. Beispielsweise kann ein Mitarbeiter der Logistikabteilung per E-Mail durch die Workflow Engine informiert werden, sobald ein Produkt versendet werden darf.

Prozesse ändern

In einer produktiven Umgebung wird ein Prozessmodell aus vielen unterschiedlicher Tasks und Events bestehen, um den Geschäftsprozess auf unterschiedliche Weise steuern zu können. Ein Vertriebsleiter kann beispielsweise die Möglichkeit erhalten, den Gesamtprozess manuell zu unterbrechen. Eine solche Statusänderung wirkt sich dann unmittelbar auf alle noch aktiven Subprozesse aus, indem diese gestoppt werden. Je nach verwendeter Workflow-Engine können die Prozessmodelle auch während der Laufzeit geändert werden, ohne dass dazu Anpassungen an den verbundenen Microservices oder ein Re-deployment notwendig werden.

Fazit

Vieles von dem, was heute meist hart codiert in der Businesslogik eines Microservices abgebildet wird, kann durch die Business Process Service Architecture nun in ein Prozessmodell übertragen werden. Neben der Kontrolle des Geschäftsprozesses kann ein Business Process Service auch jede Art von Metainformationen aus einzelnen Services sammeln und anderen Services zur Verfügung stellen. Damit wird der Business Process Service zum Central Point of Information innerhalb einer Microservices-Architektur und hilft dabei, die Synchronisationsprobleme zwischen den einzelnen Services aufzulösen. Für die Umsetzung einer solchen Architektur sind natürlich auch Erfahrungen in der Geschäftsprozessmodellierung erforderlich. Die Auswirkungen dieser Architektur können jedoch beeindruckend sein, vor allem, wenn die Workflow Engine selbst bereits viele Funktionen der Businesslogik abdeckt. So können z. B. mit dem Open-Source-Projekt Imixs Workflow, E-Mail-Nachrichten versendet oder Aufgaben an verschiedene Akteure im Unternehmen verteilt werden. Auch die Überwachung von Abläufen und die Protokollierung einzelner Prozessschritte kann mit einer Workflow Engine abgebildet werden.

Das Konzept einer Business-Process-Service-Architektur zeichnet sich durch eine hohe Flexibilität bei der Umsetzung von Geschäftsprozessen und unterstützt gleichzeitig die Entkoppelung einzelner Services. Wir können jetzt unser Geschäftsprozessmodell ändern, ohne dabei bestehende Implementierungen in einzelnen Services zu gefährden und haben damit tatsächlich unsere Services voneinander entkoppelt. Dies macht das Konzept sehr mächtig und bietet gleichzeitig eine einfache und elegante Möglichkeit, dem Ziel eines agilen Prozessmanagements einen Schritt näher zu kommen.

Geschrieben von
Ralph Soika
Ralph Soika
Ralph Soika ist Projectlead im Open-Source-Projekt Imixs-Workflow und Geschäftsführer der Imixs GmbH. Er berät Unternehmen bei der Einführung von Geschäftsprozessmanagementlösungen und Architekturen. Ralph Soika entwickelt BPM-Systeme im Java-EE-Umfeld und ist Commiter im Open-Source-Projekt Eclipse BPMN2 Modeler.
Kommentare
  1. Ralph Soika2017-01-04 23:21:05

    Informationen über das Imixs-Workflow Projekt finden Sie unter:
    http://www.imixs.org

Hinterlasse eine Antwort

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