La arquitectura de concepto de prueba toma entrada de Tarea: Análisis de activos existentes y tiene en cuenta el Concepto: Cartera de servicios definido por Actividad: Realizar especificación de servicio.
Igualmente, cuando se tratan aplicaciones existentes, deberán examinarse y tenerse en cuenta los siguientes elementos:
-
Manejo de excepciones: Es necesario entender cómo funciona el manejo de excepciones hoy en día. En el
proceso de lotes, cuando se produce una excepción, el programa finaliza anormalmente y produce un volcado del
núcleo. El programador debe observar el volcado del núcleo y observar qué se debe hacer. Esto puede no ser
aceptable. Uno debe averiguar lo que debe hacerse... por ejemplo, cómo realizar la integración con la
infraestructura del manejo de excepciones.
-
Distribución de datos y procesos: Tenemos que examinar dónde se ejecutan los datos y procesos. La aplicación
CICS que se ejecuta en una máquina y puede enviar una solicitud a otra máquina (también conocida como función envío
en CICS) o datos de llamada remotos en otra máquina. Quizás deseemos ir directamente (JDBC a DB) a la máquina
remota en la que se ejecutan los datos o el proceso, en lugar de utilizar el conector que atraviesa de JDBC a DB.
-
Disponibilidad de datos: Si tenemos un archivo de cliente en VSAM que necesita, digamos, una ventana de
mantenimiento de 4 horas, entonces no podremos dar soporte al servicio de cliente de 24 horas los 7 días de la
semana. Deberíamos considerar la posibilidad de una nueva solución de almacenamiento.
-
Autorización/Autenticación: Muchas aplicaciones heredadas tienen mecanismos de autorización y autenticación
en el código de aplicación. Esto requeriría la migración de la gestión de acceso de usuarios a un entorno
gestionado de forma federada soportado por mejores prácticas.
-
Retardos de intermedio: Normalmente los programas de lotes se ejecutan una vez al día de noche. Si los
requisitos obligan a ejecutar el programa más frecuentemente, entonces tendremos que modificar el programa de
planificación para cambiar la frecuencia.
La lista anterior no es exhaustiva; se proporciona aquí como instrucción.
Ejemplo
En el ejemplo Alquiler de un coche, la realización de servicio debe tener en cuenta los siguientes requisitos:
-
Interfaz perfecta entre cliente/servidor remoto, aplicaciones de estación de trabajo y aplicaciones IMS del sistema
principal.
-
Eliminar el "desecho de pantalla" desde el punto de vista de la aplicación remota. Se trata de eliminar la
necesidad de cambiar el proceso de la aplicación remota, simplemente porque un mensaje se añade a una pantalla, o
un cambio cambia las posiciones de una pantalla.
-
Dar soporte a mensajes de entrada y salida de las aplicaciones IMS que están predefinidas y tienen formato fijo.
-
El proceso relacionado con el formateo de mensajes debe ser transparente para la aplicación IMS, de modo que se
reduzca de forma significativa el tiempo necesario para desarrollar y probar nuevas aplicaciones remotas.
-
Dar soporte a nuevas características de aplicación IMS y a nuevos campos de datos en sistemas remotos de forma
puntual, por ejemplo, reduciendo el tiempo que tardan en mejorarse los sistemas existentes.
Los elementos de estas decisiones y consideraciones de viabilidad técnica se relacionan con aspectos funcionales y
operativos de la arquitectura. Para cumplir con los anteriores requisitos, se utilizó el siguiente enfoque:
-
Intermediario de mensajes/Intermediario de integración para controlar el formateo de mensajes hacia y desde las
aplicaciones IMS. El intermediario de mensajes realiza las siguientes funciones:
-
Volver a formatear mensajes de entrada (de XML a un formato de longitud fija) en un formato predefinido
aceptado por las aplicaciones IMS del sistema principal.
-
Volver a formatear (de formato de longitud fija a XML) las respuestas de salida de IMS del sistema
principal a un formato de palabra clave de IMF, para que sean procesados por la aplicación de envío
original.
-
Interrogar a un mensaje de entrada para determinar si está en formato IMF comprobando la cabecera del
mensaje que precede a la carga útil de datos. La cabecera está en un formato posicional, y contiene varios
componentes clave de información necesario para que IMF se procese correctamente.
-
Realiza direccionamiento y transformación basados en el contenido de la cabecera de mensaje y del código de
transacciones IMS. Este código de transacciones IMS es necesario para ejecutar la transacción adecuada
dentro del sistema principal de IMS.
-
Puente IMS-MQ que actúe como un conducto entre el intermediario de mensajes y el sistema IMS.
El uso del intermediario de mensajes/integración reduce enormemente o elimina la necesidad de personalizar cada
aplicación IMS para controlar las solicitudes de transacción de diversos sistemas remotos. Como la mayoría de los
procesos relacionados con formateo de mensajes son transparentes para la aplicación IMS, el tiempo necesario para
desarrollar y probar nuevas aplicaciones remotas se verá reducido de forma drástica. Además, nuevas características de
aplicación IMS y nuevos campos de datos estarán disponibles en los sistemas remotos de manera puntual, reduciendo el
tiempo que tarda en mejorarse los sistemas existentes. Esto conduce a un acoplamiento débil de las aplicaciones, uno de
los principios fundamentales de la arquitectura orientada a servicios.
|