Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Aplicaciones que comparten programas
El siguiente diagrama ilustra las aplicaciones A y B de mainframe que ejecutan un programa compartido denominado programa AB.1. Este caso también se aplica cuando las aplicaciones A y B incluyen programas que se denominan subprogramas compartidos.
![\[Mainframe applications that share programs\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared.png)
**Pasos para el análisis**
1. Realice un análisis de impacto del programa compartido AB.1 para poder migrar las aplicaciones A y B y programar AB.1 de forma conjunta. Recomendamos utilizar las herramientas de descubrimiento que se enumeran en la sección [Recursos adicionales](resources.md) para automatizar el análisis.
1. Basándose en el análisis de impacto, identifique el número de aplicaciones dependientes que utilizan programas compartidos, como el programa AB.1.
1. (Recomendado) Realice un análisis del dominio empresarial para determinar si el programa compartido puede agregarse a un dominio con aplicaciones y exponerse como una API como uno de los servicios del dominio.
Puede utilizar uno de los siguientes enfoques para desvincular las aplicaciones como preparación para la migración:
+ [Utilice una API independiente](api.md)
+ [Usa una biblioteca compartida](library.md)
+ [Usa una cola de mensajes](queue.md)
# Método 1: desacople mediante una API independiente
Al utilizar este enfoque, se crea una instancia de una API independiente al convertir el programa COBOL AB.1 compartido en un programa Java. Para minimizar los esfuerzos de refactorización, puede utilizar las herramientas de refactorización automatizadas proporcionadas por los AWS socios (consulte la sección de [recursos adicionales) a fin de generar una red para el programa](resources.md). APIs Algunas herramientas pueden generar automáticamente una capa de fachada a partir del programa seleccionado mediante un entorno de desarrollo integrado (IDE) como Eclipse.
Recomendamos este enfoque cuando se pueda crear una instancia del programa compartido como un servicio independiente. Los componentes restantes de las aplicaciones A y B se refactorizan en Java como un todo y se migran a la nube. Puede migrar las aplicaciones en la misma oleada o en oleadas diferentes.
## Migración de aplicaciones en la misma oleada
En el siguiente diagrama, las aplicaciones A y B se agrupan para migrarlas en la misma oleada.
![\[Migrating mainframe applications that share programs: using an standalone API and a single migration wave\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-same.png)
Si vas a desvincular el código mediante una API independiente y migrar las aplicaciones en la misma oleada, sigue estos pasos:
1. Refactoriza ambas aplicaciones con sus respectivos programas y mírgalas a la nube.
1. Utilice el informe de análisis de impacto de la fase de análisis para ayudar a los desarrolladores y a los equipos a identificar las aplicaciones refactorizadas que se denominan programa compartido AB.1. Sustituya la llamada interna al programa compartido AB.1 por llamadas a la API de red.
1. Tras la migración, retire las aplicaciones de mainframe locales y sus componentes.
## Migración de aplicaciones en diferentes oleadas
Cuando las aplicaciones son demasiado grandes para agruparlas en la misma ola de migración, puede migrarlas en varias oleadas, como se muestra en el siguiente diagrama, y mantener la continuidad del servicio durante la migración. Con este enfoque, puede modernizar sus aplicaciones por fases sin tener que agruparlas. La migración de las aplicaciones en oleadas independientes las desacopla sin necesidad de realizar cambios significativos en el código del mainframe.
![\[Migrating mainframe applications that share programs: using an standalone API and multiple migration waves\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-1-diff.png)
Si va a desvincular el código mediante una API independiente y migrar las aplicaciones en distintas oleadas, siga estos pasos:
1. Migre (refactorice) la aplicación A con sus programas asociados a la nube mientras la aplicación B sigue residiendo en las instalaciones.
1. En la aplicación A, sustituya la llamada al programa interno al programa compartido AB.1 por una llamada a la API.
1. Mantenga una copia del programa AB.1 en el ordenador central para que la aplicación B pueda seguir funcionando.
1. Congele el desarrollo de funciones del programa AB.1 en la computadora central. Después de este punto, todo el desarrollo de las funciones se llevará a cabo en el programa refactorizado AB.1 en la nube.
1. Una vez que la aplicación A se haya migrado correctamente, retire la aplicación local y sus componentes (excepto el programa compartido). La aplicación B y sus componentes (incluido el programa compartido) siguen residiendo en las instalaciones.
1. En la siguiente serie de oleadas de migración, migre la aplicación B y sus componentes. Puede denominar AB.1 al programa migrado y refactorizado para reducir los esfuerzos de refactorización de la aplicación B.
# Método 2: Desacoplar mediante una biblioteca compartida
En este enfoque, el programa compartido AB.1 se convierte en una biblioteca común de Java y se empaqueta con las aplicaciones para su migración. Recomendamos este enfoque cuando el programa compartido sea una biblioteca de soporte en lugar de un servicio independiente.
El resto de los componentes de las aplicaciones A y B se refactorizan en programas Java y se migran a la nube. Puede migrar las aplicaciones en la misma oleada o en oleadas diferentes.
## Migración de aplicaciones en la misma oleada
En el siguiente diagrama, las aplicaciones A y B se agrupan para migrarlas en la misma oleada.
![\[Migrating mainframe applications that share programs: using a common library and a single migration wave\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-same.png)
Si va a desvincular el código mediante una biblioteca compartida y migrar las aplicaciones en la misma oleada, siga estos pasos:
1. Refactoriza las aplicaciones A y B con sus programas asociados a Java y mírgalas a la nube.
1. Mantenga el código fuente de las aplicaciones en un servicio de control de código fuente totalmente gestionado. Los equipos que utilizan el programa compartido pueden colaborar en los cambios de código mediante solicitudes de extracción, ramificaciones y fusiones, y pueden controlar los cambios realizados en el código del programa compartido.
1. Tras la migración, retire las aplicaciones de mainframe locales y sus componentes.
## Migración de aplicaciones en diferentes oleadas
Cuando las aplicaciones son demasiado grandes para agruparlas en la misma ola de migración, puede migrarlas en varias oleadas, como se muestra en el siguiente diagrama, y mantener la continuidad del servicio durante la migración. Con este enfoque, puede modernizar sus aplicaciones por fases sin tener que agruparlas. La migración de las aplicaciones en oleadas independientes las desacopla sin necesidad de realizar cambios significativos en el código del mainframe.
![\[Migrating mainframe applications that share programs: using a common library and multiple migration waves\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-2-diff.png)
Si va a desvincular el código mediante una biblioteca compartida y migrar las aplicaciones en distintas oleadas, siga estos pasos:
1. Migre (refactorice) la aplicación A con sus programas asociados a la nube mientras la aplicación B sigue residiendo en las instalaciones.
1. Mantenga una copia del programa AB.1 en el ordenador central para que la aplicación B pueda seguir funcionando.
1. Congele el desarrollo de funciones del programa AB.1 en la computadora central. En este punto, todo el desarrollo de las funciones se llevará a cabo en el programa AB.1 refactorizado en la nube.
1. Al desarrollar nuevas funciones para el programa AB.1, mantenga la compatibilidad con versiones anteriores para respaldar la migración de la aplicación B en futuras oleadas.
1. Una vez que la aplicación A se haya migrado correctamente, retire la aplicación local y sus componentes (excepto el programa compartido). La aplicación B y sus componentes (incluido el programa compartido) siguen residiendo en las instalaciones.
1. En la siguiente serie de oleadas de migración, migre la aplicación B y sus componentes. Puede utilizar la biblioteca compartida más reciente del programa AB.1 en la nube para reducir los esfuerzos de refactorización de la aplicación B.
# Método 3: Desacoplar mediante una cola de mensajes
En este enfoque, el programa compartido AB.1 se convierte en un programa Java y se migra a la nube como parte de la aplicación A. Se utiliza una cola de mensajes como interfaz entre la aplicación refactorizada en la nube y la aplicación antigua local. Con este enfoque, puede dividir las aplicaciones de mainframe estrechamente acopladas en productoras y consumidoras, y hacerlas más modulares para que puedan funcionar de forma independiente. La ventaja adicional es que puede migrar las aplicaciones en distintas fases.
Le recomendamos que utilice este enfoque cuando:
+ Las aplicaciones que residen en el mainframe pueden comunicarse con las aplicaciones migradas a la nube a través de una cola de mensajes.
+ No se pueden mantener varias copias del programa AB.1 (por ejemplo, una copia local y una copia en la nube, como en los dos enfoques anteriores).
+ El patrón de arquitectura de colas cumple con los requisitos empresariales de las aplicaciones que residen en el mainframe, ya que implica rediseñar la arquitectura de las aplicaciones existentes.
+ Las aplicaciones que no forman parte de la primera oleada requieren más tiempo (seis meses o más) para migrar a la nube.
## Migración de aplicaciones en distintas oleadas
Cuando las aplicaciones son demasiado grandes para agruparlas en la misma ola de migración, puede migrarlas en varias oleadas, como se muestra en el siguiente diagrama, y mantener la continuidad del servicio durante la migración. Con este enfoque, puede modernizar sus aplicaciones por fases sin tener que agruparlas.
![\[Migrating mainframe applications that share programs: using a message queue and multiple migration waves\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-mainframe-decoupling-patterns/images/shared-3-diff.png)
Si utiliza este enfoque, siga estos pasos:
1. Migre (refactorice) la aplicación A con sus programas asociados a la nube mientras la aplicación B sigue residiendo en las instalaciones.
1. Refactoriza la aplicación A (en la nube) para que se comunique con la aplicación B (local) a través de una cola de mensajes.
1. Refactoriza la aplicación B localmente para reemplazar el programa compartido AB.1 por un programa proxy que envía mensajes a la aplicación A y recibe mensajes desde ella a través de la cola de mensajes.
1. Una vez que la aplicación A se haya migrado correctamente, retire la aplicación local A y sus componentes (incluido el programa compartido). La aplicación B y sus componentes siguen residiendo en las instalaciones.
1. En la siguiente serie de oleadas de migración, migre la aplicación B y sus componentes. La arquitectura de colas poco acoplada sigue actuando como una interfaz entre las aplicaciones A y B en la nube. Esto reduce los esfuerzos de refactorización de la aplicación B sin afectar a la aplicación A.