L’un des objectifs des travaux R&D menés sur la solution BlueMind consiste à concevoir une architecture moderne capable de satisfaire toutes les typologies de clients (chantiers d’architecture et d’infrastructure). Il s’agit en particulier de :
- concevoir une architecture évolutive, à même de répondre à des organisations de quelques dizaines à plusieurs centaines de milliers d’utilisateurs,
- assurer des performances optimales en permettant des évolutions d’architecture pour garantir une utilisation performante tout en maîtrisant les consommations de ressource,
- proposer des points d’extension permettant l’enrichissement de la solution BlueMind par des plugins sans nécessiter des développements complexes,
- Exposer l’ensemble des fonctionnalités de BlueMind sous la forme d’une API afin que toutes les actions des applications BlueMind passent par des API.
Cet article présente l’architecture du composant Core de BlueMind et donne une vision globale des API disponibles (lire la documentation BlueMind consacrée aux API et dans l’espace BlueMind Docs).
Description de l’architecture du Core v2
Core, dans sa génération 2, est un programme en Java. Core v2 expose des services web représentant l’API BlueMind. Il exécute des taches planifiées (sauvegarde, re-indexations, synchronisations annuaires, reporting).
Seul ce composant manipule les données des bases PostgreSQL, tous les autres passent par lui pour lire et modifier des informations. Il reçoit des requêtes http sur le port 8090 et fournit des réponses en format json.
Les différentes méthodes http sont utilisées pour indiquer le type d’opérations :
- GET pour une récupération de données,
- POST pour une mise à jour,
- PUT pour une création,
- DELETE pour une suppression.
Ce type de service web est communément appelé RESTfull.
Technologies utilisées
Plusieurs technologies caractérisent le Core :
- Vert.x
License : open source, Apache software license 2.0
Site internet : http://vertx.io
Framework applicatif de type « Réacteur », il transforme les requêtes réseau reçues en événements sur lesquels on va pouvoir s’abonner pour réagir.
Basé sur la bibliothèque réseau netty, il met en avant l’utilisation d’I/O non bloquants pour améliorer la scalabilité et maximiser l’efficacité sur les cpus multicœurs. Avec ce type d’architecture, Un grand nombre de connexions réseaux est supporté par seulement quelques threads (généralement 2x nombre de cœurs du serveur).
Un bus de messages distribué permet la communication entre différents composants applicatifs permettant le découpage des rôles au sein de l’application. Les composants applicatifs vont déclarer des adresses sur le bus auxquels ils savent répondre. Le bus étant de nature distribué, la réponse à un message peut venir d’une autre instance de vert.x sur un autre serveur. Ceci permet à la fois haute disponibilité et répartition de charge en allumant plusieurs core sur le réseau.
Un autre aspect de vert.x utilisé par BlueMind est que le bus d’événements peut être étendu jusqu’au navigateur internet de l’utilisateur. Le code javascript dans le navigateur établit une connexion websocket avec core. Le code javascript peut s’abonner à des adresses du bus pour recevoir les messages postés à ces adresses. C’est alors le serveur qui peut initier le dialogue. Cette capacité est par exemple utilisée pour notifier les navigateurs des utilisateurs instantanément lorsqu’un nouvel e-mail vient d’arriver et éviter des vérifications périodiques coûteuses.
- Jackson
xLicense : Apache License 2.0
Site internet : https://github.com/FasterXML/jackson
Les modules core, databind et annotations sont utilisés pour transformer automatiquement nos objets Java en json, et inversement.
Les annotations présentes sur nos interfaces et objets permettent de ne pas implémenter de client méthode par méthode : tout est géré automatiquement à la volée à l’aide d’objets java.lang.reflect.Proxy (voir HttpClientFactory). Les interfaces sont disponibles en version synchrone et asynchrone.
- OSGi / Eclipse Runtime
License : open source, eclipse
Les technologies de l’IDE eclipse sont utilisées pour l’injection de dépendances et la création de plugins. Les composants déclarent des points d’extensions à l’aide d’un schéma (fichiers .exsd) référencé depuis un fichier plugin.xml. Les composants se branchent et implémentent une extension à l’aide d’un fichier plugin.xml. Un même composant peut à la fois déclarer des points d’extensions et devenir extensible, tout en étendant lui même d’autres points d’extension
Containers, Items
Pour comprendre certaines API core, il faut expliquer la notion de Containers et Items.
Core est articulé autour d’un ensemble de containers qui disposent d’un uid (unique identifier) et d’un type. Ces containers contiennent des items. Les items disposent aussi d’un uid, unique, à l’intérieur de leur container.
Exemples
Container :
Uid : abcd-1234-5678-afef Type : installation
Ce container de type installation dont l’identifiant unique est généré à l’installation de BlueMind va contenir des items de type serveur.
Container :
Uid : bluemind.net Type : domain
Un container de ce type est créé lorsqu’un domaine est ajouté à un BlueMind.
Container :
Uid : users_bluemind.net Type : users
Un container de ce type est créé lorsqu’un domaine est créé et va contenir les utilisateurs du domaine bluemind.net.
Container :
Uid : addressbook_bluemind.net Type : addressbook
Va contenir des items de type VCard qui représentent les informations de contact des utilisateurs et des groupes.
Fonctionnalités génériques
L’utilisation de ces containers génériques permet d’avoir des fonctionnalités transverses réutilisables, les 3 principales étant :
- la gestion des droits et ACLs que l’on va positionner sur les containers
- le maintien automatique d’un historique de changement, d’un numéro de version sur le container et d’une version sur l’item
- la gestion des abonnements (je m’abonne au « container calendrier_richard » pour qu’il soit toujours visible dans mon interface)
Les items génériques vont porter les valeurs que l’on aurait généralement sur tous les objets :
- Date de dernière modification, Date de création
- Uid de l’utilisateur utilisé pour la dernière modification, Uid lors de la création
- Version
- Identifiant externe (particulièrement utile dans le cadre de migration pour sauvegarder l’identifiant de l’objet dans la source et savoir qu’il s’agit d’un objet importé)
Synchronisation au niveau des containers
La majorité des API BlueMind s’utilise en précisant le container sur lequel on souhaite agir. Lorsqu’un container est créé, une séquence base de données est créée pour maintenir des numéros de version au sein du container.
Une table de ChangeLog est peuplée automatiquement à chaque fois qu’un item est créé, mis à jour ou supprimé.
Cela va permettre des mécanismes génériques de synchronisation particulièrement efficaces puisque la communication avec le serveur va se limiter à des échanges de numéros de version, type de modification. En fonction du nombre de version d’écart entre le client et le serveur, le client va pouvoir ensuite demander les changements et les données (par tranches ou en une fois suivant la quantité de données).
Le code de synchronisation est donc implémenté une fois et n’est pas répété : le mécanisme sera strictement identique pour des événements, des contacts, ou quel que soit le type de données pour lequel on souhaite suivre les changements.
Il est situé dans ContainerStoreService, via les méthodes changelog() et changeset().
SecurityContext et gestion des droits
Lors de l’authentification, un SecurityContext est créé et un identifiant de session est alloué. Cet objet enregistre l’identifiant de session, l’uid de l’utilisateur ainsi que les groupes dont il est membre.
L’identifiant de session est retransmis dans les demandes aux APIs via un Header X-Bm-Apikey.
Et la suite ?
Cette refonte d’architecture complète a occupé l’équipe R&D pendant de nombreux mois, ce qui expliquait le long délai de réalisation de notre version 3.5. Mais, grâce à ces travaux, cette architecture robuste et évolutive nous permet de répondre à 3 enjeux majeurs :
- une élasticité des infrastructures autorisant des montées en charge vers des dizaines, puis des centaines de milliers d’utilisateurs
- la capacité à répartir les charges et à redonder nos services
- la capacité à remplacer la base de données relationnelles par des bases noSQL et des structures fichiers plus adaptées aux solutions Cloud.
Pour aller plus loin, retrouvez ici notre article sur l’intégration continue chez BlueMind. Vous pouvez également visionner la conférence de notre responsable qualité Dominique Eav sur l’usine de production de BlueMind.
Et pour finir, nous vous invitons à nous rejoindre au Libday à l’occasion du DevOps D-day à Marseille le 14 novembre 2019 pour une conférence : « DevOps et agilité : plongée dans l’usine de production BlueMind ».
