Generación de conectores BL.MOM - Parte 2

ilustración de interoperabilidad
Arquitectura global del generador de conectores BL-MOM

La arquitectura global de la solución propuesta se muestra en la Figura 1. En ella se representan los principales componentes del Generador de Conectores BL-MOM y sus interacciones para satisfacer los diferentes requisitos de generación. Básicamente, la aplicación es una arquitectura de tres niveles compuesta por: (i) Front-endEl Generador de Conectores BL-MOM es una aplicación web que permite a un usuario final (es decir, típicamente un desarrollador de módulos de interoperabilidad) interactuar con los diversos servicios de generación proporcionados por el Generador de Conectores BL-MOM, así como acceder a un catálogo de módulos generados persistiendo en una base de datos. (ii) Back-end es la parte de procesamiento del Generador de Conectores BL-MOM que comprende los diferentes servicios de generación (mencionados anteriormente), la lógica de aplicación responsable de la implementación de la lógica de negocio y que representa el aspecto funcional de la solución, y la parte de la base de datos para el procesamiento y almacenamiento de datos. 

En el contexto de BL.MOM y con el objetivo de construir sistemas de intercambio adaptables utilizando nodos de interoperabilidad generados parcial o totalmente de forma automática. Se propuso el Generador de Conectores BL.MOM. Se trata de un proyecto que ayuda a gestionar la complejidad de desarrollar conectores de interoperabilidad BL.MOM desde cero y favorece una mayor productividad y una ganancia en términos de tiempo y coste de desarrollo de estos conectores. 

En un anterior artículo se presentaron los servicios de generación del Generador de Conectores BL.MOM, que consiste en un conjunto de servicios REST débilmente acoplados, cada uno de los cuales realiza tareas específicas de generación y se comunican entre sí a través de sus endpoints para generar diferentes tipos de proyectos, según los parámetros de configuración recibidos de los usuarios finales dentro de las peticiones REST. A continuación, un recordatorio de los servicios de generación: 

  • El servicio Initializr se encarga de producir esqueletos de proyectos Spring personalizados interactuando con el servidor Spring Initializr.  
  • El servicio de generación de creadores de esquemas de mensajes genera proyectos para crear bibliotecas Java de mensajes Apache Avro. También solicita al servicio de generación de Concordian que mantenga las especificaciones HTML de estos mensajes compatibles con su código.
  • Los servicios de generación de envolturas que generan un proyecto de envoltura de mensajes para manejar tipos de mensajes y diferentes mensajes de publicación y consumo por tipo de mensaje 
  • Los servicios de generación de autoconfiguración que genera un módulo para soportar las estructuras de configuración y la autoconfiguración  
  • El servicio de generación de conectores supervisa la generación de partes de módulos consumidores y publicadores de mensajes para uno o varios temas existentes. Estos módulos deben completarse para abordar el código relacionado con el contexto empresarial, en el que podemos especificar, por ejemplo, lo que hay que hacer después de recibir un mensaje.  

El creador del esquema de mensajes, el wrapper y los proyectos de autoconfiguración se generan una vez para cada contexto de intercambio de datos relacionado con un conjunto de temas de negocio, es lo que llamamos contexto de interoperabilidad. Y se pueden generar tantos conectores (editores/consumidores) como sean necesarios para cada nueva necesidad de intercambio de datos para el mismo contexto de interoperabilidad. 

Para ir más allá y proponer una herramienta completa que capture las configuraciones de los usuarios finales para la generación de estos módulos BL.MOM, se han desarrollado servicios complementarios de Back-end y Front-end, que se presentan a continuación.   

Figura 1. Arquitectura global de BL-MOM

Figura 1. Arquitectura global del generador de conectores BL-MOM

El Back-end es una aplicación Spring-boot compuesta por los siguientes componentes: 

  • Un conjunto de controladores para capturar los datos de la interfaz del usuario a través de las peticiones HTTP, y para asegurar su traducción en acciones gestionadas por los servicios de generación. 
  • Un cliente REST que llama a los servicios de generación para generar código a partir de la información capturada en el front-end. 
  • Un conjunto de servicios, una parte de los cuales es proporcionada por la herramienta de generación de conectores BL.MOM que asegura la generación de módulos de interoperabilidad, y la otra parte está relacionada con la gestión de estos conectores, los contextos de interoperabilidad y los temas mantenidos.  
  • Un componente de persistencia de datos que consiste en una instancia de un servidor MonogDB para la gestión y almacenamiento de las diferentes entidades, agrupadas como un conjunto de colecciones de documentos MongoDB.

El Front-end es una aplicación web basada en Angular y compuesta por componentes y servicios independientes, entre ellos  

  • Conjunto de plantillas que combinan los elementos HTML del contenido mostrado en el navegador web. 
  • Un conjunto de componentes de Angular que definen cada uno una clase que contiene toda la lógica de negocio y los datos necesarios para ser mostrados en las plantillas. 
  • Un conjunto de enrutadores que permiten la navegación entre las diferentes páginas de la aplicación web. 
  • Un conjunto de servicios Angular que permite la comunicación entre el front-end y el back-end. 
Generador de conectores BL.MOM - La herramienta

La aplicación web propuesta ofrece las siguientes posibilidades y servicios:  

  • Interfaces de usuario para: crear nuevos contextos de interoperabilidad, examinar los contextos existentes y modificarlos, añadir temas a un contexto de interoperabilidad, examinar la lista de temas y modificarlos, crear un conector, examinar la lista de conectores. La herramienta ofrece, por tanto, un catálogo que se alimenta para enumerar los contextos de intercambio, los conectores y los esquemas de mensajes (temas).  
Figura 2. Catálogo de contextos de interoperabilidad

Figura 2. Catálogo de contextos de interoperabilidad

Figura 3. Creación de un nuevo conector

Figura 3. Creación de un nuevo conector

  •  Un sistema integrado editor para el AsyncAPI con una forma de documentación de los esquemas de los mensajes y el manejo de errores al escribir la especificación. El editor está vinculado con un contenido AsynchAPI parser para recuperar los datos relativos a la descripción de los esquemas de los mensajes. 
Figura 4. Editor de AsyncAPI integrado y documentación del esquema

Figura 4. Editor de AsyncAPI integrado y documentación del esquema

Figura 5. Documentación del esquema de mensajes generado - según la especificación AsyncAPI

Figura 5. Documentación del esquema de mensajes generado - según la especificación AsyncAPI

Tl Editor de especificaciones de AsyncAPI, que acepta formatos JSON o YAML, permite especificar el conjunto de temas (canales) del contexto de interoperabilidad y los esquemas (conjunto de campos y sus propiedades) de los mensajes asociados a los temas. La documentación y las herramientas de verificación que aparecen en la parte derecha del editor se actualizarán en el momento de la entrada y cada vez que el desarrollador introduzca nueva información. En caso de que se introduzcan datos no válidos o que no se ajusten a la estructura/sintaxis de un documento AsyncAPI se mostrará un mensaje de error. 

Una vez realizada la configuración de un contexto de interoperabilidad o de un nuevo conector asociado a un contexto existente, el usuario puede generar el código de sus proyectos asociados (se generan proyectos de creación de esquemas de mensajes, wrapper y autoconfiguración para el contexto de interoperabilidad, y un proyecto esqueleto para cada conector).  

Como ejemplo de código generado mediante la herramienta de generación de conectores BL-MOM, la figura 6 (lado derecho) muestra un fragmento de código de un proyecto de "creador de esquemas" generado para un tema determinado. En cambio, la Figura 6 (lado izquierdo) muestra un ejemplo de código escrito manualmente por un desarrollador para el mismo proyecto. Como puede verse, los dos proyectos son casi idénticos, se detectan muy pocas diferencias. 

Figura 6. Código escrito manualmente en el lado izquierdo Vs código generado en el lado derecho

Figura 6. Código escrito manualmente en el lado izquierdo Vs código generado en el lado derecho

Autores : Nawel Amokrane y Hamza Sahli

Más ...

Ir arriba