FR 3012896 A1 20150508 FR 1360780 A 20131104 La présente invention concerne un procédé de validation du temps de réponse d'une application, un procédé de déploiement d'une application comportant un tel procédé de validation, un programme d'ordinateur et des dispositifs correspondants. L'invention s'applique plus particulièrement à des applications temps-réel modulaires (à base de composants) et flexibles (à base de services). La conception d'une application temps-réel se fait traditionnellement en ciblant une infrastructure spécifique, ce qui peut rendre son développement cher et sa maintenance difficile. En outre, les applications temps réels sont de plus en plus complexes, et leur cycle d'évolution est de plus en plus court : évolution des besoins, maintenance préventive/curative, etc. Un point essentiel d'une application temps réel est la prédictibilité de son temps de réponse, en particulier le fait de connaître la borne supérieure du temps de réponse. Par ailleurs, pour des applications qui ne sont pas en temps réel, l'approche à services et composants a été adoptée par l'industrie informatique, car il s'agit d'un moyen efficace pour répondre aux besoins d'intégration et de modularité des systèmes informatiques. En effet, la modularité et la flexibilité d'une application à services/composants facilitent la maintenance et peuvent rendre le développement plus rapide et moins cher. Ces deux concepts - modularité et flexibilité - ont été regroupés dans l'approche des « modèles à composants orientés services », dans laquelle les différentes unités logicielles (les composants) interagissent par biais de services, ceux-ci étant bien définis par une description de service, et publiables (par les fournisseurs, retrouvables par les consommateurs) dans un annuaire de services. Il a donc été recherché d'utiliser l'approche à services pour les applications temps-réel. Dans ce cas, pour valider une composition de services, il a été proposé de traduire la composition de service en un langage permettant le calcul de la durée de réponse de la composition de services. Par exemple, dans l'article de Benghazi et al. intitulé « Real-time web services orchestration and choreography » publié en 2010 dans « Proceedings of the 6th International Workshop on Enterprise & Organizational Modeling and Simulation », EOMAS '10, pages 142-153, il est proposé d'établir une correspondance entre un programme écrit dans le langage BPEL et une formulation dans le langage Timed CPS. Cette solution nécessite de connaître la durée d'exécution de chaque service au moment de la conception de la composition de service. Or cette durée d'exécution n'est pas toujours disponible à ce moment, ou bien n'est pas forcément fiable car souvent fournie par le fabriquant du service, et non par celui qui utilise le service dans une composition. Il peut ainsi être souhaité de prévoir un procédé de validation du temps de réponse d'une application destinée à être déployée sur des machines informatiques, qui permette de s'affranchir d'au moins une partie des problèmes et contraintes précités. Il est donc proposé un procédé de validation du temps de réponse d'une application destinée à être déployée sur des machines informatiques en réseau, l'application comportant : des composants implémentant une ou plusieurs opérations de service, chaque opération étant implémentée par une fonction du composant, et au moins un programme implémentant une composition d'opérations, au moyen d'appels aux fonctions implémentant les opérations de la composition, les composants et le ou les programmes étant destinés à être exécutés chacun par une machine informatique, le procédé comportant : l'obtention de caractéristiques d'exécution propre à chaque machine informatique, l'évaluation de la durée d'exécution de chaque programme à partir des caractéristiques d'exécution des machines informatiques, la comparaison de la durée d'exécution de chaque programme avec une durée maximale prédéterminée d'exécution associée à ce programme, dans le cas où la durée d'exécution d'au moins un programme est supérieure à sa durée maximale d'exécution, la génération d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé. Ainsi, grâce à l'invention, il n'est pas nécessaire de connaître la durée des services au moment de leur composition. En outre, la durée d'exécution de la composition de services est fiable car réalisée en tenant compte des caractéristiques des machines informatiques sur laquelle la composition de services sera exécutée. De manière optionnelle, le procédé comporte en outre : l'évaluation de la durée d'exécution de chaque fonction implémentant une opération d'un composant à partir des caractéristiques d'exécution de la machine informatique sur laquelle ce composant est destiné à être exécuté, la durée d'exécution de chaque programme étant obtenue à partir des durées d'exécution des fonctions implémentant les opérations appelées par ce programme. De manière optionnelle également, chaque composant comporte du code machine fait d'instructions élémentaires, et le procédé comporte en outre : - l'obtention des durées de traitement par chaque machine informatique des instructions élémentaires de chaque composant destiné à être exécuté par cette machine informatique, les caractéristiques d'exécution de la machine informatique comportant les durées de traitement. De manière optionnelle également, pour au moins une machine informatique, les durées de traitement des instructions élémentaires sont évaluées par un logiciel de mesure exécuté par cette machine informatique. De manière optionnelle également, les machines informatiques sont reliées entre elles par au moins un lien de communication, et le procédé comporte en outre : - l'obtention de la latence de chaque lien de communication, les caractéristiques d'exécution d'une machine informatique comportant la latence de chaque lien de communication reliant cette machine. De manière optionnelle également, l'application comporte plusieurs programmes, chacun associé à une certaine priorité, et le procédé comporte en outre : la sélection des programmes de priorités les plus élevées, tels que, lorsque ces programmes sont exécutés à la chaîne, la durée totale d'exécution reste inférieure à chacune de leurs durées maximale d'exécution, dans le cas où au moins un programme n'est pas sélectionné, la génération du résultat de validation indiquant que le temps de réponse de l'application n'est pas validé. Il est également proposé un procédé de déploiement d'une application, comportant : la mise en oeuvre d'un procédé selon l'invention de validation du temps de réponse de l'application, en l'absence de résultat de validation indiquant que le temps de réponse de l'application n'est pas validé, le déploiement de l'application par l'installation des composants et du ou des programmes sur leurs machines informatiques respectives, en présence d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé, l'interruption du déploiement de l'application et/ou l'affichage d'un message d'erreur et/ou l'écriture dans un fichier de compte-rendu d'une entrée indiquant que le temps de réponse de l'application n'est pas validé. Il est également proposé un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé selon l'l'invention de validation du temps de réponse d'une application, ou bien d'un procédé selon l'invention de déploiement d'une application, lorsque ledit programme d'ordinateur est exécuté sur un ordinateur. Il est également proposé un dispositif de validation du temps de réponse d'une application destinée à être déployée sur des machines informatiques en réseau, l'application comportant : des composants implémentant une ou plusieurs opérations de service, chaque opération étant implémentée par une fonction du composant, et au moins un programme implémentant une composition d'opérations, au moyen d'appels aux fonctions implémentant les opérations de la composition, les composants et le ou les programmes étant destinés à être exécutés chacun par une machine informatique, le dispositif comportant : une unité d'obtention de caractéristiques d'exécution propre à chaque machine informatique, une unité d'évaluation de la durée d'exécution de chaque programme à partir des caractéristiques d'exécution des machines informatiques, une unité de comparaison de la durée d'exécution de chaque programme avec une durée maximale prédéterminée d'exécution associée à ce programme, une unité de génération, dans le cas où la durée d'exécution d'au moins un programme est supérieure à sa durée maximale d'exécution, d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé Il est également proposé un dispositif de déploiement d'une application, comportant : un dispositif selon l'invention de validation du temps de réponse de l'application, une unité de déploiement de l'application par l'installation des composants et du ou des programmes sur leurs machines informatiques respectives, en l'absence de résultat de validation indiquant que le temps de réponse de l'application n'est pas validé, une unité d'interruption du déploiement de l'application et/ou d'affichage d'un message d'erreur et/ou d'écriture dans un fichier de compte-rendu d'une entrée indiquant que l'application est invalide, en présence d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé. L'invention sera mieux comprise à l'aide de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : la figure 1 représente schématiquement la structure générale d'une installation informatique selon un mode de réalisation de l'invention, la figure 2 représente schématiquement un découpage fonctionnel en services d'une application destinée à être déployée, la figure 3 représente schématiquement une implémentation des services de la figure 2 en composants de l'application, la figure 4 illustre les étapes successives d'un procédé de déploiement de l'application, selon un mode de réalisation de l'invention, et la figure 5 représente schématiquement la structure générale de l'installation informatique de la figure après déploiement de l'application. En référence à la figure 1, une installation informatique 100 selon l'invention va à présent être décrite. L'installation informatique 100 comporte tout d'abord une machine 102 de déploiement d'une application. L'application est de préférence une application temps réel. Comme cela sera expliqué plus en détail plus loin, l'application est destinée à être déployée sur des machines informatiques de l'installation informatique 100. L'application comporte des composants et au moins un programme utilisant les composants pour réaliser une fonctionnalité souhaitée de l'application. Les composants et le ou les programmes sont destinés à être exécutés chacun par une des machines informatiques. La machine de déploiement 102 est munie d'une unité de traitement 102A, d'une mémoire vive 102B, d'une mémoire de masse 102C et d'une interface réseau 102D. L'installation informatique 100 comporte en outre des machines informatiques 106, 108 destinées à exécuter chacune au moins un composant et/ou au moins un programme de l'application. Chaque machine d'exécution 106, 108 est munie d'une unité de traitement 106A, respectivement 108A, d'une mémoire vive 106B, respectivement 108B, d'une mémoire de masse 106C, respectivement 108C, d'une première interface réseau 106D, respectivement 108D, et d'une seconde interface réseau 106E, respectivement 108E. Dans l'exemple décrit, les secondes interfaces réseau 106E, 108E sont des interfaces InfiniBand (marque déposée). Les machines informatiques 102, 106, 108 sont des ordinateurs au sens large. Il s'agit par exemple de serveurs, de tablettes ou bien encore de téléphones intelligents (de l'anglais « smartphones »). Les unités de traitement 102A, 106A, 108A sont destinées à exécuter des instructions de programme d'ordinateur et comportent par exemple chacune un ou plusieurs processeurs ou bien un ou plusieurs microprocesseurs à un ou plusieurs coeurs. Les mémoires vives 102B, 106B, 108B sont destinées à contenir de manière provisoire les données traitées lors de l'exécution de programmes d'ordinateur. Les mémoires vives 102B, 106B, 108B comportent par exemple de la mémoire à accès direct (de l'anglais « Random Access Memory » ou RAM). Les mémoires de masse 102C, 106C, 108C sont destinées à contenir des données sur une longue durée, et en particulier lors de la mise hors tension des machines informatiques 102, 106, 108. Les mémoires de masse 102C, 106C, 108C comportent par exemple un disque dur, un lecteur/enregistreur de disque muni d'un disque, tel qu'un disque CD ou un disque DVD, ou bien encore un disque électronique (de l'anglais « Solid State Drive » ou SSD). L'installation informatique 100 comporte en outre des liens de communication 110, 112, 114. Le premier lien de communication 110 est une liaison reliant l'interface réseau 102D de la machine de déploiement 102 à l'interface réseau 106D de la première machine d'exécution 106. Le deuxième lien de communication 112 est une liaison reliant l'interface réseau 102D de la machine de déploiement 102 à l'interface réseau 108D de la seconde machine d'exécution 108. Le troisième lien de communication 114 est une liaison InfiniBand reliant l'interface InfiniBand 106E de la première machine d'exécution 106 à l'interface InfiniBand 108E de la seconde machine d'exécution 108. L'installation informatique 100 comporte en outre un intergiciel (de l'anglais « middleware ») de déploiement de l'application. L'intergiciel comporte une première partie, appelée intergiciel principal 116, installée sur la machine de déploiement 102. L'intergiciel principal 116 est enregistré dans la mémoire de masse 102C et comporte des instructions destinées à être chargées dans la mémoire vive 102B pour être exécutées par l'unité de traitement 102A afin de réaliser les étapes correspondantes du procédé de déploiement qui sera décrit par la suite. L'intergiciel comporte en outre deux autres parties, appelées intergiciels auxiliaires 120, 122, respectivement installées sur les machines d'exécution 106, 108. Les intergiciels auxiliaires 120, 122 sont respectivement enregistrés dans les mémoires de masse 106C, 108C et comportent des instructions destinées à être respectivement chargées dans les mémoires vives 106B, 108B pour être respectivement exécutées par les unités de traitement 106A, 108A afin de réaliser les étapes correspondantes du procédé de déploiement qui sera décrit par la suite. De préférence, l'intergiciel présente une interface homme/machine permettant à un utilisateur de lui fournir des informations nécessaires au déploiement de l'application. Cette interface homme/machine comporte par exemple une interface système en mode texte (de l'anglais « shell ») ou bien une interface graphique. L'installation informatique 100 comporte en outre un logiciel de mesure 124 installé sur la seconde machine d'exécution 108. Le logiciel de mesure 124 est enregistré dans la mémoire de masse 108C et comporte des instructions destinées à être chargées dans la mémoire vive 108B pour être exécutées par l'unité de traitement 108A afin de réaliser les étapes correspondantes du procédé de déploiement qui sera décrit par la suite. L'installation informatique 100 comporte en outre des première et seconde machines virtuelles 126, 128 respectivement installées sur les première et seconde machines d'exécution 106, 108. Les machines virtuelles 126, 128 sont des programmes d'ordinateur respectivement enregistrés dans les mémoires de masse 106C, 108C et comportant des instructions destinées à être respectivement chargées dans les mémoires vives 106B, 108B pour être respectivement exécutées par les unités de traitement 106A, 108A afin de simuler chacune une machine informatique. Dans l'exemple décrit, les machines virtuelles 126, 128 sont des machines virtuelles Java (marque déposée) temps réel. En référence à la figure 2, un découpage fonctionnel de l'application en services va à présent être décrit. De manière générale, l'application utilise plusieurs services offrant chacun au moins une opération. Chaque opération peut nécessiter (c'est-à-dire appeler) une ou plusieurs opérations d'un autre service. Dans l'exemple décrit, l'application est découpée fonctionnellement en trois services SCalcul, Sminuteur et SDonnées. Le service SCalcul est destiné à réaliser un calcul et offre pour cela une opération Calculer. Le service SMinuteur est destiné à déclencher le calcul et offre pour cela une opération DéclencherCalcul. Le service SDonnées est destiné à récupérer le résultat du calcul et offre pour cela une opération RécupérerRésultat. En référence à la figure 3, une implémentation des services en composants va à présent être décrite. De manière générale, un composant est un programme d'ordinateur implémentant les opérations d'un ou plusieurs services. Les composants sont donc du code machine fait d'instructions élémentaires provenant de la compilation de code source écrit dans un langage informatique, tel que le langage Java, C, C++, ou bien Ada. Chaque composant comporte des fonctions (appelées « méthodes » dans la programmation orientée objet). Des premières fonctions implémentent les opérations des services, tandis que les autres fonctions sont utilisées par les premières fonctions pour réaliser les opérations. Par ailleurs, les composants peuvent être regroupés en composants plus gros, appelés parfois « composites ». Dans l'exemple décrit, les services de l'application sont implémentés en deux composants CMinuteur, CCalcul. Le premier composant CMinuteur implémente les services SMinuteur et SDonnées, tandis que le second composant CCalcul implémente le service SCalcul. Dans l'exemple décrit, les composants CMinuteur et CCalcul sont du code machine pour machine virtuelle Java, également appelée JVM (de l'anglais « Java Virtual Machine »), et proviennent donc de la compilation de code source écrit en Java. En référence à la figure 4, un procédé 400 de déploiement de l'application va à présent être décrit. Au cours d'une étape 402, l'intergiciel principal 116 obtient une description D1 de l'environnement matériel de l'application. La description D1 indique tous d'abord les machines d'exécution 106, 108, c'est-à-dire les machines informatiques destinées à exécuter l'application. La description D1 indique en outre les ressources de chaque machine d'exécution 106, 108. Ces ressources sont divisées entre ressources quantifiables et ressources partagées. Les ressources quantifiables sont celles qui peuvent être représentées par une quantité pouvant être consommée en tout ou en partie lors de l'exécution d'un composant. Les ressources quantifiables comportent par exemple la mémoire vive disponible, la mémoire de masse disponible sont utilisées intégralement par un ou plusieurs composants. Il s'agit par exemple d'une interface réseau, d'une unité de traitement d'un type particulier, ou bien encore d'un logiciel installé. La description D1 indique en outre les liens de communication pouvant être utilisés pour l'exécution de l'application. Dans l'exemple décrit, la description D1 comporte les informations suivantes : Machine d'exécution 106 : 192 GB de mémoire vive 106B (ressource quantifiable) machine virtuelle Java temps réel 126 (ressource partagée) interface InfiniBand 106E (ressource partagée) Machine d'exécution 108 : 32 GB de mémoire vive 108B (ressource partagée) machine virtuelle Java temps réel 128 (ressource partagée) interface InfiniBand 108E (ressource partagée) Lien de communication 114 entre les interfaces InfiniBand 106E, 108E : - de type InfiniBand (ressource partagée) - débit de 56 Gb/s (ressource quantifiable) Au cours d'une étape 404, l'intergiciel principal 116 obtient une description D2 de modes d'exécution de l'application. La description D2 indique un ou plusieurs modes d'exécution, chacun deux indiquant les machines informatiques et les ressources de ces machines informatiques pouvant être utilisées par l'application. Dans l'exemple décrit, la description D2 comporte un seul mode d'exécution, appelé mode normal, dans lequel les deux machines 106, 108 et toutes leurs ressources peuvent être utilisées. Au cours d'une étape 406, l'intergiciel principal 116 obtient une description D3 des services de l'application. La description D3 indique les services SCalcul, SMinuteur, SDonnées utilisés par l'application, ainsi que les opérations de chacun d'eux. Dans l'exemple décrit, la description D3 comporte les informations suivantes : Service SCalcul : - Opération Calculer Service SMinuteur : - Opération DéclencherCalcul Service SDonnées : - Opération RécupérerRésultat La description D3 peut en outre comporter d'autres informations pour chaque opération, telles que les entrées et sorties de l'opération (type de données, taille, etc.) et des conditions sur ces entrées et sorties (par exemple, entrée non vide, etc.). Au cours d'une étape 408, l'intergiciel principal 116 obtient une description D4 des composants de l'application. Chaque composant peut faire appel à des opérations implémentées par d'autres composants. La description D4 indique les composants CMinuteur, CCalcul de l'application. En outre, la description D4 indique la machine d'exécution 106, 108 sur laquelle chaque composant CMinuteur, CCalcul est destiné à être déployé, ainsi que les services fournis et les services requis par le composant. Par ailleurs, la description D4 indique les ressources requises par chaque composant CMinuteur, CCalcul. Dans le cas d'une ressource quantifiable, la description D4 indique la quantité de ressource requise. Dans l'exemple décrit, la description D4 comporte les informations suivantes : Composant CMinuteur : machine d'exécution 108 services fournis : SMinuteur, SDonnées services requis : SCalcul ressources requises : - 1 MB de mémoire vive - une interface InfiniBand - une JVM temps réel Composant CCalcul : - machine d'exécution 106 - services fournis : SCalcul - services requis : (aucun) - ressources requises : - 10 MB de mémoire vive - une interface InfiniBand - une JVM temps réel Au cours d'une étape 410, l'intergiciel principal 116 obtient une description D5 d'une politique de déploiement de l'application. La description D5 indique tout d'abord l'ordre dans lequel les composants CMinuteur, Cdonnées doivent être déployés. Elle indique en outre les actions à entreprendre lorsque le temps de réponse de l'application n'est pas validé, comme cela sera expliqué par la suite. Au cours d'une étape 412, l'intergiciel principal 116 obtient une description D6 du ou des programmes de l'application. Chaque programme de l'application correspond à une composition d'opérations implémentées par les composants. De préférence, un seul programme peut être exécuté à la fois. La description D6 indique chaque programme de d'application, ainsi que la machine d'exécution 106, 108 sur laquelle il est destiné à être déployé. La description D6 indique en outre une durée maximale prédéterminée d'exécution de chaque programme. La description D6 indique par ailleurs la composition des opérations implémentée par chaque programme. Cette composition est par exemple indiquée sous la forme de pseudo-code et comporte des appels à des opérations de services implémentés par les composants CMinuteur, CCalcul de l'application. La description D6 indique en outre le langage informatique dans lequel le pseudo-code est destiné à être traduit. Dans l'exemple décrit, la description D6 comporte les informations suivantes : Programme (PMinuteur) : - machine d'exécution 108 - durée maximale d'exécution : 250 ms - Composition des opérations : Invoquer SMinuteur -> « DeclencherCalcul » ; Résultat := SDonnees -> « RecupererRésultat » ; Afficher Résultat à l'écran ; - Langage informatique : Java Les descriptions D1 à D6 précédentes sont généralement générées par un utilisateur qui les fourni à l'intergiciel principal 116 par exemple sous la forme de fichiers. Les fichiers sont alors de préférence écrits dans un langage à balises, tel que le langage XML ou une variante du langage XML. Au cours d'une étape 414, l'intergiciel principal 116 traduit le pseudo-code du ou des programmes en code source rédigé dans le langage informatique indiqué dans la description D6 de la ou des programmes de l'application, puis compile le code source en code machine. Dans l'exemple décrit, le programme PMinuteur est ainsi d'abord traduit en code source Java, puis compiler en code machine Java. Au cours d'une étape 416, l'intergiciel principal 116 obtient le mode d'exécution à utiliser, appelé mode en cours. Le mode d'exécution à utiliser est par exemple indiqué, avant le déploiement de l'application, à l'intergiciel principal 116 par un utilisateur. Au cours d'une étape 418, l'intergiciel principal 116 met en oeuvre un procédé de validation du temps de réponse de l'application comportant les étapes 420 à 430 suivantes. Au cours d'une étape 420, l'intergiciel principal 116 obtient, pour chaque machine d'exécution 106, 108, des caractéristiques d'exécution de programme par cette machine. L'intergiciel principal 116 enregistre ces caractéristiques, par exemple dans la mémoire de masse 102C pour pouvoir les réutiliser. Les caractéristiques d'exécution d'une machine comportent tout d'abord les durées de traitement des instructions élémentaires par la machine d'exécution. Les instructions élémentaires, également appelées instructions machines, sont les instructions de base qu'une unité de traitement peut traiter. L'intergiciel principal 116 peut par exemple obtenir une durée de traitement pour chaque instruction élémentaire. En variante, il peut obtenir une même durée de traitement pour toutes les instructions élémentaires, par exemple la durée de traitement la plus longue. Les caractéristiques d'exécution d'une machine comportent en outre les latences du ou des liens de communication 114 reliant cette machine à d'autres machines d'exécution 106, 108. La latence correspond au délai entre l'envoi d'un message à une extrémité du lien de communication et sa réception à l'autre extrémité. Les caractéristiques d'exécution d'une machine comportent en outre la durée de commutation entre deux tâches en cours d'exécution sur la machine. Dans l'exemple décrit, les caractéristiques d'exécution de la seconde machine d'exécution 108 sont mesurées par le logiciel de mesure 124 qui les transmet ensuite à l'intergiciel principal 116. Le logiciel de mesure 124 évalue ainsi les durées de traitement des instructions élémentaires du composant CMinuteur par la machine d'exécution 108, la durée de commutation entre deux tâches en cours d'exécution de la machine d'exécution 108, et la latence du lien de communication 114 au travers de l'interface 108D. Ces durées et la latence sont par exemple mesurées par la répétition de tests. La valeur finale retenue est de préférence la plus mauvaise valeur. Par exemple, pour mesurer la durée de traitement d'une instruction élémentaire, le logiciel de mesure 124 fournit plusieurs fois cette instruction élémentaire à l'unité de traitement correspondante et mesure à chaque fois le temps de traitement. La durée de traitement retenue est alors la plus élevée des mesures. Dans l'exemple décrit où les composants sont destinés à être exécutés par des machines virtuelles Java, l'unité de traitement à laquelle le logiciel de mesure 124 fournit les instructions élémentaires est l'unité de traitement virtuelle de la machine virtuelle Java. En outre, dans l'exemple décrit, pour évaluer des caractéristiques d'exécution pour la première machine d'exécution 106, l'intergiciel principal 116 utilise celles reçues pour la seconde machine d'exécution 108 et les transpose à la première machine d'exécution 106. Par exemple, comme le lien de communication 114 relie les deux machines d'exécution 106, 108, la même valeur de latence peut être utilisée. En outre, si les unités de traitement 106A, 108A sont similaires, les durées de traitement des instructions élémentaires et la durée de commutation entre tâches de la seconde machine d'exécution 108 peuvent être utilisées pour la première machine d'exécution 106. Si les unités de traitement 106A, 108A ne sont pas similaires, l'intergiciel principal 116 peut par exemple utiliser des règles prédéterminées de transposition. Au cours d'une étape 422, l'intergiciel principal 116 obtient la durée d'exécution de chaque fonction de chaque composant CMinuteur, CCalcul. Dans l'exemple décrit, l'intergiciel principal 116 évalue la durée d'exécution au pire cas de chaque fonction à partir des caractéristiques d'exécution de la machine d'exécution 106,108 sur laquelle le composant est destiné à être exécuté. L'intergiciel principal 116 utilise en particulier les durées de traitement des instructions élémentaires et, éventuellement, la ou les latences obtenues. Pour évaluer la durée d'exécution d'une fonction, l'intergiciel principal 116 peut par exemple analyser le code machine constituant le composant pour générer, pour chaque fonction du composant, un graphe de flot de contrôle (de l'anglais « Control Flow Graph » ou CFG). Dans un tel graphe, chaque sommet correspond à un bloc d'instructions qui se suivent sans saut ni cible de saut. Ainsi, la durée d'exécution de chaque sommet correspond à la somme des durées de traitement des instructions élémentaires du sommet. En outre, la durée d'exécution d'un chemin du graphe (qui correspond à une exécution particulière de la fonction) est égale à la somme des durées d'exécution des sommets par lesquels le chemin passe. L'intergiciel principal 116 évalue ainsi la durée d'exécution de la fonction en déterminant le chemin du graphe ayant la durée d'exécution la plus longue. Si la fonction comporte un appel à une opération d'un autre composant, l'intergiciel principal 116 peut par exemple enregistrer une expression représentant le calcul de la durée d'exécution. Dans cette expression, la durée d'exécution de l'appel est laissée comme variable non connue. Lorsque les durées d'exécution des fonctions de cet autre composant sont connues, l'intergiciel principal 116 évalue alors l'expression en y intégrant la durée d'exécution de l'opération appelée. En outre, lorsque les deux composants sont destinés à être installés sur deux machines d'exécution différentes, l'intergiciel principal 116 intègre la latence du lien de communication reliant les deux machines d'exécution. Par exemple, la durée de l'opération DéclencherCalcul sera évaluée de la manière suivante : Durée d'exécution du code machine de l'opération DéclencherCalcul par la machine d'exécution 108 + latence de l'interface 108E (pour l'appel à l'opération Calculer) + durée d'exécution du code machine de l'opération Calculer par la machine d'exécution 106 + latence de l'interface 106E (pour la réponse de l'opération Calculer) Au cours d'une étape 424, l'intergiciel principal 116 obtient la durée d'exécution de chaque programme de l'application. Dans l'exemple décrit, l'intergiciel principal 116 évalue la durée d'exécution de au pire cas de chaque programme PMinuteur à partir de l'analyse du code machine du programme, des durées d'exécution des fonctions implémentant les opérations appelées et de la ou des latences obtenues lorsque l'appel passe par un lien de communication. Par exemple dans l'exemple décrit, le programme PMinuteur appelle tout d'abord l'opération DéclencherCalcul, puis appelle l'opération RécupérerRésultat, puis affecte le résultat récupéré dans une variable « Résultat », puis affiche cette variable à l'écran. Ainsi, la durée d'exécution du programme PMinuteur sera évaluée de la manière suivante : Durée de l'opération DéclencherCalcul + durée de l'opération RécupérerRésultat + durée du code machine implémentant l'affectation du résultat à la variable « Résultat » et affichant cette variable à l'écran. L'évaluation de la durée du code machine d'un programme est par exemple réalisée de la même manière que pour les fonctions des composants, c'est-à-dire en utilisant un graphe de flot et les durée de traitement des instructions élémentaires. Au cours d'une étape 426, l'intergiciel principal 116 compare la durée d'exécution de chaque programme PMinuteur avec la durée maximale d'exécution qui lui est associée dans la description D6. Si la durée d'exécution d'au moins un programme est supérieure à sa durée maximale d'exécution, le temps de réponse de l'application est considéré comme non validé. Si l'application comporte plusieurs programmes, l'intergiciel principal 116 réalise, au cours d'une étape 428, une analyse d'ordonnançabilité pour valider le temps de réponse de l'enchaînement de tous les programmes. Pour ce faire, l'intergiciel principal 116 sélectionne les programmes de priorités les plus élevées, tels que, lorsque ces programmes sont exécutées à la chaîne, la durée totale d'exécution reste inférieure à chacune de leurs durées d'exécution maximale prédéterminée. De préférence, la durée totale d'exécution prend en compte les durées de commutation entre tâches obtenues par l'intergiciel principal 116, en insérant ces durées entre celles d'exécution des programmes. Si au moins un programme n'est pas sélectionné, le temps de réponse de l'application est considéré comme non validé. Par exemple, en considérant une application comportant trois programmes A, B, C de priorités décroissantes, associés chacun à une durée maximal d'exécution de 100 ms et en supposant que leurs durées d'exécution ont été évaluées à respectivement 30 ms, 60ms et 20ms et que les durées de commutation sont de 2ms, l'intergiciel principal 116 sélectionnerait les deux premiers programmes A, B. En effet, l'exécution de ces deux programmes à la chaîne est évaluée à 30ms + 2ms + 60ms soit 92ms, ce qui est inférieur à la durée maximale d'exécution de chacun d'eux. En revanche, en ajoutant le troisième programme, la durée totale d'exécution serait de 30ms + 2ms + 60ms + 2ms + 20ms soit 114ms. Ainsi, la durée maximale d'exécution pour les programmes ne pourrait plus être respectée. Dans l'exemple décrit où l'application ne comporte qu'un seul programme PMinuteur, le procédé passe directement à l'étape 430. Au cours d'une étape 430, l'intergiciel principal 116 génère un résultat de validation. Si le temps de réponse de l'application n'est pas validé suite à l'étape 426 ou 428, le résultat de validation l'indique. Le résultat de validation peut en outre indiquer l'étape 426 et/ou 428 ayant conduit à ne pas valider le temps de réponse de l'application, ainsi que chaque programme dont la durée d'exécution a été trouvée supérieure à la durée maximale d'exécution au cours de l'étape 426, et chaque programme qui n'a pas été sélectionné au cours de l'étape 428. Dans le cas contraire, le résultat de validation indique que le temps de réponse de l'application est validé. Si le résultat de validation indique que le temps de réponse n'est pas validé, au cours d'une étape 432, l'intergiciel principal 116 réalise l'action prévue dans ce cas dans la description D5 des politiques de déploiement. Par exemple, l'intergiciel principal 116 interrompt le déploiement de l'application et/ou affiche un message d'erreur et/ou écrit dans un fichier de compte- rendu d'une entrée reprenant le résultat de validation. Si le déploiement n'est pas interrompu, le procédé continue à l'étape 434. Si le résultat de validation indique que le temps de réponse est validé, le procédé continue à l'étape 434. Au cours d'une étape 434, l'intergiciel principal 116 consulte la description D5 pour déterminer le prochain le composant à installer, appelé composant en cours. Dans l'exemple décrit, le composant CMinuteur doit être installé en premier, et le composant CCalcul en second. Au cours d'une étape 436, l'intergiciel principal 116 vérifie que la machine d'exécution sur laquelle le composant en cours doit être déployé selon la description D4, appelée machine en cours, est autorisée dans le mode en cours. Au cours d'une étape 438, l'intergiciel principal 116 obtient la quantité disponible de chaque ressource quantifiable de la machine en cours. Par exemple, si le composant en cours est le premier à être déployé sur la machine en cours 106, 108, l'intergiciel auxiliaire 120, 122 installé sur la machine en cours 106, 108 mesure la quantité disponible de chaque ressource quantifiable et transmet cette mesure à l'intergiciel principal 116. Si le composant en cours n'est pas le premier à être déployé sur la machine en cours 106, 108, l'intergiciel principal 116 prend la quantité de ressource quantifiable disponible qu'il a calculée, durant l'étape 442 décrite plus loin, suite aux déploiements des précédents composants. Dans l'exemple décrit, ce dernier cas ne se produit pas, car il n'y a qu'un seul composant par machine d'exécution. Ainsi, lors du déploiement du composant CMinuteur, l'intergiciel principal 116 obtient la quantité disponible de mémoire vive de la machine d'exécution 108 mesurée par le second intergiciel auxiliaire 122. Lors du déploiement du composant CCalcul, il obtient la quantité disponible de mémoire vive de machine d'exécution 106 mesurée par le premier intergiciel auxiliaire 120. Au cours d'une étape 440, l'intergiciel principal 116 vérifie que la machine en cours possède les ressources qui sont la fois autorisées par le mode en cours et requises par le composant en cours selon la description D4 des composants de l'application. Dans l'exemple décrit, lors du déploiement du composant CMinuteur, l'intergiciel principal 116 vérifie que la machine d'exécution 108 possède 1 MB de mémoire vive, une interface InfiniBand et une JVM temps réel. Lors du déploiement du composant CCalcul, l'intergiciel principal 116 vérifie que la machine d'exécution 106 possède 10 MB de mémoire vive, une interface InfiniBand et une JVM temps réel. Si une ressource requise est manquante, l'intergiciel principal 116 interrompt par exemple le déploiement. Si la machine en cours ne possède pas les ressources requises, l'intergiciel principal 116 réalise l'action prévue dans ce cas dans la description D5. Cette action comporte par exemple : l'interruption du déploiement de l'application et/ou l'affichage d'un message d'erreur et/ou l'écriture dans un fichier de compte-rendu d'une entrée d'erreur. Au cours d'une étape 442, l'intergiciel principal 116 mets à jour les quantités disponibles des ressources quantifiables en enlevant la quantité nécessaire au composant en cours, telle qu'indiquée dans la description d'implémentation. Dans l'exemple décrit, lors du déploiement du composant CMinuteur, l'intergiciel principal 116 enlève 1 MB à la quantité de mémoire vive qu'il a obtenu du second intergiciel auxiliaire 122. Lors du déploiement du composant CCalcul, l'intergiciel principal 116 enlève 10 MB à la quantité de mémoire vive qu'il a obtenu du premier intergiciel auxiliaire 122. Au cours d'une étape 444, l'intergiciel principal 116 transmet le composant en cours à la machine d'exécution 106, 108 sur laquelle il doit être installé, cette dernière enregistrant le composant en cours dans sa mémoire de masse 106C, 108C. De préférence, l'ensemble des descriptions ainsi que les binaires du ou des composants destinés à être exécutés sur une même machine d'exécution sont assemblés pour former une unité de déploiement. Plusieurs formats sont supportés : zip, tar, tar.gz, jar, répertoire non compressé, etc. Ces unités de déploiement peuvent être placées dans un dépôt informatique pour être réutilisées plus tard. Au cours d'une étape 446, l'intergiciel principal 116 vérifie si tous les services requis par le composant en cours sont disponibles. Si ce n'est pas le cas, au cours d'une étape 448, l'intergiciel principal 116 note le composant en cours comme invalide et retourne à l'étape 434 pour installer le composant suivant. Si c'est le cas, au cours d'une étape 450, l'intergiciel principal 116 note le composant en cours comme valide et publie ses services. La publication des services comporte l'enregistrement des services, avec leurs opérations, dans un annuaire. L'annuaire est par exemple enregistré dans la mémoire de masse 102C, ou bien dans l'importe quel entrepôt informatique accessible par la machine de déploiement 102. L'annuaire indique ainsi les opérations disponibles pour être utilisées. En outre, l'intergiciel principal 116 retourne à l'étape de vérification 446 pour chacun des composants qui ont précédemment été notés comme invalides. En effet, la validation du composant en cours a peut être résolu les dépendances de ces précédents composants. Au cours d'une étape 452, lorsque tous les composants sont valides, l'intergiciel principal 116 transmet chaque programme de l'application à la machine d'exécution 106, 108 sur laquelle il doit être installé, cette dernière enregistrant le programme dans sa mémoire de masse 106C, 108C. On notera que chaque programme de l'application est sous forme de code machine suite à la compilation de l'étape 414. Dans l'exemple écrit, l'intergiciel principal 116 transmet le programme PMinuteur à la machine d'exécution 108. Au cours d'une étape 454, chaque composant et chaque programme de l'application est chargé en mémoire vive par l'intergiciel auxiliaire 120, 122 de la machine d'exécution 106, 108 sur laquelle il est enregistré. Les intergiciels auxiliaires 120, 122 gardent une référence vers chaque programme de l'application, pour par exemple en interrompre l'exécution, l'arrêter ou inspecter son état. Dans l'exemple décrit, pour réaliser l'étape 454, les intergiciels auxiliaires 120, 122 chargent tout d'abord respectivement les machines virtuelles Java 126, 128 dans les mémoires vives 106B, 108B. Les machines virtuelles Java 126, 128 sont alors respectivement exécutées dans des processus notés 126* et 128*. Les intergiciels auxiliaires 120, 122 chargent ensuite les composants CMinuteur, CCalcul et le programme PMinuteur dans des processus virtuels Java, notés CMinuteur*, CCalcul* et PMinuteur*. Ces processus virtuels Java sont contenus dans les processus 126*, 128* des machine virtuelles Java. Plus précisément, le premier intergiciel auxiliaire 120 charge le composant CCalcul dans le processus 126* de la première machine virtuelle Java 126, tandis que le second intergiciel auxiliaire 122 charge le composant CMinuteur et le programme PMinuteur dans le processus 128* de la seconde machine virtuelle Java 128. À la fin de l'étape 454, l'application est déployée. Le résultat obtenu est représenté sur la figure 5. Les flèches en pointillés indiquent les appels du programme en cours d'exécution PMinuteur* aux composants en cours d'exécution CMinuteur*, CCAIcuI* afin d'utiliser leurs opérations. Les références 120* et 122* indiquent les intergiciels auxiliaires 120, 122 en cours d'exécution. La référence 124* indique le logiciel de mesure 124 en cours d'exécution. Il apparaît clairement qu'un procédé de déploiement d'application tel que celui décrit précédemment permet de garantir le temps de réponse de l'application en fonction des machines d'exécution, sans nécessiter de connaître les durées d'exécution de service au préalable. On notera par ailleurs que l'invention n'est pas limitée au mode de réalisation décrit précédemment. Il apparaîtra en effet à l'homme de l'art que diverses modifications peuvent être apportées au mode de réalisation décrit ci-dessus, à la lumière de l'enseignement qui vient de lui être divulgué. Par exemple, les étapes précédentes pourrait être réalisées dans un autre ordre, du moment que ce nouvel ordre est techniquement possible. Dans les revendications qui suivent, les termes utilisés ne doivent pas être interprétés comme limitant les revendications au mode de réalisation exposé dans la présente description, mais doivent être interprétés pour y inclure tous les équivalents que les revendications visent à couvrir du fait de leur formulation et dont la prévision est à la portée de l'homme de l'art en appliquant ses connaissances générales à la mise en oeuvre de l'enseignement qui vient de lui être divulgué.5 REVENDICATIONS1. Procédé (418) de validation du temps de réponse d'une application destinée à être déployée sur des machines informatiques (106, 108) en réseau, l'application comportant : des composants (CCalcul, CMinuteur) implémentant une ou plusieurs opérations de service, chaque opération étant implémentée par une fonction du composant, et au moins un programme (PMinuteur) implémentant une composition d'opérations, au moyen d'appels aux fonctions implémentant les opérations de la composition, les composants (CCalcul, CMinuteur) et le ou les programmes (PMinuteur) étant destinés à être exécutés chacun par une machine informatique (106, 108), le procédé comportant : l'obtention (420) de caractéristiques d'exécution propre à chaque machine informatique (106, 108), l'évaluation (424) de la durée d'exécution de chaque programme (PMinuteur) à partir des caractéristiques d'exécution des machines informatiques (106, 108), la comparaison (426) de la durée d'exécution de chaque programme (PMinuteur) avec une durée maximale prédéterminée d'exécution associée à ce programme (PMinuteur), dans le cas où la durée d'exécution d'au moins un programme (PMinuteur) est supérieure à sa durée maximale d'exécution, la génération (430) d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé. 2. Procédé (418) selon la revendication 1, le procédé comportant en outre : l'évaluation (422) de la durée d'exécution de chaque fonction implémentant une opération d'un composant (CCalcul, CMinuteur) à partir des caractéristiques d'exécution de la machine informatique (106, 108) sur laquelle ce composant (CCalcul, CMinuteur) est destiné à être exécuté, la durée d'exécution de chaque programme (PMinuteur) étant obtenue à partir des durées d'exécution des fonctions implémentant les opérations appelées par ce programme (PMinuteur). 3. Procédé (418) selon la revendication 2, dans lequel chaque composant (CCalcul, CMinuteur) comporte du code machine fait d'instructions élémentaires, le procédé comportant en outre : l'obtention (420) des durées de traitement par chaque machine informatique (106, 108) des instructions élémentaires de chaque composant (CCalcul, CMinuteur) destiné à être exécuté par cette machine informatique, les caractéristiques d'exécution de la machine informatique comportant les durées de traitement. 4. Procédé (418) selon la revendication 3, dans lequel, pour au moins une machine informatique (108), les durées de traitement des instructions élémentaires sont évaluées par un logiciel de mesure (124) exécuté par cette machine informatique (108). 5. Procédé (418) selon l'une quelconque des revendications 1 à 4, dans lequel les machines informatiques (106, 108) sont reliées entre elles par au moins un lien de communication (114), le procédé comportant en outre : - l'obtention (420) de la latence de chaque lien de communication (114), les caractéristiques d'exécution d'une machine informatique (106, 108) comportant la latence de chaque lien de communication (114) reliant cette machine (106,108). 6. Procédé (418) selon l'une quelconque des revendications 1 à 5, dans lequel l'application comporte plusieurs programmes, chacun associé à une certaine priorité, le procédé comportant en outre : la sélection (428) des programmes de priorités les plus élevées, tels que, lorsque ces programmes sont exécutés à la chaîne, la durée totale d'exécution reste inférieure à chacune de leurs durées maximale d'exécution, dans le cas où au moins un programme n'est pas sélectionné, la génération du résultat de validation indiquant que le temps de réponse de l'application n'est pas validé. 7. Procédé (400) de déploiement d'une application, comportant : la mise en oeuvre d'un procédé (418) selon l'une quelconque des revendications 1 à 6 de validation du temps de réponse de l'application,en l'absence de résultat de validation indiquant que le temps de réponse de l'application n'est pas validé, le déploiement de l'application par l'installation des composants (CMinuteur, CCalcul) et du ou des programmes (PMinuteur) sur leurs machines informatiques respectives (106, 108), en présence d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé, l'interruption du déploiement de l'application et/ou l'affichage d'un message d'erreur et/ou l'écriture dans un fichier de compte-rendu d'une entrée indiquant que le temps de réponse de l'application n'est pas validé. 8. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 6 de validation du temps de réponse d'une application, ou bien d'un procédé selon la revendication 7 de déploiement d'une application, lorsque ledit programme d'ordinateur est exécuté sur un ordinateur. 9. Dispositif de validation du temps de réponse d'une application destinée à être déployée sur des machines informatiques (106, 108) en réseau, l'application comportant : des composants (CCalcul, CMinuteur) implémentant une ou plusieurs opérations de service, chaque opération étant implémentée par une fonction du composant, et au moins un programme (PMinuteur) implémentant une composition d'opérations, au moyen d'appels aux fonctions implémentant les opérations de la composition, les composants (CCalcul, CMinuteur) et le ou les programmes (PMinuteur) étant destinés à être exécutés chacun par une machine informatique (106, 108), le dispositif comportant : - une unité d'obtention de caractéristiques d'exécution propre à chaque machine informatique (106, 108), une unité d'évaluation (424) de la durée d'exécution de chaque programme (PMinuteur) à partir des caractéristiques d'exécution des machines informatiques (106, 108),une unité de comparaison de la durée d'exécution de chaque programme (PMinuteur) avec une durée maximale prédéterminée d'exécution associée à ce programme (PMinuteur), une unité de génération, dans le cas où la durée d'exécution d'au moins un programme (PMinuteur) est supérieure à sa durée maximale d'exécution, d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé 10. Dispositif de déploiement d'une application, comportant : un dispositif selon la revendication 9 de validation du temps de réponse de l'application, une unité de déploiement de l'application par l'installation des composants (CMinuteur, CCalcul) et du ou des programmes (PMinuteur) sur leurs machines informatiques respectives (106, 108), en l'absence de résultat de validation indiquant que le temps de réponse de l'application n'est pas validé, une unité d'interruption du déploiement de l'application et/ou d'affichage d'un message d'erreur et/ou d'écriture dans un fichier de compte-rendu d'une entrée indiquant que l'application est invalide, en présence d'un résultat de validation indiquant que le temps de réponse de l'application n'est pas validé.