Top 10 SOA-Fallstricke: #9 - Versionierung

Letzte Woche haben wir den Countdown der Top 10 SOA-Fallstricke mit der Nummer 10 begonnen : Das NIH-Syndrom. Diese Woche ist es Zeit für #9. Versionskonflikte gehören zu den Wachstumsschmerzen einer SOA. Eine SOA beginnt einfach, aber nach einer Weile werden neue Versionen von Diensten erscheinen und die Komplexität wird zunehmen. Ein gutes Lebenszyklusmanagement und unterstützende Tools helfen Ihnen, die Komplexität zu kontrollieren.

Die Implementierung einer SOA wird Dienste enthalten. Ursprünglich sind die Dienste für einen bestimmten Zweck konzipiert. Die Verbraucher dieser Dienste werden die Funktionalität wie vorgesehen nutzen. Im Laufe der Zeit können sich die Dienste jedoch ändern oder es werden neue Funktionen benötigt. Welche Auswirkungen hat dies auf die Kunden, die Dienste und die Infrastruktur? Schauen wir uns diese Änderungen genauer an. Die Änderungen lassen sich in größere Änderungen (v1.0 bis v2.0 ) und kleinere Änderungen (1.0 bis 1.1) unterteilen. Die folgenden Arten von Änderungen können identifiziert werden (Kombinationen der Arten können auftreten):

1. Geringfügige Änderung der Schnittstelle: Die aktuelle Schnittstelle wird erweitert, ohne die aktuelle Funktionalität und Verwendung der Schnittstelle zu beeinträchtigen. Zum Beispiel wird eine neue Methode mit neuer Funktionalität hinzugefügt.
2. Geringfügige Änderung der Funktionalität: Die Funktionalität wird geändert, ohne Auswirkungen auf die Verbraucher. Die Implementierung wird überarbeitet. Zum Beispiel eine Fehlerbehebung der aktuellen Version.
3. Größere Änderung der Schnittstelle: Die aktuelle Schnittstelle wird so geändert, dass sie nicht mehr abwärtskompatibel ist. Zum Beispiel werden die Methoden geändert oder die Funktionalität ist völlig neu.
4. Wesentliche Änderung der Funktionalität: Obwohl bei dieser Änderung die Oberfläche gleich bleibt, wird die Funktionalität so geändert, dass sie sich auf die Verbraucher auswirkt.

Im Allgemeinen haben die geringfügigen Änderungen keine Auswirkungen auf die derzeitigen Verbraucher. Diese Verbraucher können weiterhin die bestehende Schnittstelle oder Funktionalität nutzen. Normalerweise kann der Dienst durch die neue Version ersetzt werden, ohne dass die alte Version online bleibt. Allerdings sind Regressionstests erwünscht, um sicherzustellen, dass die neue Funktionalität/Schnittstelle die bestehende Funktionalität/Schnittstelle nicht beeinträchtigt hat. Beachten Sie, dass die neue Funktionalität in das aktuelle SLA passen sollte. Bei einer größeren Änderung werden sich die Änderungen höchstwahrscheinlich auf die aktuellen Kunden auswirken. Die alte Version kann aus mehreren Gründen nicht durch die neue Version ersetzt werden.

• Die derzeitigen Verbraucher sind nicht in der Lage, rechtzeitig auf die neue Version zu aktualisieren
• Die alte Funktionalität wird weiterhin benötigt, obwohl sie nicht funktional unterstützt wird (nur technisch).
• Die Verbraucher wollen nicht aufrüsten und/oder sind nicht bereit, für die zusätzlichen Kosten zu zahlen. Diese Kosten werden in den meisten Fällen mit der Zeit steigen.

In diesen Fällen stehen den Verbrauchern zwei Versionen desselben Dienstes zur Verfügung, obwohl sich die Funktionalität und die Schnittstelle unterscheiden. Wenn es mehrere Versionen eines Dienstes gibt, steigt die Komplexität der SOA. Obwohl einige Unternehmen die Anzahl der Versionen in der Produktion begrenzen, ist es oft schwierig, die Versionen zu pflegen. Oft gilt der funktionale Support nur für die neue Version, aber technisch gesehen sollten alle Versionen unterstützt werden. Die Wartung ist für beide Versionen erforderlich, was dazu führen kann, dass die alte Hauptversion durch eine kleinere neue Version ersetzt wird. Probleme bei der Versionierung werden in den meisten Fällen durch schlechte Verwaltung und fehlende unterstützende Tools verursacht. In der Praxis sind die häufigsten Probleme mit Versionen folgende:

• Wer verwendet die Versionen? Wer hat die alte Schnittstelle verwendet? Wie lange ist es her, dass sie verwendet wurde?
• Fehlende Hilfsmittel für die Verwaltung der verschiedenen Versionen.
• Wie lange wird der Support für eine alte Version benötigt. Wann ist es sicher, eine Version zu aktualisieren oder zu entfernen.
• Werden die Verbraucher auf die richtige Version umgeleitet?
• Die Verbraucher verbinden sich direkt mit den Diensten, ohne einen Proxy.

Um den Überblick über all diese Dienste zu behalten, ist eine gute Registrierung erforderlich. Die Registrierung enthält die Dienste, die aktiv sind. Die Registry enthält den Standort und die Verbraucher, die die Dienste nutzen. Tools wie ein ESB können wie ein Proxy für verschiedene Versionen fungieren. Der genaue Standort einer Version ist für die Verbraucher verborgen. Der ESB leitet den Aufruf an die richtige Version des Dienstes weiter. Beachten Sie, dass allgemeine öffentliche Internetdienste schwer zu versionieren sind. In diesen Fällen sind die Verbraucher unbekannt und können nicht kontaktiert werden. Obwohl die gleichen Prinzipien gelten, können sie nur auf anonyme Weise benachrichtigt werden (z.B. durch eine Benachrichtigung auf einer Website). Abschließend lässt sich sagen, dass sich die Versionen der Dienste im Laufe der Zeit ändern werden. Daher ist es wichtig, auf diese Änderungen vorbereitet zu sein. Begrenzen Sie die Anzahl der Versionen und halten Sie in einer Registrierung fest, wer sie verwendet. Verwenden Sie Tools, um die Implementierung vor den Verbrauchern zu verbergen, damit Sie flexibler mit mehreren Versionen umgehen können. Nächste Woche wird sich Viktor Grgic mit Fallstrick Nr. 8 befassen.