Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Services Web ASP.NET (ASMX) basés sur SOAP
Lorsque vous modernisez un ancien service Web ASP.NET (ASMX) en une API REST activée AWS, il se peut que des clients dépendants ne puissent pas, et ne devraient probablement pas, en raison des risques associés, être mis à niveau en même temps. L'illustration suivante illustre un service Web ASMX qui compte trois consommateurs dépendants.
Étant donné que ces consommateurs appellent le service ASMX à l'aide du protocole SOAP, le remplacement du service ASMX par une API REST provoquerait une interruption de service pour ces consommateurs. En outre, la refactorisation du service ASMX en une API REST pendant que vous convertissez le système d'une architecture monolithique en microservices impliquera très probablement de remodeler le comportement du système et le modèle de domaine. Cela est susceptible de créer des changements décisifs supplémentaires pour les consommateurs.
Pour maintenir la rétrocompatibilité avec l'ancien service afin de moderniser progressivement le système, vous pouvez appliquer l'approche Strangler Fig. Dans l'approche Strangler Fig, les risques associés à la modernisation d'un système existant important sont, en partie, gérés en remplaçant progressivement l'ancien système par un nouveau.
Brancher par abstraction est une autre approche introduite par Martin Fowler qui est une technique efficace pour implémenter le motif Strangler Fig. À l'instar de l'approche Strangler Fig, la branche par abstraction aide les ingénieurs à apporter des modifications incrémentielles et graduelles aux systèmes lorsque des fonctionnalités majeures doivent être remplacées ou modernisées. Dans cette approche, une couche d'abstraction est introduite entre le code qui implémente une fonctionnalité spécifique et le code qui consomme cette fonctionnalité (c'est-à-dire le code client). Il n'est pas nécessaire que cette couche d'abstraction soit un type abstrait pouvant être hérité par des classes concrètes. Il peut plutôt s'agir de n'importe quelle implémentation qui capture le contrat fonctionnel entre le consommateur et le fournisseur.
Dans le cas des anciens services Web ASP.NET basés sur SOAP, vous pouvez permettre la migration progressive des consommateurs de services de l'ancien au nouveau en maintenant la compatibilité, grâce à une approche inspirée de la technique de branche par abstraction. Toutefois, l'approche des services Web ASP.NET basés sur SOAP utilise la délégation plutôt que l'héritage. La compatibilité avec les consommateurs ASMX est obtenue en refactorisant l'ancien service ASMX afin de déléguer sa mise en œuvre à la nouvelle API REST. L'illustration suivante illustre l'ancien service ASMX qui délègue son implémentation à la nouvelle API REST. Cette délégation permet au consommateur de services 3 de passer à la nouvelle API REST tandis que les consommateurs de services 1 et 2 sont mis à niveau indépendamment.
La nature de la refactorisation du service ASMX dépend des exigences fonctionnelles et non fonctionnelles (interfonctionnelles) de ce service. Dans certains cas, la refactorisation peut impliquer le passage des anciens mécanismes d'authentification et d'autorisation aux nouveaux, la transformation de la charge utile ASMX du service XML en JSON, puis l'appel de l'API REST avec la charge utile transformée. Dans des scénarios plus complexes, le service ASMX refactorisé peut avoir à orchestrer des appels à plusieurs REST et à maintenir l'état. APIs
Le processus de migration des consommateurs de services de l'ancien service ASMX vers l'API REST modernisée se poursuit progressivement jusqu'à ce que tous les consommateurs de services aient été mis à jour pour faire référence à la nouvelle API. L'illustration suivante illustre l'état de modernisation complète, dans lequel tous les consommateurs de services font référence à l'API REST, et le service ASMX a été mis hors service car il n'est plus nécessaire.
Exemple d'architecture
L'architecture finale du service ASMX basé sur SOAP montre que tous les consommateurs de services utilisent l'API REST modernisée, ce qui entraîne la mise hors service de l'ancien service Web ASMX. Toutefois, ce modèle ne se concentre pas sur l'architecture de l'état final, mais sur l'architecture de l'état intermédiaire nécessaire pendant la migration, pendant la mise à niveau des consommateurs. Cet état provisoire est illustré dans le schéma suivant. Dans cette architecture provisoire, les consommateurs de services 1 et 2 utilisent toujours l'ancien service ASMX, qui a été refactorisé pour déléguer sa mise en œuvre à l'API REST modernisée. Le service Windows refactorisé est déployé sous forme de conteneur Windows dans Amazon ECS, configuré sur trois zones de disponibilité pour une haute disponibilité et accessible via un Application Load Balancer. Service Consumer 3 a été mis à jour pour utiliser la nouvelle API REST directement via API Gateway.
