Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Applicazioni che condividono programmi
Il diagramma seguente illustra le applicazioni mainframe A e B che eseguono un programma condiviso denominato programma AB.1. Questo caso è applicabile anche quando le applicazioni A e B includono programmi che richiamano sottoprogrammi condivisi.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Fasi di analisi**
1. Eseguite un'analisi dell'impatto del programma condiviso AB.1, in modo da poter migrare le applicazioni A e B e programmare AB.1 insieme. Si consiglia di utilizzare gli strumenti di rilevamento elencati nella sezione [Risorse aggiuntive per automatizzare](resources.md) l'analisi.
1. In base all'analisi dell'impatto, identifica il numero di applicazioni dipendenti che utilizzano programmi condivisi come il programma AB.1.
1. (Consigliato) Completate un'analisi del dominio aziendale per determinare se il programma condiviso può essere aggregato in un dominio con applicazioni ed esposto come API come uno dei servizi di dominio.
È possibile utilizzare uno dei seguenti approcci per disaccoppiare le applicazioni in preparazione alla migrazione:
+ [Utilizza un'API autonoma](api.md)
+ [Usa una libreria condivisa](library.md)
+ [Usa una coda di messaggi](queue.md)
# Approccio 1: disaccoppiamento utilizzando un'API autonoma
Quando si utilizza questo approccio, si crea un'istanza di un'API autonoma convertendo il programma COBOL condiviso AB.1 in un programma Java. [Per ridurre al minimo gli sforzi di refactoring, è possibile utilizzare gli strumenti di refactoring automatici forniti dai AWS partner (vedere la sezione Risorse aggiuntive) per generare una rete per il programma.](resources.md) APIs Alcuni strumenti possono generare automaticamente un livello di facciata dal programma selezionato utilizzando un ambiente di sviluppo integrato (IDE) come Eclipse.
Consigliamo questo approccio quando è possibile creare un'istanza del programma condiviso come servizio autonomo. I componenti rimanenti delle applicazioni A e B vengono rifattorizzati in Java nel suo complesso e migrati nel cloud. È possibile migrare le applicazioni nella stessa ondata o in ondate diverse.
## Migrazione delle applicazioni nella stessa ondata
Nel diagramma seguente, le applicazioni A e B sono raggruppate per essere migrate nella stessa ondata.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
Se stai disaccoppiando il codice utilizzando un'API autonoma e migrando le applicazioni nella stessa ondata, segui questi passaggi:
1. Effettua il refactoring di entrambe le applicazioni con i rispettivi programmi e migrale nel cloud.
1. Utilizza il rapporto di analisi dell'impatto relativo alla fase di analisi per aiutare gli sviluppatori e i team a identificare le applicazioni rifattorizzate che richiamano il programma condiviso AB.1. Sostituisci la chiamata interna del programma al programma condiviso AB.1 con chiamate API di rete.
1. Dopo la migrazione, ritirate le applicazioni mainframe locali e i relativi componenti.
## Migrazione delle applicazioni in diverse fasi
Quando le applicazioni sono troppo grandi per essere raggruppate nella stessa ondata di migrazione, è possibile migrarle in più ondate, come illustrato nel diagramma seguente, e mantenere la continuità del servizio durante la migrazione. Con questo approccio, è possibile modernizzare le applicazioni in più fasi senza raggrupparle insieme. La migrazione delle applicazioni in fasi separate le separa senza richiedere modifiche significative al codice sul mainframe.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
Se stai disaccoppiando il codice utilizzando un'API autonoma e migrando le applicazioni in diverse fasi, segui questi passaggi:
1. Migra (rifattorizza) l'applicazione A con i programmi associati sul cloud mentre l'applicazione B continua a risiedere in locale.
1. Nell'applicazione A, sostituite la chiamata di programma interna al programma condiviso AB.1 con una chiamata API.
1. Conservate una copia del programma AB.1 sul mainframe in modo che l'applicazione B possa continuare a funzionare.
1. Bloccate lo sviluppo delle funzionalità del programma AB.1 sul mainframe. Dopo questo punto, lo sviluppo di tutte le funzionalità avverrà nel programma rifattorizzato AB.1 nel cloud.
1. Una volta completata la migrazione dell'applicazione A, ritirate l'applicazione locale e i relativi componenti (escluso il programma condiviso). L'applicazione B e i suoi componenti (incluso il programma condiviso) continuano a risiedere in locale.
1. Nella prossima serie di ondate di migrazione, migrate l'applicazione B e i suoi componenti. È possibile chiamare il programma migrato e rifattorizzato AB.1 per ridurre gli sforzi di refactoring per l'applicazione B.
# Approccio 2: disaccoppiamento utilizzando una libreria condivisa
In questo approccio, il programma condiviso AB.1 viene convertito in una libreria comune Java e viene fornito insieme alle applicazioni per la migrazione. Consigliamo questo approccio quando il programma condiviso è una libreria di supporto anziché un servizio autonomo.
I componenti rimanenti delle applicazioni A e B vengono rifattorizzati in programmi Java e migrati nel cloud. È possibile migrare le applicazioni nella stessa ondata o in ondate diverse.
## Migrazione delle applicazioni nella stessa ondata
Nel diagramma seguente, le applicazioni A e B sono raggruppate per essere migrate nella stessa ondata.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
Se stai disaccoppiando il codice utilizzando una libreria condivisa e migrando le applicazioni nella stessa ondata, segui questi passaggi:
1. Effettua il refactoring delle applicazioni A e B con i programmi associati in Java e migrale nel cloud.
1. Mantieni il codice sorgente delle applicazioni in un servizio di controllo del codice sorgente completamente gestito. I team che utilizzano il programma condiviso possono collaborare alle modifiche al codice utilizzando richieste pull, ramificazioni e fusioni e possono controllare le modifiche apportate al codice del programma condiviso.
1. Dopo la migrazione, ritirate le applicazioni mainframe locali e i relativi componenti.
## Migrazione delle applicazioni in diverse fasi
Quando le applicazioni sono troppo grandi per essere raggruppate nella stessa ondata di migrazione, è possibile migrarle in più ondate, come illustrato nel diagramma seguente, e mantenere la continuità del servizio durante la migrazione. Con questo approccio, è possibile modernizzare le applicazioni in più fasi senza raggrupparle insieme. La migrazione delle applicazioni in fasi separate le separa senza richiedere modifiche significative al codice sul mainframe.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
Se stai disaccoppiando il codice utilizzando una libreria condivisa e migrando le applicazioni in fasi diverse, segui questi passaggi:
1. Migra (rifattorizza) l'applicazione A con i programmi associati sul cloud mentre l'applicazione B continua a risiedere in locale.
1. Conservate una copia del programma AB.1 sul mainframe in modo che l'applicazione B possa continuare a funzionare.
1. Bloccate lo sviluppo delle funzionalità del programma AB.1 sul mainframe. A questo punto, lo sviluppo di tutte le funzionalità avverrà nel programma rifattorizzato AB.1 nel cloud.
1. Quando sviluppi nuove funzionalità per il programma AB.1, mantieni la compatibilità con le versioni precedenti per supportare la migrazione dell'applicazione B nelle ondate future.
1. Una volta completata la migrazione dell'applicazione A, ritirate l'applicazione locale e i relativi componenti (escluso il programma condiviso). L'applicazione B e i suoi componenti (incluso il programma condiviso) continuano a risiedere in locale.
1. Nella prossima serie di ondate di migrazione, migrate l'applicazione B e i suoi componenti. Puoi utilizzare l'ultima libreria condivisa del programma AB.1 nel cloud per ridurre gli sforzi di refactoring per l'applicazione B.
# Approccio 3: disaccoppia utilizzando una coda di messaggi
In questo approccio, il programma condiviso AB.1 viene convertito in un programma Java e migrato nel cloud come parte dell'applicazione A. Una coda di messaggi viene utilizzata come interfaccia tra l'applicazione sottoposta a refactoring nel cloud e l'applicazione legacy locale. Utilizzando questo approccio, è possibile suddividere le applicazioni mainframe strettamente collegate tra produttori e consumatori e renderle più modulari in modo che possano funzionare in modo indipendente. L'ulteriore vantaggio è che è possibile migrare le applicazioni in diverse fasi.
Si consiglia di utilizzare questo approccio quando:
+ Le applicazioni che risiedono sul mainframe possono comunicare con le applicazioni migrate nel cloud tramite una coda di messaggi.
+ Non è possibile conservare più copie del programma AB.1 (ad esempio, una copia locale e una copia su cloud, come nei due approcci precedenti).
+ Il modello di architettura di accodamento soddisfa i requisiti aziendali per le applicazioni che risiedono sul mainframe, poiché implica la riprogettazione delle applicazioni esistenti.
+ Le applicazioni che non fanno parte della prima ondata richiedono un periodo di tempo più lungo (sei mesi o più) per la migrazione al cloud.
## Migrazione delle applicazioni in diverse fasi
Quando le applicazioni sono troppo grandi per essere raggruppate nella stessa ondata di migrazione, è possibile migrarle in più ondate, come illustrato nel diagramma seguente, e mantenere la continuità del servizio durante la migrazione. Con questo approccio, è possibile modernizzare le applicazioni in più fasi senza raggrupparle insieme.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
Se utilizzi questo approccio, segui questi passaggi:
1. Migra (rifattorizza) l'applicazione A con i programmi associati sul cloud mentre l'applicazione B continua a risiedere in locale.
1. Effettua il refactoring dell'applicazione A (nel cloud) per comunicare con l'applicazione B (in locale) tramite una coda di messaggi.
1. Effettua il refactoring dell'applicazione B in locale per sostituire il programma condiviso AB.1 con un programma proxy che invia e riceve messaggi dall'applicazione A tramite la coda dei messaggi.
1. Una volta completata la migrazione dell'applicazione A, ritirate l'applicazione locale A e i relativi componenti (incluso il programma condiviso). L'applicazione B e i relativi componenti continuano a risiedere in locale.
1. Nella prossima serie di ondate di migrazione, migrate l'applicazione B e i suoi componenti. L'architettura di accodamento ad accoppiamento libero continua a fungere da interfaccia tra le applicazioni A e B sul cloud. Ciò riduce gli sforzi di refactoring per l'applicazione B senza influire sull'applicazione A.