Brevet FR3087916A1 — publié le 20200501

Procédé de traitement d'un code source, dispositif, système et programme correspondant. 1. Domaine L'invention se rapporte au domaine du traitement de code informatique. L'invention se rapporte plus particulièrement au traitement de codes appelés scripté. Il s'agit de code interprétable et/ou exécutable par l'intermédiaire d'une machine virtuelle ou d'un interpréteur. Plus spécifiquement encore, le domaine de l'invention est celui de l'optimisation de l'exécution de code scripté au sien d'un environnement d'exécution dynamique. 2. Art Antérieur Il est fréquent, notamment dans un cadre institutionnel ou en entreprise, de disposer d'architectures de systèmes d'information complexes, impliquant la mise en oeuvre de nombreux dispositifs (ordinateurs, serveurs, dispositifs mobiles), interconnectés par un ou plusieurs réseaux de communications. Au sein de telles organisations, le nombre de dispositifs connectés entre eux ne cesse de croître et la maintenance de ces architectures matérielles et logicielles coûte chère. Pour tenter d'économiser sur ces coûts, les entreprises font également appel à des services dit de « cloud », afin par exemple de mettre en oeuvre des solutions de type SaaS (de l'anglais pour « Software as a Service ») ou AaaS (de l'anglais pour « Application as a Service »). Bien que pouvant effectivement limiter les coûts de maintenance liés à des architecture détenues en propre, ces solutions ne sont pas exemptes d'autres contraintes (notamment au niveau de la sécurisation des données ou de la performance). Pour ce qui est de la performance, quelle que soit la solution retenue par l'organisation, celle-ci est souvent appréciée à l'aune des attentes des utilisateurs. Lorsque l'organisation possède son infrastructure, le besoin en performance, notamment pour l'exécution d'application serveur ou client-serveur, nécessite l'achat de matériels toujours plus puissants, disposants de toujours plus de ressources (processeurs, quantité de mémoire, disques rapides), afin de répondre aux besoins rencontrés par les utilisateurs. Or il se trouve que bien que certaines applications ou certains programmes sont effectivement en mesure d'utiliser pleinement les ressources mises à disposition par les nouveaux matériels, d'autres en sont souvent incapables. En effet, les programmes et applications peuvent être divisés en deux grandes catégories (dans la suite on ne parle plus que de programmes). La première est celle des programmes compilés ; Il s'agit de programmes dont le code source (par exemple écrit dans le langage C, C#, C++, Pascal, etc.) est transformé, par l'utilisation d'un ou plusieurs compilateur et/ou un ou plusieurs optimiseurs en un code exécutable pour une 2 plateforme donnée (une plateforme s'entendant comme une architecture de processeur et/ou un système d'exploitation). Ces programmes compilés sont efficaces en ce qu'ils sont capables de tirer parti de l'ensemble des ressources fournies par la plateforme sur laquelle ils s'exécutent. Cette efficacité tire son origine sur les nombreux travaux publiés permettant d'optimiser un code binaire 5 en fonction des plateformes de destination (par exemple utilisation de tous les coeurs de processeur disponible, parallélisation, utilisation commune de la mémoire, etc.). La deuxième catégorie est celle des programmes interprétés ; il s'agit de programmes dont le code source est interprété avant d'être exécuté. Parmi les langages de programmation populaires de ce type on trouve par exemple le PHP, le Javascript, ou encore le bytecode Java. Dans le cadre 10 de l'invention, on utilise le terme code scripté pour se référer au code d'un programme écrit dans un langage de ce type. L'avantage des programmes écrits dans ces langages est qu'ils sont multiplateformes : le code scripté du programme s'exécute de la même manière sur différents types de plateforme. Seul l'interpréteur est optimisé pour une plateforme donnée. Ceci facilite grandement la diffusion des programmes. En revanche, les performances de ce type de programme 15 sont souvent moins bonnes que celles des programmes binaires, même en réalisant une compilation dynamique. Et pour cause, bien que de nombreux travaux aient été conduits pour améliorer le fonctionnement des interpréteurs et des machines virtuelles, ceux-ci n'ont pas toujours conduits à des résultats totalement satisfaisants. Par exemple, le langage javascript permet d'écrire des programmes (scripts) qui sont 20 exécutés par un moteur Javascript (ou interpréteur Javascript). Un tel moteur est soit intégré au sein d'un navigateur Web (FirefoxTM, ChromeTM, EdgeTM, Opéra TM) soit mis en oeuvre séparément au sein d'un interpréteur dédié (par exemple Node.js'"). Comme pour d'autres langages, le code javascript est historiquement un langage s'exécutant dans un environnement mono-thread (c'est-à-dire que tous les événements s'effectuent les uns après les autres). Lorsqu'une fonction longue 25 est mise en oeuvre par l'interpréteur, celui-ci n'est pas nécessairement disponible pour effectuer d'autres tâches tant que la fonction n'est pas terminée. Bien entendu, avec les récentes évolutions intégrées au sein des interpréteurs, il est possible de créer des flots d'exécution isolés via des interfaces disponibles (par exemple les « webworkers » dans les navigateurs) ou dans Node.js (webworkers, child.spawn/fork). Ainsi, des solutions existent théoriquement pour réaliser un appel 30 de fonction déporté au sein d'un flot d'exécution différent du flot principal. Cependant, la problématique principale réside dans la portée du code exécuté dans un autre flot d'exécution. En effet, pour pouvoir fonctionner correctement, ces solutions existantes, telles que celles 3 mentionnées précédemment doivent être intégrées au sein du code source scripté lors de son écriture par le développeur. Par exemple, l'appel à un webworker doit être prévu à l'avance par le développeur du programme qui doit donc savoir, en avance de phase, que le programme est susceptible de s'exécuter sur une longue période et qu'il est donc nécessaire de prévoir un ou 5 plusieurs flots d'exécution pour l'exécution du programme. Chaque flot d'exécution (chaque webworker) implémente un code qui lui est propre (et défini par un fichier javascript particulier). Il n'y a donc pas de dynamicité de la création d'un webworker et encore moins de répartition dynamique de charge. Par ailleurs, les flots d'exécution sont indépendants les uns des autres. Cela signifie que ces dernières ne permettent pas de gérer à la fois la correspondance des objets entre 10 appelant et appelé car les solutions existantes effectuent des recopies d'objets (lorsqu'elles en effectuent), et ne permettent pas non plus de gérer l'étendue de l'applicabilité des variables et des fonctions au sein des différents flots d'exécution. Il existe donc un besoin de fournir une solution qui ne pose pas les problèmes précédemment mentionnés et permette de tirer parti de plus de ressource disponible au sein des 15 infrastructures de traitement de l'information. 3. Résumé La méthode proposée par les inventeurs ne pose pas ces problèmes de l'art antérieur. En effet, il est proposé un procédé d'exécution d'un code scripté d'une application, procédé mis en oeuvre par l'intermédiaire d'un dispositif électronique, appelé ressource appelante (ResA, A), au 20 sein de laquelle ladite application est exécutable. Selon l'invention, un tel procédé comprend : une étape d'obtention (20) du code scripté de l'application (PCP) comprenant un ensemble d'objets projetables, un objet projetable de l'ensemble d'objets projetables comprenant au moins une fonction exécutable auprès d'une ressource d'exécution de destination (resX, B) ; 25 - une étape de préparation d'une structure de données de transmission (PCP#, heap) d'au moins un objet projetable dudit code scripté préalablement obtenu, ladite structure de données de transmission associant à chaque objet projetable du code scripté, au moins une donnée d'indexation ; une étape de transmission (40), à une ressource d'exécution de destination, de la structure 30 de données de transmission (PCP#, heap) du code scripté; et 4 postérieurement à l'exécution (50), par la ressource d'exécution de destination, d'au moins une fonction dudit au moins un objet projetable de la structure de données de transmission : une étape de réception (60) d'une structure de données (ExObj, diff) de résultats 5 d'exécution de ladite au moins une fonction ; une étape d'intégration de résultats d'exécution de la structure de données de résultats d'exécution au sein de la ressource appelante . Ainsi, l'invention rend possible l'exécution, sur de multiples ressources, d'un code source scripté, sans nécessiter, sur les ressources distantes (ressource d'exécution de destination), la mise 10 en oeuvre d'un processus différent de celui mis en oeuvre usuellement pour l'exécution d'un code scripté par l'une de ces ressources d'exécution de destination. Selon une caractéristique particulière, l'étape d'intégration de résultats d'exécution de la structure de données de résultats d'exécution au sein de la ressource appelante comprend une vérification différentielle de l'intégrité des données mise à jour au cours de l'exécution (50), par la 15 ressource d'exécution de destination. Ainsi, il est possible, au sein de la ressource appelante, de s'assurer que les résultats d'exécution distants ne viennent pas en opposition avec d'autres ressources (locales ou de destination) qui auraient pu modifier les mêmes données préalablement à la réception de ces données modifiées par la ressource d'exécution de destination. On évite donc ainsi de propager ou 20 d'intégrer des incohérences dans les données traitées lorsque celles-ci sont au moins partiellement traitées à distance. Selon une caractéristique particulière, l'étape d'obtention du code scripté comprenant un ensemble d'objets projetables comprend : une étape d'obtention (10) d'un code source scripté (CSSE), représentatif de l'application à 25 exécuter par la ressource appelante (ResA, A) ; une étape de détermination, au sein du code source scripté (CSSE), d'au moins une fonction susceptible d'être exécutée par une ressource d'exécution de destination, dite fonction projetable ; une étape de modification du code source scripté, délivrant un code scripté d'exécution 30 comprenant ledit ensemble d'objets projetables, en fonction de ladite au moins une fonction projetable préalablement déterminée. 5 Ainsi, le code source scripté n'est pas directement transmis aux ressources pour être exécuté. A la place, il est analysé de manière à déterminer quelles sont les portions de code qui sont susceptibles d'être projetées vers des ressource d'exécution de destination, éventuellement en modifiant le code source scripté lui-même. 5 Selon un mode de réalisation particulier, en ce que l'étape de préparation d'une structure de données de transmission d'au moins un objet projetable dudit code scripté comprend une étape de création d'un tableau d'indexation (refA), pour chaque objet projetable (OA, XA) à transmettre à une ressource d'exécution de destination (ResX, B), tableau au sein duquel un index (0, 1, ...) est associé à une référence d'objet (RefXA, RefXA,...) ; 10 - une étape de création de la structure de données de transmission (PCP, heap) sous la forme d'un tableau comprenant, pour chaque objet projetable, un index (0, 1, ...), correspondant à l'index (0, 1, ...) de la référence de cet objet projetable au sein du tableau d'indexation (ref,,), et une représentation sérialisée (r0, r1, ...) de l'objet projetable ; Ainsi, en utilisant deux structures de données différentes, du côté de la ressource 15 appelante, pour indexer le code scripté d'exécution qui est transmis, on assure qu'il est possible, lorsque le code exécuté par la ressource destination est terminé, de retrouver une correspondance d'objet identique à celle qui a été transmise, et donc on permet une vérification des données reçues en provenance de la ressource d'exécution de destination. Selon un mode de réalisation particulier l'étape de réception d'une structure de données 20 de résultats (ExObj, diff) d'exécution de ladite au moins une fonction comprend : une étape de réception, de la structure de données de transmission (PCP#, heap) préalablement transmise, sous la forme d'un tableau comprenant, pour chaque objet projetable, un index (0, 1, 2,...), correspondant à l'index (0, 1, 2,...) de la référence de cet objet projetable au sein d'un tableau d'indexation (refB) de la ressource d'exécution de 25 destination (ResX, B), et une représentation sérialisée (r0, r1, r2...) de l'objet projetable ; une étape de réception, de la structure de données de résultats d'exécution (ExObj, diff) sous la forme d'un tableau comprenant, pour chaque objet projetable de la structure de données de transmission (PCP, heap) préalablement transmise, un index (0, 1, 2,...) et et une représentation sérialisée (r'O, r'1, ...) des modifications effectuées par ladite au moins 30 une fonction exécutée par la ressource d'exécution de destination (ResX, B). Ainsi, il est possible de suivre l'évolution (les modifications) réalisée sur les données, indépendamment de la structuration des données transmises, tout en conservant l'indexation 6 effectuée en entré du processus lors de la création des données à destination de la ressource d'exécution de destination. Selon une caractéristique particulière, l'étape d'intégration de résultats d'exécution de la structure de données de résultats d'exécution (ExObj, diff) au sein de la ressource appelante 5 comprend : une étape de mise à jour, au sein de la ressource appelante (ResA, A), d'une liste d'objets, la mise à jour comprenant une création d'un nouvel objet lorsque qu'un objet absent de la structure de données de transmission a été créé par la ressource d'exécution de destination au cours de l'exécution (50); 10 - une étape de mise à jour des valeurs des objets de la liste d'objets, comprenant une vérification de la cohérence des valeurs à mettre à jour en fonction des valeurs d'origine contenues dans la structure de données de transmission. Ainsi, on rend possible la vérification de la préservation de la sémantique, tant sur le code que les données transmises et retournées par la ressource d'exécution de destination. 15 Selon une caractéristique particulière, l'étape de modification du code source scripté, délivrant un code scripté d'exécution comprenant ledit ensemble d'objets projetables, en fonction de ladite au moins une fonction projetable préalablement déterminée comprend : une étape de détermination d'au moins un contexte d'exécution de ladite application, en fonction du code source scripté (CSSE), ledit contexte d'exécution de ladite application 20 comprenant, pour chaque variable et/ou objet du code source scripté (CSSE), une représentation d'une variable et/ou objet correspondant, accessible et/ou modifiable lors de la projection vers une ressource d'exécution de destination, ledit contexte d'exécution tenant compte de la portée de chaque variable et/ou objet du code source scripté (CSSE); une étape de construction du code scripté (PCP) en fonction du code source scripté (CSSE) 25 et dudit contexte d'exécution préalablement déterminé. Ainsi, on assure que le code projeté vers la ressource d'exécution de destination peut s'exécuter avec un contexte identique à celui de la ressource locale. Au final, cela permet d'assurer un fonctionnement plus efficace des codes projetés, en minimisant les éventuelles opérations d'invalidation d'exécution. 30 Il est entendu, dans le cadre de la description de la présente technique selon l'invention, qu'une étape de transmission d'une information et/ou d'un message d'un premier dispositif à un deuxième dispositif, correspond au moins partiellement, pour ce deuxième dispositif à une étape 7 de réception de l'information et/ou du message transmis, que cette réception et cette transmission soit directe ou qu'elle s'effectue par l'intermédiaire d'autres dispositifs de transport, de passerelle ou d'intermédiation, y inclus les dispositifs décrits dans la présente selon l'invention. Selon un autre aspect, l'invention se rapporte également à un dispositif électronique 5 d'exécution d'un code scripté, appelé ressource appelante. Un tel dispositif comprend : des moyens d'obtention du code scripté comprenant un ensemble d'objets projetables, un objet projetable de l'ensemble d'objets projetables comprenant au moins une fonction exécutable auprès d'une ressource d'exécution de destination ; des moyens de préparation d'une structure de données de transmission d'au moins un 10 objet projetable dudit code scripté préalablement obtenu, ladite structure de données de transmission associant à chaque objet du code scripté, au moins une donnée d'indexation ; des moyens de transmission à une ressource d'exécution de destination, de la structure de données de transmission du code scripté; et des moyens de réception d'une structure de données de résultats d'exécution, mis en 15 oeuvre postérieurement à l'exécution, par la ressource d'exécution de destination, de la structure de données de transmission ; des moyens d'intégration de résultats d'exécution de la structure de données de résultats d'exécution. L'invention se rapporte également, selon un aspect complémentaire, à un système 20 d'exécution d'un code scripté. Un tel système comprend au moins une ressource appelante prenant la forme d'un dispositif électronique d'exécution tel que décrit précédemment et au moins une ressource distante, prenant la forme d'une ressource d'exécution de code scripté accessible depuis la ressource appelante. Selon une implémentation préférée, les différentes étapes des procédés selon l'invention 25 sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif d'exécution selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en oeuvre au niveau du terminal de communication, du dispositif électronique d'exécution et/ou du serveur distant, dans le cadre d'une répartition des traitements à effectuer et 30 déterminés par un codes source scripté. 8 En conséquence, l'invention vise aussi des programmes, susceptibles d'être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus. Un programme peut utiliser n'importe quel langage de programmation, et être sous la 5 forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker 10 le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal 15 électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution 20 du procédé en question. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. 25 Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, 30 routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). 9 De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit 5 intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour 10 la mise en oeuvre de l'invention. 4. Figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : 15 la figure 1 décrit un système dans lequel l'invention est mise en oeuvre ; la figure 2 décrit une situation de perte de correspondance entre objets pour l'exécution déportée d'un code scripté ; la figure 3 décrit un mode de réalisation spécifique du procédé de traitement de code scripté; 20 - la figure 4 illustre la problématique de portée des variables au sein d'un code scripté; la figure 5 illustre une architecture d'une ressource appelante apte à mettre en oeuvre un procédé de traitement de l'invention ; la figure 6 illustre une architecture d'une ressource d'exécution de destination apte à mettre en oeuvre un procédé de traitement de l'invention. 25 5. Description 5.1. Exposé des principes techniques Comme indiqué précédemment, un objet de l'invention est de permettre une utilisation efficace de ressources d'exécutions disponibles au sein d'une infrastructures, dans le cadre d'exécution de programmes scriptes par un interpréteur ou une machine virtuelle. Plus 30 particulièrement, l'invention rend possible l'exécution, à distance ou localement, dans une pluralité de flots d'exécution (un flot d'exécution faisant partie du groupe comprenant un thread processeur, un processeur, un coeur de processeur, un thread de langage scripté, un contexte d'exécution d'une 10 séquence d'instructions), d'une ou plusieurs portions d'applications. Ainsi, l'invention permet une intégration dynamique de ressources d'exécution (serveurs, ordinateurs personnels, smartphones et tablettes) et l'allocation dynamique de portions d'applications aux ressources d'exécution nouvellement intégrées. 5 L'invention apporte une solution simple et efficace aux problématiques précédemment mentionnées. Notamment, dans le cadre d'un environnement mono-serveur, l'invention offre la possibilité d'utiliser de manière automatique, l'intégralité des ressources disponibles au sein de ce serveur (en utilisant l'intégralité des coeurs de processeurs disponibles). L'identification des portions de code à distribuer est quant à elle soit automatique, soit manuelle. Dans le cadre d'une 10 utilisation multiserveurs, l'invention permet de distribuer des portions de codes exécutables entre plusieurs serveurs afin de mettre en oeuvre les ressources d'exécution disponibles au sein de ces serveurs. En troisième lieu, l'invention permet également de distribuer de portions de codes exécutables sur différents dispositifs (ordinateurs personnels, tablettes, smartphones) connectés par l'intermédiaire d'un ou plusieurs réseaux de communication. 15 Pour ce faire, l'invention est basée sur la mise en oeuvre d'un module logiciel spécifique, lequel est utilisé en mode supervisé ou en mode pair à pair. Dans le mode de réalisation décrit par la suite, le mode supervisé est détaillé. On décrit, en relation avec la figure 1, une mise en oeuvre générale d'un traitement de code scripté implémentant la technique de l'invention. Le module logiciel spécifique (XStrmr), qui s'exécute sur une ressource appelante (ResA), comprend une unité 20 de compilation (ComU) et une unité d'allocation (AllocU). Ce module logiciel (XStrmr) : Prend (10) en entrée un code source scripté à exécuter (CSSE); Analyse (20) le code source scripté à exécuter (CSSE) et recherche et/ou construit des portions de code projetables (PCP) qui peuvent faire l'objet d'une projection à destination 25 d'une ressource d'exécution destinatrice (ResX) (dispositif séparé ou coeur spécifique d'un dispositif d'exécution multicceurs); ces deux premières étapes sont mises en oeuvre par l'unité de compilation (ComU) Identifie (30) une ou plusieurs ressources d'exécution (ResX) aptes à exécuter les portions de code projetables (PCP); 30 - lorsque les portions de codes et les ressources disponibles sont identifiées (et/ou construites), il projette (40) ces portions de code projetables (PCP), vers une ou plusieurs ressources d'exécution (ResX) préalablement identifiées ; 11 Les ressources identifiées implémentent elles-mêmes une pluralité des fonctions précédemment décrites, et donc une portion au moins du module logiciel (XStrmr) décrit, voire l'intégralité de celui-ci ; Les ressources d'exécution (ResX) exécutent (50) les portions de code projetées (PCP); 5 Les résultats d'exécution (ExObj) de ces portions de codes (PCP) par les ressources disponibles sont transmis (60) au module logiciel appelant (XStrmr); Le module logiciel appelant (XStrmr) traite (70) les résultats reçus. Ces cinq dernières étapes sont mises en oeuvre par l'unité d'allocation (AllocU). Les flots d'exécutions sont initialisés avant la transmission des portions de code 10 projetables. Cela signifie que lorsqu'une portion de code projetable est transmise, un flot d'exécution apte à exécuter ce code projetable a déjà été initialisé. Ainsi, d'une manière générale, la ressource appelante est à même de décomposer et/ou modifier (automatiquement ou pas) l'application d'origine, en portions (morceaux) exécutables indépendamment, puis est à même de transmettre ces portions (et leur contexte d'exécution) à 15 une ressource identifiée, laquelle exécute cette portion, à l'aide du contexte transmis, et renvoie le résultat à la ressource appelante pour traitement. Plus particulièrement, selon l'invention, on met notamment en oeuvre une méthode de gestion des flots d'exécution, méthode qui comprend un processus de sauvegarde de la portion de code (avant sa transmission à la ressource destinatrice) et un processus de gestion des portées (de variables notamment, également appelé 20 processus de gestion des scopes) et ce afin d'assurer une cohérence d'exécution du code dans la ressource destinatrice. Ces deux processus permettent de certifier que les portions de codes exécutées par la ressource distante préservent la sémantique, tant sur le code que les données (et donc qu'ils fournissent un résultat qui est identique à celui qui aurait été obtenu si ces portions avaient été exécutées par la ressource appelante). 25 Plus précisément, la méthode de gestion de flots d'exécution est mise en oeuvre, au sein du module logiciel précédemment présenté, à l'aide des unités de compilations et des unités d'allocations. Cette méthode de gestion de flots d'exécution permet de conserver, dans les différents flots créés pour la projection des portions de code, un référentiel d'exécution unifié, lequel est utilisé pour assurer une unicité de l'exécution. En d'autres termes, selon l'invention, 30 l'exécution des différentes portions de codes projetées dans les flots d'exécution parallélisés est transparente pour l'application. Cette dernière ne sait pas qu'elle fait l'objet d'une décomposition en plusieurs portions exécutées indépendamment par différentes ressources, au sein de différents 12 flots d'exécution : de son point de vue, tout se déroule comme si le traitement avait été réalisé au sein d'un seul et unique flot d'exécution. Cela est avantageux à plus d'un titre. Notamment, n'importe quelle application peut être exécutée par le module logiciel objet de la présente technique. Il n'est notamment pas nécessaire de d'écrire l'application de manière spécifique. Une 5 interface d'aide à la décomposition peut être mise en oeuvre ultérieurement afin de guider les décompositions. Cependant, le développeur se contente d'écrire l'application comme il le souhaite, en fonction des exigences qui lui sont propre. Le module logiciel analyse le code de l'application, en fonction de paramètres d'analyse spécifique et détermine seul les portions de code (fonctions, procédure, modules) à projeter dans des flots d'exécution parallèles. Le développeur n'a pas à 10 apprendre une interface ou à développer selon une façon précise. En d'autres termes, afin de 'paralléliser' un programme, lors du chargement du programme, l'unité de compilation identifie (et/ou construit) les fonctions potentiellement parallélisables et génère les instrumentations nécessaires afin qu'elles puissent être soumise à l'unité d'allocation. 15 Pour l'exécution l'unité d'allocation s'appuie sur trois blocs fonctionnels (ces blocs pouvant potentiellement être intégrés au sein d'un seul et même programme) : service, master et runner. Un runner matérialise les flots. Le master la stratégie de placement de fonctions projetables. Le service fournit le code à exécuter dans le cluster. Afin d'exécuter une fonction sur une ressource d'exécution de destination : 20 le service est en charge du début et de la fin de l'exécution des fonctions projetables. Pour l'exécution, il définit un travail (job) qui contient les données nécessaires à l'exécution de la fonction (paramètre d'entrée, scope d'exécution, système objet sérialisé, code de la fonction) sous la forme d'une structure de données de transport et la transmet au master. 25 le master est en charge du placement des différents travaux (jobs) sur les runners. Il gère une queue d'attente et d'exécution des fonctions projetables (transportées). un runner permet d'exécuter un ou plusieurs jobs en parallèles sur une ressource (par exemple un nodejs, ou un navigateur, un serveur, un cluster, etc.). une fois la fonction exécutée, le ru nner effectue un travail de différentiation, ajoute 30 les paramètres de sortie et communique au master la fin de l'exécution du job (le travail de différentiation est notamment effectué à l'aide d'une structure de 13 donnée de différentiation comme cela est explicité par la suite en lien avec un mode de réalisation). le master retire de la file d'exécution de job et indique au service qu'il est terminé ; le service valide les propriétés ACID (à moins qu'elles ne s'appliquent pas), les 5 propriétés d'ordre et met à jour l'espace des objets. Un mode de réalisation spécifique de la technique proposé est décrit par la suite en lien avec le langage scripté « javascript ». Il est bien entendu que ce mode de réalisation dans le cadre du langage javascript est présenté à titre d'exemple et qu'il n'est nullement limitatif de la technique en elle-même, qui peut d'une manière générale être mise en oeuvre dans tout langage scripté ou 10 interprétable, tels PHP, ou encore du bytecode (java ou autre). D'une manière générale, selon l'invention, le code scripté est découpé/modifié/structuré, en une ou plusieurs passes, par l'unité de compilation du module logiciel. Une fois structuré en portions de code projetable, l'unité d'allocation du module logiciel décide, à la volée, de l'exécution de portions de code à l'aide d'autres ressources disponibles. Ainsi, préalablement, on considère 15 que le module logiciel est à même d'obtenir ou de détecter une ou plusieurs ressources disponibles, localement ou à distance. La manière dont cette détection est effectuée ne fait pas partie de l'objet de l'invention. La seule caractéristique importante étant qu'un serveur (par exemple la ressource locale) a connaissance des ressources disponibles. Sur la base du code découpé en portions projetables et de la pluralité de ressources 20 disponibles, le module logiciel : identifie au moins une ressource d'exécution de destination ; définit localement une structure d'échange de données, cette structure d'échange comprenant au moins une liste de pointage et une liste d'objets ; sérialise la structure d'échange ; 25 transmet la structure d'échange sérialisée à la ressource d'exécution de destination. - traite les résultats reçus de la part de la ressource d'exécution de destination, ces résultats étant compris dans structure d'échange de données initiale, retransmise par la ressource d'exécution de destination, et une structure de différences, listant les modifications effectuées. 30 On note que les opérations précédemment définies, notamment l'opération d'identification de la ressource de destination peut être réalisée en amont, tout comme la définition de la structure de données d'échange. 14 En d'autres termes, la technique ci-dessus consiste en une modification de la sérialisation, laquelle ne consiste plus à transmettre les objets sérialisés tels quels, mais bien à transmettre une structure de données différente, issues des objets à transmettre, cette structure de données est construite par la ressource appelante, sur la base des objets (et fonctions) à projeter, puis est elle- 5 même transmise à la ressource d'exécution de destination. La ressource d'exécution de destination créée l'ensemble des objets sur la base de cette structure de données projetée et met à jour cette structure projetée (lorsque les fonctions ou objets modifient des valeurs attachées) et créée une structure de données complémentaire de différence, qui dresse le bilan des données modifiées au cours de l'exécution des fonctions. Lorsque les traitements sont terminés, ces deux structures de 10 données (la structure d'origine et la structure des différences), sont retournées à la ressource appelante, qui sur la base des modifications réalisées, effectue les mises à jour des objets (et le leurs données) pour refléter l'exécution qui a eu lieu au sein de la ressource d'exécution de destination (lorsque certaines propriétés sont à respectées et sont respectées bien sûr, par exemple les propriété ACID, telles que décrites ci-dessous). 15 La structure de données est construite par exemple par sérialisation. La sérialisation permet de construire une structure de donnée indépendante machine transférable sur un protocole réseau et après la réception, réaliser une instanciation afin de reconstruire la structure de donnée d'origine Selon la présente technique, les traitements de décomposition, identification, création, projection et traitement des résultats sont mis en oeuvre de manière itérative et/ou récursive tout 20 au long de l'exécution de l'application. 5.2. Description d'un mode de réalisation Dans ce mode de réalisation, on décrit l'implémentation des principes techniques précédemment décrit au langage javascript. Plus particulièrement, on décrit la manière dont on gère, pour le langage Javascript, les contextes d'exécution, la gestion de la portée, et la 25 conservation des propriétés ACID du code exécuté. 5.2.1. Support d'exécution dans des flots différents Les moteurs Javascript permettent la création de flot d'exécution isolés via des interfaces disponibles dans les navigateurs (par exemple les webworkers) ou dans Node.js (webworkers, child.spawn/fork). La méthode décrite ici permet de réaliser un appel de fonction depuis un flot 30 d'exécution A dans un second flot d'exécution B qu'il soit local (sur le même ordinateur) ou distant (sur un autre ordinateur) tout en conservant un contexte d'exécution unifié. La méthode permet 15 de fournir des fonctionnalités d'exécution déportée unifiée et ouvre le champ d'application de l'exécution distante à toute fonction et sans limitation. 5.2.1.1. Correspondance des systèmes objets A la base, pour permettre une exécution unifiée, il est nécessaire de disposer d'une solution 5 de suivi des modifications réalisées sur les objets par la fonction appelée et maintenir les systèmes objets du flot A et du flot B en correspondance. Lorsqu'un flot Javascript A créé un flot B, les flots d'exécution sont isolés dans le sens ou, aucune propriété ou objets de A ne sont accessibles par B. Le seul moyen pour A de communiquer des propriétés ou des objets à B est d'utiliser un moyen de communication entre A et B (IPC). Les 10 données transmises par A sont ainsi recopiées dans l'espace de B. B peut les utiliser comme bon lui semble car il n'y a pas de lien entre les données de A et les données de B. Réciproquement B peut utiliser un IPC pour communiquer à A des propriétés ou objets. Afin de transmettre des objets, on effectue une sérialisation de ceux-ci, puis une fois reçus par le flot d'exécution destinataire, on en effectue une instanciation dans ce flot destinataire. Sur 15 la figure 2, un flot A veut communiquer au flot B l'objet Oa, contenant les propriétés pl (numérique 12) et p2 (une référence sur un objet Xa). Xa contenant une propriété pl (numérique 13). La sérialisation (Sr) de l'objet Oa est effectuée, ainsi que celle de Xa (par exemple en utilisant l'appel JSON.stringify(Oa)). Une fois reçu, les objets sont instanciés (lnst) en Ob et Xb (par exemple en utilisant l'appel eval ou JSON.parse). 20 Il est intéressant de noter que cette façon de faire qui est utilisable en Javascript permet d'échanger des objets, mais elle a le désavantage majeur et limitatif de perdre la correspondance des objets entre les flots A et B. Par exemple, le flot B ne sait pas (n'a aucune connaissance du fait) que Ob correspond à Oa, et que Xb correspond à Xa. La technique mise en oeuvre par les inventeurs créée l'illusion que la fonction qui s'est 25 exécutée dans le flot B s'est exécuté dans le flot A. Aussi il est possible de maintenir une équivalence des objets pour pouvoir mettre à jour les modifications des objets au sein des vrais objets du flot A. Pour ce faire les inventeurs ont défini une solution qui étend la sérialisation et l'instanciation afin de préserver ces liens. Cette solution comprend plusieurs étapes, illustrées en relation avec la figure 3. Les éléments textuels de la figure 3 ne constituent pas un texte, mais du code, et ne nécessitent 30 donc pas de traduction. En figure 3, on présente (à gauche l'état des objets dans le flot d'exécution A. L'étape 0 (S0) consiste en une extension de la sérialisation : 16 Pour chaque objet, un indice (0a-> 0 et Xa->1) est attribué ; Un tableau refA enregistre (sauvegarde) la référence de l'objet (ref[0] = refOa et ref[1] = refXa) Un autre tableau heapA enregistre (sauvegarde) le contenu de chaque objet, et si 5 c'est un autre objet l'indice de cet objet (heapA[0]={p1:{type:"number", value:12}, p2:{type:"object", index:1}} et heapA[1] = {pl:{type:"number", value:13}} Ainsi refA [0] et heap' [0] sont associés à Oa et refA [1] et heap' [1] sont associés à Xa. Lors de la communication (sérialisation) effectuée entre A et B, seul heapA est transmis. Sur la figure, le tableau heap n'est représenté qu'une seule fois pour plus de clarté dans la 10 présentation. L'étape 1 (Si) correspond à l'étape d'instanciation des objets au sein du flot B. Sur B: refB est mis à vide (refB=[]), puis le heapA reçu (qui devient donc heapB du point de vue du flot B) est parcouru pour tous les éléments. Pour chaque élément un nouvel objet est instancié et la référence est stocké dans l'index correspondant dans ret. 15 Ainsi, après instanciation, le contenu du tableau refB du flot B permet de faire une correspondance avec le contenu de refA du flot A (on sait par exemple que refB[1] sur B désigne refA[1] sur A). A ce stade, le flot B est en mesure d'exécuter une ou plusieurs fonctions présentes au sein des objets Ob ou Xb. Ces fonctions, pour l'exemple décrit ici lisent et/ou modifient les nouveaux 20 objets (Ob, Xb) et paramètres instanciés. Par exemple, le flot B change Ob.pl de la valeur 12 à la valeur 24 et associe à Ob.p2 un nouvel objet Yb. Par ailleurs Xb.pl est modifié de la valeur 13 à la valeur 243. Pour ce faire, le flot B utilise le heap reçu de la part de A. Soit A a supprimé le heap de son côté, soit A a conservé le heap de son côté, en fonctions des conditions de mise en oeuvre opérationnelles. 25 L'étape 2 (S2) réalise un calcul des différences (suite à l'exécution des fonctions) : Une fois la ou les fonctions exécutées, il est possible de parcourir le tableau refA et de vérifier grâce à la heapB si une propriété d'un l'objet (Ob, Xb) a changé ou pas. Lors de ce parcours on crée ainsi un tableau diffa qui contiend la liste des différences. Dans le cas d'un changement vers un nouvel objet, un nouvel indice est créé dans heapa afin de matérialiser 30 le nouvel objet. Le tableau diffa contient ainsi pour l'objet 0 la nouvelle valeur pour pl (c'est-à-dire 24) et le nouvel index (2) de l'objet créé dans heapB pour p2 (refYb). Il contiendra aussi la nouvelle valeur de la propriété pl de Xb (à savoir 243). 17 A supposer que Ob contienne une autre propriété (p3) et que sa valeur est inchangée, elle ne sera pas décrite dans le tableau diffa. Le tableau diffa ne contient que les modifications sur les objets (ajout d'objet, modification d'objet (modification d'une propriété, suppression ou ajout d'une propriété). 5 Une fois le calcul des différences et la mise à jour de heapB réalisée, diffa et heaps sont transmis au flot A (c'est-à-dire qu'il est sérialisé et transmis au flot appelant A). On peut également ne transmettre diffa que et se contenter de conserver heapa sur la ressource appelante (c'est-à-dire qu'on ne retransmet pas heapB en même temps que diffB à la fin de l'exécution sur le flot B, on ne retransmet que diff. : cela allège les transmissions, mais cela 10 met une pression mémoire plus importante sur la ressource appelante). L'étape 3 (S3) instanciation des nouveaux objets sur A : Lors de la réception de diffB, A (Etape 3) instancie tous les nouveaux objets insérés dans heap,,, et ajoute les références dans le tableau refA. Les propriété ACID des objets peuvent être vérifiées à l'issue de cette instanciation (voir ci- 15 après); L'étape 4 (non représentée) mise à jour des objets sur A : Dernière étape à l'aide du tableau diff, A met à jour le contenu des objets de A. Comme indiqué sur le schéma, l'ensemble des objets ont été reconstruits entre A et B et les modifications ont été reportées dans l'espace objet de A. 20 Notons que les étapes 0, 1, 2, 3 et 4 s'exécute respectivement au sein des flots A, B, B, A, et A et que pendant ces étapes rien d'autre ne peut s'exécuter au sein de ces flots. Notons également que si l'objet Xa est accédé par un autre objet autre que Oa, la nouvelle valeur de Xa a été propagée. Si Xa n'était que référencé par Oa, alors suite à la mise à jour il sera collecté par le ramasse miette de la machine virtuelle. 25 5.2.1.2. Appels effectifs des fonctions Grâce au procédé décrit ci-avant, les inventeurs ont le moyen de maintenir les équivalences des systèmes objets entre deux flots, ce qui n'était pas possible précédemment. Afin de réaliser l'appel de fonction, l'ensemble des paramètres d'entrée de la fonction est sérialisé. Puis une fois exécutée, des paramètres de sortie sont ajoutés dans la sérialisation, selon 30 le même mécanisme. Il est ainsi possible d'appeler une fonction tout en maintenant les objets liés aux paramètres d'entrée et de sortie. 18 5.2.1.3. Gestion des scopes En dehors des paramètres, une fonction peut avoir besoin d'accéder à des propriétés/objets accessibles dans son scope (dans sa portée), c'est-à-dire des propriétés/objets, qui bien que n'étant pas définis au sein d'un objet à transmettre à la ressource d'exécution de 5 destination, sont tout de même accessibles dans le code scripté initial. C'est par exemple le cas de variables globales, de variables ou de propriétés d'un niveau précédent ou encore d'objets parents (lors d'héritage d'objets par exemple). Ainsi, un problème à résoudre pour pouvoir effectuer un transfert vers un autre flot est également de pouvoir effectuer un transfert de contexte d'exécution, le contexte comprenant l'ensemble des propriétés/objets auxquels la fonction a accès 10 durant son exécution. La détermination de ce contexte est effectuée en amont, c'est-à-dire avant le transfert vers la ressource d'exécution de destination, normalement par l'unité fonctionnelle de compilation. Le contexte créé fait partie des objets qui sont sérialisés et transmis par la méthode de transmission précédemment décrite. La figure 4 illustre la problématique des scopes (portées d'exécution). On comprend que si l'on souhaite transmettre, à une ressource d'exécution de 15 destination, l'exécution de f2 et de f3, la transmission correcte du contexte d'exécution est essentielle. Notamment, par exemple, le scope de f3 est différent du scope de f2, malgré le fait que ces deux fonctions f2 et f3 définissent une variable nommée t dont le scope est limité. Il ne faut donc pas par exemple que les scopes de f2 et f3 entrent en collision. Ainsi, afin de transmettre le contexte de l'environnement à un appel de fonction distant, 20 deux possibilités de traitement des scopes sont possibles : soit être en phase d'exécution pour pouvoir accéder à l'environnement et le transmettre directement, ou réécrire le code scripté d'une certaine manière. Une première solution consiste à simuler le contexte Javascript. Dans cette première solution, afin de transmettre le contexte sans l'aide de l'interpréteur 25 (par exemple sans l'aide du moteur Javascript), il est nécessaire de créer le contexte dans le langage choisi (par exemple en Javascript). Pour cela, il est nécessaire de connaître toutes les portées de variables, de chaînes de portées et tous les accès au contexte. Pour pouvoir le faire, nous devons exclure toute portée dynamique, c'est-à-dire l'utilisation de mots clés du style «with» et «eval», et donc être dans une portée purement lexicale. La méthode de création comprend : 30 - La construction de la chaîne de scope associée à chaque scope dans le programme ; 19 La séparation du programme en deux ensembles de scopes, l'un pour le scope des fonctions qui vont être exécutées à distance (remote) et l'autre pour le reste du programme (résident); Optionnellement, supprimer, dans les scopes résidents, toutes les liaisons de variable qui ne sont pas utilisées dans une fonction distante ; Optionnellement, fusionner certains scopes en renommant un nom de liaison ou de variable en conflit (par exemple, pour ne conserver qu'un scope unique par fonction) Transformer le programme comme suit : 10 Lorsque le scope global est créé, créer un objet vide et placer cet objet comme contexte courant dans l'objet 'global' (dans la suite, nommons le (global.currentContext) pour être accessible de tout le programme ; ; Chaque fois qu'un scope est créé, générez un objet vide, ajoutez lui une propriété symbolique 'parent' qui pointe sur le context pointé par `global.currentContext', et 15 mettez cette objet comme contexte courant dans l'objet 'global' (global.currentContext). Chaque fois qu'un scope est détruit, faire pointer le 'global.currentScope' sur l'objet pointé par `globa.currentScope.parent. Ainsi, une pile dynamique de contextes dont le haut est à tout moment pointé par 'global.currentContext' est créée et mise à jour 20 durant l'exécution du programme ; A chaque fois qu'une fonction 'f' est définie : a. ajouter une propriété symbolique f.context pointant sur le contexte actuel pointé par 'global.currentContext' (f est l'objet fonction); b. ajouter dans l'objet context pointé par `global.currentContext tous les 25 paramètres de la fonction (le nom du paramètre devenant le nom d'une propriété, et sa valeur, la valeur de cette propriété); ; Remplacez tous les accès à une variable v incluse dans un scope résident dans une fonction f: a. Si l'étape 4 (optimisation optionnelle) est appliquée, recherchez le nom de la 30 liaison correspondant à la variable v (appelons la w) ; b. Si l'étape 4 n'est pas appliquée, w = ; c. Remplacer l'accès à la variable v par un accès à f.context.w. 20 En utilisant cette première solution, consistant à réécrire le code et définir un contexte de transmission qui est associés aux différents scopes, transmettre et exécuter une fonction auprès d'une ressource d'exécution de destination est aisé : il suffit de transmettre l'objet fonction, qui contient tout le contexte d'exécution de cette fonction par l'intermédiaire de sa propriété symbolic 5 'context'. Une deuxième solution consiste à capturer le contexte et à le falsifier. Pour pouvoir mettre en oeuvre cette solution, nous devons exclure toute portée dynamique, c'est-à-dire l'utilisation de mots clés «with» et «eval», et donc être dans une portée purement lexicale. 10 1. Construire la chaîne de scope associée à chaque scope dans le programme. Marquez la liaison avec un attribut constant pour les variables déclarées avec const et marquez la liaison avec un attribut tdz (zone morte temporelle) pour les variables déclarées avec const ou let et qui peuvent se retrouver dans une zone morte temporelle. Pour ces derniers, nous pouvons également fixer le moment exact où la liaison n'est sûrement pas dans la zone 15 morte temporelle, mais nous décrirons cela plus tard comme une optimisation. 2. Pour chaque fonction, diviser le programme en deux ensembles de scopes, un pour le scope des fonctions que vous voulez exécuter à distance (distant) et un pour le reste du programme (résident). 3. De manière optimisée et optionnelle, parcourir le code de la fonction que nous voulons 20 exécuter à distance pour marquer chaque liaison dont la fonction a besoin dans le scope résident. 4. Pour chaque fonction que nous voulons exécuter à distance : a. Ajouter une fonction qui capture le contexte dans un objet de contexte avec les variables provenant d'une liaison marquée à l'étape 3 (ou toutes les variables du 25 scope résident si pas d'étape 3). i. Construire un objet contextuel, avec (I) un identifiant définissant la configuration de la variable Temporal Dead Zone, (Il) une liste de noms de variables dans la Temporal Dead Zone, (III) deux objets vides, un pour contenir les variables non mutables (const), et un autre pour les variables 30 mutables (var, let, function et class). ii. Placez une propriété par variable, le nom de la propriété est le nom de la variable et l'emplacement de la propriété dépend du type de la variable (un 21 des deux objets définit en i.II : mutable ou non mutable). La valeur de la propriété est la valeur de la variable. iii. Afin de gérer la zone morte temporelle, nous devons « try/catch » chaque accès aux variables potentiellement dans la Temporal Dead Zone au cas où 5 ces variables seraient réellement dans la Temporal Dead Zone. Dans ce cas, nous devons simplement insérer le nom de la variable dans le tableau de la Temporal Dead Zone (i.l). Nous devons également calculer un identifiant qui identifie la configuration des variables de la Temporal Dead Zone en définissant un bit dans l'identifiant représentant cette variable. 10 b. Ajouter une fonction qui met à jour le contexte à partir de l'objet « context » en écrivant les variables provenant d'une liaison marquée à l'étape 3 (ou toutes les variables du scope résident si pas d'étape 3) . Dans le cas d'une variable potentiellement dans la Temporal Dead Zone, nous devons tester si elle était effectivement dans Temporal Dead Zone de l'objet contexte, en testant le bit id, et 15 dans le cas contraire, mettre à jour le contexte avec la valeur provenant de l'objet contexte. c. Lier ces deux nouvelles fonctions dans l'objet fonction en utilisant des propriétés nommées avec soin (comme "captureContext" et "updateContext") ou en utilisant un symbole. 20 d. On peut imaginer l'ajout d'une troisième fonction utilisant les deux premières fonctions, qui réalise l'appel distant avec un mécanisme spécifique (capture de contexte, appel distant avec ce contexte, mise à jour du contexte). 5. Remplacer la fonction dans la partie distante par une fonction qui : a. Prend un objet de contexte comme argument. 25 b. Créé toutes les variables nécessaires avec leur valeur initiale contenue dans l'objet context. Si la variable est dans l'ensemble non mutable, utiliser const pour la déclarer. Si la variable est dans le mutable (read/write), utilisez let. c. Exécute (ou appelle) le code original dans un bloc try. d. Créée toutes les variables nécessaires dans la Temporal Dead Zone avec le let. 30 e. Met à jour l'objet context avec la valeur provenant du contexte dans le bloc finally correspondant au bloc try. Ignorer simplement la variable dans la zone morte temporelle ou dans la section r (read). 22 Un certain nombre d'alternatives peuvent être imaginées à l'aide de fonctions utilitaires, Ici aussi, la transformation doit ëtre prudente vis-à-vis des conflits de noms avec ses propres variables, mais la transformation a la connaissance de tous les scopes, et peut donc facilement éviter les conflits. 5 Pour projeter l'exécution d'une fonction avec cette alternative, le programme devra obtenir l'objet context de la fonction à projeter en appelant la fonction pointée par la propriété captureUpdate de cette même fonction. Il devra alors sérialiser ce object context avec le même mécanisme que précédemment décrit. Au retour de l'exécution de cette fonction, le programme devra mettre à jour le context grâce à l'objet context provenant de la désérialisation qu'il passera 10 à la fonction pointée par la propriété updateContext de cette même fonction. 5.2.1.4. Cohérence des objets, exécution ACID d'une fonction, exécution ordonnée Dans le cas précédemment décrit, une fonction exécutée dans un autre flot d'exécution (sur une ressource d'exécution de destination) modifie les objets passés en paramètres. Compte 15 tenu du fait que cette fonction peut s'exécuter de façon asynchrone et parallèle, le flot d'exécution A (ressource appelante) ou un autre flot d'exécution (autre ressource d'exécution de destination) peut pendant ce temps modifier les mëmes objets. Ceci n'est pas possible dans un système javascript standard dans lequel toutes les fondions s'exécutent dans le même flot. Afin de maintenir la cohérence des objets, par défaut les fonctions doivent préserver les propriétés ACID 20 (Atomicité, Cohérence, Isolation et Durabilité). Les inventeurs ont donc développé une technique de conservation de ces propriétés ACID. Ainsi, afin d'exécuter une propriété ACID de la fonction une validation différentielle est effectuée, qui consiste notamment à vérifier que : les paramètres d'entrée de la fonction et les objets liés n'ont pas étés modifiés (sur A) depuis le début d'exécution de la fonction ; 25 - les variables scopées et les objets liés sont inchangés (sur A). Pour ce faire on réutilise l'étape 2 (S2) décrite précédemment, mais appliquée sur le flot A. Si le tableau diffa est vide, alors aucune modification n'a été apportée pendant l'exécution de la fonction on procède au commit (la validation) de la fonction et on met à jour le système objet du flot A (étapes 3 (S3) et 4). Si le tableau diffa n'est pas vide alors on invalide la fonction exécutée par 30 la ressource d'exécution de destination : on ne propage pas les mises à jour des paramètres et objets et on exécute la fonction à nouveau. 23 Grâce à cette validation différentielle, il est possible d'exécuter de façon asynchrone et parallèle, une fonction, dans un autre flot, tout en maintenant son exécution cohérente dans l'application initiale. Par ailleurs notons que le fait d'exécuter à nouveaux la fonction de façon asynchrone ne pose pas de problème car la fonction à exécuter est elle-même asynchrone. 5 Une autre propriété à respecter est la relation d'ordre d'exécution asynchrone qui est définie par setimmediate uniquement. Par exemple la séquence suivante : setImmediate ( fl) setImmediate (f2) , setImmediate (f3) Présuppose que fl sera exécutée avant f2, et que f2 sera exécutée avant f3. Aussi, dans le 10 cas d'une exécution déportée, comme décrite précédemment, si f2 ou f3 se termine avant fl, il est nécessaire d'attendre la validation (le commit) de f1 avant de faire le commit de f2, puis de f3. Auquel cas, la méthode permet d'identifier ces cas de figure en réalisant une passe spécifique à ces aspects lors de la décomposition du code source scripté. Par ailleurs, lors de l'exécution, on effectue un séquencement des validations (commits) dans l'ordre d'activation et/ou on invalide/Iéexécute si 15 besoin les fonctions invalidées. Ci-dessous un exemple simple montrant l'utilisation de cette relation d'ordre. La relation d'ordre est nécessaire afin d'obtenir le bon résultat induit par la causalité des variables du code. let result = 0; function £(index) { 20 result += (result * index) + (index * index); setImmediate (f , 1) , setImmediate (f, 2) . Dans cet exemple si l'ordre est respecté le résultat vaut 7 ; si l'ordre n'est pas respecté il vaut 9. 25 Dans le cas de cet exemple, d'une part le compilateur (l'unité de compilation) peut éviter de dissocier l'exécution de ces fonction et d'autre part l'unité d'allocation, si elle agit indépendamment de l'unité de compilation peut décider de ne pas transporter l'exécution de ces fonctions dans une ressource d'exécution de destination. En fonction des modes de réalisation, pour les développeurs, il est possible de fournir une 30 solution de traitement des décompositions qui soient personnalisables, par exemple par l'intermédiaire d'une interface de programmation (API) spécifique. 24 D'un point de vue développeur, il est possible d'offrir le moyen d'exécuter une fonction de façon asynchrone avec ou sans garantie ACID, avec ou sans garantie d'ordre. Cette dernière appelant un handler de fin. Il est également possible de fournir le même support en créant une promesses qui 5 permettra de réaliser un point de synchronisation simple dans le code (f(params).then()), ou l'utilisation de await dans des fonctions async de plus haut niveau. 5.3. Autres caractéristiques et avantages Afin qu'elle soit efficace, la technique précédemment décrite doit permettre de transporter l'exécution d'une quantité importante de fonctions. Grâce à la technique des inventeurs, 10 Potentiellement, toute fonction asynchrone est projetable/déportable. Cela peut être : - des fonctions qui sont déclenchées sur événement (par exemple les .on('event', f), ou les setTimeOut ou setlmmediate ; - des fonctions async ; - des fonctions exécutées dans des webworkers. 15 Concernant d'autres séquences de code synchrones, elles sont également projetable/déportable en fonction de leurs données utilisées. Par exemple, dans une séquence synchrone on a un comportement suivant dans le code Javascript : - FA - travail sur un ensemble de données A et production de A'; - FB - travail sur un ensemble de données B et production de 8'; 20 - FC- travail sur un ensemble de données Cet production de C'; - Suite - on continue le code. Il est aisé de comprendre que si A, A' B, B, Cet C' sont des objets/propriétés différentes, alors FA, F8 et FC sont projetable/déportables et qu'il suffit de créer un point de synchronisation avant que Suite ne s'exécute il n'y a pas de problème sur l'exécution. Ainsi le travail sur des boucles 25 dont les fonctions travaillant sur des objets/propriétés disjointes sont ainsi projetable/déportables. Dès lors, ce code let samples = [ ] ; let out = [] ; for (let index = 0; index { // return element to new Array 5 H ; Également : f ( ) Préambule... 10 // travail sur un set de donnée A // /./travail sur un set de donnée B 15 // Suite_ Une transformation de code permettant de créer par exemple des promesses peut être utilisée. L'unité de compilation génère ces transformations en s'appuyant sur la propriété ACID et 20 d'ordre d'exécution du des fonctions. Par exemple : f ( - - ) Préambule... async function mf () ( async function 's'AH 25 //travail sur un set de donnée A async function dB(1 //travail sur un set de donnée B 1 30 let adA = dA(1; let °dB = dB(); await odA; 26 await °dB; mf () .then(function () I // Suite... 5 I ) ; 1.4. Systèmes et dispositifs de mise en oeuvre On présente, en relation avec la figure 5, une architecture simplifiée d'un dispositif 10 électronique d'exécution apte à effectuer le traitement et l'exécution d'un code scripté. Un dispositif électronique d'exécution comprend une mémoire 51, une unité de traitement 52 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 53, mettant en oeuvre le procédé tel que précédemment décrit. Dans au moins un mode de réalisation, l'invention est mise en oeuvre sous la forme d'une application installée sur ce dispositif. Un tel dispositif 15 comprend : des moyens d'obtention du code scripté comprenant un ensemble d'objets projetables, un objet projetable de l'ensemble d'objets projetables comprenant au moins une fonction exécutable auprès d'une ressource d'exécution de destination ; des moyens de préparation d'une structure de données de transmission d'au moins un 20 objet projetable dudit code scripté préalablement obtenu, ladite structure de données de transmission associant à chaque objet du code scripté, au moins une donnée d'indexation ; des moyens de transmission à une ressource d'exécution de destination, de la structure de données de transmission du code scripté; et des moyens de réception d'une structure de données de résultats d'exécution, mis en 25 oeuvre postérieurement à l'exécution, par la ressource d'exécution de destination, de la structure de données de transmission ; des moyens d'intégration de résultats d'exécution de la structure de données de résultats d'exécution. On présente, en relation avec la figure 6, une architecture simplifiée d'un dispositif 30 électronique d'exécution, également appelée ressource d'exécution de destination apte à effectuer des transactions à l'aide d'une empreinte contextuelle. Un tel dispositif électronique d'exécution, comprend une mémoire 61, une unité de traitement 62 équipée par exemple d'un 27 microprocesseur, et pilotée par le programme d'ordinateur 63, mettant en oeuvre le procédé selon l'invention. Dans au moins un mode de réalisation, l'invention est mise en oeuvre sous la forme d'une application installée sur un dispositif électronique d'exécution accessible par une ressource appelante. Un tel dispositif électronique d'exécution comprend : 5 des moyens de réception, de la structure de données de transmission du code scripté; et des moyens d'exécution du code scripté résultant de l'instanciation, sous la forme d'objets projetables, de la structure de données reçue, et des moyens de traçage des résultats d'exécution d'au moins une fonction contenue dans ces objets ; des moyens de préparation d'une structure de données de résultats d'exécution dudit au 10 moins un objet projetable dudit code scripté préalablement exécuté, ladite structure de données de résultats d'exécution associant à chaque objet du code scripté modifié, au moins une donnée d'indexation ; des moyens de transmission à une ressource d'exécution locale, de la structure de données de de résultats d'exécution du code scripté; 15 Ces moyens se présentent sous la forme d'une application logicielle spécifique, ou encore sous la forme de composants matériels dédiés. Plus particulièrement, dans au moins un mode de réalisation, REVENDICATIONS1. Procédé d'exécution d'un code scripté d'une application, procédé mis en oeuvre par l'intermédiaire d'un dispositif électronique, appelé ressource appelante (ResA, A), au sein de laquelle ladite application est exécutable, le procédé comprenant : une étape d'obtention (20) du code scripté de l'application (PCP) comprenant un ensemble d'objets projetables, un objet projetable de l'ensemble d'objets projetables comprenant au moins une fonction exécutable auprès d'une ressource d'exécution de destination (resX, B) ; - une étape de préparation d'une structure de données de transmission (PCP#, heap) d'au moins un objet projetable dudit code scripté préalablement obtenu, ladite structure de données de transmission associant à chaque objet projetable du code scripté, au moins une donnée d'indexation ; une étape de transmission (40), à une ressource d'exécution de destination, de la structure de données de transmission (PCP#, heap) du code scripté; et postérieurement à l'exécution (50), par la ressource d'exécution de destination, d'au moins une fonction dudit au moins un objet projetable de la structure de données de transmission : une étape de réception (60) d'une structure de données (ExObj, diff) de résultats d'exécution de ladite au moins une fonction ; une étape d'intégration de résultats d'exécution de la structure de données de résultats d'exécution au sein de la ressource appelante . 2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'intégration de résultats d'exécution de la structure de données de résultats d'exécution au sein de la ressource appelante comprend une vérification différentielle de l'intégrité des données mise à jour au cours de l'exécution (50), par la ressource d'exécution de destination. 3. Procédé d'exécution d'un code scripté selon la revendication 1, caractérisé en ce que l'étape d'obtention du code scripté comprenant un ensemble d'objets projetables comprend : 2 une étape d'obtention (10) d'un code source scripté (CSSE), représentatif de l'application à exécuter par la ressource appelante (ResA, A) ; une étape de détermination, au sein du code source scripté (CSSE), d'au moins une fonction susceptible d'être exécutée par une ressource d'exécution de destination, dite 5 fonction projetable ; une étape de modification du code source scripté, délivrant un code scripté d'exécution comprenant ledit ensemble d'objets projetables, en fonction de ladite au moins une fonction projetable préalablement déterminée. 10 4. Procédé d'exécution d'un code scripté selon la revendication 1, caractérisé en ce que l'étape de préparation d'une structure de données de transmission d'au moins un objet projetable dudit code scripté comprend : une étape de création d'un tableau d'indexation (refA), pour chaque objet projetable (0A, XA) à transmettre à une ressource d'exécution de destination (ResX, B), tableau au sein 15 duquel un index (0, 1, ...) est associé à une référence d'objet (RefOA, RefXA,...); une étape de création de la structure de données de transmission (PCP, heap) sous la forme d'un tableau comprenant, pour chaque objet projetable, un index (0, 1, ...), correspondant à l'index (0, 1, ...) de la référence de cet objet projetable au sein du tableau d'indexation (refA), et une représentation sérialisée (r0, r1, ...) de l'objet projetable ; 20 5. Procédé d'exécution d'un code scripté selon la revendication 1, caractérisé en ce que l'étape de réception d'une structure de données de résultats (ExObj, diff) d'exécution de ladite au moins une fonction comprend : une étape de réception, de la structure de données de transmission (PCP#, heap) 25 préalablement transmise, sous la forme d'un tableau comprenant, pour chaque objet projetable, un index (0, 1, 2,...), correspondant à l'index (0, 1, 2,...) de la référence de cet objet projetable au sein d'un tableau d'indexation (refB) de la ressource d'exécution de destination (ResX, B), et une représentation sérialisée (r0, r1, r2...) de l'objet projetable ; une étape de réception, de la structure de données de résultats d'exécution (ExObj, diff) 30 sous la forme d'un tableau comprenant, pour chaque objet projetable de la structure de données de transmission (PCP, heap) préalablement transmise, un index (0, 1, 2,...) et et 3 une représentation sérialisée (VO, r'1, ...) des modifications effectuées par ladite au moins une fonction exécutée par la ressource d'exécution de destination (ResX, B). 6. Procédé d'exécution d'un code scripté selon la revendication 1, caractérisé en ce que 5 l'étape d'intégration de résultats d'exécution de la structure de données de résultats d'exécution (ExObj, diff) au sein de la ressource appelante comprend : une étape de mise à jour, au sein de la ressource appelante (ResA, A), d'une liste d'objets, la mise à jour comprenant une création d'un nouvel objet lorsque qu'un objet absent de la structure de données de transmission a été créé par la ressource d'exécution de 10 destination au cours de l'exécution (50) ; une étape de mise à jour des valeurs des objets de la liste d'objets, comprenant une vérification de la cohérence des valeurs à mettre à jour en fonction des valeurs d'origine contenues dans la structure de données de transmission. 15 7. Procédé d'exécution d'un code scripté selon la revendication 3, caractérisé en ce que l'étape de modification du code source scripté, délivrant un code scripté d'exécution comprenant ledit ensemble d'objets projetables, en fonction de ladite au moins une fonction projetable préalablement déterminée comprend : une étape de détermination d'au moins un contexte d'exécution de ladite application, en 20 fonction du code source scripté (CSSE), ledit contexte d'exécution de ladite application comprenant, pour chaque variable et/ou objet du code source scripté (CSSE), une représentation d'une variable et/ou objet correspondant, accessible et/ou modifiable lors de la projection vers une ressource d'exécution de destination, ledit contexte d'exécution tenant compte de la portée de chaque variable et/ou objet du code source scripté (CSSE); 25 une étape de construction du code scripté (PCP) en fonction du code source scripté (CSSE) et dudit contexte d'exécution préalablement déterminé. 8. Dispositif électronique d'exécution d'un code scripté, appelé ressource appelante, le dispositif comprenant : 30 des moyens d'obtention du code scripté comprenant un ensemble d'objets projetables, un objet projetable de l'ensemble d'objets projetables comprenant au moins une fonction exécutable auprès d'une ressource d'exécution de destination ; 4 des moyens de préparation d'une structure de données de transmission d'au moins un objet projetable dudit code scripté préalablement obtenu, ladite structure de données de transmission associant à chaque objet du code scripté, au moins une donnée d'indexation ; 5 des moyens de transmission à une ressource d'exécution de destination, de la structure de données de transmission du code scripté; et des moyens de réception d'une structure de données de résultats d'exécution, mis en oeuvre postérieurement à l'exécution, par la ressource d'exécution de destination, de la structure de données de transmission ; 10 - des moyens d'intégration de résultats d'exécution de la structure de données de résultats d'exécution. 9. Système d'exécution d'un code scripté, caractérisé en ce qu'il comprend au moins une ressource appelante prenant la forme d'un dispositif électronique d'exécution selon la 15 revendication 8 et au moins une ressource distante, prenant la forme d'une ressource d'exécution de code scripté accessible depuis la ressource appelante. 10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un 20 microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé selon la revendication 1, lorsqu'il est exécuté sur un ordinateur. 25