Servizi Web ASP.NET basati su SOAP (ASMX)

Quando si modernizza un servizio Web ASP.NET (ASMX) legacy con un'API REST attiva AWS, è possibile che utenti dipendenti non possano, e molto probabilmente non dovrebbero, a causa dei rischi associati, essere aggiornati contemporaneamente. L'illustrazione seguente mostra un servizio Web ASMX con tre consumatori dipendenti.

Poiché questi consumatori chiamano il servizio ASMX utilizzando il protocollo SOAP, la sostituzione del servizio ASMX con un'API REST provocherebbe un'interruzione. Inoltre, il refactoring del servizio ASMX in un'API REST durante la conversione del sistema da un'architettura monolitica a microservizi comporterà molto probabilmente il rimodellamento del comportamento del sistema e del modello di dominio. È probabile che ciò comporti ulteriori cambiamenti epocali per i consumatori.

Per mantenere la retrocompatibilità con il vecchio servizio in modo che il sistema possa essere modernizzato in modo incrementale, è possibile implementare la guida dell'approccio strangler fig. Nell'approccio Strangler Fig, i rischi associati alla modernizzazione di un importante sistema legacy vengono, in parte, gestiti sostituendo gradualmente il sistema precedente con uno nuovo.

Branch by abstraction è un altro approccio introdotto da Martin Fowler che rappresenta una tecnica efficace per implementare lo strangler fig pattern. Analogamente all'approccio strangler fig, branch by abstraction aiuta gli ingegneri ad apportare modifiche incrementali e graduali ai sistemi quando le principali funzionalità devono essere sostituite o modernizzate. In questo approccio, viene introdotto un livello di astrazione tra il codice che implementa funzionalità specifiche e il codice che utilizza tale funzionalità (ovvero il codice client). Questo livello di astrazione non deve essere un tipo astratto che può essere ereditato da classi concrete. Può invece essere qualsiasi implementazione che acquisisca il contratto funzionale tra il consumatore e il fornitore.

Nel caso dei servizi Web ASP.NET preesistenti basati su SOAP, è possibile consentire la migrazione graduale degli utenti dei servizi da quelli vecchi a quelli nuovi mantenendo la compatibilità, tramite un approccio ispirato alla tecnica Branch by Abstraction. Tuttavia, l'approccio per i servizi Web ASP.NET basati su SOAP utilizza la delega anziché l'ereditarietà. La compatibilità con i consumatori ASMX si ottiene rifattorizzando il servizio ASMX legacy per delegarne l'implementazione alla nuova API REST. La figura seguente mostra il servizio ASMX legacy che delega la sua implementazione alla nuova API REST. Questa delega consente all'utente del servizio 3 di eseguire l'aggiornamento alla nuova API REST mentre gli utenti del servizio 1 e 2 vengono aggiornati indipendentemente.

La natura del refactoring del servizio ASMX dipende dai requisiti funzionali e non funzionali (interfunzionali) di tale servizio. In alcuni casi, il refactoring potrebbe comportare la conversione dai vecchi ai nuovi meccanismi di autenticazione e autorizzazione, la trasformazione del payload ASMX del servizio da XML a JSON e quindi il richiamo dell'API REST con il payload trasformato. In scenari più complessi, il servizio ASMX rifattorizzato potrebbe dover orchestrare le chiamate a più REST e mantenere lo stato. APIs

Il processo di migrazione degli utenti del servizio dal servizio ASMX legacy all'API REST modernizzata continua in modo incrementale fino a quando tutti gli utenti del servizio non saranno aggiornati per fare riferimento alla nuova API. L'illustrazione seguente mostra lo stato di completa modernizzazione, in cui tutti gli utenti del servizio fanno riferimento all'API REST e il servizio ASMX è stato disattivato perché non è più necessario.

Architettura di esempio

L'architettura dello stato finale del servizio ASMX basato su SOAP mostra che tutti gli utenti del servizio utilizzano l'API REST modernizzata, con conseguente disattivazione del servizio web ASMX legacy. Tuttavia, il fulcro di questo modello non è l'architettura dello stato finale, ma l'architettura dello stato provvisorio necessaria durante la migrazione, mentre i consumatori vengono aggiornati. Questo stato provvisorio è illustrato nel diagramma seguente. In questa architettura provvisoria, gli utenti del servizio 1 e 2 utilizzano ancora il servizio ASMX legacy, che è stato rifattorizzato per delegarne l'implementazione all'API REST modernizzata. Il servizio Windows refactorizzato viene distribuito come contenitore Windows in Amazon ECS, configurato su tre zone di disponibilità per un'elevata disponibilità e accessibile tramite un Application Load Balancer. Service consumer 3 è stato aggiornato per utilizzare la nuova API REST direttamente tramite API Gateway.