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.
# Applications qui partagent des programmes
Le schéma suivant illustre les applications mainframe A et B qui exécutent un programme partagé appelé programme AB.1. Ce cas est également applicable lorsque les applications A et B incluent des programmes qui appellent des sous-programmes partagés.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Étapes de l'analyse**
1. Effectuez une analyse d'impact du programme partagé AB.1 afin de pouvoir migrer les applications A et B, ainsi que le programme AB.1 ensemble. Nous vous recommandons d'utiliser les outils de découverte répertoriés dans la section [Ressources supplémentaires](resources.md) pour automatiser l'analyse.
1. Sur la base de l'analyse d'impact, identifiez le nombre d'applications dépendantes qui utilisent des programmes partagés tels que le programme AB.1.
1. (Recommandé) Effectuez une analyse du domaine métier pour déterminer si le programme partagé peut être agrégé dans un domaine contenant des applications et exposé sous forme d'API en tant que service de domaine.
Vous pouvez utiliser l'une des approches suivantes pour dissocier les applications en vue de la migration :
+ [Utiliser une API autonome](api.md)
+ [Utiliser une bibliothèque partagée](library.md)
+ [Utiliser une file d'attente de messages](queue.md)
# Approche 1 : découpler à l'aide d'une API autonome
Lorsque vous utilisez cette approche, vous instanciez une API autonome en convertissant le programme COBOL partagé AB.1 en programme Java. Pour minimiser les efforts de refactoring, vous pouvez utiliser les outils de refactoring automatisés fournis par les AWS partenaires (voir la section [Ressources supplémentaires](resources.md)) pour générer un réseau APIs pour le programme. Certains outils peuvent générer automatiquement une couche de façade à partir du programme sélectionné à l'aide d'un environnement de développement intégré (IDE) tel qu'Eclipse.
Nous recommandons cette approche lorsque le programme partagé peut être instancié en tant que service autonome. Les autres composants des applications A et B sont refactorisés dans Java dans leur ensemble et migrés vers le cloud. Vous pouvez migrer les applications dans la même vague ou dans des vagues différentes.
## Migration des applications au cours de la même vague
Dans le schéma suivant, les applications A et B sont regroupées pour être migrées dans la même vague.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
Si vous découplez votre code en utilisant une API autonome et en migrant des applications au cours de la même vague, procédez comme suit :
1. Refactorisez les deux applications avec leurs programmes respectifs et migrez-les vers le cloud.
1. Utilisez le rapport d'analyse d'impact issu de la phase d'analyse pour aider les développeurs et les équipes à identifier les applications refactorisées qui appellent le programme partagé AB.1. Remplacez l'appel de programme interne au programme partagé AB.1 par des appels d'API réseau.
1. Après la migration, retirez les applications mainframe locales et leurs composants.
## Migration des applications en différentes vagues
Lorsque les applications sont trop volumineuses pour être regroupées dans une même vague de migration, vous pouvez les migrer en plusieurs vagues, comme le montre le schéma suivant, et maintenir la continuité du service pendant la migration. Grâce à cette approche, vous pouvez moderniser vos applications par étapes sans les regrouper. La migration de vos applications par vagues distinctes les dissocie sans nécessiter de modifications de code importantes sur le mainframe.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
Si vous découplez votre code en utilisant une API autonome et en migrant des applications par étapes, procédez comme suit :
1. Migrez (refactorisez) l'application A avec ses programmes associés vers le cloud tandis que l'application B continue de résider sur site.
1. Dans l'application A, remplacez l'appel de programme interne au programme partagé AB.1 par un appel d'API.
1. Conservez une copie du programme AB.1 sur le mainframe afin que l'application B puisse continuer à fonctionner.
1. Bloquez le développement des fonctionnalités du programme AB.1 sur le mainframe. Passé ce point, tous les développements de fonctionnalités auront lieu dans le programme refactorisé AB.1 dans le cloud.
1. Une fois l'application A migrée avec succès, retirez l'application locale et ses composants (à l'exception du programme partagé). L'application B et ses composants (y compris le programme partagé) continuent de résider sur place.
1. Lors de la prochaine série de vagues de migration, migrez l'application B et ses composants. Vous pouvez appeler le programme migré et refactorisé AB.1 pour réduire les efforts de refactorisation de l'application B.
# Approche 2 : découpler en utilisant une bibliothèque partagée
Dans cette approche, le programme partagé AB.1 est converti en bibliothèque commune Java et est empaqueté avec les applications pour la migration. Nous recommandons cette approche lorsque le programme partagé est une bibliothèque de support plutôt qu'un service autonome.
Les autres composants des applications A et B sont refactorisés dans des programmes Java et migrés vers le cloud. Vous pouvez migrer les applications dans la même vague ou dans des vagues différentes.
## Migration des applications au cours de la même vague
Dans le schéma suivant, les applications A et B sont regroupées pour être migrées dans la même vague.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
Si vous découplez votre code en utilisant une bibliothèque partagée et en migrant des applications au cours de la même vague, procédez comme suit :
1. Refactorisez les applications A et B avec leurs programmes associés en Java et migrez-les vers le cloud.
1. Gérez le code source des applications dans un service de contrôle de source entièrement géré. Les équipes qui utilisent le programme partagé peuvent collaborer sur les modifications du code en utilisant des pull requests, des branchements et des fusions, et peuvent contrôler les modifications apportées au code du programme partagé.
1. Après la migration, retirez les applications mainframe locales et leurs composants.
## Migration des applications en différentes vagues
Lorsque les applications sont trop volumineuses pour être regroupées dans une même vague de migration, vous pouvez les migrer en plusieurs vagues, comme le montre le schéma suivant, et maintenir la continuité du service pendant la migration. Grâce à cette approche, vous pouvez moderniser vos applications par étapes sans les regrouper. La migration de vos applications par vagues distinctes les dissocie sans nécessiter de modifications de code importantes sur le mainframe.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
Si vous découplez votre code en utilisant une bibliothèque partagée et en migrant des applications par étapes, procédez comme suit :
1. Migrez (refactorisez) l'application A avec ses programmes associés vers le cloud tandis que l'application B continue de résider sur site.
1. Conservez une copie du programme AB.1 sur le mainframe afin que l'application B puisse continuer à fonctionner.
1. Bloquez le développement des fonctionnalités du programme AB.1 sur le mainframe. À ce stade, tous les développements de fonctionnalités auront lieu dans le programme refactorisé AB.1 dans le cloud.
1. Lorsque vous développez de nouvelles fonctionnalités pour le programme AB.1, maintenez la rétrocompatibilité afin de prendre en charge la migration de l'application B lors des prochaines vagues.
1. Une fois l'application A migrée avec succès, retirez l'application locale et ses composants (à l'exception du programme partagé). L'application B et ses composants (y compris le programme partagé) continuent de résider sur place.
1. Lors de la prochaine série de vagues de migration, migrez l'application B et ses composants. Vous pouvez utiliser la dernière bibliothèque partagée du programme AB.1 dans le cloud pour réduire les efforts de refactorisation de l'application B.
# Approche 3 : découpler à l'aide d'une file de messages
Dans cette approche, le programme partagé AB.1 est converti en programme Java et migré vers le cloud dans le cadre de l'application A. Une file de messages est utilisée comme interface entre l'application refactorisée dans le cloud et l'ancienne application sur site. En utilisant cette approche, vous pouvez diviser les applications mainframe étroitement couplées en producteurs et en consommateurs, et les rendre plus modulaires afin qu'elles puissent fonctionner de manière indépendante. L'avantage supplémentaire est que vous pouvez migrer les applications en différentes vagues.
Nous vous recommandons d'utiliser cette approche lorsque :
+ Les applications résidant sur le mainframe peuvent communiquer avec les applications migrées dans le cloud par le biais d'une file de messages.
+ Plusieurs copies du programme AB.1 (par exemple, une copie sur site et une copie dans le cloud, comme dans les deux approches précédentes) ne peuvent pas être conservées.
+ Le modèle d'architecture de mise en file d'attente répond aux exigences commerciales des applications résidant sur le mainframe, car il implique une refonte de l'architecture des applications existantes.
+ Les applications qui ne font pas partie de la première vague nécessitent plus de temps (six mois ou plus) pour être migrées vers le cloud.
## Migration des applications en différentes vagues
Lorsque les applications sont trop volumineuses pour être regroupées dans une même vague de migration, vous pouvez les migrer en plusieurs vagues, comme le montre le schéma suivant, et maintenir la continuité du service pendant la migration. Grâce à cette approche, vous pouvez moderniser vos applications par étapes sans les regrouper.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
Si vous utilisez cette approche, procédez comme suit :
1. Migrez (refactorisez) l'application A avec ses programmes associés vers le cloud tandis que l'application B continue de résider sur site.
1. Refactorisez l'application A (dans le cloud) pour communiquer avec l'application B (sur site) via une file de messages.
1. Refactorisez l'application B sur site pour remplacer le programme partagé AB.1 par un programme proxy qui envoie des messages à l'application A et en reçoit des messages via la file d'attente de messages.
1. Une fois l'application A migrée avec succès, retirez l'application locale A et ses composants (y compris le programme partagé). L'application B et ses composants continuent de résider sur place.
1. Lors de la prochaine série de vagues de migration, migrez l'application B et ses composants. L'architecture de file d'attente faiblement couplée continue de servir d'interface entre les applications A et B sur le cloud. Cela réduit les efforts de refactorisation pour l'application B sans affecter l'application A.