FR3094527A1 - Traitement informatisé d’un enchaînement d’agents de calcul mis en œuvre par un ensemble de technologies distinctes - Google Patents

Abstract

Procédé pour l’exécution d’un traitement composé d’un ensemble d’agents de calcul sur une plateforme de traitement de données, chaque agent associant une routine à des modalités d’exécution de ladite routine, et ledit procédé comprenant une étape de fourniture (S1) d’une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de nœuds, chaque nœud correspondant à un desdits agents de calcul ; une étape de décomposition (S2) dudit squelette en un graphe exhaustif dans laquelle on détermine l’ensemble des modules logiciels pouvant mettre en œuvre chacun desdits agents, et on remplace le cas échéant chaque nœud par un groupe de nœuds, chaque nœud dudit groupe correspondant à un module logiciel pouvant mettre en œuvre l’agent correspondant au nœud remplacé ; une étape d’affectation (S3) de coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ; une étape de détermination (S4) d’un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ; une étape d’exécution (S5) consistant à appeler de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.

Description

Traitement informatisé d’un enchaînement d’agents de calcul mis en œuvre par un ensemble de technologies distinctes

La présente invention concerne l’enchaînement automatisé de traitements informatiques sur des données telles que, par exemple, des données d'imagerie numérique. Elle concerne plus particulièrement l’enchaînement de traitements issus de technologies différentes, c'est-à-dire, notamment, de plateformes de traitement distinctes.

Contexte de l’invention

Le traitement automatisé de données numériques implique généralement l’enchaînement d'un certain nombre de sous-traitements afin d'aboutir à un résultat recherché. Ces sous-traitements peuvent être très spécifiques ou plus généraux, et, essentiellement dans ce dernier cas, ils peuvent être offerts par des technologies différentes comme autant d'implémentations.

Ainsi, par exemple, un processus de traitement et d'analyse d'images d'origine biologique peut consister en un ensemble de traitements consistant à

• visualiser des images de cellule par le biais de logiciels propriétaires des microscopes. Chaque image est enregistrée indépendamment sur le système de l'utilisateur ;
• puis, sur chaque image est appliquée un ensemble d'algorithme de traitement afin d'extraire des informations particulières (position des noyaux de cellule, indicateurs de la forme des cellules, etc.) ;
• ces données sont ensuite stockées sur un tableau. Leur analyse statistique est réalisée par la composition de macro-fonctions du tableau (par exemple, le logiciel Excel) et de scripts en langage Python par exemple.

La durée d'un tel processus pour être de plusieurs heures. En outre, un besoin d'automatisation existe afin de libérer les opérateurs humains (chercheurs, techniciens...) de tâches longues et fastidieuses, et de diminuer le coût du processus.

Si des outils existent pour certaines étapes de la chaine de traitement, d'autres ne sont pas automatisés, comme notamment la liaison entre les étapes qui reste essentiellement manuelle dans les solutions de l'état de l'art (copie des images, formatage des données....)

En outre, chaque étape du processus peut être mise en œuvre par une technologie existante (un outil ou logiciel d'analyse ou de traitement d'image...), mais chaque outil est associé à des modalités particulières, issues de son domaine d'opération normal, et ayant des implications notamment sur ses interfaces (formats des données d'entrée, de sortie...).

Ainsi, différents outils de traitement d'image existent (OpenCV, ImageJ, ITK...), mais chacun possède des spécificités car issus d'un domaine distinct et répondant aux exigences de métiers différents (imagerie médicale, imagerie spatiale, etc.)

Par nature, ces outils ne sont pas nativement interopérables. Bien que l'utilisation de solutions dites de "bindings" permette d'utiliser OpenCV en langage Java, la traduction entre les structures de données n'est pas fournie et l'utilisateur doit donc développer les éléments nécessaires.

Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités.

Plus particulièrement, la présente invention vise donc à améliorer la situation en proposant une solution permettant de faire interopérer des outils variés, en automatisant les interfaçages entre ces outils ainsi que la sélection de la technologie permettant d'implémenter une étape d'un traitement complexe.

A cette fin, la présente invention propose un procédé pour l’exécution d’un traitement composé d’un ensemble d’agents de calcul sur une plateforme de traitement de données, chaque agent associant une routine à des modalités d’exécution de ladite routine, et ledit procédé comprenant

• une étape de fourniture d’une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de nœuds, chaque nœud correspondant à un desdits agents de calcul ;
• une étape de décomposition dudit squelette en un graphe exhaustif dans laquelle on détermine l’ensemble des modules logiciels pouvant mettre en œuvre chacun desdits agents, et on remplace le cas échéant chaque nœud par un groupe de nœuds, chaque nœud dudit groupe correspondant à un module logiciel pouvant mettre en œuvre l’agent correspondant au nœud remplacé ;
• une étape d’affectation de coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ;
• une étape de détermination d’un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ;
• une étape d’exécution consistant à appeler de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.

Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles :

• les couts affectés à chaque nœud dudit graphe exhaustif comprennent un temps d’exécution, et les coûts affectés à chaque transition comprennent un temps de traduction des données entre les environnements technologies des modules logiciels associés aux nœuds concernés, et un temps de transfert des données ;
• à chaque nœud dudit squelette est associé un exécuteur instanciant lesdites modalités d’exécution associé à l’agent correspondant audit nœud ;

ledit squelette comporte des nœuds génériques correspondant chacun à un agent de calcul pouvant être mis en œuvre par au moins deux modules logiciels, et des nœuds spécifiques correspondant chacun à un agent de calcul pouvant être mis en œuvre par un unique module logiciel.

Un autre aspect de l’invention concerne un dispositif pour l’exécution d’un traitement informatique composé d’un ensemble de routines sur une plateforme multi-technologique comprenant des moyens pour

• fournir une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de nœuds, chaque nœud correspondant à un desdits agents de calcul;
• décomposer ledit squelette en un graphe exhaustif en déterminant l’ensemble des modules logiciels pouvant mettre en œuvre chacune desdits agents, et remplaçant, le cas échéant, chaque nœud par un groupe de nœuds, chaque nœud dudit groupe correspondant à un module logiciel pouvant mettre en œuvre l’agent correspondant au nœud remplacé ;
• affecter des coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ;
• déterminer un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ;
• exécuter ledit traitement en appelant de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.

Suivant des modes de réalisation préférés, l’invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles :

• les couts affectés à chaque nœud dudit graphe exhaustif comprennent un temps d’exécution, et les coûts affectés à chaque transition comprennent un temps de traduction des données entre les environnements technologies des modules logiciels associés aux nœuds concernés, et un temps de transfert des données ;
• le dispositif comprends des moyens pour, à chaque nœud dudit squelette, associer un exécuteur instanciant lesdites modalités d’exécution associé à l’agent correspondant audit nœud.
• ledit squelette comporte des nœuds génériques correspondant chacun à un agent de calcul pouvant être mis en œuvre par au moins deux modules logiciels, et des nœuds spécifiques correspondant chacun à un agent de calcul pouvant être mis en œuvre par un unique module logiciel.

Un autre aspect de l’invention concerne un système pour l’exécution d’un traitement informatique composé d’un ensemble d’agents de calcul, comportant un dispositif tel que précédemment défini, ainsi que des applications logicielles mettant à disposition lesdits modules logiciels audit dispositif.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d’un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés.

La figure 1 représente schématiquement un organigramme fonctionnel selon un mode de réalisation de l’invention.

La figure 2 représente schématiquement des exemples de motifs pour la formation de squelettes selon un mode de réalisation de l’invention.

Les figures 3a, 3b, 3c représentent schématiquement des exemples de squelettes selon un mode de réalisation de l’invention.

Description détaillée de l’invention

L'invention peut s'appliquer aux traitements d'images numériques, par exemple des images médicales ou de tissus organiques afin d'établir des informations sur la composition cellulaire.

Mais elle peut s'appliquer également à toute chaîne complexe de traitement de données numériques (traitement du signal, etc.) et tout champ d'application.

D'une façon générale, ces traitements peuvent se décrire comme un ensemble de sous-traitements, organisés sous la forme d'une chaîne ou d'autres types d'arrangement ou "workflow".

Selon différents mode de réalisation, l'invention concerne un procédé et un dispositif pour l'exécution d'une telle chaîne de traitement sur une plateforme de traitement de l'information. Cette plateforme peut être un serveur ou un ensemble de serveurs informatiques, de type "ferme de serveurs", éventuellement virtualisé et abstraites sous la forme d'un "nuage" (ou "cloud" selon la terminologie en langue anglaise plus habituelle).

Le dispositif peut former un "noyau" d'une chaîne d'outils logiciels plus complète offrant différents services pour aider le développeur de la chaîne de traitement à la mettre concrètement en place sur la plateforme. Préférentiellement, ce noyau et ces outils annexes, ainsi que le procédé, rendent les aspects technologiques transparents pour ces développeurs afin de permettre aux personnes spécialisés dans un champ d'application (imagerie médicale, imagine biologique...) d'utiliser des outils provenant de technologies tierces sans recourt à des connaissances spécifiques à ces technologies, et sans utiliser non plus de connaissances pointues en informatique.

Un traitement peut se définir par un ensemble d'agents logiciels, ou agents de calcul, chacun représentant un "sous-traitement".

Un agent peut se définir, d'une façon générale, par une association entre une ou plusieurs routines logicielles, et des modalités d'exécution de ces routines. Ces modalités définissent des besoins techniques pour exécuter la ou les routines : ressources du CPU, ressources mémoires, ressources en communication, etc.

L’ouvrage de Jacques Ferber, « Les systèmes multi-agents. Vers une intelligence collective », InterEditions, 1995, proposent des définitions formelles des notions de systèmes multi-agents et d’agents de calcul, pages 14-16.

On peut par ailleurs ici considérer un agent comme une instance technologique dédiée à l’exécution d’une routine spécifique, elle-même étant la spécialisation d’une routine dite générique (ou sémantique). Un agent possède ainsi un objectif de traitement, des ressources d’exécution et une capacité de communiquer avec le cœur de l’application.

La figure 1 schématise un organigramme fonctionnel d'une mise en œuvre du procédé selon l'invention.

Ce procédé peut être décomposé en deux phases P1, P2. Une première phase P1 correspond à la génération d'une séquence d'exécution correspondant à la chaîne de traitement, et une seconde phase, P2, correspond à l'orchestration de l'exécution proprement dite de la séquence d'exécution.

La première phase P1 comprend une première étape S1, consistant à fournir une représentation de cette chaîne de traitement sous la forme d'un squelette composé d'un ensemble orienté de nœuds, chaque nœud correspondant à un agent de la chaîne de traitement.

Cette étape S1 prend donc en entrée une première représentation du traitement qui peut être dépendant d'une technologie de formalisation quelconque et a pour but de la transformer dans une seconde représentation sous la forme d'un squelette.

En particulier, cette étape S1 peut comprendre une « désérialisation », selon laquelle le modèle d’exécution est traduit par le noyau depuis un langage descriptif (xml, yaml, json…) vers une représentation objet de notre approche du squelette algorithmique. Comme on le verra plus loin, le modèle d’exécution décrit ainsi les exécuteurs, les routines à appliquer et les enchaînements des processus.

Un squelette algorithmique, ou simplement "squelette", est un concept qui a été introduit dans Cole M.« Algorithmic skeletons : A structured approach to the management of parallel computation», PhD Thesis, University of Edinburgh, Computer Science Dpt, Edinburgh 1988 ; ainsi que dans Cole M.« Algorithmic Skeletons : Structured Management of Parallel Computation». Research Monographs in Parallel and Distributed Computing », Pitman/MIT Press: London, 1989

On peut définir un squelette comme un modèle haut-niveau de représentations d'un traitement particulièrement adapté à la description des aspects de parallélisassions haut-niveau et de distribution des calculs.

Un squelette peut être considéré, et construit, comme la composition de motifs particuliers dont chacun peut être lui-même un sous-squelette, et ceci de manière récursive. Des motifs terminaux s’inscrivent en tant qu’élément minimaux de squelette. Ce sont les motifs « map », « split » et « reduce ».

Différents motifs ont été décrits dans l'état de la technique. La figure 2 illustre 4 motifs : "map", "pipe", "farm" et "reduce".Cette liste n’est pas exhaustive. Ainsi, on peut ajouter par exemple le motif « split » qui permet de transformer un flux de données en plusieurs flux sortants.

Le motif "map" décrit l'application d'un algorithme particulier à chaque élément d'une collection. Le motif "pipe" est une succession de motifs "map". Le motif "farm" désigne l'application en parallèle de plusieurs motifs "map". Le motif "reduce" synthétise plusieurs données pour n'en retourner qu'une seule (la somme de termes, par exemple).

Ces motifs sont décrits dans de nombreuses sources de l'état de la technique, par exemple dans «Patterns and Skeletons for Parallel and Distributed Computing», de Fethi A. Rabhi, Sergei Gorlatch ; ou bien encore dans E. Chis, Adriana & Gonzalez-Velez, Horacio. (2018). “Design Patterns and Algorithmic Skeletons: A Brief Concordance”.10.1007/978-3-319-73767-6_3.

Selon un mode de réalisation de l’invention, un squelette peut être vu comme une arborescence, dont chaque nœud correspond à un agent, et chaque agent représentant un "sous traitement".

Les liens entre les nœuds correspondent aux interfaces d'entrée et de sortie qui caractérise chaque agent. Chaque nœud correspondant à un agent, il peut donc être associé à une ou plusieurs routines (un agrégat de routines) et aux modalités d'exécution de ces routines.

La figure 3a schématise un exemple de squelette pour un traitement constitué d'une chaîne de sous-traitements, ou agents, 31, 32, 33, 34.

Dans une étape S2, on décompose ce squelette en un graphe exhaustif, c'est-à-dire incorporant les implémentations possibles d'un agent donné par des modules logiciels disponibles.

Ces modules logiciels sont des fonctions offertes de façon autonome par des outils ou applications logicielles. Ainsi un agent est une vue abstraite d'une fonctionnalité qui peut être offerte, ou "instanciée" par un ou plusieurs modules.

Par exemple, un rééquilibrage de la balance des blancs dans une image peut être un agent qui peut être implémentés par des modules logiciels offerts par diverses applications de traitement numérique de l'image. Ces modules logiciels correspondent à des "technologies" distinctes, caractérisés par des modalités de fonctionnement spécifiques (structures de données, temps de calcul, performances....).

Dès lors, on peut différentier des nœuds génériques et des nœuds spécifiques. Un nœud spécifique ne peut être implémenté que par une unique technologie (c'est-à-dire par un unique module logiciel), tandis qu'un nœud générique peut être implémenté par au moins deux technologies (ou modules logiciels). Pour ces nœuds génériques, un choix doit donc être effectué, et un des avantages de l'invention est de permettre un choix automatique et transparent de l'implémentation d'un nœud générique.

Les différentes implémentations d'un agent peuvent être mémorisées dans une structure de données afin de pouvoir, à partir d'un nœud générique, déterminer l'ensemble des implémentations possibles.

Une fois déterminé l'ensemble des modules implémentant un agent, on peut construire un graphe exhaustif en remplaçant le cas échéant chaque nœud du squelette par un groupe de nœud, dans lequel chaque nœud correspond à un module logiciel pouvant mettre en œuvre l'agent correspondant au nœud remplacé. Bien sûr, dans le cas d'un nœud spécifique, celui-ci correspond directement au module logiciel (unique) implémentant l'agent en question, il n'y a pas de sens à le remplacer (ou bien, on peut considérer qu'il est remplacé par un groupe formé d'un singleton).

La figure 3b illustre un tel graphe exhaustif basé sur l'exemple de la figure 3a. Sur ces deux figures, les « textures » à l'intérieur des nœuds correspondent aux technologies. Les nœuds 31 et 33 correspondent ainsi à des technologies distinctes (c'est-à-dire qui doivent être implémentés par des modules distincts) tandis que les nœuds 32 et 34 sont des nœuds génériques (en blanc). Dans cet exemple, on suppose que deux modules logiciels sont disponibles.

Le nœud 31 est un nœud spécifique, c'est-à-dire qu'un seul module logiciel disponible permet de l'implémenter. Ce nœud est donc conservé dans le graphe exhaustif tel quel.

Le nœud 32 est un nœud générique, il est donc remplacé par un groupe 32a, 32b, chacun de ces deux nœuds correspondant aux deux modules logiciels permettant de mettre en œuvre l'agent du nœud 32.

Le nœud 33 est un nœud spécifique ; il est donc conservé dans le graphe exhaustif tel quel. Le nœud 34 est un nœud générique, il est donc remplacé par un groupe 34a, 34b, chacun de ces deux nœuds correspondant aux deux modules logiciels permettant de mettre en œuvre l'agent du nœud 34.

Ainsi, le graphe exhaustif est un graphe orienté allant de la donnée à traiter vers le résultat final. Chaque nœud correspond à une routine de calcul. Les nœuds d'un même niveau correspondent à une alternative technologique. Chaque agent générique génère autant de chemins alternatifs que de technologies implémentent une solution à cette routine.

Dans une étape S3, on affecte des coûts à chaque nœud et à chaque transition entre les nœuds.

Les coûts affectés à un nœud peuvent comprendre notamment un temps d'exécution. Les coûts affectés aux transitions entre nœuds peuvent comprendre les temps de transfert de données entre le noyau et les modules logiciels ainsi que les temps de traduction des données vers et depuis ces modules logiciels. En effet, chaque module logiciel (technologie) est associé à des formats de données particuliers et les changements de format impliquent nécessairement des temps de calcul propres.

Ces différents temps peuvent être obtenus à partir de modèles théoriques, qui peuvent se baser sur la connaissance des infrastructures de déploiement, mais aussi sur des données empiriques. Par exemple, des benchmarks peuvent être préalablement prévus sur des ensembles de données tests afin de fournir ces différents temps.

Toutefois, d'autres coûts, et d'autres combinaisons de coûts sont également possibles.

Dans une étape S4, on détermine un graphe optimal en choisissant un chemin minimisant ces coûts. La figure 3c illustre un tel graphe optimal dans le cas de l'exemple des figures 3a et 3b. Le choix d'un chemin passe par la sélection d'un unique nœud pour chaque groupe de nœuds d'un même niveau, c'est-à-dire correspondant à un même agent de calcul. Autrement dit, cette étape consiste à sélectionner, pour chaque agent, un module logiciel permettant de l'implémenter.

Ce choix, basés sur les coûts, permet de prendre en compte bien sûr les performances des différents modules disponibles (temps d'exécution...), mais aussi les interactions engendrées par chaque choix (temps de traduction...). En effet, il peut par exemple être plus intéressant de sélectionner un module offrant des performances moindres qu'un autre, mais impliquant moins de traduction de données avec les modules amont et/ou aval de la chaîne de traitement.

Dans une étape S5, le traitement composé de l'ensemble des agents de calcul peut être exécuté sur la plateforme de traitement en orchestrant les appels vers les différents modules logiciel. Plus précisément, il s'agit de parcourir le graphe optimal et d'appeler séquentiellement les modules logiciels de chaque nœud en assurant les traductions et synchronisation entre chaque appel.

Ainsi quand deux agents successifs du traitement sont mis en œuvre par des modules logiciels distincts, le noyau assure les traductions des données depuis le format associé au module amont vers le format associé au module aval. Dans l'exemple de la figure 3c, les nœuds 31 et 32b correspondent à des modules logiciels distincts, une traduction de données est donc nécessairement mise en place par le noyau pour traduire le résultat de l'exécution du nœud 31 en tant qu'entrée du nœud 32b.

Le noyau assure également la synchronisation, c'est-à-dire à la transmission des données vers et depuis chaque module logiciel. La mise en œuvre de ces transmissions dépend de la plateforme de traitement sous-jacente et des applications logicielles mettant à disposition les modules logicielles implémentant les agents de calcul. Par exemple, les transmissions peuvent être assurées par des mécanismes d'espaces mémoires partagés («memory mapping»), ou d'un fichier, ou d'un flux de données dans le cas d'une topologie distribuée de la plateforme de traitement sous-jacente.

Selon un mode de réalisation, les agents représentent des associations entre une ou plusieurs routines et les modalités d'exécution instanciées par des exécuteurs (ou «executors» en langue anglaise). Ces exécuteurs sont des abstractions de plusieurs éléments dédiés à l'exécution d'une routine. Des travaux de standardisation (RFC C++20/23) proposent une formalisation de cette notion d'exécuteur. L’approche décrite ici est généralisée afin de prendre en compte la distribution multiprocessus sur des ressources d'exécution.

La bibliothèque standard du Java propose également une interprétation et une implémentation des executors, différant notamment par les options configurables lors de l’exécution..

Un exécuteur peut contenir un ensemble de modèles, des métadonnées décrivant les ressources d'exécution, le contexte les agents exécutant les calculs.

Il répond aux questions suivantes : ce qu’il doit exécuter (la routine), comment il doit l’exécuter (en parallélisant les calculs ou non par exemple, il s’agit de la stratégie), et avec quelles ressources (inhérentes aux unités de calcul par exemple).

Les ressources d'exécution sont les unités de calcul utilisables par le programme. Un CPU ou un GPU est ainsi une ressource. Le modèle de ressource d'exécution décrit ainsi les fonctionnalités fondamentales de cette ressources : sa compétence de vectorisation des calculs, ses opérations fondamentales de mesure de performance, ses compétences de mémorisation, etc.

Le contexte d'exécution et une agrégation d'une ressource et d'un ensemble d'agents. Ainsi, il est possible de spécifier un contexte en tant que multithread partiel d'un seul processeur. Le contexte décrit ainsi la manière d'exécuter les routines avec une ressource, par le biais des agents.

Les agents correspondent aux unités fondamentales d'exécution d'un calcul, tel qu'un thread (ou fil d'exécution). Chaque agent exécute une tâche.

En outre, la stratégie d'exécution d'un exécuteur peut être paramétrée par la définition de stratégies. Ces dernières permettent de caractériser la mise en priorité de l'exécution des tâches (première arrivée, première exécutée, par exemple) et la manière d'agréger les sous-nœuds d'un motif du squelette.

Il est à noter que les squelettes algorithmiques présents dans la littérature (tels que Skepu2, ArrayFire, Muesli...) ne considèrent pas du tout la personnalisation du modèle d'exécution par l'explicitation de la ressource. Ainsi, ces outils ne permettent que la rédaction d'un code hétérogène CPU/GPU sans aucune considération de l'approche multiprocessus. Dans certains cas, le choix de l'unité de calcul est défini par implémentation: cela signifie qu'un algorithme particulier n'est accessible que sur une seule ressource.

La synchronisation des données est ainsi gérée par le squelette sans aucune paramétrisation possible et est rendue implicite pour le développeur. Si l'approche implicite permet de faciliter la rédaction d'un code source pour le développeur, l'opportunité d'explicitation permet des optimisations à la rédaction du code source et un choix dans la distribution de calcul.

La détermination des ressources réelles affectées aux ressources exprimées par les exécuteurs se font au moment de l'exécution du noyau, c'est-à-dire en fonction des ressources effectivement disponibles.

Lors de l'étape S2 de décomposition du squelette en un graphe exhaustif, on associe à chaque nœud un exécuteur. Si celui-ci n'a pas été préalablement déterminé (ce qui est le cas lorsqu'un nœud générique est décomposé en un groupe de nœuds), Par défaut, un nœud hérite de l'exécuteur issu de son nœud parent.

Lors de la génération du graphe optimal, les exécuteurs peuvent être utilisés pour définir les étapes de synchronisation des données.

Ainsi, chaque nœud du graphe optimal est nécessairement lié à un exécuteur. Lorsqu’un nœud soumet une tâche, dans l'étape d'exécution S5, il le soumet à l'exécuteur associé.

Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art.

Claims (9)

1. Procédé pour l’exécution d’un traitement composé d’un ensemble d’agents de calcul sur une plateforme de traitement de données, chaque agent associant une routine à des modalités d’exécution de ladite routine, et ledit procédé comprenant

   • une étape de fourniture (S1) d’une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de nœuds, chaque nœud correspondant à un desdits agents de calcul ;
   • une étape de décomposition (S2) dudit squelette en un graphe exhaustif dans laquelle on détermine l’ensemble des modules logiciels pouvant mettre en œuvre chacun desdits agents, et on remplace le cas échéant chaque nœud par un groupe de nœuds, chaque nœud dudit groupe correspondant à un module logiciel pouvant mettre en œuvre l’agent correspondant au nœud remplacé ;
   • une étape d’affectation (S3) de coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ;
   • une étape de détermination (S4) d’un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ;
   • une étape d’exécution (S5) consistant à appeler de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.
2. Procédé selon la revendication précédente, dans laquelle les couts affectés à chaque nœud dudit graphe exhaustif comprennent un temps d’exécution, et les coûts affectés à chaque transition comprennent un temps de traduction des données entre les environnements technologies des modules logiciels associés aux nœuds concernés, et un temps de transfert des données.
3. Procédé selon l’une des revendications précédentes, dans lequel à chaque nœud dudit squelette est associé un exécuteur instanciant lesdites modalités d’exécution associé à l’agent correspondant audit nœud.
4. Procédé selon l’une des revendications précédentes dans lequel ledit squelette comporte des nœuds génériques correspondant chacun à un agent de calcul pouvant être mis en œuvre par au moins deux modules logiciels, et des nœuds spécifiques correspondant chacun à un agent de calcul pouvant être mis en œuvre par un unique module logiciel.
5. Dispositif pour l’exécution d’un traitement informatique composé d’un ensemble de routines sur une plateforme multi-technologique comprenant des moyens pour

   • fournir une représentation dudit traitement informatique sous la forme d’un squelette composé d’un ensemble orienté de nœuds, chaque nœud correspondant à un desdits agents de calcul;
   • décomposer ledit squelette en un graphe exhaustif en déterminant l’ensemble des modules logiciels pouvant mettre en œuvre chacune desdits agents, et remplaçant, le cas échéant, chaque nœud par un groupe de nœuds, chaque nœud dudit groupe correspondant à un module logiciel pouvant mettre en œuvre l’agent correspondant au nœud remplacé ;
   • affecter des coûts à chaque nœud dudit graphe exhaustif, et à chaque transition entre nœuds ;
   • déterminer un graphe optimal en conservant un chemin dudit graphe minimisant lesdits coûts ;
   • exécuter ledit traitement en appelant de façon ordonnée les modules logiciels correspondant audit graphe optimal et à assurer les traductions et synchronisation de données entre chaque appel.
6. Dispositif selon la revendication précédente, dans laquelle les couts affectés à chaque nœud dudit graphe exhaustif comprennent un temps d’exécution, et les coûts affectés à chaque transition comprennent un temps de traduction des données entre les environnements technologies des modules logiciels associés aux nœuds concernés, et un temps de transfert des données.
7. Dispositif selon l’une des revendications 5 ou 6, comprenant des moyens pour, à chaque nœud dudit squelette, associer un exécuteur instanciant lesdites modalités d’exécution associé à l’agent correspondant audit nœud.
8. Dispositif selon l’une des revendications 5 à7, dans lequel ledit squelette comporte des nœuds génériques correspondant chacun à un agent de calcul pouvant être mis en œuvre par au moins deux modules logiciels, et des nœuds spécifiques correspondant chacun à un agent de calcul pouvant être mis en œuvre par un unique module logiciel.
9. Système pour l’exécution d’un traitement informatique composé d’un ensemble d’agents de calcul, comportant un dispositif selon l’une des revendications 5 à 8, ainsi que des applications logicielles mettant à disposition lesdits modules logiciels audit dispositif.