La bibliothèque logicielle Ingescape permet de mettre en place des systèmes d’information industriels et opérationnels autour de logiciels hétérogènes provenant de n’importe quel langage de programmation et de n’importe quel système d’exploitation. Ces logiciels utilisant Ingescape sont appelés des agents et sont modélisés selon un formalisme simple mais complet pour proposer des services très ciblés à très évolués, sans contrainte technologique.
Ingescape est donc adapté à la création de nouveaux systèmes d’information mais aussi à l’adaptation et à la migration totale ou partielle de plateformes logicielles existantes. La faible empreinte, la simplicité et la structure autonome d’Ingescape rendent « l’agentification » de logiciels existants généralement simple et rapide, en quelques heures à quelques jours tout au plus. Dans la pratique, Ingescape n’impose aucune contrainte sur l’architecture logicielle ou les techniques de développement.
Un agent modélisé avec Ingescape propose des entrées et sorties nommées et typées (impulsions, booléens, entiers, nombres flottants, chaînes de caractères ou données binaires) pouvant être reliées à d’autres agents pour constituer des flux d’information appelés mapping. En complément, chaque agent peut exposer des services sous forme de fonctions nommées, appelées services, accompagnées de paramètres eux-aussi nommés et typés.
L’illustration qui suit résume les notions clés d’un modèle d’agent, les schémas de communication, les types de données et les événements que les agents savent détecter entre eux.
Sur un même ordinateur ou sur des ordinateurs connectés en réseau, ainsi que via internet et le « cloud », les agents se découvrent entre eux automatiquement avec une configuration réseau ne réclamant pas de connaître le reste du système. Cette découverte produit un réseau d’agents maillés totalement décentralisés avec un couplage logiciel faible à nul selon les schémas d’architecture utilisés.
Cet article présente les différents schémas d’architecture proposés par Ingescape, en les comparant avec les pratiques industrielles et technologiques les plus actuelles. Deux articles connexes, pointés à la fin de celui-ci, permettent ensuite d’entrer dans le détail d’une part de la notion de services (services web, RPC, etc.), et d’autre part de la notion de flux de données (bus logiciels).
Même ordinateur ou même réseau local
Découverte sur le réseau
Le plus souvent, une plateforme Ingescape est un ensemble d’agents logiciels utilisant la bibliothèque Ingescape et connectés sur le même réseau local, c’est à dire conjointement :
- Sur des adresses IP appartenant au même sous-réseau,
- Avec le même masque de réseau et la même adresse de broadcast,
- Sur le même port.
De façon synthétique, ceci est configuré par la ligne de code suivante dans tout agent Ingescape :
Cette ligne de code permet, pour un agent donné, de sélectionner un périphérique réseau (ici « en0 »), et donc une adresse IP, un masque et une adresse broadcast – déterminés par la configuration du périphérique réseau choisi -, ainsi qu’un port réseau (ici 5670) correspondant à la « clé commune » de la plateforme à joindre : tous les agents utilisant le même réseau et le même port se découvrent automatiquement, indépendamment du langage et du système d’exploitation qu’ils utilisent.
Ingescape propose aussi une découverte par le biais de brokers qui sont des logiciels dédiés, chargés de la mise en relation entre agents. Ce second mode de découverte, plus centralisé, réclame de connaître au moins l’adresse IP de l’un des brokers de la plateforme. Si les brokers sont éteints ou qu’un agent ne connaît pas l’adresse d’au moins l’un d’entre eux, il ne pourra pas se connecter aux autres agents. Nous préférons donc utiliser le plus souvent le mode d’auto-découverte, reposant uniquement sur la configuration réseau de l’ordinateur hébergeant un agent donné. Il est à noter que même en utilisant des brokers, les agents constituent un réseau maillé décentralisé. La perte d’un broker empêchera seulement les agents nouveaux-venus utilisant ce broker de se connecter aux autres agents déjà présents.
Ensemble maillé décentralisé
Quel que soit le mode de découverte, Ingescape permet la création d’un réseau maillé et décentralisé d’agents : tous les agents se connaissent et sont capables de communiquer de pair à pair. Une plateforme Ingescape ne possède aucun point central. Un agent peut se connecter ou s’arrêter à son gré. Les autres agents sont notifiés de l’arrivée et du départ des autres agents sur la plateforme.
L’aspect maillé et décentralisé, couplé à un échange initial automatique d’informations de configuration, permet aux agents de constituer un ensemble cohérent et connu de chacun d’entre eux. Les agents sont alors capables, en temps réel, de façon dynamique, d’établir des flux de données et des appels de services entre eux. Cet échange initial d’informations pour la création du maillage prend généralement quelques centièmes de secondes avec quelques centaines d’octets transitant entre chaque agent deux à deux. Ceci permet aux plateformes Ingescape, sur un réseau informatique classique 100BaseT de pouvoir faire face sans difficulté à plusieurs dizaines de milliers d’agents. Généralement, les plateformes Ingescape industrielles et opérationnelles sont composées de quelques dizaines d’agents, réservant une large marge de progression.
Optimisation automatique des canaux de communication
Pour l’ensemble des agents maillés, les flux d’information et appels de services utilisent des connexions pair à pair de très haute performance portées par ZeroMQ. Ces connexions sont capables de pleinement tirer parti des réseaux les plus performants, avec un surcout de communication très faible par rapport aux données brutes à faire transiter. Ceci permet à Ingescape de proposer des performances de communication très élevées en termes de débits et de latence, pour répondre aux attentes des systèmes les plus exigeants, bien au-delà de connexions TCP/IP classiques.
Lorsque deux agents fonctionnent sur le même ordinateur dans deux processus/applications différents, Ingescape utilise automatiquement des connexions pair à pair plus performantes que le TCP/IP. Sous Windows, la loopback est utilisée. Sur les systèmes UNIX, ce sont des connexions IPC. Les gains de latence et de débit permis par cette optimisation complètement transparente pour les développeurs d’agents sont très substantiels et sont adaptés à des communications à très haute fréquence et à très haut débit, recherchées dans des systèmes de calcul intensif ou de simulation complexe.
Ingescape permet aussi de regrouper des ensembles d’agents au sein d’un même processus/application, que ce soit dans un même thread ou dans des threads séparés. La communication est alors assurée par de la mémoire partagée offrant des performances encore plus élevées que les échanges IPC. Ingescape est bien sûr thread-safe.
Avec cette souplesse, les mêmes modélisations de mappings et échanges de services restent applicables quelle que soit la localisation entre deux agents. Il est possible – et fréquent en contextes de développement, de mise au point, de diagnostic ou de prototypage – de délocaliser certains agents entre différentes machines opérées par plusieurs développeurs ou mainteneurs, pour ensuite optimiser les regroupements lors de la mise en service. Ces regroupements peuvent aller d’un assemblage dans une même application à des choix d’urbanisation des applications sur un ensemble de machines, physiques, virtuelles ou conteneurisées.
Enfin, pour les cas où chaque microseconde est comptée avec des topologies réseau ne permettant pas de passer outre le TCP/IP, Ingescape permet la création de flux de communication spécifiques, nécessitant un développement additionnel mais fortement facilité, puisque s’appuyant sur les mêmes mécanismes de communication qu’Ingescape utilisant la performance très largement reconnue de ZeroMQ.
Edge computing, distribution des ressources de calcul et de la bande passante
Contrairement à des solutions client/serveur ou des systèmes de communication à base de brokers (Apache Kafka, RabbitMQ, MQTT, etc.) réclamant des infrastructures statiques pour fonctionner autour de points de centralisation pour la circulation de l’information, Ingescape est très adapté au découpage de systèmes logiciels en unités indépendantes restant capables de communiquer de façon efficace, performante et contrôlée de pair à pair. A ce titre, Ingescape facilite grandement l’architecture des systèmes d’information distribués et hétérogènes en permettant de répartir les activités de calcul, de stockage/récupération, d’interactions utilisateurs, etc. de façon optimale par rapport aux capacités matérielles disponibles.
La dynamicité d’Ingescape, c’est à dire sa capacité à créer et rediriger des flux d’information et des services à la volée, permet de traiter de façon simple les problématiques de parallélisation et d’edge computing pour allouer finement – et ajuster au fil du temps – les ressources de traitement et de stockage de l’information, ainsi que des besoins et nécessités de circulation de l’information sur les réseaux. Le fait que chaque agent Ingescape soit un programme exécutable autonome, pouvant être développé dans pratiquement n’importe quel langage et pour tout système d’exploitation, en incluant des machines virtuelles et conteneurs (docker, etc.), donne une souplesse très significative par rapport à la plupart des solutions industrielles actuelles.
Les développeurs utilisant Ingescape bénéficient à tout moment de tous les services et de toutes les informations leur permettant, de façon statique ou à la volée, d’adapter la topologie de leur plateforme, les ressources de calcul, les flux d’information et les stratégies de redondance et de balance de charge.
Microservices et réutilisation
Un agent logiciel Ingescape peut être vu comme un service modélisé avec une combinaison de flux d’entrée/sortie et de services que l’on peut solliciter. La simplicité du modèle permet aussi la simplicité de la compréhension des services, même si ces derniers sont avancés et riches. L’expérience de l’utilisation d’Ingescape a montré les avantages du modèle Ingescape, y compris dans des systèmes qui étaient préalablement modélisés avec des solutions intrinsèquement plus complexes : la traduction de ces modèles tiers vers celui d’Ingescape a été opérée très facilement par les équipes concernées, qu’il s’agisse de services web, d’interrogation de bases de données ou de protocoles ou flux spécifiques.
La modélisation d’un système en agents de complexité toujours adaptée aux services qu’ils contiennent permet également de maximiser la réutilisation de ces services. Il est fréquent pour les utilisateurs d’Ingescape de pouvoir réutiliser des agents d’un projet à l’autre parce qu’ils fournissent des services bien définis et faiblement couplés au reste de l’environnement. Ce gain obtenu dans la durée est très significatif en termes de coûts et de maîtrise technique, que ce soit sur des produits à adapter ou à configurer pour des clients, ou pour des réalisations sur mesure dans un domaine donné.
Structures de données avancées et sérialisation
Avec son modèle d’entrées/sorties et de services, Ingescape propose déjà des capacités de structuration de l’information intéressantes et adaptées à la plupart des projets industriels et opérationnels. Il est facile de compléter cette structuration avec d’une part des formalismes à base de texte (JSON, XML, etc.) et d’autre part avec des solutions de sérialisation pour les données binaires telles que Protocol Buffers. Ingescape est complètement ouvert à des échanges de données structurées complexes en format texte et binaire, sans créer l’obligation d’utiliser celles-ci et donc en n’imposant pas de complexité formelle souvent source d’erreurs et de complications lors des évolutions d’architecture.
En complément, l’éditeur visuel Ingescape permet un affichage et même une vérification des formats structurés tiers textuels et binaires afin de valider la conformité des échanges.
Résilience, redondance et administration système en temps-réel
Il est simple sur une plateforme Ingescape de lancer plusieurs instances d’un même agent, recevant et émettant les mêmes flux de données et proposant les mêmes services. Nous ne décrivons pas ici les capacités d’Ingescape à distribuer de l’information pour faire du calcul parallèle : ce point est traité dans l’article Plateformes Ingescape – Partie 2 – Bus logiciels et flux de données avec Ingescape. Nous introduisons par contre la notion d’élections permettant à plusieurs instances d’un même agent – et plus largement à tout groupe d’agents y ayant un intérêt – d’organiser des élections pour un rôle donné. Cette notion permet notamment de mettre en place facilement des architectures de type principal/secours, avec un ou plusieurs secours, offrant de façon très accessible des possibilités de redondance à chaud.
Par ailleurs, la nature maillée et complètement dynamique d’une plateforme Ingescape permet à tout agent d’être informé de l’arrivée ou du départ de tout autre agent. Ceci permet donc aux agents de s’adapter à la perte ou à l’arrivée d’un autre agent pour réagir à ces événements, activer des modes dégradés, diriger différemment les flux d’information, réorienter les services accessibles, etc. Il est également très simple de déclencher des mesures d’administration systèmes via des agents watchdogs créés spécialement pour une plateforme et capables de piloter des lancements de processus, des notifications système, etc.
Plateformes distantes, cloud et internet – au-delà des réseaux locaux
Ingescape, bien que permettant la coordination de dizaines de milliers d’agents au sein d’une plateforme, est d’abord adapté à la mise en relation d’agents sur une même machine ou un même réseau local. Pour produire des architectures géographiquement distribuées, la philosophie portée par Ingescape vise la mise en place de multiples plateformes interconnectées, avec une approche edge computing. Ingescape offre alors la possibilité de relier ces différentes plateformes entre elles pour en exporter ou y injecter des flux d’information ou appels de services venant d’autres plateformes.
Un écosystème Ingescape réparti entre plusieurs réseaux disjoints, et donc plusieurs plateformes disjointes, peut être vu comme des groupes d’agents, chacun dans une plateforme et offrant l’accès à ces agents indépendamment de la plateforme sur laquelle il s’exécute.
Dans la pratique, lorsque deux plateformes sont reliées, Ingescape permet de « projeter » un ou plusieurs agents d’une plateforme source sur une plateforme cible, rendant ces agents accessibles sur la plateforme cible, comme s’ils s’y exécutaient nativement. Un agent projeté expose alors ses entrées, sorties et services aux agents de la plateforme cible.
Tout comme les agents sont maillés au sein d’une plateforme, il est possible de mailler des plateformes entre elles :
Ces plateformes peuvent fonctionner sur des sous-réseaux différents sur un même site géographique, sur des sites différents reliés par des liaisons privées (VPN) ou publiques (Internet), ou bien sur des plateformes hybrides, locales d’une part et s’exécutant dans le « cloud » d’autre part, c’est à dire sur des serveurs ou conteneurs hébergés par des tiers sur des infrastructures à part.
Relier et fusionner des plateformes distantes avec Ingescape
Pour relier des plateformes distantes, Ingescape propose des proxies. Un proxy Ingescape est un agent particulier permettant de gérer la mise en relation entre deux plateformes. Il fonctionne selon deux modes :
- Un mode local permet d’exposer tout ou partie des agents d’une plateforme source avec un point de contact centralisé vers l’extérieur, matérialisé par une adresse IP et un port dont l’accès peut être contrôlé par un pare-feu et/ou un NAT, et être accessible par un VPN,
- Symétriquement, un mode distant permet, depuis la plateforme cible, de se connecter à un proxy en mode local pour projeter le ou les agents exportés depuis la plateforme source vers la plateforme cible.
Lorsque deux proxies, l’un en mode local et l’autre en mode distant, sont connectés, les agents exportés depuis la plateforme source sont exposés sur la plateforme cible comme s’ils s’exécutaient directement sur cette dernière. Les agents de la plateforme cible sont alors capables d’échanger de l’information et d’utiliser des services de ces agents exportés de la plateforme source, exactement comme s’ils étaient présents localement. La seule contrainte à prendre en compte est la qualité de la connexion entre les deux proxies pour s’assurer que la latence et la bande-passante sont adaptés aux besoins d’échanges entre les agents concernés.
Les proxies Ingescape permettent des combinaisons souples :
- Un proxy peut fonctionner à la fois en mode local et distant, de sorte à ce que deux plateformes puissent projeter mutuellement des agents de l’une vers l’autre. Le cas d’usage ultime est la fusion complète entre deux plateformes distantes.
- Si les besoins en bande passante ou la segmentation de l’information le justifient, plusieurs proxies peuvent être mis en œuvre pour relier une même plateforme source et une même plateforme cible. Chaque proxy consomme alors la bande passante associée aux agents qu’il relaie sur la connexion qui lui est allouée.
- Plusieurs plateformes sources peuvent être projetées vers une même plateforme destination et une même plateforme source peut être projetée vers plusieurs plateformes destination. Il est donc possible de mailler un nombre non-contraint de plateformes entre elles, pour aller si besoin jusqu’à la fusion de plusieurs plateformes entre elles.
Les liaisons entre proxies sont sécurisées par défaut et peuvent être complétées par l’utilisation de certificats spécifiques avec un cryptage asymétrique. Le niveau de sécurité proposé est complètement adapté à une utilisation via Internet ou des réseaux non-sécurisés.
Comme dans toute architecture réseau géographiquement distribuée, l’utilisation des proxies doit être adaptée à la bande passante et aux contraintes de latence à respecter. La performance brute des proxies assure un surcoût minimal quant à la bande passante et à la latence. La possibilité de mettre en jeu plusieurs proxies entre deux plateformes distantes permet également de découper les flux de données pour assurer une qualité de service minimale lorsque cela est souhaitable.
Intégrer des applications web depuis des navigateurs web ou applications mobiles
Au-delà des plateformes géographiquement éloignées, certaines applications logicielles ne peuvent se présenter comme des applications « clients lourds » communiquant sur un réseau local. C’est le cas lorsque :
- Une application fonctionne dans un navigateur web, imposant de fait un schéma client/serveur et limitant les communications à des requêtes HTTP et des websockets,
- Une application, légère, riche ou lourde, dans un navigateur web, sur tablette/téléphone ou sur un ordinateur classique, est localisée sur un réseau différent de celui de la plateforme, y compris sur Internet ou via un VPN, sans la possibilité de mettre en place une plateforme cible, c’est-à-dire de contrôler le réseau local cible et son pare-feu.
Pour faire face à ces situations, les proxies Ingescape permettent également d’offrir un accès à une plateforme source pour des agents isolés sur des réseaux tiers. Afin de permettre une compatibilité large de communications et une utilisation simple dans les navigateurs web (et pour tout autre type d’applications moins contraintes), les proxies Ingescape permettent la création d’un mode local alternatif ouvrant un serveur de type websocket. Cette connexion locale offre les mêmes possibilités de contrôle et de configuration que la connexion source/cible classique présentée dans la section précédente.
Les applications clientes voulant intégrer une plateforme source par ce biais sont qualifiées de pseudo-agents dans le sens où elles vont être manipulables comme des agents classiques sur la plateforme source mais se connectent en utilisant une architecture client/serveur correspondant à celle d’un serveur websocket ayant une adresse de la forme suivante : wss://adresse_serveur:port. Ces pseudo-agents n’embarquent pas la bibliothèque Ingescape directement mais une version simplifiée disponible pour le moment en Javascript, C++/Qt et Java, notamment pour Android.
L’arrivée et le départ des pseudo-agents est détectée comme pour les agents classiques. La version simplifiée de la bibliothèque Ingescape utilisée par les pseudo-agents offre les mêmes capacités de simplicité et d’apprentissage rapide que l’originale avec une interface de programmation très similaire. La simplification concerne principalement les capacités de maîtrise du réseau mais les concepts de programmation autour du modèle Ingescape et des événements associés sont identiques.
Il est possible de connecter des quantités importantes (centaines, milliers voire millions) de pseudo-agents à une plateforme source mais cela réclame les mêmes précautions de dimensionnement, de bande passante, de sécurité, etc. que pour des architectures client/serveur de type web à fort volume. Il est possible de lancer plusieurs proxies simultanément pour offrir plusieurs points d’accès redondants à une même plateforme source ou de réaliser de la balance de charge comme les proxies de serveurs web le permettent. Les stratégies à mettre en place sont en fait les mêmes que celles très familières aux administrateurs de plateformes web classiques.
Sécurité
Pour les plateformes Ingescape, la sécurité implique les aspects suivants :
- Contrôler et bloquer les tentatives de connexion à une plateforme pour les agents non-autorisés,
- Crypter les communications entre agents sur une plateforme donnée,
- Contrôler, crypter et bloquer si besoin les connexions entres plateformes et depuis les pseudo-agents dans les applications web et mobiles.
La bibliothèque Ingescape s’appuie sur la couche de sécurité proposée par ZeroMQ. Cette couche de sécurité assure l’authentification et le cryptage par certificats privés et publics autour du mécanisme SASL, de cryptographie sur les courbes elliptiques de type Curve25519 avec des clés de 256 bits, via la bibliothèque libsodium(https://libsodium.gitbook.io/doc/).
Les niveaux d’authentification et de cryptage correspondent à l’État de l’Art technologique de 2020. La sécurité proprement dite repose sur la capacité à préserver des certificats privés et à distribuer les certificats publics associés. Étant donnée la nature industrielle et distribuée des plateformes Ingescape, nous n’utilisons pas d’autorité de certification pour les certificats, contrairement aux certificats utilisés en HTTPS. Une exception notable est cependant introduite pour les connexions websocket en WSS pour lesquelles il est bien sûr possible d’utiliser des certificats émanant d’autorités de certification reconnues.
Avec Ingescape, des agents d’une même plateforme doivent avoir accès, chacun à leur certificat privé et tous aux certificats publics des autres agents. Des proxies locaux et distants doivent avoir accès réciproquement à leur propre certificat privé et au certificat public de l’autre, ces certificats pouvant être différents de ceux de la plateforme.
Les connexions websockets peuvent utiliser la couche WS-Security (WSS) et ses différentes possibilités selon la norme 1.0 établie par OASIS-Open. Le plus généralement avec WSS, seules les parties signature et chiffrement sont utilisées au travers de certificats X.509, de façon similaire aux connexions HTTPS utilisant ces mêmes types de certificats.
A lire ensuite
Suite à cet article qui donne une vue d’ensemble de l’utilisation d’Ingescape pour des plateformes distribuées, locales, distantes et par le web, deux articles complémentaires sont accessibles :