BL.MOM Connector Generation – Part 2

interoperability illustration
BL-MOM Connector Generator Global Architecture

The global architecture of the proposed solution is shown in Figure 1. It depicts the main components of BL-MOM Connector Generator and their interactions to meet the different generation requirements. Basically, the application is a three-tier architecture composed of: (i) Front-end, a web application allowing an end-user (i.e., typically a developer of interoperability modules) to interact with the various generation services provided by BL-MOM Connector Generator, as well as to access to a catalogue of generated modules persisted in a database. (ii) Back-end is the processing part of BL-MOM Connector Generator comprising the different generation services (mentioned above), the application logic responsible for the implementation of the business logic and representing the functional aspect of the solution, and the database part for data processing and storage. 

In the context of BL.MOM and with the aim to build adaptable exchange systems using interoperability nodes that are partially or completely automatically generated. BL-MOM Connector Generator was proposed. It is a project that helps to manage the complexity of developing BL.MOM interoperability connectors from scratch and favours a better productivity and a gain in terms of time and cost of development of these connectors. 

In a previous article the generation services of BL.MOM Connector Generator were presented, it consists of a set of loosely coupled REST services, each performing specific generation tasks and communicating with each other through their endpoints to generate different types of projects, according to configuration parameters received from end-users within the REST requests. Here is a reminder of the generation services: 

  • The Initializr service is responsible of producing customized Spring projects skeletons by interacting with the Spring Initializr server.  
  • The message schema creator generation service generates projects for creating Java libraries of Apache Avro messages. It also calls for the Concordian generation service to maintain HTML specifications of these messages compatible with their code.
  • The wrapper generation services that generates a message wrapper project for handling message types and different publishing and consuming messages per message type 
  • The auto-configuration generation services that generates a module to support configuration structures and auto-configuration  
  • The connector generation service oversees the generation of parts of message consumer and publisher modules for one or more existing topics. These modules need to be completed to address business context related code, in which we can specify for example what needs to be done after receiving a message.  

The message schema creator, wrapper and auto-configuration projects are generated once for each data exchange context related to a set of business topics, it is what we call the interoperability context. And as many connectors (publishers/consumers) as required can be generated for each new need of data exchange for the same interoperability context. 

To go further and propose a complete tool to capture end-users’ configurations for the generation of these BL.MOM modules, complementary Back-end services and Front-end services have been developed, these are presented in the following.   

Figure 1. Global architecture of BL-MOM

Figure 1. Global architecture of BL-MOM Connector Generator

The Back-end is a Spring-boot application composed of the following components: 

  • A set of controllers to capture data from the user’s interface through HTTP requests, and to ensure their translation into actions managed by the generation services. 
  • A REST client calling the generation services to generate code from the information captured on the front-end. 
  • A set of services, part of which is provided by the BL.MOM connector generation tool that ensures the generation of interoperability modules, and the other part is related to the management of these connectors, interoperability contexts and the maintained topics.  
  • A data persistence component which consists of an instance of a MonogDB server for the management and storage of the different entities, grouped as a set of MongoDB document collections.

The Front-end is an Angular-based web application composed of independent components and services, including:  

  • A set of templates that combine the HTML elements of the content displayed in the web browser. 
  • A set of Angular components that each define a class containing all the business logic and data necessary to be displayed in the templates. 
  • A set of routers that allow the navigation between the different pages of the web application. 
  • A set of Angular services allowing the communication between the front-end and the back-end. 
BL.MOM Connector Generator – The tool

The proposed web application offers the following possibilities and services:  

  • User interfaces for: creating new interoperability contexts, browsing existing contexts and modifying them, adding topics to an interoperability context, browsing the list of topics and modifying them, creating a connector, browsing the list of connectors. The tool thus offers a catalogue to be fed to list the exchange contexts, connectors and message schemas (topics).  
Figure 2. Interoperability contexts catalogue

Figure 2. Interoperability contexts catalogue

Figure 3. Creating a new connector

Figure 3. Creating a new connector

  •  An integrated editor for the AsyncAPI specification with a form of documentation of message schemas and error handling when writing the specification. The editor is linked with an AsynchAPI content parser to retrieve data relating to the description of message schemas. 
Figure 4. Integrated AsyncAPI editor and schema documentation

Figure 4. Integrated AsyncAPI editor and schema documentation

Figure 5. Generated message schema documentation – according to the AsyncAPI specification

Figure 5. Generated message schema documentation – according to the AsyncAPI specification

The AsyncAPI specification Editor, which accepts JSON or YAML formats, allows the specification of the set of topics (channels) of the interoperability context and the schemas (set of fields and their properties) of the messages associated to the topics. The documentation and verification tools displayed in the right side of the editor will be updated at the time of input and each time the developer types in new information. In case of invalid data entry or data that does not match the structure/syntax of an AsyncAPI document an error message will be displayed. 

Once the configuration of an interoperability context or a new connector associated to an existing context is done, the user can generate the code of their associated projects (message schema creator, wrapper and auto-configuration projects are generated for the interoperability context, and a skeleton project is generated for each connector).  

As an example of a generated code using the BL-MOM Connector Generation tool, Figure 6 (right side) shows a piece of code of a “schema creator” project generated for a given topic. In contrast, Figure 6 (left side) shows an example of code written manually by a developer for the same project. As it can be seen, the two projects are almost identical, very few differences can be detected. 

Figure 6. Manually written code on the left side Vs generated code on the right side

Figure 6. Manually written code on the left side Vs generated code on the right side

Authors : Nawel Amokrane & Hamza Sahli

More ...

Scroll to Top