As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Aplicativos que compartilham programas
O diagrama a seguir ilustra os aplicativos de mainframe A e B que executam um programa compartilhado chamado programa AB.1. Esse caso também é aplicável quando os aplicativos A e B incluem programas que chamam subprogramas compartilhados.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Etapas para análise**
1. Faça uma análise de impacto do programa compartilhado AB.1, para que você possa migrar os aplicativos A e B e programar o AB.1 juntos. Recomendamos usar as ferramentas de descoberta listadas na seção [Recursos adicionais](resources.md) para automatizar a análise.
1. Com base na análise de impacto, identifique o número de aplicativos dependentes que usam programas compartilhados, como o programa AB.1.
1. (Recomendado) Conclua uma análise do domínio comercial para determinar se o programa compartilhado pode ser agregado em um domínio com aplicativos e exposto como uma API como um dos serviços de domínio.
Você pode usar uma das seguintes abordagens para desacoplar os aplicativos na preparação para a migração:
+ [Use uma API independente](api.md)
+ [Use uma biblioteca compartilhada](library.md)
+ [Use uma fila de mensagens](queue.md)
# Abordagem 1: desacoplar usando uma API autônoma
Ao usar essa abordagem, você instancia uma API autônoma convertendo o programa COBOL compartilhado AB.1 em um programa Java. Para minimizar os esforços de refatoração, você pode usar ferramentas automatizadas de refatoração fornecidas pelos AWS parceiros (consulte a seção [Recursos adicionais](resources.md)) para gerar uma rede para o programa. APIs Algumas ferramentas podem gerar automaticamente uma camada de fachada a partir do programa selecionado usando um ambiente de desenvolvimento integrado (IDE), como o Eclipse.
Recomendamos essa abordagem quando o programa compartilhado pode ser instanciado como um serviço independente. Os componentes restantes dos aplicativos A e B são refatorados em Java como um todo e migrados para a nuvem. Você pode migrar os aplicativos na mesma onda ou em ondas diferentes.
## Migrando aplicativos na mesma onda
No diagrama a seguir, os aplicativos A e B são agrupados para serem migrados na mesma onda.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
Se você estiver desacoplando seu código usando uma API independente e migrando aplicativos na mesma onda, siga estas etapas:
1. Refatore os dois aplicativos com seus respectivos programas e migre-os para a nuvem.
1. Use o relatório de análise de impacto da fase de análise para ajudar desenvolvedores e equipes a identificar os aplicativos refatorados que chamam o programa compartilhado AB.1. Substitua a chamada interna do programa pelo programa compartilhado AB.1 por chamadas de API de rede.
1. Após a migração, retire os aplicativos de mainframe locais e seus componentes.
## Migração de aplicativos em diferentes ondas
Quando os aplicativos são grandes demais para serem agrupados na mesma onda de migração, você pode migrá-los em várias ondas, conforme mostrado no diagrama a seguir, e manter a continuidade do serviço durante a migração. Com essa abordagem, você pode modernizar seus aplicativos em fases sem agrupá-los. A migração de seus aplicativos em ondas separadas os separa sem exigir alterações significativas no código do mainframe.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
Se você estiver desacoplando seu código usando uma API independente e migrando aplicativos em diferentes ondas, siga estas etapas:
1. Migre (refatore) o aplicativo A com seus programas associados para a nuvem enquanto o aplicativo B continua residindo no local.
1. No aplicativo A, substitua a chamada interna do programa pelo programa compartilhado AB.1 por uma chamada de API.
1. Mantenha uma cópia do programa AB.1 no mainframe para que o aplicativo B possa continuar operando.
1. Congele o desenvolvimento de recursos do programa AB.1 no mainframe. Após esse ponto, todo o desenvolvimento de recursos ocorrerá no programa refatorado AB.1 na nuvem.
1. Depois que o aplicativo A for migrado com êxito, desative o aplicativo local e seus componentes (excluindo o programa compartilhado). O aplicativo B e seus componentes (incluindo o programa compartilhado) continuam residindo no local.
1. No próximo conjunto de ondas de migração, migre o aplicativo B e seus componentes. Você pode chamar o programa migrado e refatorado de AB.1 para reduzir os esforços de refatoração do aplicativo B.
# Abordagem 2: desacoplar usando uma biblioteca compartilhada
Nessa abordagem, o programa compartilhado AB.1 é convertido em uma biblioteca comum Java e é empacotado com os aplicativos para migração. Recomendamos essa abordagem quando o programa compartilhado é uma biblioteca de suporte em vez de um serviço independente.
Os componentes restantes dos aplicativos A e B são refatorados em programas Java e migrados para a nuvem. Você pode migrar os aplicativos na mesma onda ou em ondas diferentes.
## Migrando aplicativos na mesma onda
No diagrama a seguir, os aplicativos A e B são agrupados para serem migrados na mesma onda.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
Se você estiver desacoplando seu código usando uma biblioteca compartilhada e migrando aplicativos na mesma onda, siga estas etapas:
1. Refatore os aplicativos A e B com seus programas associados em Java e migre-os para a nuvem.
1. Mantenha o código-fonte dos aplicativos em um serviço de controle de origem totalmente gerenciado. As equipes que usam o programa compartilhado podem colaborar nas alterações de código usando pull requests, ramificação e mesclagem, além de controlar as alterações feitas no código do programa compartilhado.
1. Após a migração, retire os aplicativos de mainframe locais e seus componentes.
## Migração de aplicativos em diferentes ondas
Quando os aplicativos são grandes demais para serem agrupados na mesma onda de migração, você pode migrá-los em várias ondas, conforme mostrado no diagrama a seguir, e manter a continuidade do serviço durante a migração. Com essa abordagem, você pode modernizar seus aplicativos em fases sem agrupá-los. A migração de seus aplicativos em ondas separadas os separa sem exigir alterações significativas no código do mainframe.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
Se você estiver desacoplando seu código usando uma biblioteca compartilhada e migrando aplicativos em diferentes ondas, siga estas etapas:
1. Migre (refatore) o aplicativo A com seus programas associados para a nuvem enquanto o aplicativo B continua residindo no local.
1. Mantenha uma cópia do programa AB.1 no mainframe para que o aplicativo B possa continuar operando.
1. Congele o desenvolvimento de recursos do programa AB.1 no mainframe. Nesse ponto, todo o desenvolvimento de recursos ocorrerá no programa refatorado AB.1 na nuvem.
1. Ao desenvolver novos recursos para o programa AB.1, mantenha a compatibilidade com versões anteriores para suportar a migração do aplicativo B em futuras ondas.
1. Depois que o aplicativo A for migrado com êxito, desative o aplicativo local e seus componentes (excluindo o programa compartilhado). O aplicativo B e seus componentes (incluindo o programa compartilhado) continuam residindo no local.
1. No próximo conjunto de ondas de migração, migre o aplicativo B e seus componentes. Você pode usar a biblioteca compartilhada mais recente do programa AB.1 na nuvem para reduzir os esforços de refatoração do aplicativo B.
# Abordagem 3: desacoplar usando uma fila de mensagens
Nessa abordagem, o programa compartilhado AB.1 é convertido em um programa Java e migrado para a nuvem como parte do aplicativo A. Uma fila de mensagens é usada como uma interface entre o aplicativo refatorado na nuvem e o aplicativo legado no local. Ao usar essa abordagem, você pode dividir aplicativos de mainframe fortemente acoplados em produtores e consumidores e torná-los mais modulares para que possam funcionar de forma independente. A vantagem adicional é que você pode migrar os aplicativos em diferentes ondas.
Recomendamos que você use essa abordagem quando:
+ Os aplicativos que residem no mainframe podem se comunicar com os aplicativos migrados na nuvem por meio de uma fila de mensagens.
+ Várias cópias do programa AB.1 (por exemplo, uma cópia local e uma cópia na nuvem, como nas duas abordagens anteriores) não podem ser mantidas.
+ O padrão de arquitetura de filas atende aos requisitos comerciais dos aplicativos que residem no mainframe, pois envolve a rearquitetura dos aplicativos existentes.
+ Os aplicativos que não fazem parte da primeira onda exigem mais tempo (seis meses ou mais) para serem migrados para a nuvem.
## Migração de aplicativos em diferentes ondas
Quando os aplicativos são grandes demais para serem agrupados na mesma onda de migração, você pode migrá-los em várias ondas, conforme mostrado no diagrama a seguir, e manter a continuidade do serviço durante a migração. Com essa abordagem, você pode modernizar seus aplicativos em fases sem agrupá-los.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
Se você estiver usando essa abordagem, siga estas etapas:
1. Migre (refatore) o aplicativo A com seus programas associados para a nuvem enquanto o aplicativo B continua residindo no local.
1. Refatore o aplicativo A (na nuvem) para se comunicar com o aplicativo B (no local) por meio de uma fila de mensagens.
1. Refatore o aplicativo B no local para substituir o programa compartilhado AB.1 por um programa proxy que envia e recebe mensagens do aplicativo A por meio da fila de mensagens.
1. Depois que o aplicativo A for migrado com êxito, desative o aplicativo A local e seus componentes (incluindo o programa compartilhado). O aplicativo B e seus componentes continuam residindo no local.
1. No próximo conjunto de ondas de migração, migre o aplicativo B e seus componentes. A arquitetura de filas fracamente acoplada continua atuando como uma interface entre os aplicativos A e B na nuvem. Isso reduz os esforços de refatoração do aplicativo B sem afetar o aplicativo A.