Tarea: Construir prueba de concepto arquitectónica (SOA)
Esta tarea define cómo desarrollar una arquitectura de prueba de concepto, para una solución de SOA, basada en un perfil de riesgo y en requisitos arquitectónicos.
Disciplinas: Análisis y diseño
Amplía: Construir arquitectura de prueba de concepto
Objetivo

Para sincronizar una solución ejemplar que cumpla con los requisitos arquitectónicos importante, este ejemplo puede limitarse de alguna forma, por ejemplo:

  • la solución resultante puede ser simplemente conceptual,
  • la solución resultante puede sólo ilustrar algún aspecto crítico de los requisitos globales.
Relaciones
Descripción principal

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.

Pasos
Decidir el enfoque de la construcción

Seleccione las técnicas que se utilizarán en la construcción de la arquitectura de prueba de concepto, por ejemplo:

  • Modelado conceptual
  • Prototipos 'rápidos'
  • Simulación
  • Traducción automática de especificaciones en código
  • Especificaciones 'ejecutables'
  • Construcción de  'picos' como prototipos: porciones verticales a través de las capas

El arquitecto de software necesita poder razonar estos modelos y descubrir en el proceso algo sobre los espacios de problemas y soluciones.

Seleccionar los activos y las tecnologías de la arquitectura de prueba de concepto

El arquitecto de software debe seleccionar, entre los activos y las tecnologías que se han identificado en Tarea: Análisis de la arquitectura, aquellos que se utilizarán en la construcción de la arquitectura de prueba de concepto.

Construir la arquitectura de prueba de concepto

Mediante las técnicas seleccionadas para la construcción, el arquitecto de software crea la arquitectura de prueba de concepto, utilizando las tecnologías y los activos seleccionados, para cumplir (en el grado necesario para el perfil de riesgos del proyecto) los requisitos significativos arquitectónicamente, tal como se capturan en las realizaciones de guión de uso estándar, los modelos de diseño y despliegue de la visión general, y el documento de arquitectura de software.



Más información
Conceptos