Versionierung von SOA-Diensten

Rik de Groot schrieb vor etwa einem Jahr einen Blogeintrag über die Versionierung von Diensten als Teil der Top 10 SOA-Fallstricke. Er berührte das Thema der verschiedenen Versionen bei der Bereitstellung und bot uns im Grunde die Möglichkeit, Dienste mit Hilfe eines ESB umzuleiten. Es ist allgemein bekannt, dass Verbraucher einen Dienst weiterhin nutzen und hoffen, dass sie nur dann ein Upgrade durchführen, wenn sie zusätzliche oder geänderte Funktionen benötigen. Dienste sind jedoch nicht für einen einzelnen Kunden gedacht, sondern für viele Kunden. Selbst wenn diese ein Upgrade wünschen, werden sie es nicht gleichzeitig durchführen. Sie werden also mehrere Versionen von Diensten laufen haben. Ich sehe mehrere Möglichkeiten, mit Versionen von Diensten umzugehen:

1. Minimieren Sie dies durch die Verwendung von Rerouting innerhalb des ESB.
2. Lassen Sie alle Versionen laufen, während Sie sie benutzen.
3. Sie haben eine vertragliche Vereinbarung mit Verfallsdatum.
4. Verwenden Sie inhaltsbasiertes Routing.
5. Konstruieren Sie Adapter für die Konvertierung Zunächst möchte ich einen Blick darauf werfen, welche Versionen erscheinen könnten. Eine größere Versionserweiterung eines Dienstes bedeutet, dass wir nicht mehr abwärtskompatibel sind. Ein Verbraucher, der die nächste Hauptversion verwenden möchte, muss daher mit der Programmierung beginnen, um diesen Dienst nutzen zu können. Bei einem Minor-Inkrement ist die Abwärtskompatibilität gegeben und es werden zusätzliche Funktionen angeboten. Das bedeutet, dass ein Verbraucher den Dienst ohne großen Aufwand nutzen kann (eine Änderung der Bindung würde ausreichen). Ein Patch-Inkrement eines Dienstes bedeutet eine Änderung, ohne die Spezifikationen zu verändern. Eine neue Patch-Version kann - und sollte - daher die ältere Version ersetzen. In allen Optionen sollten wir die Anzahl der erstellten Versionen eines Dienstes begrenzen. Das bedeutet, dass Dienste nicht innerhalb von Projekten erstellt werden sollten, sondern in einem separaten Track (neu) erstellt werden sollten, um generische Dienste und eine optimale Wiederverwendung zu ermöglichen. Dieser Track sollte alle Anforderungen von (potenziellen) Kunden sammeln, den gemeinsamen Nenner finden und eine neue Version erstellen. Nicht selten wird eine neue Version erstellt, weil ein einzelner Kunde eine bestimmte Funktionalität wünscht, die noch nicht angeboten wird, und ohne sich umzusehen, wird die neue Version maßgeschneidert.

   Zurück zu den Optionen. Ich behaupte, dass die erste Option (ESB-Rerouting) eine logische Wahl ist. Die Adressierung großer Inkremente ist jedoch kompliziert und sollte vermieden werden, da Sie damit beginnen, zu viel Logik in einen Router-Mechanismus einzubauen. Minor Inkremente sollten kein Problem darstellen (die meisten Konvertierungen sind unkompliziert). Es bietet daher nur die Einschränkung von Minor-Versionen einer einzigen Major-Version. Ein Nebeneffekt ist, dass die WSDL sowohl im ESB (als Einstiegspunkt für Verbraucher) als auch in der implementierenden Anwendung bereitgestellt werden muss. Für Testzwecke ist diese Option interessant, da bei der Migration beide Versionen angesprochen und auf Unterschiede geprüft werden können. Option fünf ist eine Alternative zur vorherigen Option, bei der das Routing aus dem ESB ausgelagert wird, sich aber immer noch als Wrapper um den Kern der Dienste befindet. Die zweite Option ist viel einfacher. Mit der Zeit wird sie jedoch Ihre SOA wie einen Stapel noch nicht gelesener Zeitschriften füllen. Ergebnisse aus älteren Versionen können den Ergebnissen neuerer Versionen widersprechen. Zweitens muss die Nutzung jedes Dienstes genau überwacht werden, bevor er eingestellt wird. Im Windschatten könnte ein unregelmäßiger Verbraucher jedoch unter der Nichtverfügbarkeit leiden. Das ist keine sehr gesunde Art, Dienste in großen SOA-Umgebungen zu pflegen. Wenn die Situation jedoch stabil ist und die Kosten für die Wartung im Verhältnis zu den Auswirkungen auf die Verbraucher, die migrieren müssen, akzeptabel sind, kann die Situation durch das Einfrieren der Funktionalität alter Dienste eingedämmt werden. Die vierte Option, inhaltsbasiertes Routing zu verwenden, ist in den meisten Situationen nicht ratsam. Das Routing auf der Grundlage des Inhalts (einer Versionszeichenfolge als Teil des Inhalts) einer Nachricht führt zu nicht strikten Verträgen und überlässt die Kontrolle über das Routing dem Verbraucher. Wie sollte der Verbraucher seine Nachricht für eine bestimmte Version aufbauen? Bleibt noch die letzte Option, die wir beschreiben können, nämlich die Verwendung von Verträgen. Das ist kein sehr ungewöhnliches Modell, da es von vielen Softwareanbietern für funktionalen Support verwendet wird. Bei der Nutzung schließt der Verbraucher einen (halb-)jährlichen Vertrag ab. Nach Ablauf des Vertrags kann der Kunde diese spezielle Version nicht mehr verwenden und muss migrieren, was die Bereinigung älterer Versionen ermöglicht. Ein Upgrade während dieses Zeitraums auf eine neuere kleinere Version kann das Ablaufdatum verlängern. Das bedeutet natürlich Vertragsmanagement und Zugriffskontrolle auf Dienste, aber die Verbraucher können Budget für Upgrades reservieren und Vertragsmanagement ist in großen Unternehmen nicht ungewöhnlich. In solchen Fällen kann der Kunde entscheiden, ob er einen teureren Vertrag (aufgrund höherer Wartungskosten) oder eine Migration auf die neue Plattform akzeptiert. Es hängt natürlich von der jeweiligen Situation ab, welche Option Sie wählen. Wenn Sie viele (externe) Kunden haben, ist es vielleicht klüger, die Vertragsoption anzubieten. Wenn Sie nur wenige interne Kunden haben, ist die zweite Option sicherlich keine schlechte Wahl. In den meisten Fällen ist jedoch die erste Option vorzuziehen.