FR2805905A1 - Procede d'execution d'une action dans un systeme d'information heterogene - Google Patents

Abstract

Le procédé comprend la génération de modules de commande (25) adaptés à l'exécution d'une action (23) par différents types respectifs (20) de système d'exploitation dans un système d'information, et le lancement d'un moteur (24) pour sélectionner dans l'action le ou les modules de commande adaptés aux types respectifs de système d'exploitation qui sont impliqués par l'exécution de l'action et pour charger le ou les modules de commande sélectionnés dans les systèmes d'exploitation respectifs impliqués par l'exécution de l'action, et faire exécuter l'action par ces derniers systèmes d'exploitation.

Description

Titre Procédé d'exécution d'une action dans un système d'information hétérogène. Description. Domaine technique.

L'invention se rapporte à un procédé d'exécution d'une action dans un système d'information hétérogène. Bien que ce procédé puisse appliquer à une ou plusieurs actions particulières dans un système d'information, il est bien adapté à des actions regroupées dans de nombreuses taches complexes, telles que celles mises en oeuvre dans un système d'administration d'un système d'information incluant un grand nombre de composants matériels et logiciels très hétérogènes. Un tel système d'administration servira d'exemple pour bien illustrer les caractéristiques et tous les principaux avantages de (invention.

D'autre part, un système d'information est dit hétérogène quand contient divers types de systèmes d'exploitation pour exécuter une action. L'exemple qui suit portera sur les types de systèmes d'exploitation de norme Unix, tels que ceux connus sous les noms AIX, HP-UX , IRIX , Linux et Solaris . Cependant, on verra que l'invention peut s'appliquer plus généralement à tout système d'information hétérogène.

L'invention a donc aussi pour objets corollaires un système d'information et un système d'administration qui mettent en oeuvre le procédé de distribution.

L'art antérieur.

Une action est destinée à être exécutée sur une machine cible, le plus souvent pour accomplir une tâche d'administration. Une action peut etre exécutée individuellement, comme par exemple créer un utilisateur ou augmenter un espace de mémoire virtuelle (swap space). Une action est plus souvent une composante d'une tâche (job). Par exemple, une tâche d'impression simple comprend une action d'investigation pour vérifier si des conditions requises pour l'impression sont satisfaites, une action d'exécution de l'impression et une action d'affichage pour informer l'utilisateur de tout problème rencontré lors de l'exécution des actions d'investigation et d'impression.

Il existe une grande variété d'actions et de tâches dans un système d'information incluant un grand nombre de ressources matérielles et logicielles. Un exemple en est donné par l'application de gestion de configuration connue sous le nom CGOV (Configuration Governor) dans le système d'administration connu sous le nom OpenMaster du demandeur. L'application CGOV donne à un utilisateur administrateur d'un grand système d'information une maîtrise très étendue sur un très grand nombre de ressources du système. Notamment, les configurations matérielles et/ou logicielles sont maîtrisées pour détecter rapidement dans le système d'information toute mauvaise configuration. Les configurations matérielles et/ou logicielles de systèmes sont maîtrisées pour homogénéiser la configuration d'un ensemble de systèmes, vérifier cette homogénéité et déclencher des actions correctrices sur les systèmes non conformes. L'installation de logiciels est aussi maîtrisée de façon, exemple, à les installer correctement seulement en décrivant le modèle des machines candidates à l'installation, sans fournir une liste des logiciels à installer. Par exemple, si on veut mettre à jour un logiciel donné dans le système d'information, l'utilisateur n'a pas à fournir la liste des machines incorporant le logiciel donné mais simplement un critère indiquant les machines cibles sont les machines incorporant une version du logiciel donné. Une maîtrise de distribution permet de configurer de façon cohérente les objets gérés qui coopèrent entre eux sur le réseau, grâce à une vue globale et une administration centralisée. La diversité est aussi maîtrisée pour rassembler logiquement les machines du système d'information en un ou plusieurs groupes homogènes et pour contrôler et agir au niveau de ces groupes et non plus au niveau des machines. Les évolutions de la gestion de la configuration sont aussi maîtrisées, en récupérant des fichiers d'administration existants pour les utiliser sous forme d'actions ou, le cas échéant, pour les invoquer lors de contrôles de cohérence. Enfin, l'application CGOV est ouverte grâce à la possibilité d'introduire des actions écrites par l'administrateur.

L'exécution d'actions dans un grand système d'information hétérogène se heurte aux graves problèmes que posent les nombreux types de systèmes d'exploitation possibles ou disponibles dans un tel système. exemple, l'application CGOV est livrée avec un ensemble d'actions de base adaptées à un nombre donné de types de systèmes d'exploitation de norme Unix , tels que ceux indiqués plus haut. Le premier problème réside dans l'adaptation de l'exécution des actions à un type existant de système d'exploitation Unix mais non inclus dans ledit nombre donné ou à un type de système d'exploitation Unix émergeant ou à venir. Ce problème est dû au fait que les codes d'exécution de nombreuses actions sont très dépendants de chaque type de système d'exploitation. Par exemple, il faut des codes différents pour exécuter la même action de créer un utilisateur sur les types de systèmes d'exploitation AIX , HP-UX et Solaris .

De nombreuses solutions existent à ce jour pour l'exécution d'une action ou d'une tâche d'administration sur différents types existants de système d'exploitation Unix . Une première solution consiste à utiliser un langage de haut niveau, le langage C par exemple, pour créer toutes les actions d'administration. Cependant, ce type de langage pose le problème après une compilation du code source, on obtient un programme qui ne peut s'exécuter que sur un type de système d'exploitation et non sur un autre Il faut donc générer autant de codes binaires que de types de système d'exploitation, puis installer le bon code binaire sur chaque type de système d'exploitation.

Une seconde solution utilise un langage interprété, par exemple langage PERL (Practical Extraction and Report Language), qui permet de faire de nombreuses tâches d'administration de système. Cependant, une tache d'administration un peu complexe ne peut pas être prise en compte dans ce langage, comme par exemple la création d'un utilisateur. D'autre part, cette solution nécessite au préalable l'installation d'un interpréteur de script PERL sur l'ensemble des machines. Une troisième solution utilise un script exécutable défini par norme Unix par le terme "shell script" et appelé par la suite script "shell" pour exécuter une tâche d'administration. Le problème est qu'il faut alors coder dans le script la correspondance entre un type de système d'exploitation et le morceau de code relatif à la tâche à exécuter. Si on souhaite une exécution sur un autre type de système d'exploitation, il faut adapter ce à (ensemble des actions de la tâche, en modifiant en conséquence l'ensemble actions.

On comprend que le même problème se pose lorsqu'un nouveau de système d'exploitation Unix arrive sur le marché. Cet exemple l'avantage de bien faire ressortir la gravité du premier problème alors qu'il ne concerne que des types différents d'un système d'exploitation fondé sur la norme Unix.

L'exécution d'actions dans un grand système d'information hétérogène se heurte aussi à un second problème important lorsqu'il faut ajouter une nouvelle action à exécuter dans un type de système d'information. Le problème est dû à (interaction fréquente d'actions entre elles dans une même tâche et/ou dans d'autres tâches. La seule solution possible actuellement est de modifier en conséquence les actions liées à celle ajoutée. Cependant, la modification d'une action liée à celle ajoutée implique souvent la modification de celles qui lui sont aussi proprement liées. Ce problème est d'autant plus grave qu'il se cumule avec le premier problème. La conséquence pratique de ce cumul est qu'il faut actuellement modifier le code de pratiquement l'ensemble des actions qui ont déjà été décrites. De surcroît une telle conséquence est actuellement fréquente dans le domaine l'administration, qui subit une évolution rapide et s'élargit à de nombreuses applications, notamment les télécommunications. Cette conséquence a notamment pour inconvénients de rendre difficilement gérable l'évolution d'un système d'administration, d'impliquer de grands coûts et de présenter une période de rémanence très longue pour adapter une action existante à un type de système d'exploitation et beaucoup plus longue s'il s'agit d'une nouvelle action. Sommaire de l'invention.

premier but de l'invention est de rendre l'exécution d'une action indépendante des types de système d'exploitation pouvant exister actuellement plus tard dans un système d'information hétérogène. Il en résulte l'avantage de laisser inchangé le code d'une action existante lorsqu'on veut exécuter cette action sur un autre type de système d'exploitation.

Un second but de l'invention est de rendre l'exécution d'une nouvelle action indépendante des actions existantes dans un système d'information hétérogène. Il en résulte l'avantage de laisser inchangé le code de l'ensemble actions existantes lorsqu'on veut exécuter une nouvelle action dans système d'information.

troisième but est de faciliter la maintenance du procédé d'exécution d'une action. Ce but offre l'avantage d'avoir une maintenance aisément contrôlée et adaptable à toute évolution.

quatrième but de l'invention est d'atteindre les buts précédents à un coût global nettement moins élevé que le cout résultant de la mise en ceuvre d'une solution de la technique antérieure. L'avantage ainsi offert se cumule avec une plus grande rapidité d'adaptation de mise sur le marché de produits bien adaptés aux systèmes d'exploitation disponibles et aux évolutions désirées.

L'invention a pour objet un procédé d'exécution d'une action dans un système d'information incluant au moins un processeur des moyens de mémoire, caractérisé en ce qu'il comprend la génération dans les moyens de mémoire de modules de commande adaptés à l'exécution de l'action par différents types respectifs de système d'exploitation dans le système d'information, et le lancement d'un moteur, contenu dans les moyens de mémoire, pour sélectionner le ou les modules de commande adaptés aux types respectifs de système d'exploitation qui sont impliqués l'exécution de l'action et pour charger le ou les modules de commande sélectionnés dans les systèmes d'exploitation respectifs impliqués par l'exécution de l'action, et faire exécuter l'action par ces derniers systèmes d'exploitation. L'invention a pour premier objet corollaire un système d'information incluant au moins un processeur, des moyens de mémoire et différents types de système d'exploitation, caractérisé en ce que l'exécution d'au moins une action dans le système d'information est faite selon le procédé défini précédemment.

L'invention a pour second objet corollaire un système d'administration pour la mise en ceuvre du procédé défini précédemment, comprenant au moins un processeur, des moyens de mémoire et gestionnaire d'un système d'information incluant différents types de système d'exploitation, le gestionnaire incluant dans les moyens de mémoire au moins une action à exécuter dans le système d'information, caractérisé en ce que gestionnaire inclut en outre dans les moyens de mémoire des modules de commande adaptés à l'exécution de l'action par des types respectifs système d'exploitation dans le système d'information et un moteur incluant des moyens pour sélectionner le ou les modules de commande adaptés types respectifs de système d'exploitation qui sont impliqués par l'exécution de l'action et des moyens pour charger le ou les modules de commande sélectionnés dans les systèmes d'exploitation respectifs impliqués l'exécution Présentation des dessins.

# La figure 1 est une vue synoptique d'un système d'administration d'un système informatique incorporant une machine gestionnaire incorporant une application d'administration mettant en oeuvre le procédé conforme ' l'invention pour l'exécution d'actions dans le système d'information.

# La figure 2 est une vue schématique de l'application d'administration représentée sur la figure 1 et illustrant un exemple de structure pour mise oeuvre du procédé conforme à l'invention.

# La figure 3 est une vue schématique illustrant un exemple de modélisation d'une action pour la mise en oeuvre par la structure représentée sur la figure du procédé conforme à l'invention pour l'exécution de l'action dans le système d'information représenté sur la figure 1. Et la figure 4 est un diagramme illustrant des étapes d'un exemple de mise en oeuvre du procédé d'exécution de l'action représentée sur la figure 3 au moyen de la structure représentée sur la figure 2.

Description détaillée d'exemples illustrant l'invention.

La figure 1 représente un système d'administration 10 d'un système d'information 11. L'exemple qui suit se rapporte au système d'administration et de sécurité connu sous le nom de marque déposée OpenMaster du demandeur. Sa conception est conforme aux normes ISO de l'administration de systèmes et réseaux. Dans ces conditions, termes utilisés seront conformes à cette norme, qui sont de langue anglaise, notamment les sigles et acronymes. D'autre part, les verbes "administrer" et "gérer" et leurs dérivés qui seront employés ici traduisent tous deux indifféremment le verbe anglais "manage" et ses dérivés. L'homme métier connaît bien ces normes. Compte tenu de leur masse informative on ne donnera ici que les éléments nécessaires à la compréhension de l'invention.

Le système d'information illustré 11 est distribué et se compose de machines 12, en l'occurrence quatre machines 12a-12d, organisées en un ou plusieurs réseaux 13. Une machine est une unité conceptuelle très large, de nature matérielle et logicielle, pouvant être les moyens impliqués pour exécuter une application donnée, des moyens pour exécuter .une fonction donnée, un ordinateur, ainsi qu'un système informatique dans une architecture à systèmes en cascade. Les machines 12 peuvent être donc très diverses, telles que stations de travail, serveurs, routeurs, machines spécialisées passerelles entre réseaux. Le système d'information 11 est ordinairement un système comprenant plusieurs processeurs un processeur 14 étant par exemple illustré dans chaque machine 12, des moyens de mémoire 15 pour contenir les logiciels et les données du système, et des moyens d'entrée-sortie 16 servant pour la communication entre machines par l'intermédiaire du réseau 13 à l'aide de protocoles divers, ainsi que pour une ou plusieurs communications extérieures, par exemple pour l'impression, la télécopie, etc. Un tel système peut par exemple gérer des données à distance, distribuer des données dans le cas d'un système de réservation commander l'exécution de programmes à distance sur des machines spécialisées, partager localement des ressources physiques ou logicielles, et communiquer. Plus généralement, le système 11 se compose de ressources matérielles et/ou logicielles, réelles ou virtuelles, telles que machines, imprimantes, circuits virtuels réseaux et applications. Le système d'administration utilise au moins l'une de ces ressources selon un modèle de données oriente objets, dont on connaît les principales caractéristiques : classes, objets, héritage, encapsulation, méthodes et événements.

Le système d'administration 10 choisi a une architecture de type client-serveur. Dans l'exemple illustré, un gestionnaire 17 forme un serveur d'administration inclus dans la machine 12a, dite machine gestionnaire, tandis les clients d'administration 18a,18b et 18c sont appelés agents et sont inclus dans les machines respectives 12b, 12c et 12d, dites machines gérées. gestionnaire 17 analyse et agit sur l'environnement à gérer selon la technologie orientée objets. Dans l'exemple choisi, tous les objets sont hiérarchisés dans un arbre correspondant à une base d'information d'administration plus connue sous le nom de MIB (Management Information Base). agents 18a-18c permettent l'accès aux ressources à gérer dans les machines respectives 12b-12d. Les ressources gérées dans les machines 12b- 12d sont identifiées sous forme d'objets organisés dans des sous-arbres respectifs 19a-19c de la base MIB. On suppose que les machines gérées 12b- 12d incluent dans leurs sous-arbres respectifs 19a-19c trois types différents respectifs 20a-20c de système d'exploitation OS (Operating System), par exemple types AIX , HP-UX et Solaris . Selon une option courante et avantageuse du système d'administration 10, un gestionnaire 17 gère aussi la machine gestionnaire 12a correspondante ou gère tout ou partie d'autres machines gestionnaires possibles (non illustrées). Cela peut se faire de façon similaire a celle illustrée précédemment sur une machine gérée et plus ou moins adaptée à cette option. L'exemple illustré offre le double avantage de faciliter la lecture des dessins tout en permettant à l'homme métier de faire une généralisation du système décrit et illustré. Le système d'administration 10 inclut diverses applications d'administration contenues dans le gestionnaire 17, notamment une application de gestion de configuration 21 connue sous le nom CGOV et dont fonctions ont été décrites en introduction de la présente demande.

La figure 2 illustre un exemple de structure 22 incluse dans l'application 21 pour la mise en oeuvre du procédé d'exécution d'au moins une action 23 dans le système d'information 11. La structure 22 comprend un nombre n d'actions à exécuter 23, en (occurrence trois actions 23a-23c, un moteur 24 commun aux n actions.

La figure 3 illustre un exemple de structure de modélisation d'une action 23. L'action 23 inclut des modules de commande 25 correspondant à des types respectifs 20 de système d'exploitation OS. Dans l'exemple considéré dans la figure 1, l'action 23 a trois modules de commande -25c correspondant aux trois types respectifs 20a-20c de système d'exploitation qui existent dans le système d'information 11. Chaque module commande 25 contient un code adapté à l'exécution de l'action 23 un type correspondant 20 de système d'exploitation. Ce code doit être chargé pour être exécuté. Dans l'exemple choisi, les modules de commande -25c sont des scripts "shell" de commande des types respectifs 20a-20c de système d'exploitation. L'action 23 inclut aussi un module 26 de lancement du moteur Dans l'exemple choisi, le moteur 24 est aussi un script "shell".

La figure 4 est un diagramme illustrant des étapes d'un exemple procédé d'exécution d'une action 23a dans le système d'information au moyen de la structure 22. On suppose qu'à une étape 40 l'action 23a doit s exécuter dans seulement la machine gérée 12c disposant du type 20b de système d'exploitation. À une étape 41 l'action 23a lance, au moyen du module 26, le moteur 24. À une étape 42 le moteur 24 cherche à déterminer quel ou quels types 20 de système d'exploitation doivent exécuter l'action 23a. Dans l'exemple considéré, le moteur 24 détermine le type 20b de système d'exploitation. À une étape 43, le moteur 24 fait une recherche dans l'action d'un module de commande, ici 25b, adapté au type 20b de système d'exploitation qui a été déterminé à l'étape 42. Dans l'exemple illustré la recherche 43 comprend une lecture, dans le gestionnaire 17, d'une table 27 de correspondance entre types 20 de système d'exploitation et modules de commande 25 de l'action considérée 23a. S'il y a au moins une correspondance, la recherche est positive et comprend en outre la sélection du ou des modules de commande 25 impliqués, en l'occurrence le module 25b Dans ce cas, à une étape 44, le moteur 24 charge le module de commande dans la machine 12c. Le système d'exploitation OS dans la machine 12e peut alors exécuter correctement, à une étape 45, l'action 23a. À une étape correspondant à la fin de l'exécution de l'action 23a dans la machine 12c, un message de bonne exécution est généré et envoyé pour être écrit dans un journal 28 du gestionnaire 17. Si à l'étape 43 le moteur 24 n'avait pas trouve dans la table 27 une correspondance du type 20b de système d'exploitation avec un module de commande 25b dans l'action 20a, le moteur 24 aurait généré à une étape 47 un message de non-exécution et l'aurait envoyé pour être écrit dans le journal 28. Les messages du journal 28 sont destinés a informer l'utilisateur du système d'information 11 de l'exécution correcte ou non l'action désirée 23a dans la machine 12c.

Plus généralement, on suppose par exemple que l'action 23b doit être exécutée dans les machines gérées 12b et 12d. Le moteur 24 détermine les types 20a et 20c des systèmes d'exploitation qui vont exécuter l'action 23b dans machines 12b et 12d et sélectionne dans la table 27 les modules de commande 25a et 25c pour les charger respectivement dans les machines 12b et Les deux machines 12b et 12d vont exécuter les modules correspondants 25a et 25c qui sont bien adaptés à leurs systèmes d'exploitation respectifs. Il est à noter que le chargement d'un module de commande 25 est destiné à tous les systèmes d'exploitation de même type qui sont impliqués par l'exécution de l'action dans les machines 12.

Pour l'exécution du procédé, le moteur 24 a des moyens 29 pour rechercher le ou les types 20 de système d'exploitation impliqués par l'exécution de l'action désirée et des moyens 30 connectés aux moyens 29 pour recevoir les résultats d'une recherche positive et pour rechercher et sélectionner les modules de commande 25 correspondants. Dans l'exemple illustré, les moyens 29 sont en liaison avec la table 27. Le moteur inclut en outre des moyens 31 connectes aux moyens 30 pour en recevoir les modules sélectionnés et pour charger ces modules dans les machines cibles. Accessoirement, il inclut aussi des moyens 32 de génération de messages relatifs à l'état d'exécution de faction et d'écriture dans le journal 28.

D'autre part, actions 23a-23c ont souvent en commun un ensemble de fonctionnalités. Par exemple, les actions d'administration peuvent générer des messages pouvant être écrits dans plusieurs langues pour avertir des utilisateurs de langues différentes. Les fonctionnalités communes peuvent alors être gestion des messages, la gestion de la langue pour écrire les messages dans la langue choisie par un utilisateur, et la vérification du nombre de paramètres passé à l'action. Selon une caractéristique accessoire mais avantageuse de l'invention, les fonctionnalités communes aux actions 23a- sont contenues dans le moteur 24 et sont prises en charge par des moyens 33 du moteur. Ainsi, pour l'exécution d'une action, le moteur est lancé le module 26 et charge un catalogue de messages en fonction de la langue choisie par l'utilisateur, vérifie le nombre de paramètres, ..., puis détermine le système d'exploitation, en déduit le module de commande à charger, charge ce module et le fait exécuter.

Pour toutes les actions existantes 23a-23c, il est très facile d'ajouter un nouveau type système d'exploitation. Il suffit d'ajouter à chacune des actions un module de commande 25 correspondant au nouveau type de système d'exploitation d'ajouter dans la table de correspondance 27 le nouveau type de système d'exploitation et/ou le nouveau module de commande 25 correspondant. taille du nouveau module de commande 25 pour l'ensemble des actions existantes 23a-23c dépend de la nature des actions et du nouveau type système d'exploitation. En d'autres termes, il est important de noter que l'ajout de nouveaux modules de commande 25 se fait sans aucune modification code des modules de commande existants 25 relatifs à l'ensemble des actions existantes 23.

D'autre part, il est facile d'ajouter une nouvelle action, par exemple l'action 23d représentée par un trait discontinu sur la figure 2. Il suffit d'écrire les modules de commande 25a-25c correspondant aux types respectifs 20a-20c des systèmes d'exploitation impliqués par la nouvelle action. Selon une caractéristique accessoire mais avantageuse de l'invention le moteur 24 est commun aux actions 23 et peut donc s'appliquer à la nouvelle action 23d de la même façon que celle décrite précédemment. L'ajout d'une nouvelle action 23d se fait donc sans modification des actions existantes 23a 23c. Il est à noter aussi que l'emploi de scripts "shell" dans la solution l'invention présente l'avantage de ne pas nécessiter de portage. D'autre part, la solution proposée est facile à maintenir. Notamment, il est possible de modifier le moteur 24, par exemple pour ajouter une nouvelle langue pour élargir l'internationalisation de la solution, des nouveaux messages, etc., sans changer le contenu de l'ensemble des actions existantes 23.

En pratique, la mise en oeuvre de la solution dans (application d'administration CGOV 21 du produit OpenMaster est prévue comme suit. Les actions 23 se présentent sous forme d'un ensemble de fichiers qui sera livré à l'installation de l'application CGOV dans le gestionnaire d'administration 17. Il suffit d'installer les actions sur l'ensemble des machines 12 à administrer, puis déclencher ces actions sur toutes machines avec un jeu de paramètres. Ces opérations se font de façon centralisée sur la machine OpenMaster et de façon automatique l'ensemble de machines ou sur au moins un groupe d'entre elles. Cependant, la commande centralisée qui a servi d'exemple n'est pas indispensable. Il ressort de la description qui précède que la commande d'exécution d'une action peut être distribuée dans le système d'information 11 et optionnellement hiérarchisée. En d'autres termes, la structure 22 pourrait être reproduite au moins partiellement dans le système d'information 11 pour ne commander l'exécution d'une action générale ou locale dans un groupe de machines du système d'information.

De nombreuses variantes peuvent encore être apportées par l'homme du métier à (exemple de mise en oeuvre du procédé de l'invention qui vient d'être décrit. D'une manière générale, elle peut s'appliquer à toute action et à tout système d'exploitation. Bien que décrit pour des types de système d'exploitation Unix, le procédé pourrait être mis en oeuvre pour exécuter une action sur par exemple les types de système d'exploitation Windows NT et Windows 2000 , après y avoir préalablement installé un interpréteur de script "shell". Un tel interpréteur peut être celui connu sous le nom NuTCRACKER. Plus généralement, la solution qui a été décrite dans le cadre de la norme Unix peut s'adapter à tout type de système d'exploitation capable d'interpréter script "shell". Dans la mesure où le concept du script "shell" s'est largement étendu à de nombreux types de systèmes d'exploitation autres que ceux conformes à la norme Unix , on comprend que l'exemple illustré peut etre appliqué de la même façon à ces autres types de systèmes d'exploitation, avec usage d'interpréteurs entre ces types. Cependant, les modules de commande pourraient aussi être des codes binaires ou tout autre code pouvant s'exécuter sur un type de système d'exploitation ou une autre norme de système. Le mieux serait qu'à l'avenir existe une couche de langage commun à un groupe ou de l'ensemble des systèmes d'exploitation pour la mettre en oeuvre dans le procédé de l'invention. D'autre part, dans l'exemple illustré le lancement du moteur 24 est fait par un module de lancement contenu dans l'action. Bien entendu, on pourrait charger le moteur et exécuter l'action désirée, mais une telle solution paraît être moins avantageuse que celle décrite. Il faudrait au départ lancer un interpréteur de commande qui serait soit l'action, auquel cas l'action lancerait le moteur, soit fonction du moteur. De même que les modules de commande 25, le module de lancement 26 pourrait être autre chose qu'un script "shell". En outre bien que les modules de commande 25 décrits soient contenus dans l'action correspondante 23, il ressort clairement de l'exemple illustré que ces modules pourraient être localisés ailleurs que dans l'action, dans le gestionnaire 17 l'occurrence, ou dans un gestionnaire localisé dans une autre machine, tel qu'un supra- gestionnaire.

D'une manière générale, il ressort de ce qui précède que l'invention a pour objet un procédé d'exécution d'une action 23 dans un système d'information 11, le procédé comprenant la génération de modules de commande 25 adaptés à l'exécution de l'action par différents types respectifs 20 de système d'exploitation dans le système d'information, et lancement d'un moteur 24 pour sélectionner le ou les modules de commande adaptés aux types respectifs de système d'exploitation qui sont impliqués l'exécution de l'action et pour charger le ou les modules de commande sélectionnés dans les systèmes d'exploitation respectifs impliqués par l'exécution l'action, et faire exécuter l'action par ces derniers systèmes d'exploitation.

Diverses variantes accessoires de l'invention peuvent être apportées séparément ou en combinaison l'une à l'autre à cette définition. Par exemple, on a vu que les modules de commande 25 et le module lancement sont de 'férence des scripts "shell", mais qu'ils pourraient être faits de tout autre code. On a vu aussi que la sélection illustrée des modules comprend la lecture d'une table de correspondance 27 entre les différents types de système d'exploitation et les modules de commande relatifs à ladite action. En outre, le lancement du moteur peut être fait par un module de lancement 26, optionnellement contenu dans l'action. Les modules 25 sont aussi de préférence contenus dans l'action 23. D'autre part, le moteur peut être commun pour au moins une autre action à exécuter. Dans ce cas, avantage optionnel de faire traiter par le moteur des fonctionnalités communes à tout ou partie des actions 23. Enfin, l'action peut être individuelle incluse dans une tache.

L'invention a aussi pour objet un système d'information 11 incluant différents types de système d'exploitation et dans lequel est exécuté au moins une action 23 conformément au procédé de l'invention défini précédemment.

L'invention a encore pour objet un système d'administration 10 pour la mise en oeuvre du procédé de l'invention, comprenant un gestionnaire 17 d'un système d'information 11 incluant différents types de système d'exploitation, le gestionnaire incluant au moins une action dans le système d'information, des modules de commande 25 adaptés a l'exécution de l'action par des types respectifs 20 de système d'exploitation dans système d'information et un moteur 24 incluant des moyens 29, 30 pour sélectionner le ou les modules de commande adaptés aux types respectifs système d'exploitation qui sont impliqués l'exécution de l'action et des moyens 31 pour charger le ou les modules de commande sélectionnés 25 dans les systèmes d'exploitation respectifs impliqués par l'exécution de l'action pour les rendre ainsi capables d'exécuter l'action.

Claims (1)

Revendications.

1. Procédé d'exécution d'une action (23) dans un système d'information (11) incluant au moins un processeur (14) et des moyens de mémoire (15), caractérisé en ce qu'il comprend la génération dans les moyens de mémoire (15) de modules de commande (25) adaptés à l'exécution l'action par différents types respectifs (20) de système d'exploitation dans le système d'information, et le lancement d'un moteur (24), contenu dans les moyens de mémoire, pour sélectionner le ou les modules de commande adaptés aux types respectifs de système d'exploitation qui sont impliqués par l'exécution de l'action et pour charger le ou les modules de commande sélectionnés dans les systèmes d'exploitation respectifs impliqués l'exécution de l'action, et faire exécuter l'action par ces derniers systèmes d'exploitation. Procédé selon la revendication 1, caractérisé en ce que les modules commande (25) comprennent des scripts connus sous le nom de scripts "shell". Procédé selon la revendication 1 ou 2, caractérisé en ce que la sélection des modules de commande (25) comprend la lecture, dans les moyens de mémoire (15), d'une table de correspondance (27) entre lesdits types (20) de système d'exploitation et lesdits modules de commande relatifs à ladite action (23). Procédé selon l'une des revendications 1 à 3, caractérisé en ce que lancement du moteur (24) est fait par un module de lancement (26) contenu dans les moyens de mémoire (15). Procédé selon l'une des revendications 1 à 4, caractérisé en ce que modules de commande (25) et optionnellement le module de lancement (26) sont contenus dans l'action (23). 6. Procédé selon l'une des revendications 1 à 5, caractérisé en que le moteur (24) est commun à au moins une autre action (23) à exécuter. 7. Procédé selon la revendication 6, caractérisé en ce que le moteur traite (33) des fonctionnalités communes à des actions (23). 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce l'action (23) est incluse dans une tâche. 9. Système d'information (11) incluant au moins un processeur (14), des moyens de mémoire (15) et différents types (20) de système d'exploitation, caractérisé en ce que l'exécution d'au moins une action (23) dans le système d'information est faite selon le procédé défini par l'une des revendications précédentes. 10. Système d'administration (10) pour la mise en oeuvre du procédé défini par l'une des revendications 1 à 8, comprenant au moins un processeur (14), des moyens de mémoire (15) et un gestionnaire (17) système d'information (11) incluant différents types (20) de système d'exploitation, le gestionnaire incluant dans les moyens de mémoire (15) moins une action (23) à exécuter dans le système d'information, caractérisé en ce que le gestionnaire inclut en outre dans les moyens de mémoire (15) des modules de commande (25) adaptés à l'exécution de l'action des types respectifs (20) de système d'exploitation dans le système d'information et un moteur (24) incluant des moyens (29, 30) pour sélectionner le ou les modules de commande adaptés aux types respectifs système d'exploitation qui sont impliqués par l'exécution de l'action et des moyens (31) pour charger le ou les modules de commande sélectionnés (25) dans les systèmes d'exploitation respectifs impliqués par (exécution de l'action pour les rendre ainsi capables d'exécuter l'action.