Génération de connecteurs BL.MOM - Partie 2

illustration de l'interopérabilité
Architecture globale du générateur de connecteurs BL-MOM

L'architecture globale de la solution proposée est présentée dans la figure 1. Elle décrit les principaux composants du générateur de connecteurs BL-MOM et leurs interactions pour répondre aux différentes exigences de la génération. Fondamentalement, l'application est une architecture à trois niveaux composée de : (i) Front-endBL-MOM Connector Generator est une application web permettant à un utilisateur final (c'est-à-dire, typiquement, un développeur de modules d'interopérabilité) d'interagir avec les différents services de génération fournis par BL-MOM Connector Generator, ainsi que d'accéder à un catalogue de modules générés conservé dans une base de données. (ii) Back-end est la partie traitement de BL-MOM Connector Generator comprenant les différents services de génération (mentionnés ci-dessus), la logique applicative responsable de la mise en œuvre de la logique métier et représentant l'aspect fonctionnel de la solution, et la partie base de données pour le traitement et le stockage des données. 

Dans le contexte de BL.MOM et dans le but de construire des systèmes d'échange adaptables utilisant des nœuds d'interopérabilité partiellement ou totalement générés automatiquement. BL-MOM Connector Generator a été proposé. Il s'agit d'un projet qui aide à gérer la complexité du développement de connecteurs d'interopérabilité BL.MOM à partir de zéro et favorise une meilleure productivité et un gain en termes de temps et de coût de développement de ces connecteurs. 

Dans un précédent article Les services de génération de BL.MOM Connector Generator ont été présentés. Il s'agit d'un ensemble de services REST faiblement couplés, chacun effectuant des tâches de génération spécifiques et communiquant entre eux par le biais de leurs points de terminaison pour générer différents types de projets, en fonction des paramètres de configuration reçus des utilisateurs finaux dans les requêtes REST. Voici un rappel des services de génération : 

  • Le service Initializr est chargé de produire des squelettes de projets Spring personnalisés en interagissant avec le serveur Spring Initializr.  
  • Le service de génération de schémas de messages génère des projets pour créer des bibliothèques Java de messages Apache Avro. Il fait également appel au service de génération Concordian pour maintenir les spécifications HTML de ces messages compatibles avec leur code.
  • Les services de génération de wrapper qui génèrent un projet de wrapper de message pour traiter les types de messages et les différents messages de publication et de consommation par type de message. 
  • Les services de génération d'autoconfiguration qui génèrent un module pour prendre en charge les structures de configuration et l'autoconfiguration.  
  • Le service de génération de connecteurs supervise la génération de parties de modules consommateurs et éditeurs de messages pour un ou plusieurs sujets existants. Ces modules doivent être complétés pour traiter le code lié au contexte commercial, dans lequel nous pouvons spécifier par exemple ce qui doit être fait après la réception d'un message.  

Les projets de création de schémas de messages, de wrapper et d'auto-configuration sont générés une fois pour chaque contexte d'échange de données lié à un ensemble de sujets métier, c'est ce que nous appelons le contexte d'interopérabilité. Et autant de connecteurs (éditeurs/consommateurs) que nécessaire peuvent être générés pour chaque nouveau besoin d'échange de données pour le même contexte d'interopérabilité. 

Pour aller plus loin et proposer un outil complet de capture des configurations des utilisateurs finaux pour la génération de ces modules BL.MOM, des services complémentaires Back-end et Front-end ont été développés, ils sont présentés ci-après.   

Figure 1. Architecture globale de BL-MOM

Figure 1. Architecture globale du générateur de connecteurs BL-MOM

Le Back-end est une application Spring-boot composée des composants suivants : 

  • Un ensemble de contrôleurs permettant de capturer les données de l'interface utilisateur par le biais de requêtes HTTP, et d'assurer leur traduction en actions gérées par les services de génération. 
  • Un client REST appelant les services de génération pour générer du code à partir des informations capturées sur le front-end. 
  • Un ensemble de services, dont une partie est fournie par l'outil de génération de connecteurs BL.MOM qui assure la génération de modules d'interopérabilité, et l'autre partie est liée à la gestion de ces connecteurs, des contextes d'interopérabilité et des sujets maintenus.  
  • Un composant de persistance des données qui consiste en une instance d'un serveur MonogDB pour la gestion et le stockage des différentes entités, regroupées en un ensemble de collections de documents MongoDB.

Le front-end est une application web basée sur Angular, composée de composants et de services indépendants, notamment :  

  • Un ensemble de modèles qui combinent les éléments HTML du contenu affiché dans le navigateur web. 
  • Un ensemble de composants Angular qui définissent chacun une classe contenant toute la logique commerciale et les données nécessaires à l'affichage dans les modèles. 
  • Un ensemble de routeurs qui permettent la navigation entre les différentes pages de l'application web. 
  • Un ensemble de services Angular permettant la communication entre le front-end et le back-end. 
Générateur de connecteurs BL.MOM - L'outil

L'application web proposée offre les possibilités et services suivants :  

  • Des interfaces utilisateurs pour : créer de nouveaux contextes d'interopérabilité, parcourir les contextes existants et les modifier, ajouter des sujets à un contexte d'interopérabilité, parcourir la liste des sujets et les modifier, créer un connecteur, parcourir la liste des connecteurs. L'outil propose ainsi un catalogue à alimenter pour répertorier les contextes d'échange, les connecteurs et les schémas de messages (topics).  
Figure 2. Catalogue des contextes d'interopérabilité

Figure 2. Catalogue des contextes d'interopérabilité

Figure 3. Création d'un nouveau connecteur

Figure 3. Création d'un nouveau connecteur

  •  Une approche intégrée éditeur pour le AsyncAPI avec une forme de documentation des schémas de messages et du traitement des erreurs lors de la rédaction de la spécification. L'éditeur est lié à un contenu AsynchAPI analyseur syntaxique pour récupérer les données relatives à la description des schémas de messages. 
Figure 4. Éditeur AsyncAPI et documentation des schémas intégrés

Figure 4. Éditeur AsyncAPI et documentation des schémas intégrés

Figure 5. Documentation du schéma de message généré - selon la spécification AsyncAPI

Figure 5. Documentation du schéma de message généré - selon la spécification AsyncAPI

TL'éditeur de spécifications AsyncAPI, qui accepte les formats JSON ou YAML, permet de spécifier l'ensemble des sujets (canaux) du contexte d'interopérabilité et les schémas (ensemble de champs et leurs propriétés) des messages associés aux sujets. Les outils de documentation et de vérification affichés dans la partie droite de l'éditeur seront mis à jour au moment de la saisie et chaque fois que le développeur saisira de nouvelles informations. En cas de saisie de données invalides ou de données qui ne correspondent pas à la structure/syntaxe d'un document AsyncAPI, un message d'erreur sera affiché. 

Une fois la configuration d'un contexte d'interopérabilité ou d'un nouveau connecteur associé à un contexte existant effectuée, l'utilisateur peut générer le code de ses projets associés (les projets de création de schéma de messages, de wrapper et d'auto-configuration sont générés pour le contexte d'interopérabilité, et un projet squelette est généré pour chaque connecteur).  

Comme exemple de code généré à l'aide de l'outil de génération de connecteurs BL-MOM, la figure 6 (côté droit) montre un morceau de code d'un projet de "créateur de schémas" généré pour un sujet donné. En revanche, la figure 6 (côté gauche) montre un exemple de code écrit manuellement par un développeur pour le même projet. Comme on peut le voir, les deux projets sont presque identiques, très peu de différences peuvent être détectées. 

Figure 6. Code écrit manuellement sur le côté gauche Vs code généré sur le côté droit

Figure 6. Code écrit manuellement sur le côté gauche Vs code généré sur le côté droit

Auteurs : Nawel Amokrane & Hamza Sahli

Plus ...

Retour haut de page