Brevet FR2963840A1 — publié le 20120217

Procédé de monitoring d'une exécution d'un composant logiciel L'invention concerne le domaine de l'informatique, et, plus précisément, un procédé de monitoring d'une exécution d'un composant logiciel ainsi qu'un dispositif associé. Une architecture possible pour l'exécution de composants logiciels est celle définie dans le standard OSGI (Open Services Gateway Initiative). Dans une telle architecture, une plateforme centrale d'exécution de composants logiciels charge et exécute des composants logiciels de différentes provenances dont le code source n'a pas été nécessairement vérifié et/ou optimisé. Se pose ainsi la question du monitoring de l'exécution de ces composants logiciels. Le document de Tuukka Miettinen, intitulé "Resource monitoring and visualization of OSGI-based software components" (VT publications 685), disponible à l'adresse http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf aborde cette question dans le cas d'une plateforme OSGI. Il est par exemple nécessaire de pouvoir contrôler la consommation, par ces composants logiciels, des ressources de la plateforme OSGI: mémoire, puissance de calcul, descripteurs réseaux, etc. Le risque est grand en effet que certains de ces composants logiciels consomment trop de ressources, voire entraînent une paralysie de la plateforme. En particulier, il est nécessaire de pouvoir détecter quels sont les composants logiciels fortement consommateurs de ressources, de disposer d'un audit des ressources consommées par ces composants logiciels et éventuellement d'arrêter l'exécution des composants logiciels fautifs et/ou de les désintaller. Or les outils de monitoring existant sur de type de plateforme sont insuffisants pour mesurer finement les ressources consommées: on doit en effet pouvoir disposer aussi bien d'information sur la mémoire et la puissance de calcul consommée, que sur l'utilisation de descripteurs de fichiers, les variables statiques verrouillées, etc. En outre, il apparaît souhaitable que les outils de monitoring soient adaptables à tout composant logiciel exécutable sur la plateforme, quelle que soit sa provenance, et ce avec un minimum d'efforts de développement logiciel. Ce qui n'est pas le cas avec la solution décrite dans le document précité, qui, par exemple en page 30, paragraphe "byte code instrumentation (BCI)", indique que le code source de l'application à monitorer doit être modifié pour la collecte des informations désirées. Un des buts de l'invention est de remédier à des problèmes, inconvénients ou insuffisances de l'état de la technique et/ou d'y apporter des améliorations. L'invention concerne, selon un premier aspect, un procédé de monitoring d'une exécution d'un composant logiciel. Le procédé précité comprend: - une étape de déclenchement, au cours de l'exécution dudit composant logiciel, d'une exécution d'un greffon logiciel définissant une fonction de monitoring conçue pour fournir à un dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel, - une étape d'affichage d'au moins une information fournie au dispositif de monitoring par le greffon logiciel. Un greffon logiciel est un module logiciel qui est défini en utilisant une technologie de programmation par aspect. L'utilisation d'un greffon logiciel pour la définition et la mise en oeuvre d'une fonction de monitoring de composant logiciel rend la solution de monitoring non intrusive pour le programmeur du composant logiciel à monitorer: celui-ci n'a pas besoin d'avoir connaissance du code du greffon logiciel pour que le composant logiciel puisse être monitoré au moyen de ce greffon logiciel. En outre, un tel greffon logiciel est apte à monitorer l'exécution de tout composant logiciel. La solution de monitoring selon l'invention est ainsi adaptable au monitoring de tout composant logiciel, quelle que soit sa provenance, dès lors que ce composant logiciel respecte les interfaces de programmation de la plate-forme sous- jacente. L'approche programmation par aspect peut alors s'appliquer à ce composant logiciel. Enfin, un tel greffon logiciel définit, relativement à des opérations prédéfinies d'un code source d'un composant logiciel, quelle est ou quelles sont les fonctions à déclencher et quelles sont les informations à fournir au dispositif de monitoring lorsque des conditions, définies également par ce greffon logiciel, sont remplies au moment de l'exécution d'une telle opération. Dans le cadre de l'invention, la fonction définie par le greffon est une fonction de monitoring conçue pour fournir au un dispositif de monitoring une ou des informations sur l'exécution du composant logiciel monitoré. On peut ainsi finement monitorer l'exécution du composant logiciel et générer des informations sur son exécution et sa consommation de ressources, notamment être informé lorsque des événements suivants se produisent: surconsommation de ressources mémoire, de descripteurs réseau, d'inter-blocage entre composants, etc. Selon un mode de réalisation du procédé selon l'invention, ladite fonction de monitoring applique au moins une règle de monitoring définissant la ou les informations à fournir audit dispositif de monitoring et les conditions dans lesquelles cette ou ces informations sont à fournir. Tout type d'informations peut ainsi être remonté et les conditions dans lesquelles ces informations sont à remonter sont de tout type, définissables librement par le concepteur du greffon. Selon un mode de réalisation, le procédé selon l'invention comprend une étape de mise en oeuvre de moyens de sélection d'une règle de monitoring à utiliser, le greffon logiciel exécuté mettant en oeuvre une fonction de monitoring appliquant la règle sélectionnée. On rend ainsi paramétrable à souhait le monitoring de composants logiciels, puisqu'il suffit de disposer d'un greffon logiciel par fonction de monitoring que l'on désire appliquer. Selon un mode de réalisation du procédé selon l'invention, ledit greffon logiciel est utilisable pour le monitoring de plusieurs composants logiciels. En effet, le code de programme d'un greffon logiciel peut être défini sans connaissance du code de programme définissant le composant logiciel à monitorer. Il n'est en particulier pas nécessaire de créer un greffon spécifique pour un composant logiciel donné. Selon un mode de réalisation, le procédé selon l'invention comprend une étape de modification, au cours de l'exécution dudit composant logiciel, de la fonction de monitoring appliquée audit composant logiciel. L'invention permet ainsi d'adapter à la volée, c'est-à-dire au cours même de l'exécution du composant logiciel, la fonction de monitoring au composant logiciel à monitorer. Selon un mode de réalisation particulier, le procédé selon l'invention l'étape de modification de la fonction de monitoring appliquée comprend: - une étape d'arrêt de l'exécution dudit greffon logiciel, - une étape de déclenchement, au cours de l'exécution dudit composant logiciel, d'une exécution d'un autre greffon logiciel définissant une autre fonction de monitoring, conçue pour fournir au dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel et appliquant au moins une autre règle de monitoring. De manière simple et souple, une modification de fonction de monitoring revient à un remplacement d'un greffon logiciel par un autre. Ce remplacement peut s'effectuer en outre pendant l'exécution même du composant logiciel faisant l'objet du monitoring. En effet, il est possible de déclencher et/ou arrêter l'exécution d'un tel greffon logiciel au cours même de l'exécution du composant logiciel à monitorer, et ce sans avoir à interrompre même momentanément cette exécution. La solution selon l'invention offre ainsi des possibilités d'embrayage/débrayage de fonction de monitoring à la demande. L'intérêt étant pouvoir, à tout moment, observer sélectivement certains composants logiciels pour ensuite ne plus observer ces composants logiciels et en observer d'autres. Selon une implémentation préférée, les différentes étapes du procédé selon l'invention sont mises en oeuvre par un logiciel ou programme d'ordinateur, ce logiciel comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif de monitoring et étant conçu pour commander l'exécution des différentes étapes de ce procédé. En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la 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 le programme. Selon un deuxième aspect, l'invention concerne un dispositif de monitoring d'une exécution d'un composant logiciel, le dispositif comprenant - des moyens de déclenchement, au cours de l'exécution dudit composant logiciel, d'une exécution d'un greffon logiciel définissant une fonction de monitoring conçue pour fournir à un dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel, - des moyens d'affichage d'au moins une information fournie au dispositif de monitoring par le greffon logiciel. Selon un troisième aspect, l'invention concerne une plateforme d'exécution de composants logiciels, couplée à un dispositif de monitoring selon le deuxième aspect de l'invention, comprenant une interface pour exécuter, au cours de l'exécution d'un dit composant logiciel, un greffon logiciel définissant une fonction de monitoring conçue pour fournir audit dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de modules / composants logiciels. Un module logiciel ou 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, 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). D'autres buts, caractéristiques et avantages de l'invention apparaîtront à travers la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite par référence aux dessins annexés dans lesquels: - la figure 1 représente de manière schématique un système de communication intégrant un dispositif selon l'invention; - la figure 2 représente un organigramme d'un mode de réalisation du procédé selon l'invention. Le procédé de monitoring décrit ici fait appel à plusieurs technologies. Une première technologie est celle des plates-formes OSGi (Open Services Gateway Initiative). Ces plates-formes de service sont exploitées au travers d'interfaces logicielles (API, application program interface) formant une infrastructure logicielle (en anglais "framework") pour l'exploitation localement ou à distance de composants logiciels mettant en oeuvre ces services. Ces interfaces logicielles proposent notamment des fonctions de gestion de composants logiciels par le biais d'un répertoire de composants logiciels (nommé "registry") ainsi que des fonctions d'installation / désinstallation, d'exécution / arrêt, de modification de composants logiciels exécutés par une telle plateforme. Cette technologie est utilisable dans de nombreux domaines techniques, dont l'automobiles, l'automatisme industriel, les applications pour téléphones mobiles, la gestion de flottes de véhicules, etc. Une deuxième technologie est la programmation orientée aspect (AOP, aspectoriented programming). Cette technologie permet d'ajouter des fonctionnalités à modules logiciels déjà codés, sans que le programmeur de ce module logiciel n'ait besoin d'avoir connaissance de ces fonctionnalités. Elle repose sur la définition d'opérations prédéfinies, nommés points de jonction ("joint points" en anglais) susceptibles d'être exécutées au cours l'exécution du composant: par exemple, une entrée dans une boucle de traitement, un appel à une fonction, un retour à une fonction appelant une autre fonction, une initialisation de variables, une allocation mémoire, le démarrage ou arrêt du composant logiciel, etc. Relativement à ces points de jonctions sont définis un ensemble de conditions (appelés "pointcuts" en anglais) qui doivent être remplies au moment de l'exécution d'une telle opération pour qu'une fonction donnée (appelée "aspect", dans le contexte OAP) soit exécutée. Cette fonction est destinée à être mise en oeuvre par un greffon logiciel, c'est-à-dire un code de programme qui est chargé dynamiquement lorsque les conditions définies sont réunies et qui se greffe sur le code initial au point de jonction considéré. La programmation par aspect permet ainsi de spécifier les conditions d'exécution de greffons logiciels et de les gérer sans modifier le code du programme initial. Elle permet un développement procédant par différents niveaux d'abstraction, en précisant à chaque niveau d'abstraction les fonctions à exécuter, correspondant à une 6 exploitation particulière du code du programme initial dans un contexte donné. Une troisième technologie est celle du monitoring d'applications logicielles. Cette technologie a pour but de collecter des informations relatives à l'exécution d'une application, par exemple des informations sur les ressources consommées par cette application (mémoire, puissance de calcul du processeur, descripteurs de fichiers, etc) au cours de son exécution. L'invention tire profit de ces différentes technologies pour la mise en oeuvre d'une solution de monitoring hautement performante, permettant notamment un monitoring fin des composants logiciels constituant une application logicielle. L'invention permet par exemple le monitoring de composants logiciels exécutés sur une plateforme OSGI. Une architecture d'un système de monitoring utilisé pour la mise en oeuvre de l'invention est décrite par référence à la figure 1. Cette architecture comprend: - une plateforme 10 de service, pour l'exécution de composants logiciels; un répertoire 20 de composants logiciels, susceptibles d'être exécutés par la plateforme 10 de service; - une interface 15 de commande et d'accès aux services proposés par la plateforme 10; un dispositif de monitoring 30. La plateforme 10 est par exemple une plateforme OSGI, couplée au répertoire 20 de composants logiciels et intégrant une machine virtuelle Java pour l'exécution de composants logiciels codés en Java. La plateforme 10 comprend une mémoire 11 pour le chargement de code de composants logiciels et un processeur 11 pour exécuter de tels composants logiciels. Le répertoire 20 est conçu pour le stockage et le référencement de composants logiciels B1, B2 susceptibles d'être chargés et exécutés par la plateforme 10. Il est géré par l'intermédiaire de la plateforme 10 de service. Le répertoire 20 est également conçu pour le stockage et le référencement de greffon logiciels RAI, R1B susceptibles d'être chargés et exécutés par la plateforme 10, conçus pour le monitoring de composants logiciels B1, B2 exécutés par cette plateforme. De manière connue, une telle plateforme OSGi comprend une interface de commande 15 pour définir quel composant est à charger et pour déclencher le chargement et l'exécution de ce composant par la plateforme. Via l'interface de commande 15, un dispositif distant, tel que le dispositif de monitoring 30, est susceptible de communiquer avec la plateforme 10 de service, de gérer les composants logiciels du répertoire 20 et de déclencher et monitorer l'exécution d'un ou plusieurs de ces composants logiciels. Le dispositif de monitoring 30 est ainsi conçu pour exploiter la plateforme 10 au travers de l'interface 15 de commande. Le dispositif de monitoring 30 comprend dans ce but une interface 35 de communication avec la plateforme 10 via l'interface 15 de commande. La communication entre l'interface 35 et l'interface 15 est établie à travers un réseau de télécommunication ou à travers un lien local de communication, filaire ou non filaire. Le dispositif de monitoring 30 comprend en outre un composant de monitoring 37 conçu pour, lorsqu'il couplé à la plateforme 10 de service, dialoguer avec la plateforme 10 au travers des interfaces 15 et 35, afin de gérer les composants logiciels du répertoire 20, de déclencher et monitorer l'exécution d'un ou plusieurs de ces composants logiciels et ainsi mettre en oeuvre des fonctions de monitoring. Le composant de monitoring 37 est conçu pour exécuter des modules de monitoring RB1, RB2, chacun de ces modules étant couplé avec un greffon logiciel RA1, RA2 exécuté sur la plateforme 10. Par exemple le module de monitoring R1B est conçu pour dialoguer avec le greffon logiciel RAI: envoyer des commandes pour invoquer l'exécution du greffon logiciel RAI, établir une liaison de communication avec le greffon logiciel RAI et recevoir via cette liaison des notifications et informations sur l'exécution d'un composant logiciel B1 ou B2 exécuté sur la plateforme 10, produites par le greffon logiciel RA1 pendant son exécution. Il en va de même pour le module de monitoring R2B couplé au greffon logiciel RA2. Le dispositif de monitoring 30 comprend en outre une première partie 31 d'interface utilisateur au moyen de laquelle un utilisateur peut commander l'exécution d'un ou plusieurs composants logiciels référencés dans le répertoire 20 et activer des fonctions de monitoring d'un ou de plusieurs des composants logiciels en cours d'exécution. Dans ce but, cette interface utilisateur 31 comprend des éléments d'interface (boutons, menus, etc), formant moyens pour: - sélectionner un composant logiciel à exécuter parmi une liste de composants logiciels référencés, liste fournie par exemple par la plateforme 10 par interrogation du répertoire 20 de composants logiciels; il peut être prévu à cet endroit que l'utilisateur sélectionne une application logicielle parmi une liste d'applications logicielles, chacun de ces application logicielles faisant appel à un ensemble de composants logiciels; déclencher l'exécution d'un composant logiciel sélectionné; sélectionner un composant logiciel à monitorer parmi une liste de composants logiciels en cours d'exécution; - sélectionner une fonction de monitoring et/ou une règle de monitoring à utiliser pour monitorer un ou plusieurs composants logiciels en cours d'exécution; - déclencher le monitoring d'un composant logiciel en cours d'exécution en activant une fonction et/ou règle de monitoring sélectionnée. Dans le contexte de ce document, une fonction de monitoring sert à déclencher l'envoi, à un dispositif de monitoring, d'au moins une information (ou un message) sur l'exécution du composant logiciel monitoré. Cette fonction de monitoring applique au moins une règle de monitoring définissant : - une ou plusieurs conditions déterminant quand une information doit être envoyée au dispositif de monitoring - quelle est l'information à envoyer quand cette ou ces conditions sont vérifiées. Une fonction de monitoring est ainsi conçue pour vérifier si une ou plusieurs conditions sont vérifiées et pour envoyer la ou les informations définies par la ou les règles de monitoring associées à cette fonction. Le dispositif de monitoring 30 comprend enfin une deuxième partie 32 d'interface utilisateur au moyen de laquelle sont affichées des informations collectées pendant le monitoring et qui sont relatives à l'exécution, au sein de la plateforme 10 de service, d'un ou de plusieurs composants logiciels. Les informations collectées comprennent par exemple - une information sur une ou des ressources consommées pendant l'exécution du composant logiciel; - une information sur un événement particulier qui s'est produit pendant l'exécution du composant logiciel; - une information sur une ou des anomalies détectées pendant l'exécution du composant logiciel; - une valeur de variable d'état, déterminée à partir d'une ou de plusieurs des informations sur une ou des ressources consommées et/ou sur une ou des anomalies détectées; - un message d'alerte relatif au déroulement de l'exécution du composant logiciel monitoré. L'invention permet par exemple de détecter une des anomalies suivantes: Al) un composant logiciel a verrouillé une variable statique; un tel verrouillage peut paralyser l'exécution d'autres composants logiciels ayant besoin d'accéder à la variable statique verrouillée; A2) une consommation excessive de mémoire par un composant logiciel; un tel composant consomme une grande partie de la mémoire en conservant des références vers de nombreux et/ou paquets de données volumineux stockés en mémoire; une telle consommation excessive peut rendre impossible l'allocation de mémoire par d'autres composants logiciels d'exécutant sur la plateforme et déclencher une exception, c'est-à-dire l'émission d'une alerte signalant une anomalie d'exécution; A3) un composant logiciel exécute une boucle infinie: un tel composant logiciel peut rapidement consommer toutes la puissance de calcul du processeur (CPU) de la plateforme 10 ; A4) un composant logiciel crée des objets de manière répétitive sans les utiliser et/ou sans libérer l'espace mémoire servant au stockage de ces objets; un tel composant logiciel consomme inutilement les ressources du processeur (CPU); A5) un composant logiciel crée des tâches (nommées "threads" en anglais); un tel composant logiciel peut provoquer un crash de la plateforme 10 en dépassant le nombre de tâches supporté par cette plateforme; A6) un composant logiciel crée une tâche sans jamais retourner le contrôle au composant logiciel appelant; un tel composant logiciel bloque l'exécution du composant logiciel appelant; A7) un composant logiciel continue à s'exécuter même si la plateforme 10 tente de le désinstaller et/ou d'arrêter son exécution. L'invention permet la définition d'une grande variété de règles de monitoring. Comme déjà décrit ci-dessus, une règle de monitoring définit les conditions à vérifier avant l'envoi d'informations vers le dispositif de monitoring qui collecte ces informations. Ces conditions sont par exemple définies relativement aux anomalies détectées et/ou aux ressources consommées pour le ou les composants monitorés. L'information fournie est par exemple une variable d'état, représentative des ressources consommées par un composant logiciel en cours d'exécution et/ou des anomalies détectées pour ce composant logiciel. La valeur de la variable d'état fournie sera ainsi différente selon les ressources consommées et/ou les anomalies détectées. De telles règles de monitoring rendent configurable le monitoring de composants logiciels en ce qu'elles permettent de définir librement les conditions de déclenchement de l'envoi d'information / de messages d'alerte. Le tableau ci-dessous est un exemple de définition d'une fonction de monitoring à partir de trois règles de monitoring. Chaque ligne du tableau définit une de ces trois règles. La première colonne énonce les conditions devant être vérifiées pour que la valeur d'une variable d'état figurant dans la deuxième colonne soit envoyée: cette variable d'état est représentatif un état global de fonctionnement. Dans ce tableau, on note: Ccpu le pourcentage de la capacité du processeur qui est consommé par le composant logiciel monitoré; - HR (heap ratio) le pourcentage de l'espace mémoire système qui est consommé par le composant logiciel monitoré; NR le nombre de ressources consommées par le composant logiciel monitoré. Condition(s) Etat Aucune anomalie détectée "normal" 25% Pour une fonction de monitoring ou pour plusieurs est conçu et développé un greffon logiciel, comprenant des instructions de programme pour la mise en oeuvre de cette fonction de monitoring. Ce greffon logiciel est défini au moyen d'une technique de programmation par aspect, relativement à ces points de jonctions prédéfinis existant dans le code du composant logiciel à monitorer. Il n'est donc pas nécessaire d'effectuer une quelconque modification du code du composant logiciel à monitorer, ni même de personnaliser le greffon logiciel pour un composant logiciel particulier: le greffon logiciel ainsi défini est utilisable pour le monitoring de tout composant logiciel conforme aux interfaces de la plateforme. La méthode de monitoring selon l'invention est ainsi non intrusive pour le programmeur de composants logiciels. En particulier, celui-ci n'a pas besoin d'avoir connaissance de la fonction de monitoring et/ou des règles de monitoring mises en oeuvre par le greffon logiciel pour écrire le code du composant logiciel. Le code du greffon logiciel peut lui-même être écrit et/ou modifié à tout moment, par exemple après que les composants logiciels à monitorer aient été référencés dans le répertoire de composants 20, voire même au cours de l'exécution par la plateforme d'un tel composant logiciel. Un exemple simplifié de code source d'un greffon logiciel de monitoring est reproduit ci-dessous: // POINT CUTs // pointcut bundleStarted(BundleContext bc) : execution (* BundleActivator.start(BundleContext)) && args (bc); pointcut bundleStoppedQ : execution (* BundleActivator.stop(BundleContext)); pointcut threadRunQ : execution (* Runnable.run()) && !within(ThreadAspect); pointcut heapRequest() : call (*.new(..)) && !within(ThreadAspect); Ce code définit plusieurs points de jonction: - "pointcut bundleStarted(BundleContext bc)" : définit une fonction à exécuter au démarrage d'un composant logiciel ; - pointcut bundleStoppedO" : définit une fonction à exécuter à la fin de l'exécution d'un composant logiciel ; - " pointcut threadRun()" : définit une fonction à exécuter au démarrage par un composant logiciel d'une sous-tâche ("thread" en anglais); - " pointcut heapRequestO" : définit une fonction à exécuter suite à une allocation de mémoire demandée par un composant logiciel. L'utilisation d'un greffon logiciel mettant en oeuvre une fonction de monitoring et appliquant une règle de monitoring permet de modifier, au cours de l'exécution d'un composant logiciel, la règle ou la fonction de monitoring couramment utilisée pour un composant logiciel. Si on considère qu'une modification de règle / fonction revient à remplacer une règle R1 / fonction Fl initiale par une autre règle R2 / fonction F2, différente de la règle R1 / fonction Fi, la modification de règle / fonction de monitoring revient à : - arrêter l'exécution du greffon logiciel RAI mettant en oeuvre la fonction de monitoring F1, appliquant la règle Ri et conçue pour envoyer au dispositif de monitoring au moins une information sur l'exécution d'un composant logiciel visé, - déclencher, au cours de l'exécution du composant logiciel, une exécution d'un autre greffon logiciel RA2, définissant la fonction de monitoring F2, appliquant la règle de monitoring R2 et conçue pour fournir au dispositif de monitoring au moins une information sur l'exécution d'un composant logiciel visé. Le remplacement d'une règle / fonction de monitoring par une autre permet par exemple de remonter des informations différentes et/ou de considérer des anomalies différentes et/ou de définir des critères de déclenchement de remontée d'alerte différents. L'invention permet également l'activation / désactivation à tout moment de fonctions / règles de monitoring. L'activation d'une fonction de monitoring revient à déclencher, à travers l'interface 15 de commande, l'exécution d'un greffon logiciel mettant en oeuvre cette fonction / règle de monitoring. La désactivation d'une fonction de monitoring revient à stopper, à travers l'interface 15 de commande, l'exécution d'un greffon logiciel mettant en oeuvre cette fonction / règle de monitoring. L'utilisateur qui observe les informations envoyées au dispositif de monitoring peut par exemple adapter le nombre de greffons logiciels en cours d'exécution si la plateforme est déjà chargée par ailleurs par l'exécution des composants logiciels ou bien sélectionner des fonctions de monitoring moins consommatrices de ressources. Un mode de réalisation du procédé selon l'invention est décrit par référence à la figure 2: il correspond à un scénario possible pour le monitoring de composants logiciels. Dans ce qui suit, l'utilisateur U1 désigne une personne physique ou bien une application de monitoring exécutant automatiquement les opérations décrites ici concernant cet utilisateur. A l'étape 200, un utilisateur U1 du dispositif de monitoring 30 sélectionne une application logicielle parmi une liste d'applications logicielles référencées dans le répertoire 15. On suppose, pour simplifier, que cette application logicielle comprend un seul composant logiciel B2. A l'étape 210, l'utilisateur déclenche au moyen de l'interface utilisateur 31 l'exécution de cette application logicielle: une commande d'exécution est alors transmise par le dispositif de monitoring 30 à la plateforme 10 au travers des interfaces 35 et 15. En réponse à cette commande d'exécution, la plateforme 10 charge en mémoire le code du composant logiciel B2 puis exécute le composant logiciel B2. A l'étape 220, un utilisateur sélectionne une fonction F1 de monitoring parmi une liste de fonctions de monitoring disponibles et demande le déclenchement du monitoring de l'application logicielle sélectionnée à l'étape 200 au moyen de la fonction F1 sélectionnée. Cette sélection de fonction de monitoring revient à une sélection d'un greffon logiciel parmi ceux référencés par le répertoire 20. Cette sélection déclenche l'exécution par le dispositif de monitoring 30 du module R1B, qui invoque l'exécution du greffon logiciel RAi. Une commande de chargement de code de monitoring est alors transmise par le dispositif de monitoring 30 à la plateforme 10 au travers des interfaces 35 et 15. En réponse à cette commande de chargement, la plateforme 10 charge en mémoire le code d'un composant logiciel de monitoring, réalisé sous forme de greffon logiciel RAI, mettant en oeuvre la fonction de monitoring sélectionnée. Ce code est chargé sans arrêt de l'exécution du composant logiciel B2 à monitorer. Le module R1B établit alors une liaison de communication avec le greffon logiciel RAI et peut recevoir via cette liaison des notifications et informations sur l'exécution du composant logiciel B2 exécuté sur la plateforme 10, notifications et informations qui sont produites par le greffon logiciel RAI pendant son exécution. A l'étape 225, la plateforme 10 exécute le greffon logiciel RAI et met en oeuvre ainsi la fonction F1 de monitoring définie par ce greffon logiciel RAI: les règles de monitoring associées à la fonction de monitoring sélectionnée sont vérifiées et la ou les informations à remonter sont envoyées par le greffon logiciel au module R1B du dispositif de monitoring au travers des interfaces 15 et 35. Tout ou partie des informations envoyées par le greffon logiciel RAI sont affichées dans l'interface utilisateur 32 du dispositif de monitoring 30. A l'étape 230, un utilisateur sélectionne une autre fonction F2 de monitoring parmi la liste de fonctions de monitoring disponibles et demande le remplacement de la fonction F1 par la fonction F2 pour le monitoring de l'application logicielle sélectionnée à l'étape 200. Cette sélection déclenche l'exécution par le dispositif de monitoring 30 du module R2B, qui invoque l'exécution du greffon logiciel RA2. Une commande de remplacement de code de monitoring est alors transmise par le dispositif de monitoring 30 à la plateforme 10 au travers des interfaces 35 et 15. En réponse à cette commande de remplacement, la plateforme 10 arrêt l'exécution du greffon logiciel RAI puis charge en mémoire le code d'un autre composant logiciel de monitoring RA2, réalisé lui-aussi sous forme de greffon logiciel RA2, mettant en oeuvre la fonction de monitoring sélectionnée. Ce code est chargé sans arrêt de l'exécution du composant logiciel B2 à monitorer. Le module R2B établit alors une liaison de communication avec le greffon logiciel RA2 et peut recevoir via cette liaison des notifications et informations sur l'exécution du composant logiciel B2 exécuté sur la plateforme 10, notifications et informations qui sont produites par le greffon logiciel RA2 pendant son exécution. A l'étape 235, la plateforme 10 exécute le greffon logiciel RA2 et met en oeuvre ainsi la fonction F2 de monitoring définie par ce greffon logiciel RA2: les règles de monitoring associées à la fonction de monitoring sélectionnée sont vérifiées et la ou les informations à remonter sont envoyées par le greffon logiciel au module R2B du dispositif de monitoring au travers des interfaces 15 et 35. Tout ou partie des informations envoyées par le greffon logiciel RA2 sont affichées dans l'interface utilisateur 32 du dispositif de monitoring 30. A l'étape 240, un utilisateur du dispositif de monitoring 30 demande l'arrêt de l'exécution du greffon logiciel RA2 chargé à l'étape 237. Une commande d'arrêt est alors transmise par le dispositif de monitoring 30 à la plateforme 10 au travers des interfaces 35 et 15. En réponse à cette commande d'arrêt, la plateforme 10 arrête l'exécution du greffon logiciel RA2, alors que celle du composant logiciel B2 se poursuit. Les étapes 200 à 240 peuvent ensuite être répétées pour une autre application logicielle. Le scénario décrit ici peut se généraliser au cas de monitoring de plusieurs composants logiciels B1, B2 pour chacun desquels une fonction de monitoring est exécutée au moyen d'un des greffons logiciels RAI, RA2 mettant en oeuvre cette fonction. Le système de monitoring selon l'invention est ainsi souple et adaptable à toute situation, quels que soient les composants logiciels B1, B2 en cours d'exécution. Grâce à ce système, il est envisageable de créer parallèlement, au cours de l'exécution d'un composant logiciel, un nouveau greffon logiciel pour la mise en oeuvre d'une nouvelle fonction de monitoring, adaptée à la détection de certaines anomalies ou à la remontée d'informations concernant un problème particulier détecté pour ce composant logiciel, puis de référencer ce greffon logiciel dans le répertoire 20 avant d'invoquer l'exécution de ce greffon logiciel et ainsi d'améliorer l'analyse et la compréhension du problème détecté. REVENDICATIONS1. Procédé de monitoring d'une exécution d'un composant logiciel (B1, B2), le procédé comprenant - une étape de déclenchement, au cours de l'exécution dudit composant logiciel, d'une exécution d'un greffon logiciel (RAI, RB1) définissant une fonction de monitoring conçue pour fournir à un dispositif de monitoring (30) au moins une information sur l'exécution dudit composant logiciel, - une étape d'affichage d'au moins une information fournie au dispositif de monitoring par le greffon logiciel. 2. Procédé de monitoring selon la revendication 1 dans lequel ledit greffon logiciel définit, relativement à des opérations prédéfinies d'un code source dudit composant logiciel, quelle est la ou quelles sont les informations à fournir lorsque des conditions, définies également par ce greffon logiciel, sont remplies au moment de l'exécution d'une telle opération. 3. Procédé de monitoring selon la revendication 1 dans lequel ladite fonction de monitoring applique au moins une règle de monitoring définissant la ou les informations à fournir audit dispositif de monitoring et les conditions dans lesquelles cette ou ces informations sont à fournir. 4. Procédé de monitoring selon la revendication 1 comprenant une étape de modification, au cours de l'exécution dudit composant logiciel, de la fonction de monitoring appliquée audit composant logiciel. 5. Procédé de monitoring selon la revendication 4, dans lequel l'étape de modification comprend: - une étape d'arrêt de l'exécution dudit greffon logiciel, - une étape de déclenchement, au cours de l'exécution dudit composant logiciel, d'une exécution d'un autre greffon logiciel définissant une autre fonction de monitoring, conçue pour fournir au dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel et appliquant au moins une autre règle de monitoring. 6. Procédé de monitoring selon la revendication 1 comprenant une étape de mise en oeuvre de moyens de sélection d'une règle de monitoring à utiliser, le greffon logiciel exécuté mettant en oeuvre une fonction de monitoring appliquant la règle sélectionnée. 7. Procédé de monitoring selon la revendication 1 dans lequel ledit greffon logiciel est utilisable pour le monitoring de plusieurs composants logiciels. 8. Dispositif de monitoring (30) d'une exécution d'un composant logiciel, le dispositif comprenant - des moyens de déclenchement, au cours de l'exécution dudit composant logiciel, d'une exécution d'un greffon logiciel définissant une fonction de monitoring conçue pour fournir à un dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel, - des moyens d'affichage d'au moins une information fournie au dispositif de monitoring par le greffon logiciel. 9. Plateforme d'exécution de composants logiciels, couplée à un dispositif de monitoring (30) selon la revendication 9, comprenant une interface pour exécuter, au cours de l'exécution d'un dit composant logiciel, un greffon logiciel définissant une fonction de monitoring conçue pour fournir audit dispositif de monitoring au moins une information sur l'exécution dudit composant logiciel.