FR 3069669 A1 20190201 FR 1757040 A 20170725 Un système de communication et un procédé d'accès et de déploiement des microservices éphémères sur une plateforme hétérogène DOMAINE TECHNIQUE DE L'INVENTION La présente invention concerne le domaine des systèmes de communication et plus particulièrement l'amélioration de l'accès et du déploiement des microservices, basés sur le langage Java, sur une plateforme hétérogène. La présente invention concerne également un procédé d'accès et de déploiement des microservices sur une plateforme hétérogène par ce système de communication. ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION Un problème dans le domaine des systèmes de communication 15 concerne la fiabilité du système sur l'accès et le déploiement des microservices éphémères sur une plateforme informatique hétérogène. Au début de l'informatique, la communication entre machines informatiques nécessitait une connaissance approfondie des protocoles réseau et du matériel réseau. La programmation orientée objet (P00 20 consistant à la définition et l'interaction de briques logicielles ou d'application informatique appelées objets) a permis le développement des architectures d'un environnement informatique ou des réseaux, dites distribuées, en fournissant des bibliothèques (ou des collections de routines encapsulant des séquences d'instructions) de haut-niveau pour faire communiquer, entre 25 eux, des objets répartis sur des machines différentes de sorte à alléger le travail des programmeurs et d'optimiser la disponibilité des ressources sur les machines d'un réseau. Les microservices peuvent être définis comme des bibliothèques ou modules de code et peuvent constituer une unité fonctionnelle comprenant un point d'entrée connu et formant un assemblage, 30 par exemple, avec un système d'exploitation, une plateforme informatique, un framework (terme anglophone désignant une structure logicielle) ou un 2 environnement d'exécution. Chaque microservice est un processus autonome et indépendant qui peut ne pas dépendre d'autres microservices. Avec l'évolution de l'internet des objets (loT) et de la communication machine-à-machine (M2M), l'utilisation des microservices permet aux 5 développeurs ou programmeurs et opérateurs de développer, de déployer et de gérer des applications auto-adaptatives, par exemple, sur une plateforme de calcul qui répond aux besoins de nombreux scénarios d'application, en utilisant un langage (par exemple du Java) pris en charge par la plateforme de calcul et en utilisant l'environnement d'exécution standard et les 10 ressources fournies par cette plateforme de calcul. Ainsi, au lieu de lancer plusieurs instances du serveur d'application, on peut faire monter en charge un microservice donné à la demande. Ceci valorise mieux l'infrastructure sous-jacente d'un service informatique qui ne nécessite désormais plus de provisionner de nouvelles machines virtuelles, il suffit de provisionner de nouvelles instances de microservices sur les machines existantes. Il est connu de l'art antérieur, des plateformes de calcul commerciales généralement payantes (telles qu'Amazon Lambda, Azure functions, Google Functions ou Iron.io) ou une seule solution gratuite (OpenWhisk). Par exemple, Amazon Lambda est un service informatique qui permet d'exécuter un code sans nécessiter le provisionnement ou la gestion des serveurs. Il exécute le code uniquement lorsque cela est nécessaire et s'adapte automatiquement. Le temps de calcul requis pour exécuter le code et les requêtes distribuées sont facturés à l'usage par ce service et l'utilisateur ne peut se connecter aux instances de calcul ni personnaliser le système d'exploitation ou l'environnement d'exécution, car ce service informatique effectue les activités opérationnelles et administratives à la place de l'utilisateur (notamment le déploiement du code, l'adaptation de la capacité, la vérification de l'état des instances ou l'application des correctifs de sécurité). Ces solutions sont généralement payantes, ou nécessitent une plateforme de base qui est complexe à mettre en oeuvre avec des composants non interchangeables. De plus, les protocoles d'accès depuis internet sont peu diversifiés. 3 Il également connu de l'art antérieur un système et un procédé de communication améliorant l'accès aux services électroniques disponibles via un réseau de télécommunication, comme par exemple décrit dans le document US2003154265. Ce document qui traite du déploiement de 5 services temporaires sur une plateforme de télécommunication fait mention de l'utilisation d'un système cache dans lequel les services sont archivés sous un format de fichier Jar puis chargé par un chargeur de fichier Jar. Le procédé comprend la construction d'un paquet électronique, sous le format Jar, comportant le code et les données nécessaires à l'exécution du service 10 et les informations de contrôle du cache ; ainsi que la transmission du paquet à un dispositif de mise en cache pour mettre en cache le service par rapport à l'information de contrôle de cache. Cependant, ce système de communication ne permet pas de référencier les services temporaires de façon à faciliter l'identification et le déploiement des services sur demande 15 d'une requête. De plus, ce système ne peut être adapté ou mis en place pour développer et déployer des microservices éphémères, notamment du fait que les microservices ne peuvent être chargés ou rechargés sans interruption de service et sans provoquer d'impact sur les ressources utilisés. Dans ce contexte, il est intéressant de proposer une solution 20 permettant de pallier certains inconvénients de l'art antérieur en facilitant et améliorant l'accès et le déploiement des microservices éphémères sur une plateforme informatique hétérogène. DESCRIPTION GENERALE DE L'INVENTION 25 La présente invention a pour but de pallier certains inconvénients de l'art antérieur en proposant un nouveau système de communication, facilitant et fiabilisant l'accès et le déploiement de microservices éphémères sur une plateforme informatique hétérogène. A cet effet, la présente invention concerne un système de 30 communication comprenant un ou plusieurs noeuds d'exécution apte à 4 exécuter un ou plusieurs microservices, un dispositif informatique, dit « serveur hôte » (ou « hub » en terme anglophone), comportant plusieurs routeurs constituant une interface intermédiaire de communication entre chaque noeud d'exécution et l'extérieur du système de communication, une 5 plateforme informatique hétérogène, constituée d'un ensemble de matériel et logiciel ou code exécutable pour l'accès et le déploiement des microservices sur le système dans un environnement d'exécution Java (ou « runtime java » en terme anglophone) sur le serveur hôte et les noeuds d'exécution permettant l'exécution des programmes informatiques basés sur le langage 10 Java ; le système de communication permet la création de microservices éphémères par l'utilisation d'un système clef/valeur mémorisé dans un cache mémoire distribué à chaque création en référenciant chaque microservices par des noms de fichier déposés dans le système par le développeur et utilisant un protocole d'échange TCP (désignant un « protocole de contrôle 15 de transmissions ») asynchrone échangeant des notifications contenant des métadatas entre le serveur hôte et chaque noeud d'exécution ; et en ce que chaque noeud mémorise des fichiers d'exécution du ou des microservices comportant l'accès au système par au moins un des deux point d'entrée soit au serveur hôte soit au noeud d'exécution et au moins un chargeur de classe 20 assurant le déploiement des services associés aux microservices qui sont intégrés dans le noeud d'exécution. Selon une autre particularité, les échanges d'information entre le serveur hôte et les noeuds d'exécution utilisent des données de type métadatas comprenant un ou plusieurs des éléments suivants : un alias du 25 microservice (appelé clé), un chemin de localisation d'une méthode particulière dans le microservice, une action associée au chemin de localisation, un code retour d'exécution du microservice et un type de contenu d'exécution du microservice. Selon une autre particularité, un outil de développement de 30 microservices constitue une interface développeur et un outil d'envoi dans le protocole utilisé entre le microservice et le serveur hôte. 5 Selon une autre particularité, chaque noeud d'exécution comprend en outre des moyens informatiques de gestion des microservices, des moyens informatiques de lecture et d'écriture des fichiers d'exécution disposés dans une unité distribuée de stockage du système, et un système de publication et 5 souscription de message lorsqu'un microservice est déposé ou un alias est modifié par le développeur sur le système. Selon une autre particularité, chaque noeud d'exécution est apte à exécuter un algorithme prédéterminé dédié à la sélection d'un ou plusieurs noeuds d'exécution du microservice en déterminant un score (ou valeur) puis 10 en mémorisant l'adresse ou l'alias du microservice et ce score (pouvant être défini par le système clé/valeur) dans le cache mémoire distribué si le score est plus pertinent que le précédent. Selon une autre particularité, l'algorithme prédéterminé est prévu pour lancer un timeout d'inactivité (terme anglophone désignant un délai 15 d'inactivité de charge) à chaque détermination de score pour que le serveur hôte puisse réutiliser le même noeud d'exécution tant que le microservice est inexploité ou qu'un timeout d'inactivité est levé. Selon une autre particularité, une fois le noeud d'exécution choisi, le noeud appelé par le système charge le microservice dans un nouveau 20 chargeur de classe (ou en terme anglophone « classloader »), le système référencie ce chargeur de classe dans une HashMap (terme anglophone d'un exemple de système clef/valeur, c'est-à-dire qu'il s'agit d'une collection ou un dictionnaire associant une clé à une valeur) du cache mémoire distribué en fonction de l'alias utilisé dans le message d'échange 25 standardisé. Selon une autre particularité, chaque noeud d'exécution sélectionné est apte à remonter des données sous forme de score et d'attribution d'adresse dans un cache mémoire distribué du système de communication attribué à chaque microservices pour que le serveur hôte puisse lire et 30 exploiter ces données. 6 Selon une autre particularité, les routeurs du serveur hôte utilisent des applications basées sur Java et Netty pour assurer des communications multiprotocoles vers l'extérieur du système et des échanges asynchrone en protocole TCP vers les noeuds d'exécution du système. 5 Selon une autre particularité, le système mémorise les microservices au format Jar ou Javascript et le système désarchive les fichiers au format Jar en classes d'utilisation ou d'exécution pour les rendre accessible au chargeur de classe de l'environnement d'exécution Java du noeud d'exécution qui charge ces microservices depuis l'unité de stockage distribué 10 en fonction de la demande du serveur hôte (définie par l'alias de service qui permet d'identifier le microservice à charger), le chemin de la requête entrante permettant d'identifier la méthode (java ou javascript) à appeler dans le microservice chargé, et les autres formats de fichier sont mémorisés unitairement sur le système clef/valeur pour que l'environnement d'exécution 15 Java puisse lire ou exploiter selon le besoin. Selon une autre particularité, le système est apte à sélectionner un noeud d'exécution pour qu'il charge un microservice dans un chargeur de classe qui est référencié dans l'unité distribuée de stockage en fonction de l'alias utilisé dans le métadatas d'échange. 20 Selon une autre particularité, l'utilisation d'un microservice est activée par au moins un code d'accès disposé soit au niveau du service permettant l'accès à toutes les ressources du service, soit au niveau d'une ressource du service permettant l'accès à cette unique ressource, ou par au moins une méthode d'accès prédéfinie par un gestionnaire de sécurité du système de 25 communication. Selon une autre particularité, le serveur hôte utilise et réutilise le même noeud d'exécution tant que le microservice est inexploité ou qu'un délai d'inactivité de charge du microservice est levé. Selon une autre particularité, le système clef/valeur et le système de 30 notification sont des systèmes externes au système de communication qui 7 sont intégrés dans un code exécutable du système de communication, ou injectés au moment de l'exécution du système. La présente invention a également pour autre objet un procédé 5 d'accès et de déploiement fiable, de microservices éphémères sur une plateforme informatique hétérogène. Ce but est atteint par le procédé d'accès et de déploiement de microservices éphémères sur une plateforme hétérogène, par un système de communication selon une des particularités de la présente invention, 10 comprenant les étapes suivantes : - dépôt d'un ou plusieurs microservices par le développeur sur un ou plusieurs noeuds d'exécution ; - référencement des microservices par le nom de fichier déposé sans son extension dans le système clef/valeur ; 15 - mémorisation des microservices, sous forme de fichier d'exécution de type Jar ou Javascript, par le système clef/valeur dans l'unité distribuée de stockage ; - désarchivage en classes d'utilisation ou d'exécution des fichiers d'exécution au format Jar par le système clef/valeur pour les rendre 20 accessibles au chargeur de classe de l'environnement d'exécution Java du noeud d'exécution, et le format JavaScript des fichiers d'exécution sont mémorisés unitairement sur le système clef/valeur pour que l'environnement d'exécution Java puisse lire ou exploiter selon le besoin ; - chargement des classes associées aux microservices par les 25 chargeurs de classe des noeuds d'exécution à charger ; - déchargement des microservices par les noeuds d'exécution lorsque les microservices sont inexploités ou que le délai d'inactivité de charge du ou des microservices est levé. Selon une autre particularité, l'étape de déchargement des 30 microservices comprend une sélection par le serveur hôte des noeuds 8 d'exécution du microservice à charger et chaque noeud d'exécution remonte des données sous forme de score et d'adresse d'attribution du microservice dans un cache mémoire distribué du système de communication pour que le serveur hôte puisse lire et exploiter ces données. 5 Selon une autre particularité, le procédé comprend en outre une étape de création des alias aux microservices par le développeur pour que le système puisse localiser le ou les microservices à déployer. Selon une autre particularité, lorsque le microservice n'est pas chargé, le système de communication choisit le noeud d'exécution qui charge le 10 microservice dans un nouveau chargeur de classe et le référencie dans l'unité distribuée de stockage du système. Selon une autre particularité, le rechargement de microservice se fait soit par le dépôt d'un nouveau microservice avec le même nom de fichier d'exécution, soit par changement d'alias. 15 Selon une autre particularité, le rechargement de microservice entraîne un envoi de message par le système de publication et souscription pour actualiser l'ensemble des actions des noeuds d'exécution du système de communication. 20 D'autres particularités et avantage de la présente invention sont détaillés dans la description qui suit. DESCRIPTION DES FIGURES ILLUSTRATIVES D'autres particularités et avantages de la présente invention 25 apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels : - la figure 1 représente un schéma global d'un système de communication selon un mode de réalisation; 9 - la figure 2 représente un schéma le système de communication avec les différents composants pouvant intervenir à l'accès et au déploiement de microservices éphémères selon un mode de réalisation. 5 DESCRIPTION DES MODES DE REALISATION PREFERES DE L'INVENTION L'invention, en référence aux figures 1 et 2, va être maintenant décrite. La présente invention concerne un système de communication 10 permettant l'accès et le déploiement facile, élastique (c'est-à-dire modulable en fonction des besoins en applications et le plus rapidement possible), automatique et auto-régulable de microservices éphémères, basés sur le langage Java, sur une plateforme informatique hétérogène. Par exemple comme représenté sur la figure 1, le système (1) de 15 communication comprend : - au moins un noeud d'exécution (2) supportant l'environnement d'exécution des microservices (5) ; - au moins un dispositif informatique, dit « serveur hôte » (3), comprenant un point ou périphérie d'entrée public externe servant à 20 commander le système de communication ou à y envoyer ou récupérer des informations du système de communication par un utilisateur externe ; - une plateforme (4) informatique hétérogène comprenant un ensemble (40) de matériel et logiciel ou code exécutable pour l'accès et le déploiement des microservices (5) sur le système (1) dans un environnement 25 (J) d'exécution Java disposé à la fois sur le serveur hôte (3) et les noeuds d'exécution (2) pour pouvoir exécuter des programmes informatiques basés sur le langage Java. 10 Dans certains modes de réalisation, le serveur hôte (3) comprend plusieurs routeurs (30) constituant une interface intermédiaire de communication entre chaque noeud d'exécution (2) et l'extérieur du système (1) de communication, comme représenté par exemple sur les figures 1 et 2. 5 Dans certains modes de réalisation, les routeurs (30) du serveur hôte (3) utilisent des applications basées sur Java et Netty pour assurer des communications multiprotocoles vers l'extérieur du système et des échanges asynchrone en protocole TCP vers les noeuds d'exécution (2) du système (1). Ainsi, plusieurs protocoles d'accès externe (c'est-à-dire via internet) 10 peuvent être gérés par le système (1) grâce à l'utilisation du framework Netty, tels que HTTP(S) (désignant des protocoles de transfert sur internet), MQTT (désignant un protocole de messagerie de la transmission des données télémétrie), Websocket, TCP ou FTP (désignant un protocole de transfert de fichier). 15 Dans certains modes de réalisation, le système (1) de communication permet la création de microservices (5) éphémères par l'utilisation d'un système clef/valeur (6) mémorisé dans au moins un cache (8) mémoire distribué (par exemple et non limitativement les bases Redis ou Hazelcast) à chaque création en référenciant chaque microservices (5) par des noms de 20 fichier déposés dans le système (1) par un développeur (10) et utilisant un protocole (T) d'échange TCP asynchrone échangeant des notifications contenant des métadatas (M) entre le serveur hôte (3) et chaque noeud d'exécution (2). La communication via le protocole TCP asynchrone permet un gain en performance et en mémoire puisqu'elle limite le nombre de tâche 25 ou fil d'exécution/instruction nécessaire entre le serveur hôte et les noeuds. Dans certains modes de réalisation, lorsque le développeur (10) dépose un microservice (5) sur le système (1), une sélection d'un ou plusieurs noeuds (2) d'exécution du microservice se fait par un algorithme spécifique qui utilise, par exemple, NativeMemory, MetaSpace, TotalHeap ou 30 CPU (désignant une unité centrale de calcul). L'algorithme, pour chaque 11 noeud (2), détermine ainsi un score (ou une valeur) et mémorise ce score et une adresse d'attribution (clef) ou un alias du microservice dans le cache (8). Cette information (clef, valeur) est mémorisée dans le cache (8) mémoire distribué si le score est plus pertinent que le précédent et le serveur hôte 5 pourra lire cette information et choisir le noeud (2) d'exécution. Le cache mémoire distribué (8) peut être exploité par le serveur hôte (par exemple pour identifier le noeud le moins chargé) et mis à jour par les noeuds d'exécution (par exemple pour pouvoir répartir la charge entre les noeuds faite par l'algorithme). 10 Dans certains modes de réalisation, les données en entrée du système (1) peuvent être reformatées en un message standard qui est échangeable et modifiable par l'ensemble des microservices (5) et de leurs fonctions exportées mise en oeuvre. Ce message contient des métadatas (M) intégré par le serveur hôte (3), tel que par exemple un alias ou identifiant ou 15 clé du microservice pour que le système puisse identifier quel microservice utiliser, un chemin de localisation d'une méthode particulière dans le microservice et une action associée au chemin de localisation ; et/ou par les noeuds d'exécution (2), tels que par exemple un code retour d'exécution du microservice et un type de contenu d'exécution du microservice. Dans le cas 20 du chemin de localisation, par exemple, une méthode « manageUser() » peut être recherché par le chemin « /user ». Dans le cas d'une action associée au chemin de localisation, par exemple, une action peut être précisée (comme par exemple création ou suppression) : méthode « createUser() » par le chemin « /user » et une action « POST » ou méthode « deleteUser() » par le 25 chemin « /user » et une action « DELETE ». Dans certains modes de réalisation, chaque noeud (2) mémorise des fichiers d'exécution (50) du ou des microservices (5), pouvant être déposés par le développeur (10) et comportant l'accès au système (1) par au moins un des deux point d'entrée soit au serveur hôte (3) soit au noeud d'exécution 30 (2). Par exemple, ces fichiers d'exécution peuvent contenir un nom d'un 12 chemin ou une méthode de localisation dans le microservice. Dans le cas des fichiers sous format Jar, par exemple, une nomenclature similaire au Jax-rs (terme anglophone pour Java API for RESTful Wab Services et désignant une interface de programmation Java pour créer des services web 5 avec une architecture REST) peut être utilisée: utilisation du chemin de l'url (ou adresse sur le web) pour localiser la méthode à utiliser (« @Path »), réécriture des sous éléments du chemin de l'url (« @PathParam »), utilisation de verbes ou vocabulaires d'accès aux ressources (« @GET », « @POST », « @DELETE », « @PUT »). 10 Dans certains modes de réalisation, chaque noeud (2) comprend au moins un chargeur de classe (7) assurant le déploiement des services associés aux microservices (5) qui sont intégrés dans le noeud d'exécution (2), comme représenté par exemple sur les figures 1 et 2. Dans certains modes de réalisation, le système (1) est apte à sélectionner un noeud (2) 15 d'exécution pour qu'il charge un microservice (5) dans le chargeur de classe (7) qui est référencié dans une unité distribuée de stockage (9) en fonction de l'alias utilisé dans la métadata (M) d'échange. Ainsi, la gestion par le chargeur de classe de Java peut permettre de charger et recharger sans interruption de service, de sorte à obtenir un rollback (terme anglophone 20 désignant une méthode permettant d'annuler l'ensemble des requêtes réalisées) rapide. Dans certains modes de réalisation, le développeur (10) peut également créer des alias aux microservices (5). Dans certains modes de réalisation, le système clef/valeur (6) est mémorisé dans le cache mémoire distribué (8) et l'unité de stockage 25 distribué (9), par exemple et non limitativement les bases de données Redis, Cassandra, Aerospike, etc. Le système (6) clef/valeur permet de mémoriser les microservices (5) ou les fichiers d'exécution (50) des microservices sous format Jar ou sous forme de fichier simple Javascript. Dans certains modes de réalisation, le système (1) désarchive les fichiers au format Jar en classes 30 d'utilisation ou d'exécution pour les rendre accessible au chargeur de classe 13 (7) de l'environnement (J) d'exécution Java du noeud (2) d'exécution. Les autres fichiers (Javascript) sont mémorisés unitairement en se basant sur le système (6) clef/valeur pour que l'environnement (J) d'exécution Java puisse lire ou exploiter selon le besoin. Le chargeur de classe (7) peut charger les 5 microservices (5) depuis l'unité de stockage distribué (9) en fonction de la demande ou requête du serveur hôte (3), définie par l'alias de service qui permet d'identifier le microservice à charger et le chemin de la requête entrante permet d'identifier la méthode (Java ou Javascript) à appeler dans le microservice chargé. 10 Dans certains modes de réalisation, l'algorithme des noeuds (2) d'exécution est apte à lancer un timeout d'inactivité à chaque détermination de score. Ceci permet au serveur hôte (3) d'utiliser et réutiliser le même noeud (2) d'exécution, grâce à l'algorithme spécifique du noeud d'exécution, tant que le microservice est inexploité ou qu'un timeout d'inactivité est levé. 15 En effet, chaque appel de microservice peut entrainer des appels à d'autres microservices qu'il soit sur le même noeud d'exécution ou sur un autre noeud du système. De ce fait, le microservice peut comprendre une méthode particulière pour associer l'ensemble de ces réponses en une seule, pour pouvoir ainsi récupérer chacun de ces appels pour ne générer qu'une 20 réponse à l'appelant. Dans certains modes de réalisation, si le microservice (5) n'est pas chargé, le système (1) choisit le noeud (2) d'exécution. Le noeud (2) appelé par le serveur hôte (3) du système (1) charge le microservice dans un nouveau chargeur de classe (7) qui est référencié par le système dans une 25 HashMap du cache mémoire distribué (8) en fonction de l'alias utilisé dans le message d'échange standardisé. Dans certains modes de réalisation, l'appel au microservice (5) se fait par un nom ou alias de référencement unique. Par exemple, cet alias peut-être un nom de domaine web et dans le cas d'une requête HTTP sur le 30 serveur hôte (3), c'est le nom de « hast » (en-tête du fichier informatique 14 dans le protocole HTTP1.1) qui pourra être utilisé pour retrouver le microservice associé. Dans certains modes de réalisation, le serveur hôte (3) et les noeuds d'exécution (2) sont multipliables, sans aucune configuration particulière, par 5 un ou des gestionnaires du système (1). Cette configuration permet à l'administrateur ou développeur de la plateforme, de limiter les modifications ou réglages spécifiques des paramètres par serveur ou par architecture informatique pour la mise en oeuvre du système. Dans certains modes de réalisation, le système (1) peut comprendre 10 un outil de développement de microservices pour constituer une interface de développement (par exemple, via une interface de programmation applicative) pour le développeur (10) et/ou un outil d'envoi dans le protocole utilisé entre le microservice et le serveur hôte. Dans certains modes de réalisation, chaque noeud (2) d'exécution 15 peut comprendre en outre des moyens informatiques (21) de gestion des microservices, des moyens informatiques de lecture et d'écriture des fichiers d'exécution disposés dans une unité distribuée de stockage (9) du système (1), et un système (22) de publication et souscription de message (pouvant être un système de notification) lorsqu'un microservice (5) est déposé ou un 20 alias est modifié par le développeur (10) sur le système (1). Dans certains modes de réalisation, le rechargement de service se fait soit par changement d'alias, soit par le dépôt dans le système d'un nouveau microservice avec le même nom. Le dépôt du microservice ou la modification d'alias provoque donc un envoi de message via le système de publication/souscription qui 25 entraîne une action sur l'ensemble des noeuds du système de communication. Dans certains modes de réalisation, le système (6) clef/valeur et le système de notification peuvent être des systèmes externes au système (1) de communication qui peuvent être intégrés dans un code exécutable du 30 système de communication, ou injectés au moment de l'exécution du 15 système par un gestionnaire du système. Cette configuration présente l'avantage de rendre le système de communication de la présente invention, à la fois indépendant et évolutif par rapport aux systèmes externes. Ainsi, l'administrateur du système n'est pas lié vis-à-vis du système externe choisi, 5 par exemple l'administrateur pourra de préférence utiliser et facilement contrôler l'unité de stockage distribué par une base de données de type Cassandra plutôt que Redis. L'administrateur peut également, d'une part, changer facilement les composants externes en fonction de l'instanciation de la plateforme souhaitée, et d'autre part, optimiser le système de 10 communication en ajoutant sans contrainte, par exemple sans modifier l'architecture ou les codes exécutables du système, de nouveau système de notification ou de système clef/valeur plus performant. Dans certains modes de réalisation, le système peut supprimer les entrées dans la HashMap du cache mémoire distribué (8), lorsque le délai 15 d'inactivité de charge est levé ou lors du rechargement du microservice. Ce qui les permettra d'être éliminé par le Garbage Collector Java (terme anglophone désignant un « ramasse-miettes » ou un « récupérateur » de mémoire qui détermine les objets ne pouvant être utilisé par le programme pour récupérer l'espace utilisé par ces objets). En cas de rechargement du 20 microservice, les fichiers déployés ou chargés provenant du Jar seront aussi supprimés du système clef/valeur. Dans certains modes de réalisation, s'il n'y a plus de lien entre les microservices chargés par le chargeur de classe et l'environnement d'exécution Java, le chargeur de classe peut être supprimé automatiquement par le Garbage Collector Java, de sorte que le 25 rechargement multiple d'un microservice ne provoque pas d'impact sur les ressources utilisées. Dans certains modes de réalisation, l'utilisation d'un microservice (5) peut être activée par au moins un code d'accès disposé soit au niveau du service (par exemple par une annotation «PDisableSecurity») permettant 30 l'accès à toutes les ressources du service (par exemple (eDisableSecurity({7.*"})»), soit au niveau d'une ressource (par exemple 16 «PAuthentification(false)») du service permettant l'accès à cette unique ressource, ou par au moins une méthode d'accès prédéfinie par un gestionnaire de sécurité du système de communication. En effet, initialement l'appel d'un microservice non autorisé entraîne un code retour d'erreur au 5 serveur hôte. Au niveau des noeuds d'exécution, chaque appel d'un microservice devra ainsi être autorisé pour pouvoir déployer le microservice sur la plateforme. Ceci permet un accès au microservice sécurisé dans le système de communication. 10 La présente invention concerne également un procédé d'accès et de déploiement de microservices (5) éphémères sur une plateforme (4) informatique hétérogène, par le système (1) de communication selon une des modes de réalisation de la présente invention. Dans certains modes de réalisation, comme représenté par exemple 15 sur la figure 2, le procédé comprend les étapes suivantes : - dépôt d'un ou plusieurs microservices (5) par le développeur (10) sur un ou plusieurs noeuds (2) d'exécution ; - référencement des microservices (5) par le nom de fichier déposé sans son extension dans le système (6) clef/valeur ; 20 - mémorisation des microservices (5), sous forme de fichier d'exécution (50) de type Jar ou Javascript, par le système (6) clef/valeur dans l'unité (9) distribuée de stockage ; - désarchivage en classes d'utilisation ou d'exécution des fichiers d'exécution (50) au format Jar par le système (6) clef/valeur pour les rendre 25 accessibles au chargeur de classe (7) de l'environnement (J) d'exécution Java du noeud (2) d'exécution, et le format JavaScript des fichiers d'exécution (50) sont mémorisés unitairement sur le système (6) clef/valeur pour que l'environnement (J) d'exécution Java puisse lire ou exploiter selon le besoin ; 17 - chargement des classes associées aux microservices (5) par les chargeurs de classe (7) des noeuds(2) d'exécution à charger ; - déchargement ou déploiement des microservices (5) par les noeuds (2) d'exécution lorsque les microservices (5) sont inexploités ou que le délai 5 d'inactivité de charge du ou des microservices (5) est levé. Dans certains modes de réalisation, l'étape de déchargement des microservices (5) comprend une sélection par le serveur hôte (3) des noeuds (2) d'exécution du microservice à charger et chaque noeud (2) d'exécution remonte des données sous forme de score et d'adresse d'attribution du 10 microservice dans un cache (8) mémoire distribué du système (1) de communication pour que le serveur hôte (3) puisse lire et exploiter ces données. Dans certains modes de réalisation, le serveur hôte (3) choisi le noeud (2) d'exécution par trois processus différents : 15 - dans le cas où, le serveur hôte ne comprend pas d'information sur un noeud d'exécution pour un microservice donné, le serveur hôte s'adresse au cache mémoire distribué pour récupérer l'information du noeud le plus pertinent, puis s'adresse à ce noeud pour que ce dernier charge le microservice. 20 - dans le cas où, le serveur hôte comprend déjà une information sur un noeud d'exécution pour un microservice donné, et que le microservice n'est pas utilisé (c'est-à-dire que la communication entre le serveur hôte et le microservice n'est pas utilisée), le serveur hôte réutilise ce microservice ; - dans le cas où, le serveur hôte comprend déjà une information sur un 25 noeud d'exécution pour un microservice donné, et que le microservice est utilisé par ce serveur hôte (c'est-à-dire que la communication entre ce serveur hôte et ce microservice est utilisé ou qu'une requête est en cours), le serveur hôte instancie un nouveau microservice pour communiquer avec le noeud d'exécution (tel que dans le cas du premier processus décris ci- 30 dessus). 18 Dans certains modes de réalisation, le procédé comprend en outre une étape de création des alias aux microservices (5) par le développeur (10) pour que le système puisse localiser le ou les microservices (5) à déployer. 5 Dans certains modes de réalisation, lorsque le microservice (5) n'est pas chargé, le système (1) de communication choisit (par exemple via le serveur hôte) le noeud (2) d'exécution qui charge le microservice (5) dans un nouveau chargeur de classe (7) et le référencie dans l'unité (9) distribuée de stockage du système. 10 Dans certains modes de réalisation, le rechargement de microservice (5) se fait soit par le dépôt d'un nouveau microservice avec le même nom de fichier d'exécution, soit par changement d'alias. Dans certains modes de réalisation, le rechargement de microservice (5) entraîne un envoi de message par le système (22) de publication et 15 souscription pour actualiser l'ensemble des actions des noeuds (2) d'exécution du système (1) de communication. Dans certains modes de réalisation, le déploiement ou l'actualisation d'un microservice est réalisé par le développeur qui dépose le microservice (par exemple, par une interface homme machine (IHM) ou une interface de 20 programmation applicative (API) pouvant être intégré dans le noeud d'exécution) dans l'unité de stockage distribué, afin que le système de publication/souscription informe du déploiement ou de l'actualisation des microservices sur l'ensemble des noeuds d'exécution. 25 Le système de communication et le procédé d'accès et de déploiement de microservices éphémères sur une plateforme hétérogène utilisant ce système de communication, selon un des modes de réalisation de la présente invention, permettent au développeur de n'a pas avoir à appréhender les problématiques d'infrastructures techniques sous-jacentes 30 masquées. En effet, le développeur peut simplement déposer le microservice 19 (par exemple un fichier Jar pour du Java ou un fichier simple pour du Javascript) dans un des noeuds d'exécution du système (par exemple par une simple requête HTTP). Le développeur peut ainsi instancier et déployer de façon dynamique l'accès et le déploiement des microservices. Le système 5 de communication permet également de pouvoir déployer sur tout type environnement technique (de la carte ARM avec des architectures matérielles RISC (désignant un processeur à jeu d'instructions réduit) aux serveurs de calcul) supportant un environnement d'exécution Java. Par ailleurs, ce système de communication peut être utilisé dans le domaine de 10 l'internet des objets en limitant les coûts d'investissement (par exemple en investissant sur des composants modulables et réutilisables) et en évoluant de manière sélective. Enfin, le procédé selon l'invention permet un accès et un déploiement sécurisé des microservices sur la plateforme hétérogène de façon entièrement agnostique du média et/ou du réseau d'accès utilisés par 15 le développeur ou l'utilisateur. La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L'homme de métier comprendra que les caractéristiques techniques d'un 20 mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d'un autre mode de réalisation à moins que l'inverse ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne fournisse pas une solution à au moins un des problèmes techniques mentionnés dans la présente demande. 25 De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l'inverse ne soit explicitement mentionné. Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses 30 autres formes spécifiques sans l'éloigner du domaine d'application de 20 l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la protection demandée, et l'invention REVENDICATIONS1. Système (1) de communication comprenant un ou plusieurs noeuds (2) d'exécution apte à exécuter un ou plusieurs microservices (5), un dispositif informatique, dit « serveur hôte » (3), comportant plusieurs routeurs (30) constituant une interface intermédiaire de communication entre chaque noeud (2) d'exécution et l'extérieur du système (1) de communication, une plateforme (4) informatique hétérogène, constituée d'un ensemble (40) de matériel et logiciel ou code exécutable pour l'accès et le déploiement des microservices (5) sur le système dans un environnement (J) d'exécution Java (runtime java) sur le serveur hôte (3) et les noeuds (2) d'exécution permettant l'exécution des programmes informatiques basés sur le langage Java, le système (1) de communication étant caractérisé en ce qu'il permet la création de microservices (5) éphémères par l'utilisation d'un système (6) clef/valeur mémorisé dans un cache (8) mémoire distribué à chaque création en référenciant chaque microservices (5) par des noms de fichier déposés dans le système par un développeur (10) et utilisant un protocole (T) d'échange TCP asynchrone échangeant des notifications contenant des métadatas (M) entre le serveur hôte (3) et chaque noeud (2) d'exécution ; et en ce que chaque noeud (2) mémorise des fichiers (50) d'exécution du ou des microservices (5) comportant l'accès au système (1) par au moins un des deux point d'entrée soit au serveur hôte (3) soit au noeud (2) d'exécution et au moins un chargeur de classe (7) assurant le déploiement des services associés aux microservices (5) qui sont intégrés dans le noeud (2) d'exécution. 2. Système selon la revendication 1, caractérisé en ce que le serveur hôte (3) et les noeuds (2) d'exécution du système, échangent des données de type métadatas (M) comprenant un ou plusieurs des éléments suivants : un alias du microservice (appelé clé), un chemin de localisation d'une méthode particulière dans le microservice, une action associée au chemin de 22 localisation, un code retour d'exécution du microservice et un type de contenu d'exécution du microservice. 3. Système selon la revendication 1 ou 2, caractérisé en ce qu'un outil de développement de microservices constitue une interface développeur et 5 un outil d'envoi dans le protocole utilisé entre le microservice (5) et le serveur hôte (3). 4. Système selon une des revendications 1 à 3, caractérisé en ce que chaque noeud (2) d'exécution comprend en outre des moyens informatiques (21) de gestion des microservices, des moyens informatiques de lecture et 10 d'écriture des fichiers d'exécution disposés dans une unité (9) distribuée de stockage du système (1), et un système (22) de publication et souscription de message lorsqu'un microservice (5) est déposé ou un alias est modifié par le développeur (10) sur le système (1). 5. Système selon une des revendications 1 à 4, caractérisé en ce que 15 chaque noeud (2) d'exécution est apte à exécuter un algorithme prédéterminé dédié à la sélection d'un ou plusieurs noeuds (2) d'exécution du microservice (5) en déterminant un score (valeur) puis en mémorisant l'adresse ou l'alias du microservice (5) et ce score (système clé/valeur) dans le cache (8) mémoire distribué si le score est plus pertinent que le précédent. 20 6. Système selon la revendication 5, caractérisé en ce que l'algorithme prédéterminé exécuté par le noeud (2) d'exécution lance un timeout d'inactivité à chaque détermination de score pour que le serveur hôte (3) réutilise le même noeud (2) d'exécution tant que le microservice (5) est inexploité ou qu'un timeout d'inactivité est levé. 25 7. Système selon une des revendications 1 à 6, caractérisé en ce que le noeud (2) d'exécution choisit par le serveur hôte (3) appelé par le système (1), charge le microservice (5) dans un nouveau chargeur de classe (7) référencé au sein du système (1), dans une HashMap du cache (8) mémoire distribué en fonction de l'alias utilisé dans le message d'échange standardisé. 23 8. Système selon une des revendications 5 à 7, caractérisé en ce que chaque noeud (2) d'exécution sélectionné est apte à remonter des données sous forme de score et d'attribution d'adresse dans le cache (8) mémoire distribué du système (1) de communication attribué à chaque microservices 5 (5) pour que le serveur hôte (3) puisse lire et exploiter ces données. 9. Système selon une des revendications 1 à 8, caractérisé en ce que les routeurs (30) du serveur hôte (3) intègrent des applications basées sur Java et Netty pour assurer des communications multiprotocoles vers l'extérieur du système (1) et des échanges asynchrones en protocole (T) TCP 10 vers les noeuds (2) d'exécution du système (1). 10. Système selon une des revendications 1 à 9, caractérisé en ce que les microservices (5) sont mémorisés au format Jar ou Javascript par le système (1) dans le cache (8) mémoire distribué ; tandis que les fichiers au format Jar sont désarchivés en classes d'utilisation ou d'exécution par le 15 système (1) pour les rendre accessible au chargeur de classe (7) de l'environnement (J) d'exécution Java du noeud (2) d'exécution ; de sorte que ces microservices (5) soit chargés depuis l'unité (9) de stockage distribué en fonction de la demande du serveur hôte (définie par l'alias de service qui permet d'identifier le microservice à charger et le chemin de la requête 20 entrante permettant d'identifier la méthode (java ou javascript) à appeler dans le microservice chargé) ; et les autres formats de fichier sont mémorisés unitairement sur le système clef/valeur (6) pour que l'environnement (J) d'exécution Java puisse lire ou exploiter selon le besoin. 11. Système selon une des revendications 4 à 10, caractérisé en ce que 25 le système (1) est apte à sélectionner un noeud (2) d'exécution pour qu'il charge un microservice (5) dans un chargeur de classe (6) qui est référencié dans l'unité (9) distribuée de stockage en fonction de l'allas utilisé dans le métadatas (M) d'échange. 12.Système selon une des revendications 1 à 11, caractérisé en ce 30 qu'il comporte au moins un code d'accès pour une activation d'appel d'un 24 microservice (5) pour son déploiement sur la plateforme (4), ledit code d'accès est disposé soit au niveau du service permettant l'accès à toutes les ressources du service, soit au niveau d'une ressource du service permettant l'accès à cette unique ressource, ou par au moins une méthode d'accès 5 prédéfinie par un gestionnaire de sécurité du système (1) de communication. 13. Système selon une des revendications 5 à 12, caractérisé en ce que le serveur hôte (3) est configuré à utiliser et réutiliser le même noeud (2) d'exécution, au moyen de l'algorithme spécifique du noeud (2), tant que le microservice (5) est inexploité ou qu'un délai d'inactivité de charge du 10 microservice (5) est levé. 14. Système selon une des revendications 1 à 13, caractérisé en ce que le système clef/valeur (6) et le système de notification sont des systèmes externes au système de communication qui sont intégrés dans un code exécutable du système de communication, ou injectés au moment de 15 l'exécution du système (1). 15. Procédé d'accès et de déploiement de microservices (5) éphémères sur une plateforme (4) informatique hétérogène, par un système (1) de communication selon une des revendications 1 à 14, caractérisé en ce que le procédé comprend les étapes suivantes : 20 dépôt d'un ou plusieurs microservices (5) par le développeur (10) sur un ou plusieurs noeuds (2) d'exécution ; référencement des microservices (5) par le nom de fichier déposé sans son extension dans le système clef/valeur (6) ; - mémorisation des microservices (5), sous forme de fichier (50) 25 d'exécution de type Jar ou Javascript, par le système clef/valeur (6) dans l'unité (9) distribuée de stockage ; - désarchivage en classes d'utilisation ou d'exécution des fichiers d'exécution au format Jar par le système clef/valeur (6) pour les rendre accessibles au chargeur de classe (7) de l'environnement (J) 30 d'exécution Java du noeud d'exécution, et le format JavaScript des 25 fichiers d'exécution sont mémorisés unitairement sur le système clef/valeur (6) pour que l'environnement (J) d'exécution Java puisse lire ou exploiter selon le besoin ; chargement des classes associées aux microservices (5) par les 5 chargeurs de classe (7) des noeuds (2) d'exécution à charger ; déchargement des microservices (5) par les noeuds (2) d'exécution lorsque les microservices (5) sont inexploités ou que le délai d'inactivité de charge du ou des microservices (5) est levé. 16. Procédé selon la revendication 15, caractérisé en ce que l'étape de 10 déchargement des microservices (5) comprend une sélection par le serveur hôte (3) des noeuds (2) d'exécution du microservice (5) à charger et chaque noeud (2) d'exécution remonte des données sous forme de score et d'adresse d'attribution du microservice (5) dans le cache (8) mémoire distribué du système (1) de communication pour que le serveur hôte (3) puisse lire et 15 exploiter ces données. 17. Procédé selon la revendication 15 ou 16, caractérisé en ce qu'il comprend en outre une étape de création des alias aux microservices (5) par le développeur (10) pour que le système (1) puisse localiser le ou les microservices (5) à déployer. 20 18.Procédé selon une des revendications 15 à 17, caractérisé en ce que lorsque le microservice (5) n'est pas chargé, le système (1) de communication choisit le noeud (2) d'exécution qui charge le microservice (5) dans un nouveau chargeur de classe (7) et le référencie dans l'unité (9) distribuée de stockage du système (1). 25 19. Procédé selon la revendication 17 ou 18, caractérisé en ce que le rechargement de microservice (5) se fait soit par le dépôt d'un nouveau microservice (5) avec le même nom de fichier d'exécution, soit par changement d'alias. 20. Procédé selon une des revendications 15 à 19, caractérisé en ce 30 que le rechargement de microservice (5) entraîne un envoi de message par le 26 système (22) de publication et souscription pour actualiser l'ensemble des actions des noeuds (2) d'exécution du système (1) de communication.