Présentation de l'architecture logicielle OpenSILEX 

Cette page présente l’architecture technique de la suite logicielle OpenSILEX. Si vous souhaitez contribuer au code de OpenSILEX, ou bien développer un nouveau module, prendre connaissance de cette page est recommandé.

Si vous souhaitez avoir plus de détails sur les aspects techniques, vous pouvez consulter la documentation technique OpenSILEX.

Vous trouverez un guide pour déployer et installer votre propre instance.

Architecture en couche

La suite OpenSILEX est basée sur plusieurs couches logicielles, représentée par la figure ci-dessous et décrite dans la suite de la page.

Architecture technique

La suite logicielle OpenSILEX est une application Web qu’on peut décomposer en trois couches principales :

• Front-end, ou interface Web avec laquelle la plupart des utilisateurs interagissent ; 

• Back-end ou API ou Web Services, constitué d’un serveur exposant des services REST/JSON ;

• Intégration ou SilexExplorer, constitué d’un serveur GraphQL basé sur un modèle commun NoSQL et RDF/OWL, c’est en partie sur cette couche qu’est basé l'interopérabilité de OpenSILEX  ;

• Stockage de données, réparties en trois types de stockage : un triple store (RDF4J), une base NoSQL (MongoDB) et un système de fichier (local ou distribué sur des grilles de stockage).                

Front-end

L’interface Web est construite avec Vue.js. Elle interroge le back-end via des services générés par Swagger. Les principales dépendances et librairies sont les suivantes : vue-cli 4.5.15, Typescript 4.0.5, Sass 1.28.0, Bootstrap 4.6, Highcharts 9.0.1, etc. 

La dernière version d'OpenSILEX (1.5.0) utilise Vue.js en version 2. 

Une migration vers la version actuelle de Vue, la version 3, est en cours et devrait arriver pour la prochaine version de OpenSILEX, second semestre 2026. Certaines de nos dépendances vont également monter de version comme Vite 6.3.5, Typescript 5.8.3, Sass 1.89.0, Bootstrap 5.3.6, Naive UI 2.41.0, Highcharts 12.2.0, etc.

Back-end

Le back-end, écrit en Java, se présente sous la forme d’un serveur Jersey, basé sur la spécification JAX-RS, avec une architecture en deux couches (API et DAL).

La couche API (Application Programming Interface) expose à l’extérieur des services REST permettant d’effectuer des opérations CRUD (Create, Read, Update, and Delete) sur les ressources gérées par OpenSILEX. Sur le schéma, on peut voir les classes API qui regroupent les services et les classes DTO (Data Transfer Object) qui représentent les modèles échangés avec l’extérieur, sous format JSON.

La couche DAL (Data Access Layer) permet notamment d’accéder aux deux sources de persistance principales :

• À MongoDB via les connecteurs Java fournis par MongoDB.
• Au triple store via la librairie Apache Jena et une surcouche spécifique pour faire l’interface entre des classes Java et des requêtes SPARQL, suivant les patterns d’un ORM (Object-Relational Mapping). Les classes DAO (Data Access Object) permettent de fournir les différents services de persistance, et les classes Model représentent les schémas de ressource ainsi que les manières de les stocker (clés MongoDB, propriétés RDF, etc.).                            

Interopérabilité

La couche API permet d’exposer des services implémentant des standards majeurs pour les communautés comme ceux de la Breeding API (échange de données du végétal) permettant par exemple l’indexation des données par le portail FAIDARE. Plusieurs outils (Adonis, Geofolia, etc.), scripts, packages, etc. permettent d’intégrer, acquérir, explorer, afficher, analyser les données de OpenSILEX.

Intégration avec SilexExplorer

Un serveur GraphQL permet de faire une passerelle entre les deux sources : NoSQL et RDF de OpenSILEX. Il unifie ainsi l’accès aux différentes sources et intègre automatiquement les données, permettant de les rendre directement exploitables pour l’analyse scientifique. SilexExplorer et des packages R et Python associés sont disponibles.

Stockage

Les données gérées par OpenSILEX sont réparties en trois types de stockage :

• Un triple store (RDF4J) utilisé pour gérer les métadonnées au format RDF stockées suivant les schémas RDFS/OWL des ontologies OESO, OA, DublinCore, etc.

• Une base NoSQL (MongoDB), utilisée pour stocker les données et leur provenance (volumineuses), l'information géospatiale, les documents (protocoles, mode d’emploi, etc.), ces données ayant besoin d’un outil permettant de gérer le volume et  le schéma peut varier.

• Un système de fichiers, pour stocker des données brutes (images, spectres, etc.). Le système de stockage est défini sur le serveur en local ou sur des infrastructures de stockage distribué basées sur iRODS ou S3. Les connexions sont modulables on pourra implémenter à l’avenir d’autres systèmes de stockage.                                            

Ces modes de stockage sont interconnectés par une identification des ressources universelle via des URI. Ainsi, une donnée présente dans MongoDB peut faire référence à une métadonnée représentée dans le triple store. C’est le back-end qui se charge de faire le lien entre les différentes sources.

Déploiement et infrastructure

Les instances ou systèmes d’information basés sur OpenSILEX sont hébergés sur des  serveurs ou machines virtuelles dont les requirements d'utilisation et d’installation sont décrites dans la documentation d’installation en développement et en production. 

Le déploiement dépend des infrastructures utilisées par les partenaires ou projets. Actuellement nous nous appuyons sur le Cloud Orion INRAE pour les instances INRAE ou sur des grilles de calculs et stockage distribuées : EGI, France Grilles, Meso@LR avec les technologies iRODS ou S3 pour la gestion des fichiers, etc.

Une version conteneurisée de OpenSILEX, construite avec Docker Compose, permet de déployer OpenSILEX partout où docker est supporté. Elle est disponible sur le dépôt public opensilex-docker-compose avec la documentation installation.

Zoom sur la modularité de la suite logicielle

OpenSILEX est un projet Maven structuré en modules. L’application est pensée pour être extensible en fonctionnalités via de nouveaux modules.

Schéma de dépendances entre les principaux modules Maven

Les modules principaux ont chacun des rôles précis :

Chaque module apporte une partie du code servant au front-end et/ou des interfaces Web ainsi que des ontologies propres au module. Chaque module permet de définir : 

• de nouveaux Web services pour l’API,
• de nouveaux concepts spécifiques ou ontologies et leurs méthodes de manipulation,
• de nouvelles interfaces avec des systèmes tiers d’acquisition ou de stockage de données,
• de nouvelles librairies Java,
• de nouveaux paramètres de configuration,
• de nouveaux composants et pages pour l’application Web Vue.js.                              

Pour plus de détails sur le fonctionnement des modules, reportez-vous à la documentation technique de OpenSILEX.

Les modules ont des relations de dépendance entre eux, comme on peut le voir sur le schéma ci-dessus. Actuellement, plusieurs modules spécifiques sont disponibles comme ceux de gestion de procédés ou d’intégration de traitement d’analyse.

Tests

Des tests d’intégration sont automatiquement exécutés pendant le workflow de développement afin d’assurer la qualité du code. Ces tests garantissent le fonctionnement des appels API au back-end. Ils s’exécutent grâce à GitLab CI. Des tests fonctionnels sont faits par l’équipe à chaque livraison.

Code sources

Le code source est hébergé sur la forge INRAE (https://forge.inrae.fr/OpenSILEX) basée sur GitLab. Ce  dépôt est privé, pour les membres de l’équipe et partenaires INRAE. La forge est utilisée pour la gestion des versions des codes sources de OpenSILEX, la gestion de nos processus d'intégration continue : CI/CD (Continuous Integration/Continuous Delivery) de GitLab pour contrôler la qualité des codes et le déploiement des systèmes que nous gérons complètement.

Les projets GitLab principaux sont répliqués sur des dépôts publics GitHub OpenSILEX, pour plus de visibilité par le grand public.

La gestion des versions est faite en suivant les préconisations du schéma Semantic Versioning.

Les codes sources sont Licence GNU AGPLv3 et Creative Commons pour les documentations.

Pour contribuer vous pouvez consulter la page Contribution et doc technique

Contact : 

Pour toute demande de démonstration ou si vous souhaitez bien démarrer avec OpenSILEX - que ce soit pour l’utiliser, l’installer, ajouter de nouvelles fonctionnalités, contribuer au projet ou signaler un bug - n’hésitez pas à nous contacter à l’adresse suivante : opensilex@inrae.fr