Différences avec Spring Board Open NG
Avec le projet Spring Board, Open ENT NG permet de sélectionner les modules à déployer dans son environnement Open ENT.
Par défaut, tous les modules ne sont pas disponibles et leur activation dépend du fichier de configuration ent-core.json
. La configuration et le déploiement des modules s’effectuent de manière déclarative, à la manière des mods Vert.x.
Exemple de fichier ent-core.json
{
"name": "io.vertx~mod-mongo-persistor~3.2.0",
"waitDeploy": true,
"worker": true,
"multi-threaded": true,
"config": {
"address": "wse.mongodb.persistor",
"host": "mongo",
"port": 27017,
"db_name": "entcore",
"use_mongo_types": true,
"pool_size": 10
}
}
Dans Open ENT V2, ce fichier est lu par le système, qui charge les modules sous forme de Fat JARs (JAR contenant toutes les dépendances nécessaires). Les bibliothèques et classes Java incluses dans ces JARs sont ensuite accessibles via un classpath unique. Cela permettait, avec Java 8, de charger dynamiquement les bibliothèques à la volée.
Évolutions avec Open ENT V3
Avec Open ENT V3, chaque module dispose de son propre processus et de sa propre JVM. Cela signifie :
- Fin du partage de bibliothèques communes entre modules.
- Chaque module doit être déclaré explicitement dans les dépendances Maven au moment de la construction du launcher.
- Il est également nécessaire de spécifier les modules Vert.x à charger au démarrage.
Bien que Java 9+ introduise le Dynamic Module System (Jigsaw), permettant une gestion plus flexible des modules, ce mécanisme n’est pas encore pris en charge par le launcher d’Open ENT V3. Cela ajouterait la possibilité de charger des modules de manière dynamique comme dans Open ENT V2.
Vers une architecture microservices
L’objectif principal d’Open ENT V3 est de proposer une architecture microservices, favorisant l’indépendance des processus et des JVM. Par conséquent, il n’est pas prévu pour le moment d’améliorer le launcher afin d’intégrer des fonctionnalités de gestion dynamique des modules.