Feb21
SOA und EDA

In meinem letzten Artikel, Event Driven Architecture, habe ich Event getriebene Architekturen beschrieben und kurz den Unterschied zu Service Orientierten Architekturen angerissen. Jetzt stelle und beantworte ich die Frage, welche Architektur ist die bessere? Service Oriented Architecture (SOA) oder Event Driven Architecture (EDA)?

Meiner Ansicht nach gibt es kein besser oder schlechter, kein richtig oder falsch.
Es hängt davon ab, was man erreichen möchte und in welchem Umfeld man sich bewegt. Grundsätzlich dienen IT Systeme einem fachlichen Zweck. Und auch bei der Wahl der Architektur spielt die Fachlichkeit eine Rolle, bzw. die fachliche Denkweise. Wird in Prozessen und Abläufen gedacht, ist SOA mit BPM (Business Process Management) die passende Architektur. Wird dagegen in Geschäftsereignisse gedacht, bietet sich eine EDA an. Es ist von Vorteil, wenn Fachlichkeit und Technik die gleichen Denkstrukturen haben, das erleichtert die Kommunikation zwischen Fachbereich und IT.
Im Umfeld von IoT ist die EDA erste Wahl. Denn hier gibt es viele verschiedene Geräte, die oft bezüglich Netzanbindung, Akku und Performance eingeschränkt sind und die Informationen über Events austauschen. Der klassische SOA Ansatz mit Web Services kann hier zu schwergewichtig und ungeeignet sein.
Im Umfeld von Geschäftsprozessen hängt die Wahl von den Anforderungen ab. Wenn man immer gleich ablaufende Geschäftsprozesse hat, die a priori definiert sind, sind orchestrierte Services das richtige Mittel. Von Anfang an auf Events zu setzen ist dagegen dort sinnvoll, wo viel Flexibilität und Variation in Geschäftsprozessen notwendig ist.

Manche definieren die Kombination aus SOA und EDA als SOA 2.0. Dabei werden Events meist für das Monitoring verwendet, der fachliche Ablauf ist komplett im Prozess definiert. Die Events in der SOA 2.0 sind für mich aber mehr als nur Ereignisse im Prozess, die als Key Performance Indicatos (KPI) an ein Business Activity Monitoring gesendet werden. Es geht für mich mehr in Richtung Adaptive Case Management, bei dem der Ablauf im Geschäftsprozess auf Basis von Ereignissen und Informationen veränderbar ist.
Man muss sich das vorstellen wie eine Reise bei der man von A nach B möchte. Wird mit der Bahn gefahren fährt man auf vorgegebenen Schienen. Die Route kann man nicht ändern. Das entspricht dem klassischen normativen Prozess. Fährt man dagegen mit dem Auto, wird man vom Navi geleitet, das die Route dynamisch ändert, wenn z.B. auf der geplante Route ein Stau ist. Das Navi macht aber nur einen Vorschlag und man kann selbst entscheiden, wie man fährt. Das entspricht dem Adaptive Case Management. Der Weg von A nach B wird auf Basis von Ereignissen und Erfahrungswissen angepasst.

Technisch gesehen geht es bei beiden Architekturen darum eine Nachricht zu versenden. Bei SOA ist es eine gerichtete Kommunikation an einen dedizierten Empfänge, bei der EDA werden Informationen an beliebige Empfänger publiziert. Damit wird ein höherer Grad der Entkopplung erreicht.
Aber selbst hier kann man sich eine Kombination vorstellen. Beispiel: eine Produktsuche. Das ist im ersten Blick ein Service der über ein Request-Response Kommunikations-Muster aufgerufen wird. Also eine gerichtete Kommunikation. Es kann aber nebenläufige Systeme geben, die alle Produktsuchen analysieren um z.B. die beliebtesten Produkte zu identifizieren. Diese Systeme können direkt die Service-Requests analysieren. In diesem Fall wäre die Produktsuche ein Ereignis das nicht gerichtet ist. Wichtig ist also, dass der Consumer nur eine Nachricht asynchron auf einen Nachrichten-Kanal stellt. Ob diese Nachricht jetzt nur von der Produktverwaltung beantwortet oder noch von anderen Systemen parallel verarbeitet wird, muss für den Consumer egal sein. Diese Verteilung der Nachricht (Routing) erledigt eine Middleware.
Allerdings muss wohl überlegt sein, ob diese Kombination, eine Nachricht ist Service-Call und Event gleichzeitig, wirklich sinnvoll ist. Streng genommen müsste der Service-Call ein Event auslösen. Denn der Service-Call sagt was getan werden soll, das Event sagt was passiert ist. Beim Event könnten auch andere Informationen relevant sein, wie z.B. die gefundenen Produkte. Auch an diesem Beispiel ist wieder zu sehen, die Fachlichkeit ist die entscheidende treibende Kraft.

Die EDA punkten also mit Flexibilität und mehr Entkopplung, die SOA / BPM mit einem eindeutig definierten und lesbaren Ablauf. Es bleibt also festzuhalten das SOA und EDA eine Daseinsberechtigung haben, bestimmte Aspekte adressieren und kombiniert werden können. Die pauschal bessere Architektur gibt es nicht. Für die Wahl der Architektur sollten in erster Linie fachliche Aspekte Entscheidungstreiber sein. Aber auch technische Aspekte spielen eine Rolle, wie bei IoT Systemen. In diesem Fall sollte aber auch fachlich in Events gedacht werden.
Folgende Orientierung hilft bei der Entscheidung: Müssen klar definierte Abläufe ohne Ausnahmen umgesetzt werden und es kann klar definiert werden, was in welcher Reihenfolge passieren soll, dann bietet sich die SOA an. Muss auf Ereignisse reagiert werden und die weiteren Aktionen basieren auf der Analyse der Ereignisse, bietet sich die EDA an.

 

Ein Kommentar zu “
Feb21
SOA und EDA

  1. Pingback: Event Driven Architecture | discoveration

Schreibe einen Kommentar

Anmelden um einen Kommentar abzugeben.

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*