Service-Lebenszyklus

Da Software ständig angepasst wird, schlagen diese Änderungen natürlich auch auf Service-Schnittstellen deren Implementierung sowie den Business Events durch. Aber bevor wir zeigen, wie wir damit umgehen, müssen wir zunächst klären, wann und wie Änderungen sich für den Nutzer auswirken.

Kompatibilität von Services

Unter der Kompatibilität von Services versteht man die Möglichkeit, einen Service auch nach Änderung der bereitgestellten Schnittstellendefinition weiterhin nutzen zu können. Ist eine neuere Serviceversion beispielsweise nicht mehr ohne Anpassung des Clients aufrufbar, so ist diese inkompatibel zur Vorgängerversion. Unterschieden wird hierbei bzgl. der sogenannten Aufwärts- und Abwärtskompatibilität, die im Folgenden erläutert wird.

Abwärtskompatibilität

Im Folgenden betrachten wir zunächst die Abwärtskompatibilität für den allgemeinen Fall. Gegeben sei hierbei ein API in der Version v1 mit genau einer Schnittstelle.

Der Client ist hierbei der Nutzer dieser Schnittstelle, der Provider stellt eine Implementierung dieser Schnittstelle bereit. Nun muss eine neue Version dieser API samt Schnittstelle erstellt werden, indem die Schnittstelle angepasst wird. Dieses neue API habe die Version v2. Der Provider implementiere nun die neue Version der Schnittstelle.

Wenn der Client, der nach wie vor die Version v1 der Schnittstelle verwendet, weiterhin die Schnittstelle nutzen kann, so spricht man von Abwärtskompatibilität, da gedanklich die Schnittstelle v2 abwärts über v1 nutzbar ist. Kann die Schnittstelle nicht mehr genutzt werden, so ist diese abwärts inkompatibel.

In Schleupen.CS werden Schnittstellen auf Makroebene durch WSDLs beschrieben - sowohl für synchrone als auch asynchrone Kommunikation.

Aufwärtskompatibilität

Auch hier betrachten wir zunächst den allgemeinen Fall, bei dem eine Schnittstelle in der Version v1 über ein API gegeben sei. Auch hier sei der Client der Nutzer und der Provider die Implementierung dieser Schnittstelle.

Nun wird wie im obigen Fall die Schnittstelle zur Version v2 geändert. Nun kennt lediglich der Client diese neue Version, der Provider nach wie vor die alte Schnittstellen-Version.

Kann der Client nun weiterhin diese Schnittstelle nutzen, so spricht man von Aufwärtskompatibilität, da die "alte" Implementierung aufwärts aus Nutzersicht über v2 nutzbar bleibt. Ist dies nicht der Fall, so sagt man, dass die Schnittstelle v2 aufwärts inkompatibel zur Version v1 ist.

In Kompatibilitätsmatrix ist im Detail beschrieben, wann ein Service inkompatibel wird!

Versionierung

Eine in Schleupen.CS definierte Versionsnummer hat bis zu vier Stellen und entspricht ab der zweiten Stelle dem Semantic Versioning.

• 1. Stelle: Architektur (z.B. 3 für CS 3); Änderung drückt Inkompatibilität aus
• 2. Stelle: Änderung drückt eine inkompatible Änderung aus
• 3. Stelle: Änderung drückt eine kompatible Änderung aus
• 4. Stelle: Revision, nur informatorisch, Änderung ohne Auswirkung auf Syntax oder Semantik

Ändert sich eine der ersten beiden Stellen, ist die neue Version nicht mehr abwärtskompatibel zur Vorgängerversion. D.h. nutzende Aufrufer müssen angepasst werden. Die Dokumentation der neuen Version der Schnittstelle enthält Hinweise zu den Änderungen. Diese können syntaktisch (Aufrufkonvention) und/oder semantisch (Verhaltensänderung) sein.

Die dritte Stelle wird genutzt, um kompatible Änderungen einer Schnittstelle zu kennzeichnen. D.h. nutzende Aufrufer müssen nicht geändert werden, können aber ggf.  hinzugekommene, optionale Parameter nutzen. Die vierte Stelle hat lediglich einen informatorischen Charakter. Sie kann z.B. ausdrücken, aus welchem Bau die konkrete Version stammt. Bei der Betrachtung der Kompatibilität ist diese Stelle zu ignorieren.

3.12.2.0 und 3.12.3.0 sind kompatibel. Es könnte sein, dass 3.12.3.0 einen optionalen Parameter enthält.

3.12.3.0 und 3.13.0.0 sind inkompatibel.
Die ersten beiden Stellen finden sich in der ServiceId wieder. Dies zeigt folgendes Beispiel: ''Schleupen.CS.AS.MT.Benutzerkonto.BucherAusleihenActivityService_3.2''. Hierbei sind die ersten beiden Stellen der Versionsnummer 3.2. Die vollständige Versionsnummer ist im WSDL-Dokument zu finden. Siehe hierzu auch Kommunikationsarten .

Schnittstellen-Policy

Folgende Kompatibilität hinsichtlich der Versionierung und Abbildung auf die Versionsnummer wird für Schnittstellen, die keine sogenannte privilegierten Schnittstellen sind, unterstützt und über die zweite Stelle der Versionsnummer ausgedrückt.

• Process Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Activity Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Command Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Request/Reply Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Query Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Entity Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Event Service
  - die Schnittstelle gehört dem Client (derjenige, der das Event auslöst)
  - Abwärtskompatibilität
  - Aufwärtskompatibilität

Integration: Abkündigungs-Policy

Service-Lebenszyklus

Service-Lebenszyklus

Da Software ständig angepasst wird, schlagen diese Änderungen natürlich auch auf Service-Schnittstellen deren Implementierung sowie den Business Events durch. Aber bevor wir zeigen, wie wir damit umgehen, müssen wir zunächst klären, wann und wie Änderungen sich für den Nutzer auswirken.

Kompatibilität von Services

Unter der Kompatibilität von Services versteht man die Möglichkeit, einen Service auch nach Änderung der bereitgestellten Schnittstellendefinition weiterhin nutzen zu können. Ist eine neuere Serviceversion beispielsweise nicht mehr ohne Anpassung des Clients aufrufbar, so ist diese inkompatibel zur Vorgängerversion. Unterschieden wird hierbei bzgl. der sogenannten Aufwärts- und Abwärtskompatibilität, die im Folgenden erläutert wird.

Abwärtskompatibilität

Im Folgenden betrachten wir zunächst die Abwärtskompatibilität für den allgemeinen Fall. Gegeben sei hierbei ein API in der Version v1 mit genau einer Schnittstelle.

Der Client ist hierbei der Nutzer dieser Schnittstelle, der Provider stellt eine Implementierung dieser Schnittstelle bereit. Nun muss eine neue Version dieser API samt Schnittstelle erstellt werden, indem die Schnittstelle angepasst wird. Dieses neue API habe die Version v2. Der Provider implementiere nun die neue Version der Schnittstelle.

Wenn der Client, der nach wie vor die Version v1 der Schnittstelle verwendet, weiterhin die Schnittstelle nutzen kann, so spricht man von Abwärtskompatibilität, da gedanklich die Schnittstelle v2 abwärts über v1 nutzbar ist. Kann die Schnittstelle nicht mehr genutzt werden, so ist diese abwärts inkompatibel.

In Schleupen.CS werden Schnittstellen auf Makroebene durch WSDLs beschrieben - sowohl für synchrone als auch asynchrone Kommunikation.

Aufwärtskompatibilität

Auch hier betrachten wir zunächst den allgemeinen Fall, bei dem eine Schnittstelle in der Version v1 über ein API gegeben sei. Auch hier sei der Client der Nutzer und der Provider die Implementierung dieser Schnittstelle.

Nun wird wie im obigen Fall die Schnittstelle zur Version v2 geändert. Nun kennt lediglich der Client diese neue Version, der Provider nach wie vor die alte Schnittstellen-Version.

Kann der Client nun weiterhin diese Schnittstelle nutzen, so spricht man von Aufwärtskompatibilität, da die "alte" Implementierung aufwärts aus Nutzersicht über v2 nutzbar bleibt. Ist dies nicht der Fall, so sagt man, dass die Schnittstelle v2 aufwärts inkompatibel zur Version v1 ist.

In Kompatibilitätsmatrix ist im Detail beschrieben, wann ein Service inkompatibel wird!

Versionierung

Eine in Schleupen.CS definierte Versionsnummer hat bis zu vier Stellen und entspricht ab der zweiten Stelle dem Semantic Versioning.

• 1. Stelle: Architektur (z.B. 3 für CS 3); Änderung drückt Inkompatibilität aus
• 2. Stelle: Änderung drückt eine inkompatible Änderung aus
• 3. Stelle: Änderung drückt eine kompatible Änderung aus
• 4. Stelle: Revision, nur informatorisch, Änderung ohne Auswirkung auf Syntax oder Semantik

Ändert sich eine der ersten beiden Stellen, ist die neue Version nicht mehr abwärtskompatibel zur Vorgängerversion. D.h. nutzende Aufrufer müssen angepasst werden. Die Dokumentation der neuen Version der Schnittstelle enthält Hinweise zu den Änderungen. Diese können syntaktisch (Aufrufkonvention) und/oder semantisch (Verhaltensänderung) sein.

Die dritte Stelle wird genutzt, um kompatible Änderungen einer Schnittstelle zu kennzeichnen. D.h. nutzende Aufrufer müssen nicht geändert werden, können aber ggf.  hinzugekommene, optionale Parameter nutzen. Die vierte Stelle hat lediglich einen informatorischen Charakter. Sie kann z.B. ausdrücken, aus welchem Bau die konkrete Version stammt. Bei der Betrachtung der Kompatibilität ist diese Stelle zu ignorieren.

3.12.2.0 und 3.12.3.0 sind kompatibel. Es könnte sein, dass 3.12.3.0 einen optionalen Parameter enthält.

3.12.3.0 und 3.13.0.0 sind inkompatibel.
Die ersten beiden Stellen finden sich in der ServiceId wieder. Dies zeigt folgendes Beispiel: ''Schleupen.CS.AS.MT.Benutzerkonto.BucherAusleihenActivityService_3.2''. Hierbei sind die ersten beiden Stellen der Versionsnummer 3.2. Die vollständige Versionsnummer ist im WSDL-Dokument zu finden. Siehe hierzu auch Kommunikationsarten .

Schnittstellen-Policy

Folgende Kompatibilität hinsichtlich der Versionierung und Abbildung auf die Versionsnummer wird für Schnittstellen, die keine sogenannte privilegierten Schnittstellen sind, unterstützt und über die zweite Stelle der Versionsnummer ausgedrückt.

• Process Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Activity Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Command Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Request/Reply Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Query Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Entity Service
  - die Schnittstelle gehört dem Provider
  - Abwärtskompatibilität
• Event Service
  - die Schnittstelle gehört dem Client (derjenige, der das Event auslöst)
  - Abwärtskompatibilität
  - Aufwärtskompatibilität

Abkündigungsprozess

Inkompatible Änderungen erfordern Anpassungen im Code, die im Allgemeinen über Teamgrenzen hinausgehen. Um dies koordiniert durchzuführen und damit das Team, welches Code-Anpassungen durchführen muss zu einem für sich sinnvollen Zeitpunkt reagieren kann, existiert bei Schleupen folgender Prozess, der den ¼-jährlichen Entwicklungszyklus von Schleupen berücksichtigt. Wichtig hierbei ist, dass Änderungen auch an Schnittstellen auf Makroebene unabdingbar sind und Altlasten irgendwann entfernt werden müssen, da sonst die Software schnell in einen schlecht wartbareren Zustand geraten könnte.

In der dargestellten Abbildung sehen wir von links nach rechts eine zeitliche Darstellung dreier PIs. PI steht dabei für Program Increment, was dem SAFe for Lean Enterprises (scaledagileframework.com) entnommen ist. FV22 steht dabei für den Bereitstellungszeitpunkt, hier die Frühjahrsversion 2022. SV 22 steht entsprechend für Sommerversion usw.

Bis zum Beginn der Entwicklung des PIs der FV22 wurde in diesem Beispiel der Service '...Buecher.EntityService_3.4' im kanonischen Servicemodell obsolet markiert. Zum Anfang des PSI FV22 dann in eine Liste der obsoleten Services übernommen. Über internes Tooling werden nun die Teams informiert, dass diese einen obsoleten Service nutzen. Nun haben die betroffenen Teams zwei Möglichkeiten:

• Umstellung auf eine neue Version des Buecher.EntityService während des PIs der FV22
• In der Liste der obsoleten Services wird ein Veto eingelegt. Dies bedeutet, dass das Team, das den Buecher.EntityService bereitstellt, diesen Service auch im darauffolgenden PSI bereitstellen muss.

Der hier beschriebene Entwicklungsprozess bezieht sich auf die Standard-Services und Business Events. Bei privilegierten Schnittstellen versuchen wir, eine noch höhere Stabilität zu erreichen! Siehe
Integration: Abkündigungs-Policy