La generación de código se ha convertido gradualmente en un aspecto destacado del desarrollo de software actual. El proceso de escritura de software requiere que los desarrolladores reescriban con frecuencia un código similar de forma repetida. Esta práctica puede llevar mucho tiempo y ser tediosa. Los desarrolladores tratan de escribir ocasionalmente una abstracción para mantener sus aplicaciones DRY (no repetirse), sin embargo, escribir una abstracción no siempre es óptimo, puede hacer que el código producido sea menos claro y más difícil de trabajar. Aquí es donde la generación de código es útil, puede presentar un medio eficaz para gestionar el tedioso trabajo de reescribir código repetitivo y repetitivo. Actualmente, en Berger-Levrault (BL), el desarrollo de módulos/conectores para la publicación y el consumo de datos, garantizando la interoperabilidad de los sistemas internos y externos, se realiza manualmente. Además, la reparación de los fallos de funcionamiento se realiza de forma sobre una base ad hoc. Además de los costes de desarrollo y corrección que conlleva, esto no satisface los requisitos de reactividad de determinados ámbitos empresariales. De ahí la necesidad de construir sistemas de intercambio adaptables mediante nodos de interoperabilidad generados parcial o totalmente de forma automática. De este modo, se ayuda a gestionar la complejidad de desarrollar dichos conectores de interoperabilidad desde cero y a reducir el tiempo de reescribir manualmente su código.

Interoperabilidad y BL.MOM

El concepto de interoperabilidad se ha convertido en un criterio esencial que deben cumplir los sistemas de información. Cuando los sistemas de información se ponen en producción, forman parte de una red de múltiples sistemas. Si estos sistemas pueden compartir e intercambiar información sin depender de la intervención de un actor concreto, podemos calificarlos de sistemas interoperables. Una vez que se establece la interoperabilidad entre los sistemas de información que se comunican, se garantiza un aumento de la productividad y la eficacia de los procesos intra e interempresariales. La falta de interoperabilidad entre las aplicaciones y sus subsistemas es un problema crítico que puede afectar a la calidad global del servicio.
La interoperabilidad de los datos se realiza a través de sistemas de transporte e intercambio de datos, estos últimos deben ser fiables y seguros para garantizar un alto nivel de interoperabilidad. En el contexto de la interoperabilidad de datos, BL MOM (Message Oriented Middleware) es una API desarrollada por Berger Levrault como uno de los medios para establecer intercambios de datos entre las aplicaciones comunicantes de BL y con las externas. BL MOM es una API basada en la mensajería, lo que significa que los datos se transmiten en forma de mensajes. El envío y la recepción de mensajes se gestionan estableciendo un patrón de comunicación de publicación/suscripción que permite que las aplicaciones estén débilmente acopladas. BL MOM lo hace mediante el uso de Protocolo AMQP con el apoyo de RabbitMQ que implementa los conceptos de este protocolo. Para más información sobre RabbitMQ y su proceso global, se remite al lector a [1] y [2].

Generación de código: soluciones y técnicas

Los generadores de código son programas que pueden producir el código fuente de otra pieza de software, ayudando a los desarrolladores a resolver problemas de código repetitivos que no pueden ser resueltos escribiendo abstracciones. Estas herramientas pueden ser beneficiosas para aumentar la calidad y la productividad del código, facilitar el mantenimiento y acortar el tiempo de desarrollo del software. Además, es muy probable que el código generado contenga menos errores y pueda adaptarse fácilmente para mantener la evolución del software generado. El uso de técnicas de configuración y generación automáticas/semiautomáticas para producir creadores de esquemas de mensajes y módulos de conectores que garanticen la interoperabilidad en el contexto de Berger-Levrault promovería la reutilización del código existente y la posibilidad de generar módulos de interoperabilidad sobre la marcha. A su vez, este proceso de generación debería contribuir a reducir el tiempo y el esfuerzo necesarios para desarrollar nuevos conectores desde cero cada vez que surja la necesidad. Esto promoverá posteriormente el principio de vinculación automática de los emisores y receptores de los datos intercambiados, bajo el control de una autoridad de confianza.
A lo largo de los años, se han propuesto muchas herramientas y métodos de generación de código. La generación de código basada en plantillas (TBCG) de la ingeniería dirigida por modelos (MDE) es, sin duda, una de las técnicas más populares de Model-to-Text. Las herramientas basadas en TBCG pueden clasificarse en dos grupos principales: herramientas basadas en el modelo y herramientas basadas en el código. Por un lado, las herramientas basadas en el modelo permiten generar el código boilerplate de una aplicación a partir de un metamodelo abstracto definido normalmente como diagramas UML. Se han propuesto diferentes herramientas basadas en modelos, como Acceleo, Xpand, Xtend 2y EGL. Por otro lado, las herramientas basadas en código toman un modelo/plantilla textual como entrada para producir código en un lenguaje elegido como salida. Como ejemplo de este tipo de herramientas: JET, Velocidad de Apachey FreeMarker. Las herramientas basadas en modelos son las más capaces de realizar manipulaciones complejas de los datos de entrada, proporcionando un soporte adecuado para los modelos no triviales. Mientras que las herramientas basadas en código han demostrado superar a estas últimas en muchos estudios, especialmente cuando se trata de manejar modelos más grandes. Este tipo de herramientas son muy utilizadas para la generación de código boilerplate, sin embargo, existen otras diseñadas para realizar la transformación y la generación de código adoptando diversas técnicas de Model-to-Text o Text-to-Text. Algunas de estas herramientas son analizadores de código que se adaptan mejor a las generaciones de código intuitivas, directas y más específicas, como ANTLR, Tostadory JavaParser.

Herramientas de ingeniería inversa como MoDisco puede ser beneficioso en el contexto de la generación de código. La idea MoDisco que consiste en la extracción de modelos de los sistemas heredados existentes puede ser útil para manejar sus complejidades. Así, proporciona un soporte útil para razonar, reutilizar y evolucionar los sistemas.

Generador de conectores BL MOM

BL MOM connector generator es el nombre de nuestra propuesta para la generación automática de conectores de interoperabilidad completos/parciales para ser utilizados por nuestras aplicaciones. El generador puede producir en base a parámetros de configuración: módulos de publicación/consumo de mensajes, creadores de esquemas de mensajes, envoltorios de mensajes y módulos de autoconfiguración. El objetivo principal es aliviar la complejidad de escribir el código de los nuevos conectores y creadores de esquemas desde cero y reducir su tiempo de desarrollo global. Más concretamente, nuestra herramienta puede generar el contexto de interoperabilidad una vez para varios consumidores y editores, que consiste en:

• Un proyecto de autoconfiguración para apoyar las estructuras de configuración y la autoconfiguración;
• A proyecto de envoltura de mensajes para el manejo de los tipos de mensajes;
• A proyecto de definición del esquema de mensajes encapsulando las bibliotecas de esquemas de mensajes y la especificación (cuando Avro se utiliza) y todos los elementos que son comunes a todos los conectores del mismo intercambio de datos (contexto empresarial). Además, genera esqueletos de los proyectos de consumidores y editores para que los desarrolladores los enriquezcan.

Los módulos de interoperabilidad en BL se desarrollan más a menudo como Aplicaciones Spring BootPor ello, hemos optado por emplear ciertas APIs/herramientas de Java que permitan generar esqueletos personalizados de módulos de interoperabilidad, y proyectos completos de creadores de esquemas de mensajes, envoltorios de mensajes y autoconfiguración. En particular, entre otras bibliotecas, utilizamos (i) Inicialización de la primavera para generar esqueletos de proyectos Java, (ii) Tostador de Java para la generación de códigos de clase, y (iii) Velocidad de Apache para la generación de POMs de proyectos, archivos Html de especificación y otros archivos. En combinación, estas herramientas se utilizan para generar Aplicaciones Spring Boot, adaptadas para cumplir los objetivos iniciales de interoperabilidad. La elección de las herramientas se realizó tras evaluar diferentes herramientas basadas en modelos para la generación de código, así como algunas herramientas basadas en código y de ingeniería inversa. Llegamos a la conclusión de que este tipo de herramientas no se adapta a nuestras necesidades particulares, que consisten en la generación de código repetitivo dentro de nuestros módulos de interoperabilidad. De hecho, creemos que una solución basada en herramientas como Xtend2, Modisco, JHipsteretc., carecerían de la flexibilidad deseada, que es crucial para nuestras perspectivas. La solución óptima sería fácilmente adaptable para satisfacer diferentes requisitos antiguos y nuevos y permitiría considerar casos de uso avanzados en el futuro, como la adaptación de conectores existentes, esquemas de mensajes, etc.
El primer paso, antes de proceder a la generación de código, es analizar el código existente de los módulos conectores y de los proyectos de definición de esquemas de mensajes, para diferenciar los elementos redundantes y los variables en el código. Estos últimos pueden representar los datos de entrada para el sistema de generación que deben ser considerados para personalizar cada proyecto generado a un contexto empresarial determinado. Para ello, nos basamos en una formalización a un metanivel que describe la representación y las relaciones existentes entre los elementos variables que permiten la configuración de un conector y un módulo de definición de esquema de mensajes. 

Cada módulo conector tiene un conjunto de propiedades predefinidas relacionadas con el módulo java que se va a generar, con las propiedades requeridas como entrada por BL-MOM como el módulo, tenantId, o con las credenciales de conexión al RabbitMQ servidor. También es posible tener propiedades de configuración específicas del proyecto. Cada módulo conector se vincula mediante la publicación o suscripción a uno o varios Temas, cada uno de los cuales puede transmitir un conjunto de eventos empresariales. Los módulos de definición del esquema de mensajes permiten crear bibliotecas Java de Apache Avro mensajes, y mantener la documentación compatible con el código. En este caso, el código completo de este tipo de proyectos puede generarse automáticamente a partir de una definición de los esquemas de mensajes que se incluirán en el proyecto. Un esquema de mensajes se caracteriza por un Tema de interés, un conjunto de subesquemas y la definición de los campos que componen cada esquema: el nombre, el tamaño máximo, si es opcional o no y su tipo. Este último puede ser a su vez un subesquema.
Para generar inicialmente un esqueleto para los distintos tipos de proyectos de módulos de interoperabilidad, se debe crear una instancia de Inicialización de la primavera se utiliza el servidor. Para interactuar con este servidor, utilizamos la función Inicialización de la primavera API REST para poder proporcionar los parámetros de configuración del proyecto que deseamos generar. La principal ventaja de utilizar nuestro propio despliegue Inicialización de la primavera es que podríamos personalizar los esqueletos generados según nuestras necesidades específicas. Por ejemplo, estableciendo una versión específica de Java, o añadiendo nuestras propias dependencias que no se incluirían en la versión pública Inicialización de la primavera.

La arquitectura del generador de conectores BL MOM consiste en un conjunto de REST servicios, cada uno de los cuales realiza tareas de generación específicas y se comunican entre sí a través de sus puntos finales para generar diferentes tipos de proyectos, según los parámetros de configuración recibidos de los usuarios finales en términos de mensajes JSON:

• El Servicio de inicialización es responsable de producir esqueletos de proyectos Spring personalizados interactuando con el Inicialización de la primavera servidor.
• El servicio de generación de creadores de esquemas genera proyectos para crear bibliotecas Java de Apache Avro mensajes. También pide que el servicio de generación de Concordian mantenga las especificaciones Html de estos mensajes compatibles con su código.
• El servicio de generación de conectores supervisa la generación de partes de los módulos de producción y consumo de mensajes de 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.
• Por último, los servicios de generación de envoltorios de mensajes y de autoconfiguración generan los módulos que corresponden a sus respectivos nombres.

El generador de conectores BL MOM permite crear automáticamente no sólo proyectos de definición de esquemas de mensajes, envoltorios de mensajes y proyectos de autoconfiguración, sino también tantos editores y consumidores como sean necesarios para un mismo contexto de intercambio de datos. En otras palabras, se genera un wrapper una vez para cada contexto de interoperabilidad, y se crean tantos conectores como sean necesarios para cada nueva necesidad.