Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
SOAP-basierte ASP.NET-Webdienste (ASMX)
Wenn Sie einen älteren ASP.NET-Webdienst (ASMX) auf eine REST-API umstellen, kann es sein AWS, dass davon abhängige Benutzer abhängig sind, die aufgrund der damit verbundenen Risiken nicht gleichzeitig aktualisiert werden können und höchstwahrscheinlich auch nicht sollten. Die folgende Abbildung zeigt einen ASMX-Webdienst mit drei abhängigen Benutzern.
Da diese Verbraucher den ASMX-Dienst mithilfe des SOAP-Protokolls aufrufen, würde das Ersetzen des ASMX-Dienstes durch eine REST-API dazu führen, dass diese Benutzer nicht mehr funktionieren. Darüber hinaus erfordert das Refactoring des ASMX-Dienstes in eine REST-API, während Sie das System von einer monolithischen Architektur auf Microservices umstellen, höchstwahrscheinlich eine Umgestaltung des Systemverhaltens und des Domänenmodells. Dies wird wahrscheinlich zu weiteren bahnbrechenden Änderungen für die Verbraucher führen.
Um die Abwärtskompatibilität mit dem alten Dienst aufrechtzuerhalten, sodass das System schrittweise modernisiert werden kann, können Sie den Strangler-Fig-Ansatz anwenden. Beim Strangler-Fig-Ansatz werden die mit der Modernisierung eines wichtigen Altsystems verbundenen Risiken teilweise dadurch bewältigt, dass das Altsystem schrittweise durch ein neues ersetzt wird.
Verzweigung durch Abstraktion ist ein weiterer von Martin Fowler eingeführter Ansatz, der eine effektive Methode zur Implementierung des Strangler-Fig-Musters darstellt. Wie beim Strangler-Fig-Ansatz hilft Branch-by-Abstraktion Ingenieuren dabei, inkrementelle und schrittweise Änderungen an Systemen vorzunehmen, wenn wichtige Funktionen ersetzt oder modernisiert werden müssen. Bei diesem Ansatz wird eine Abstraktionsebene zwischen dem Code, der bestimmte Funktionen implementiert, und dem Code, der diese Funktionalität nutzt (d. h. Client-Code), eingeführt. Bei dieser Abstraktionsebene muss es sich nicht um einen abstrakten Typ handeln, der von konkreten Klassen vererbt werden kann. Stattdessen kann es sich um eine beliebige Implementierung handeln, die den funktionalen Vertrag zwischen dem Verbraucher und dem Anbieter erfasst.
Bei älteren SOAP-basierten ASP.NET-Webdiensten können Sie die schrittweise Migration von Dienstnutzern von alten zu neuen Diensten ermöglichen, indem Sie die Kompatibilität aufrechterhalten. Dabei verwenden Sie einen Ansatz, der von der Branch-by-Abstraktionstechnik inspiriert ist. Der Ansatz für SOAP-basierte ASP.NET-Webdienste verwendet jedoch Delegierung anstelle von Vererbung. Die Kompatibilität mit ASMX-Benutzern wird erreicht, indem der ältere ASMX-Dienst so umgestaltet wird, dass seine Implementierung an die neue REST-API delegiert wird. Die folgende Abbildung zeigt den alten ASMX-Dienst, der seine Implementierung an die neue REST-API delegiert. Diese Delegierung ermöglicht es Service Consumer 3, auf die neue REST-API zu aktualisieren, während Service Consumer 1 und 2 unabhängig voneinander aktualisiert werden.
Die Art des ASMX-Dienst-Refactorings hängt von den funktionalen und nichtfunktionalen (funktionsübergreifenden) Anforderungen dieses Dienstes ab. In einigen Fällen kann das Refactoring die Übersetzung von den alten zu den neuen Authentifizierungs- und Autorisierungsmechanismen, die Transformation der ASMX-Nutzlast des Dienstes von XML nach JSON und das anschließende Aufrufen der REST-API mit der transformierten Nutzlast beinhalten. In komplexeren Szenarien muss der umgestaltete ASMX-Dienst möglicherweise Aufrufe an mehrere REST orchestrieren und den Status beibehalten. APIs
Der Prozess der Migration von Dienstnutzern vom alten ASMX-Dienst zur modernisierten REST-API wird schrittweise fortgesetzt, bis alle Dienstnutzer aktualisiert wurden, sodass sie auf die neue API verweisen. Die folgende Abbildung zeigt den vollständig modernisierten Zustand, in dem alle Dienstnutzer auf die REST-API verweisen und der ASMX-Dienst außer Betrieb genommen wurde, weil er nicht mehr benötigt wird.
Beispielarchitektur
Die End-State-Architektur für den SOAP-basierten ASMX-Dienst zeigt, dass alle Dienstnutzer die modernisierte REST-API verwenden, was zur Außerbetriebnahme des veralteten ASMX-Webdienstes führt. Der Schwerpunkt dieses Musters liegt jedoch nicht auf der Endstatusarchitektur, sondern auf der Interim-State-Architektur, die während der Migration benötigt wird, während die Verbraucher aktualisiert werden. Dieser Zwischenzustand wird in der folgenden Abbildung veranschaulicht. In dieser Übergangsarchitektur verwenden die Dienstnutzer 1 und 2 immer noch den alten ASMX-Dienst, der überarbeitet wurde, um seine Implementierung an die modernisierte REST-API zu delegieren. Der umgestaltete Windows-Service wird als Windows-Container in Amazon ECS bereitgestellt, für hohe Verfügbarkeit in drei Availability Zones konfiguriert und über einen Application Load Balancer abgerufen. Service Consumer 3 wurde aktualisiert, um die neue REST-API direkt über API Gateway zu verwenden.
