Abkündigen inkompatibler BusinessEvents

Das Abkündigen inkompatibler BusinessEvents ist etwas komplizierter als das Abkündigen synchroner Services.

Beispiel eines inkompatiblen Events

Gegeben sei das Event BuecherAusgeliehen, das in Schleupen.CS wie folgt modelliert wird:

Entfernt man nun die ChangeInfo, so wird dieses technisch inkompatibel:

Auslöser und Konsument hätten dann verschiedene Versionen ...

... und der Konsument würde das Pflichtfeld nicht mehr erhalten. Die Änderung ist nicht aufwärtskompatibel. Aufwärtsinkompatibilität ist in der Regel technisch problematisch, da z.B. im Request ein Pflichtfeld hinzukommt, Abwärtsinkompatibilität semantisch. In beiden Fällen wird eine inkompatible Version erstellt.

Inkompatible Synchrone Services werden abgekündigt und innerhalb eines definierten Zeitraums muss auf die neue Version umgestellt werden, sofern kein Veto eingelegt wird. Technisch gesehen ist das synchronen Services unkompliziert.

Bei BusinessEvents kommt im Vergleich zu synchronen Services hinzu, dass Nachrichten des vorherigen Formats nach der Installation einer neuen Version noch in einer Queue vorhanden sein können. Diese müssen bindend noch verarbeitet werden, obwohl die neue Software auf einem System installiert ist.

Schauen wir uns hierzu ein einfaches Beispiel an, um das Problem zu verdeutlichen. Ein Publisher habe ursprünglich ein Event in der Version v1 ausgelöst und möchte nun das inkompatible Event v2 auslösen.

Würde nun der Publisher einfach ab einem Zeitpunkt nur Event v2 und nicht mehr v1 auslösen, so müssten alle Subscriber ab diesem Zeitpunkt v2 konsumieren können. Organisatorisch ist dies i.A. kaum zu realisieren (organisatorisch Team-Kopplung). Daher muss der Publisher für einen gewissen Zeitraum v1 und v2 parallel auslösen.

Vor der Installation einer neuen Version des Subscribers, der schon das Event in der Version v2 konsumiert, sieht dies wie folgt aus.

Würde der Subscriber nach Installation nur noch Events der Version v2 konsumieren, so können Nachrichten verloren gehen, weil diese noch in der Queue Q1 vorhanden sein können oder die Queue gelöscht worden ist.

Als Konsequenz muss der Subscriber für einen gewissen Zeitraum Events der Versionen v1 und v2 konsumieren. Die entscheidende Frage dann ist: Wie erkennt der Subscriber, dass ein
Event redundant ausgelöst wird? Welche Version soll er zu welchem Zeitpunkt verwenden?

Vorgehen

Das Vorgehen ist so gewählt worden, dass das Abkündigen von Events mit der bestehenden Technik möglich ist. Zudem soll das Abkündigen veralteter Commands äquivalent möglich sein. Zudem sollen - wie oben beschreiben - die Subscriber Zeit haben, um auf die neue Version eines Events zu wechseln (siehe Abkündigungsprozess).

Ausgangssituation

Die Ausgangssituation ist einfach: ein Publisher löst ein Event in der Version v1 aus und ein Subscriber konsumiert dieses mittels Queue Q1.

Publisher stellt neue Version bereit

Zunächst löst der Publisher das neue Event v2 zusätzlich, also redundant aus.

Subscriber konsumiert beide Versionen von Events

Der Subscriber implementiert nun einen Consumer für die Version v2.

Damit der Subscriber nun einfach entscheiden kann, ob es eine noch nicht verarbeitete Nachricht der Version v1 oder eine neu ausgelöste handelt, wird der Nachricht immer ein Erstellungsdatum der Nachricht mitgegeben (CreatedAt). Über ein Konfigurationswert (BoundToV2Since) wird festgesetzt, ab wann die Queue Q2 existiert, d.h. die neuen Events empfangen werden können. Dieser wird einfach über ein Konfigurationsskript gesetzt, da zu diesem Zeitpunkt keine Nachrichten verarbeitet und zugestellt werden (BusinessEventDispatcher ist heruntergefahren, etc.).

Anhand des Zeitstempels der Nachricht und des Werts von BoundToV2Since kann der Subscriber nun jeweils entscheiden, ob die Nachricht v1 oder v2 zu verarbeiten ist.

Publisher löst nach Ankündigungszeitraum nur noch Event v2 aus

Nachdem Ankündigungszeitraum, in dem alle Subscriber auf die neue Version umgestellt haben müssen, wird beim Publisher das Auslösen von Events der Version v1 entfernt.

Subscriber konsumiert nicht mehr die veraltete Version

Auch der Subscriber konsumiert nicht mehr die Version v1.

Optimierung: Diese kann ggf. schon bei vorigen Installationen nach Abwägung erfolgen.