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.
AWS Arquitectura de alto nivel Blu Age Runtime
Como parte de la solución de AWS Blu Age para modernizar los programas heredados a Java, el AWS Blu Age Runtime proporciona un punto de entrada unificado y REST basado en aplicaciones modernizadas y un marco de ejecución para dichas aplicaciones, a través de bibliotecas que proporcionan construcciones heredadas y una estandarización de la organización del código de los programas.
Estas aplicaciones modernizadas son el resultado del proceso de refactorización automatizada de AWS Blu Age para modernizar los programas de mainframe y rango medio (denominados «heredados» en el siguiente documento) a una arquitectura basada en la web.
Los objetivos de AWS Blu Age Runtime son la reproducción del comportamiento de los programas heredados (isofuncionalidad), el rendimiento (con respecto al tiempo de ejecución de los programas y el consumo de recursos) y la facilidad de mantenimiento de los programas modernizados por parte de los desarrolladores de Java, mediante el uso de entornos y modismos familiares como tomcat, Spring, getters/setters, fluentAPIs.
Temas
AWS Componentes de ejecución de Blu Age
El entorno de ejecución de AWS Blu Age se compone de dos tipos de componentes:
-
Un conjunto de bibliotecas java (archivos jar), a las que a menudo se hace referencia como “la carpeta compartida”, y que proporcionan construcciones e instrucciones heredadas.
-
Un conjunto de aplicaciones web (archivos war) que contienen aplicaciones web basadas en Spring y que proporcionan un conjunto común de marcos y servicios para los programas modernizados.
En las siguientes secciones se detalla el rol de estos dos componentes.
AWS Bibliotecas de Blu Age
Las bibliotecas AWS Blu Age son un conjunto de archivos jar almacenados en una shared/
subcarpeta que se añade a la ruta de clases estándar de Tomcat, para que estén disponibles para todos los programas Java modernizados. Su objetivo es proporcionar características que no están disponibles de forma nativa ni fácilmente disponibles en el entorno de programación Java, sino que son típicas de los entornos de desarrollo tradicionales. Estas funciones están expuestas de una forma que resulta lo más familiar posible para los desarrolladores de Java (captres/setters, basadas en clases, fluidas). APIs Un ejemplo importante es la biblioteca Data Simplifier, que proporciona estructuras antiguas de diseño y manipulación de la memoria (que se encuentran en COBOL los idiomas o idiomas) de los programas Java. PL1 RPG Estos archivos jar son una dependencia fundamental para el código Java modernizado generado a partir de programas heredados. Para obtener más información sobre Data Simplifier, consulte ¿Qué son los simplificadores de datos en AWS Blu Age?.
Aplicación web
Los archivos de aplicaciones web (WARs) son una forma estándar de implementar código y aplicaciones en el servidor de aplicaciones de Tomcat. Los que se proporcionan como parte del entorno de ejecución de AWS Blu Age tienen como objetivo proporcionar un conjunto de marcos de ejecución que reproduzcan los entornos y los monitores de transacciones tradicionales (JCLlotesCICS, IMS etc.) y los servicios necesarios asociados.
El más importante es gapwalk-application
(a menudo abreviado como «Gapwalk»), que proporciona un conjunto unificado de puntos de entrada REST basados en los que activar y controlar la ejecución de transacciones, programas y lotes. Para obtener más información, consulte AWS Tiempo de ejecución Blu Age APIs.
Esta aplicación web asigna subprocesos y recursos de ejecución de Java para ejecutar programas modernizados en el contexto para el que fueron diseñados. En la siguiente sección se detallan ejemplos de dichos entornos reproducidos.
Otras aplicaciones web añaden al entorno de ejecución (con más precisión, al “registro de programas”, que se describe a continuación) programas que emulan los programas antiguos disponibles y a los que se puede acceder desde ellos. Dos categorías importantes son las siguientes:
-
Emulación de programas proporcionados por el sistema operativo: los lotes JCL basados en lotes esperan poder llamar a una variedad de programas de manipulación de archivos y bases de datos como parte de su entorno estándar. Entre los ejemplos se incluyen
SORT
/DFSORT
yIDCAMS
. Para ello, se proporcionan programas Java que reproducen dicho comportamiento y se pueden invocar utilizando las mismas convenciones que los programas antiguos. -
Los “controladores”, que son programas especializados proporcionados por el marco de ejecución o el middleware como puntos de entrada. Un ejemplo es
CBLTDLI
de qué COBOL programas se ejecutan en el IMS entorno para acceder a los servicios IMS relacionados (IMSbase de datos, diálogo con el usuario, etc.). MFS
Registro de programas
Para participar y aprovechar esas constructos, marcos y servicios, los programas Java modernizados a partir de los antiguos se adhieren a una estructura específica documentada en AWS Estructura de Blu Age de una aplicación modernizada. Al iniciarse, el motor de ejecución de AWS Blu Age recopilará todos estos programas en un «registro de programas» común para poder invocarlos (y llamarlos entre sí) posteriormente. El registro de programas ofrece un acoplamiento flexible y posibilidades de descomposición (ya que los programas que se llaman entre sí no tienen que modernizarse simultáneamente).
Entornos de ejecución
Están disponibles los entornos y coreografías tradicionales que se encuentran con más frecuencia:
-
JCL-Los lotes controlados por lotes, una vez modernizados para incluir programas Java y scripts Groovy, se pueden iniciar de forma sincrónica (bloqueo) o asíncrona (separada). En este último caso, su ejecución se puede monitorear a través de puntos finales. REST
-
Un subsistema AWS Blu Age proporciona un entorno de ejecución similar al CICS siguiente:
-
un punto de entrada utilizado para iniciar una CICS transacción y ejecutar los programas asociados, respetando la coreografía de los CICS «niveles de ejecución»,
-
un almacenamiento externo para las definiciones de recursos,
-
un conjunto homogéneo de sentencias que se APIs
EXEC CICS
reproducen con fluidez en Java, -
un conjunto de clases conectables que reproducen CICS servicios, como colas de almacenamiento temporal, colas temporales de datos o acceso a archivos (normalmente hay varias implementaciones disponibles, como Amazon Managed Service para Apache Flink, Amazon Simple Queue Service o RabbitMQ para TD Queues),
-
en el caso de las aplicaciones orientadas al usuario, el formato de descripción de la BMS pantalla se ha modernizado para convertirlo en una aplicación web angular y se admite el correspondiente cuadro de diálogo «pseudoconversacional».
-
-
Del mismo modo, otro subsistema proporciona una coreografía IMS basada en mensajes y permite modernizar las pantallas de la interfaz de usuario en este formato. MFS
-
Además, un tercer subsistema permite la ejecución de programas en un entorno iSeries similar, incluida la modernización de las pantallas especificadas DSPF (Display File).
Todos estos entornos se basan en servicios comunes a nivel de sistema operativo, tales como:
-
la emulación de la asignación y el diseño de la memoria tradicionales (Data Simplifier),
-
Reproducción basada en subprocesos de Java del mecanismo de ejecución y paso de parámetros de las COBOL «unidades de ejecución» (sentencia),
CALL
-
emulación de organizaciones planas, concatenadas VSAM (a través del conjunto de bibliotecas Blusam) y de conjuntos de datos, GDG
-
acceso a almacenes de datos, como (declaraciones). RDBMS
EXEC SQL
Ausencia de estado y gestión de sesiones
Una característica importante del tiempo de ejecución de AWS Blu Age es permitir escenarios de alta disponibilidad (HA) y escalabilidad horizontal al ejecutar programas modernizados.
La piedra angular de esto es la apatridia, un ejemplo importante de lo cual es el manejo de las sesiones. HTTP
Gestión de sesiones
Al estar Tomcat basado en la web, un mecanismo importante para ello es la gestión de las HTTP sesiones (tal y como ofrecen Tomcat y Spring) y el diseño sin estado. El diseño de la ausencia de estado se basa en lo siguiente:
-
sin embargo, los usuarios se conectan, HTTPS
-
los servidores de aplicaciones se implementan detrás de un equilibrador de carga,
-
cuando un usuario se conecte por primera vez a la aplicación, se autenticará y el servidor de la aplicación creará un identificador (normalmente dentro de una cookie)
-
este identificador se utilizará como clave para guardar y recuperar el contexto del usuario hacia/desde una caché externa (almacén de datos).
La gestión de las cookies se realiza automáticamente mediante el marco AWS Blu Age y el servidor Tomcat subyacente, de forma transparente para el usuario. El navegador de Internet del usuario lo gestionará automáticamente.
La aplicación web Gapwalk puede almacenar el estado de la sesión (el contexto) en varios almacenes de datos:
-
Amazon ElastiCache (RedisOSS)
-
Clúster de Redis
-
en un mapa de memoria (solo para entornos de desarrollo e independientes, no apto para HA).
Alta disponibilidad y apatridia
En términos más generales, uno de los principios de diseño del marco de la Era AWS Azul es la apatridia: la mayoría de los estados no transitorios necesarios para reproducir el comportamiento de los programas heredados no se almacenan en los servidores de aplicaciones, sino que se comparten a través de una «fuente única de información» externa y común.
Algunos ejemplos de estos estados son las colas de almacenamiento temporal o las definiciones CICS de recursos, y los almacenamientos externos típicos de esos estados son los servidores compatibles con Redis o las bases de datos relacionales.
Este diseño, combinado con el equilibrio de carga y las sesiones compartidas, permite que la mayor parte del diálogo orientado al usuario («procesamiento transaccional en línea») se pueda distribuir entre varios «nodos» (en este casoOLTP, instancias de Tomcat).
De hecho, un usuario puede ejecutar una transacción en cualquier servidor sin importarle si la siguiente llamada a la transacción se realiza en un servidor diferente. Luego, cuando se genera un nuevo servidor (debido al escalado automático o para reemplazar un servidor que no esté en buen estado), podemos garantizar que cualquier servidor accesible y en buen estado pueda ejecutar la transacción según lo esperado con los resultados adecuados (valor devuelto esperado, cambio de datos esperado en la base de datos, etc.).