FR2816420A1

FR2816420A1 - Procede de gestion d'au moins une ressource informatique

Info

Publication number: FR2816420A1
Application number: FR0014153A
Authority: FR
Inventors: Bruno Farcy
Original assignee: Evidian SA
Current assignee: Evidian SA
Priority date: 2000-11-06
Filing date: 2000-11-06
Publication date: 2002-05-10
Anticipated expiration: 2020-11-06
Also published as: FR2816420B1

Abstract

La gestion est faite par l'intermédiaire d'un navigateur et se rapporte à au moins une ressource modélisée en technologie orientée objets dans des groupes (schémas CIM) de classes contenues dans un répertoire (WBEMNamespace), le navigateur ne permettant pas une représentation des groupes. Le procédé consiste à créer des classes (cimSchema) pour identifier les groupes respectifs (cimSchema1-3) et à lier les classes aux groupes correspondants. Des sous-schémas (cimSchema3. 1) peuvent aussi être créés. Il en résulte une recherche rapide d'un objet donné et un examen facile d'un répertoire.

Description

Titre
Procédé de gestion d'au moins une ressource informatique.

Domaine technique.

L'invention se rapporte à un procédé de gestion d'au moins une ressource informatique, notamment contenue dans un système d'information. Le procédé utilise un navigateur d'arbre et s'applique à toute ressource modélisée en technologie orientée objets dans des groupes de classes, tels que les groupes nommés schémas du modèle commun d'informations CIM (Common Information Model) pour donner à tout utilisateur une représentation des objets gérés. L'invention a aussi pour objets corollaires un système informatique et un système d'administration mettant en oeuvre le procédé de l'invention, ainsi qu'un programme d'ordinateur pour la mise en oeuvre du procédé de l'invention et un support d'enregistrement du programme, tel qu'un cédérom.

L'art antérieur.

L'administration de ressources informatiques est ordinairement faite par une plate-forme d'administration dont on connaît plusieurs types. La plate-forme qui servira d'exemple par la suite est celle connue sous le nom de marque déposée OpenMaster, commercialisée par le demandeur. Cette plateforme se fonde sur une technologie orientée objets. Selon cette technologie, les moyens constituant une ressource informatique sont convertis en classes d'objets organisées hiérarchiquement dans un arbre constituant une base d'informations d'administration MIB (Management Information Base).

La plate-forme prise ici comme exemple non limitatif utilise le protocole normalisé de communication dédié à l'administration, connu sous le nom de protocole CMIP (Common Management Information Protocol). Le protocole CMIP repose sur la norme ISO définissant les services pour le transfert des informations d'administration appelés services CMIS (Common Management Information Services). Ce protocole est organisé selon un langage de description des informations d'administration appelé langage

GDMO/ASN. l issu de directives pour la définition d'objets gérés (Guidelines for the Definition of Managed Objects) selon le modèle d'interconnexion connu sous le nom de marque déposée OSI (Open Systems Interconnection) de l'organisme international de normalisation ISO (International Standards Organisation), et de syntaxe ASN1 (Application Syntax Notation One). Pour des raisons de commodité, ce langage sera appelé simplement GDMO.

La plate-forme comprend des applications d'administration, par exemple adaptées à la découverte des objets de la base MIB, à la surveillance d'objets et à leur sécurité. Ces applications sont sous la commande d'un utilisateur et l'accès aux objets qu'elles manipulent se fait par émission de requêtes et réception de réponses. Les requêtes et réponses sont dirigées vers les objets cibles par un courtier de requêtes CMIP de la plate-forme. Cependant, la plupart des objets cibles ne peuvent être atteints qu'à travers des agents utilisant un protocole de transmission autre que CMIP et normalisé ou non. Comme autre protocole ayant reçu la norme ISO, on connaît le protocole SNMP (System Network Management Protocol) fondé sur la transmission de type TCP/IP (Transfer Control Protocol/Internet Protocol). La transmission des requêtes et des réponses se fait donc par une interface nommée intégrateurs d'agents, faisant la conversion entre le protocole CMIP de la plate-forme et l'autre protocole.

Cependant, il devient souhaitable que les applications puissent accéder à des objets appartenant à d'autres protocoles qui deviennent largement diffusés. Pour certains de ces protocoles, il serait possible de les convertir, mais avec de grandes difficultés et avec une certaine lourdeur. C'est le cas par exemple des ressources informatiques dont les données sont représentées selon une base technologique commune et dont les échanges de données et de services se font selon différents protocoles. Une de ces bases technologiques communes de plus en plus utilisée est le modèle commun d'informations CIM (Common Information Model). Ce modèle normalisé est défini par le consortium DMTF (Distributed Management Task Force). Le modèle CIM est orienté objets et permet de définir des schémas conceptuels et des objets du monde réel destinés à l'administration. Il utilise un langage

unifié de modélisation connu sous le nom de langage UML (Unified Modelling Language). Ce modèle reçoit actuellement un succès grandissant à cause de son adaptation aux échanges sur les réseaux de type interne. Il est ainsi utilisé pour l'administration d'entreprise par la Toile mondiale, connue actuellement sous l'acronyme WBEM (Web-Based Enterprise Management).

En particulier, le modèle CIM offre le double avantage de pouvoir utiliser, d'une part, un navigateur pour chercher des données d'administration et, d'autre part, les technologies d'internet pour l'administration. Ce modèle offre encore l'avantage d'être bien adapté à des ressources incluant une architecture d'objets distribués.

Selon le modèle CIM, les ressources à administrer sont modélisées dans des ensembles de classes d'objets, ces ensembles étant appelés des schémas. De manière classique en technologie orientée objets, un objet est une instance d'une classe. Les objets des schémas sont contenus dans un arbre d'espaces dans lesquels sont nommés les objets. Ces espaces sont appelés"Namespace"dans le modèle CIM et seront désignés plus généralement par répertoires d'objets. Un répertoire contient au moins un groupe d'objets se rapportant à des fonctions liées à un domaine spécifique.

Un groupe peut se rapporter par exemple au système, ou à des applications d'administration, ou au réseau connecté au système. Les groupes correspondent à des sous-répertoires respectifs appelés des schémas dans le modèle CIM. Les objets ainsi organisés sont représentés par une application mettant en oeuvre un moyen de navigation dans une arborescence d'objets. Dans un système de gestion des ressources, l'application est accessible par un utilisateur, nommé administrateur, du système d'administration. Quand l'administrateur veut consulter un répertoire, il y trouve à un même niveau l'ensemble des classes constitutives des sous-répertoires (schémas) présents dans le répertoire.

Un problème important est que le grand nombre de classes au même niveau dans un répertoire complique beaucoup et ralentit fortement l'examen du répertoire et la recherche d'un objet. À présent, aucune solution connue n'a été donnée à ces deux problèmes.

Sommaire de l'invention.

Un premier but de l'invention est de présenter un procédé et un système permettant de détecter facilement la présence d'un sous-répertoire (schéma) et/ou d'un objet désiré dans un répertoire. Ce but a trois avantages principaux : faciliter l'examen d'un répertoire ; faire une recherche rapide d'un objet donné ; et utiliser un navigateur dans un arbre d'objets pour faire la recherche.

Un second but est de pouvoir identifier les sous-répertoires d'un répertoire.

Un troisième but est de pouvoir s'appliquer aux répertoires nommés Namespaces dans le modèle CIM comme à d'autres répertoires possibles, dont les classes ne sont pas hiérarchisées et ne sont représentées ou accessibles qu'à un seul niveau.

Un quatrième but est d'avoir un procédé efficace et fiable et dont la mise en oeuvre est simple et peu coûteuse dans un système informatique.

L'invention a pour premier objet un procédé de gestion, par l'intermédiaire d'au moins un processeur et d'un navigateur, d'au moins une ressource modélisée en technologie orientée objets dans des groupes (schémas) de classes contenues dans un répertoire inclus dans des moyens de mémoire, le navigateur ne permettant pas une représentation des groupes, caractérisé en ce qu'il comprend les étapes de créer des classes dans les moyens de mémoire pour identifier les groupes respectifs et de lier les classes aux groupes correspondants.

L'invention a pour second objet un système informatique incluant au moins un processeur, des moyens de mémoire et un analyseur d'arbre, caractérisé en ce qu'il met en oeuvre le procédé défini précédemment.

Le système informatique peut être un système d'administration d'au moins une ressource de système d'information.

Présentation des dessins.

'La figure 1 est une vue synoptique d'un exemple de système d'administration d'au moins une ressource, en l'occurrence un système d'information, le système d'administration mettant en oeuvre un exemple de procédé conforme à l'invention de gestion du système d'information.

* La figure 2 est un diagramme illustrant de façon synoptique et partielle un exemple de base MIB de l'art antérieur.

* La figure 3 est un diagramme illustrant de façon synoptique et partielle un exemple d'arbre d'objets correspondant à la base MIB représentée sur la figure 2 et obtenu par l'art antérieur.

* La figure 4 est un diagramme illustrant un exemple de base MIB correspondant à l'exemple de la figure 2 et mis en oeuvre par le système d'administration conforme à l'invention, représenté sur la figure 1.

'Et la figure 5 est un diagramme illustrant un exemple d'arbre d'objets correspondant à celui de la figure 3 et obtenu du système d'administration conforme à l'invention, représenté sur la figure 1.

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, les 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 du 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 trois machines 12a-12c, 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 et passerelles entre réseaux. Le système d'information 11 est ordinairement un système comprenant plusieurs processeurs 14, 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 (non illustrés) 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 10 utilise au moins l'une de ces ressources selon un modèle de données orienté 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 pour administration. Cette architecture ne correspond pas à une architecture classique client-serveur, dans laquelle les clients envoient des requêtes aux serveurs pour qu'ils effectuent un traitement et retournent une réponse. Dans le cas présent, les clients sont les machines gérées, auxquelles le serveur envoie des requêtes pour les interroger ou leur faire exécuter des commandes. En d'autres termes, la partie serveur gère et la partie cliente comprend la ou les ressources à gérer. Dans l'exemple illustré, un gestionnaire 16 forme un serveur d'administration inclus dans la machine 12a, dite machine gestionnaire, tandis que les clients d'administration 17a et

17b sont appelés agents et sont inclus dans les machines respectives 12b et 12c, dites machines gérées. Le gestionnaire 16 analyse et agit sur l'environnement à gérer selon la technologie orientée objets. Dans l'exemple choisi, toutes les classes des objets gérés sont hiérarchisées dans un arbre correspondant à une base d'informations d'administration plus connue sous le nom de MIB (Management Information Base). Les agents 17a et 17b permettent l'accès aux ressources à gérer dans les machines respectives 12b et 12c. Selon une option courante et avantageuse du système d'administration 10, le gestionnaire 16 gère aussi la machine gestionnaire 12a correspondante ou peut gérer tout ou partie d'autres machines gestionnaires possibles. Cela peut se faire de façon similaire à celle illustrée avec une machine gérée, 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 du métier de faire aisément une généralisation du système décrit et illustré.

Le gestionnaire 16 constitue une plate-forme d'administration, entièrement contenue dans la machine 12a dans l'exemple illustré, mais pouvant être partagée dans d'autres machines. Le gestionnaire 16 inclut un module applicatif 20 contenant un ensemble d'applications 21 connectées à un tableau de bord 22 connecté à un navigateur 19. Le tableau de bord 22 est classique et inclut une partie graphique et un lanceur de requêtes 23. Une station graphique 24, extérieure à la plate-forme 16, est reliée au tableau de bord 22 pour visualiser les applications 21, lancer des requêtes et visualiser les résultats contenus dans les réponses aux requêtes. Elle permet à un utilisateur de se connecter à la machine 12a pour démarrer et arrêter comme il le désire ses propres copies des applications 21. L'ensemble du module 20 et de la station 24 peut constituer une station d'administration, séparée du reste du gestionnaire qui forme ainsi un serveur d'administration. Le serveur d'administration illustré utilise le protocole CMIP et comprend trois blocs fonctionnels : un module de services CMIS 25 incluant notamment une base CMIS-DB 26 de données CMIS contenant la base MIB, et un service 27 de schémas d'informations d'administration, appelé MISS (Management Information Schema Service), et constituant une interface de programmation

d'application API (Application Programming Interface) avec la base CMIS-DB 26 ; un courtier CMIP 28 aussi appelé bloc de communication ou distributeur de services CMIS (CMIS Dispatcher) contenant l'objet racine ROOT de tous les objets gérés par la plate-forme 16 ; et un module 29 intégrateur d'agents du modèle CIM. L'intégrateur 29 d'agents CIM constitue une interface entre le protocole CMIP utilisé par le gestionnaire et l'utilisateur de la station graphique 24 et un ou les protocoles du modèle CIM utilisé par les ressources contenues dans les machines gérées 12b et 12c. L'intégrateur 29 est donc une interface commune entre le gestionnaire et les agents CIM 17a et 17b. En pratique, le module 29 contient d'autres intégrateurs d'agents adaptés à d'autres protocoles normalisés ou non, tels que le protocole SNMP.

Les agents CIM 17a et 17b sont connectés au réseau 13 de type internet et sont connus sous le nom d'agents WBEM. Les deux types d'agents WBEM connus actuellement sont l'agent WMI (Windows Management Instrumentation) de la société Microsoft, équipant ses systèmes d'exploitation Windows 98tam et Windows NIT, et l'agent CIMOM (CIM Object Manager) de la société Sun Microsystems, prévu notamment pour les systèmes d'exploitation Solaris. L'agent WMI comprend un service de gestion d'objets utilisant une interface de programmation d'application, aussi connue sous le nom d'interface API (Application Programming Interface), nommée DCOM (Distributed Component Object Model) et écrite en langage C++, tandis que l'agent CIMOM utilise une interface API nommée RMI (Remote Method Invocation) en langage Java. D'autre part, ces deux types d'agents WBEM utilise le protocole HTTP (HyperText Transfert Protocol), qui est adapté au langage XML (Extensible Markup Language) élaboré par le groupe de travail ERB (Editorial Review Board) du consortium W3C (World Wide Web Consortium) et qui se nomme par conséquent protocole CIMXML/HTTP. Ces deux types d'agents WBEM fournissent donc une interface CIMXML par l'intermédiaire d'un serveur HTTP.

La figure 2 illustre de façon schématique et très partielle un exemple de structure de la base MIB contenue dans la base CMIS-DB 26. La base MIB est un arbre de classes des objets qui sont gérés par la plate-forme

constituant le gestionnaire 16 du système d'administration 10 et qui sont représentatifs d'au moins une ressource du système d'information 11. Une base MIB n'est pas une base de données proprement dite, mais est assimilable à un catalogue de caractéristiques puisqu'elle contient la description et le contenu de toutes les classes gérées par le système d'administration 10. L'organisation des classes dans l'exemple choisi du système d'administration 10 est hiérarchique. Une classe y est donc définie en subordination à une ou plusieurs classes mères. Les classes des objets gérés sont aussi dites classes MOC (Managed Object Class). Un objet géré est une vue abstraite, définie pour les besoins de la gestion, d'une ressource logique ou physique d'un système. Tous les objets de la base MIB dans la figure 2 sont placés sous la racine TOP et sont répartis en sous-arbres, dont les racines sont appelées sous-racines (rootlets).

La figure 2 donne un exemple de base MIB se rapportant au sous-arbre représentatif des agents WBEM 17a, 17b du système d'administration 10 et des objets 18a, 18b du modèle CIM qui sont gérés dans les machines respectives 12b, 12c. La racine du sous-arbre se nomme WBEMSystem et a une sous-classe nommée WBEMNamespace représentative des classes CIM contenues dans les répertoires CIM nommés schémas CIM. Les classes représentées sur la figure 2 se nomment Classl, Class2,..., Class,..., Class,..., Classp. Comme illustré, toutes les classes CIM sont disposées en parallèle et au même niveau. Les schémas CIM ne sont pas représentés, de sorte qu'il n'est pas possible de savoir à quel schéma une classe quelconque se rapporte.

À chaque classe MOC peuvent être attachées une ou plusieurs instances d'objets gérés, aussi appelées instances MOI (Managed Object Instance). On appelle couramment objet une instance d'une classe. Par conséquent, à l'arbre de la base MIB contenue dans la base CMIS-DB 26 et illustrée dans la figure 2 correspond un arbre 30 des objets gérés. À la classe racine TOP correspond un objet racine ROOT. Dans l'exemple illustré, la racine ROOT est contenue dans le courtier 28. L'arbre 19 a des sous-arbres d'objets 18a, 18b contenus dans les machines gérées correspondantes 12b et

12c du système d'administration 10. Pour analyser un arbre, tel que l'arbre de MIB ou l'arbre 19 et/ou rechercher une classe ou un objet donné dans l'arbre correspondant, on utilise un analyseur d'arbre (browser). Les résultats fournis par l'analyseur peuvent être traités pour fournir une représentation de l'arbre, par exemple sous une forme similaire à celle illustrée.

La figure 3 illustre un exemple très simplifié et très partiel d'un arbre 30 correspondant à l'arbre MIB représenté sur la figure 2 et étant obtenu d'un système d'administration 10 classique. De la classe WBEMSystem de la base MIB sont issus deux objets WBEMSystemID=l et WBEMSystemID=2 dans l'arbre 19. De la classe WBEMNamespace sont issus deux objets WBEMNamespace=Root et WBEMNamespace=Root/CIMV2 attachés à l'objetWBEMSystemID=l.

Pour la simplification des dessins, les objets sous l'objet WBEMSystemID=2 ne sont pas définis et pourraient comprendre de même des objets issus de la classe WBEMNamespace. Les classes définies sous WBEMNamespace ont aussi été instanciées en différents objets, nommés Objectl. l,..., Object2. 1,....

Objecti. 2,..., Object. 4 et liés à l'objet WBEMNamespace=Root, ainsi que Object. 5,..., Object4. 2,..., Object5. 1,..., Objectp. 5 liés à l'objet WBEMNamespace=Root/CIMV2. Les objets sont désignés ici par un premier chiffre relatif au numéro de la classe qui s'y rapporte et par un second chiffre relatif au numéro d'ordre de création de l'objet, afin de faciliter la compréhension du texte. En pratique, tous ces objets portent des noms quelconques, arbitraires ou relatifs à leur fonction ou leur qualité. De même que dans l'arbre de MIB représenté sur la figure 2, les objets sont placés au même niveau sous l'objet relatif au répertoire WBEM (WBEMNamespace). Actuellement, il est impossible d'obtenir d'un navigateur 19 une représentation des schémas CIM, de sorte qu'il n'est pas possible de savoir à quel schéma une classe ou un objet quelconque se rapporte. Un système d'administration actuel peut avoir plusieurs milliers de telles classes et d'objets. On comprend donc que la recherche actuelle d'une classe ou d'un schéma est très difficile, longue et insupportable.

Les figures 4 et 5 sont respectivement des vues similaires à celles des figures 2 et 3 et illustrent des exemples d'arbres pouvant être obtenus par la mise en oeuvre du procédé conforme à l'invention qui va maintenant être décrit. On suppose que l'administrateur du système d'information 11 dispose dans le système d'administration 10 d'une application 21 pour gérer des objets dans les machines 12b et 12c. On suppose aussi que l'application 21 utilise le navigateur 19 pour, par exemple, la découverte des objets gérés.

Dans une première étape du procédé de l'invention, des classes, nommées cimSchemal, cimSchema2 et cimSchema3, sont créées pour identifier des schémas CIM respectifs. Dans une deuxième étape, les classes CIM Classl-Classp sont liées aux schémas CIM correspondants. La liaison peut se faire simplement en attribuant aux classes Classl-Classp des liens avec les classes correspondantes qui ont été créées lors de la première étape.

Ces liens sont nommés NameBindings dans le langage GDMO, et correspondent à des règles de modélisation. Il en résulte la base MIB représentée sur la figure 4. On trouve les trois classes créées, attachées à la classe WBEMNamespace. Les classes CIM Classl-Classp ont été réparties dans les trois schémas correspondants. Les liens relatifs à chaque classe sont symbolisés par un trait commun 31 dans la figure 5. En réalité, chaque classe CIM est reliée à la classe créée correspondante par un seul lien. On a vu précédemment que les schémas correspondent à des groupes de classes contenus dans un répertoire. Ils constituent des sous-répertoires. La figure 5 illustre aussi une extension du procédé, comprenant la génération d'au moins une classe correspondant à un sous-schéma (sous-groupe) nommée cimSchema3.1.

La figure 5 illustre un exemple de représentation sous la forme d'un arbre 30 d'objets classés selon leurs schémas respectifs correspondant à l'arbre 30 représenté sur la figure 3. Le procédé de l'invention permet de classer les objets dans des schémas d'objets CIM correspondants. Ainsi, les trois classes cimSchemal-3 ont été instanciées en deux objets nommés cimSchemal et cimSchema2 liés au répertoire WBEMNamespace=Root

et deux objets cimSchemal et cimSchema3 liés au répertoire WBEMNamespace=Root/CÏMV2
La détection de la présence d'un schéma donné dans un arbre, l'arbre MIB ou 30, peut être faite de nombreuses façons. Le procédé peut ainsi comprendre la génération d'une requête R, illustrée dans la figure 1, désignant un objet correspondant à une des classes créées pour détecter la présence d'un groupe correspondant à la classe désignée. Une autre façon pourrait se faire par la génération d'une requête R désignant un objet correspondant à une classe liée à un groupe donné pour détecter la présence de ce groupe dans le répertoire. Dans l'un ou l'autre cas, la requête est lancée dans la plate-forme 16 par le lanceur 23. De préférence, elle est du type générique GET. De préférence également, l'objet visé par la requête est unique, du type connu de l'homme du métier sous le nom singleton, de sorte que la requête est aussi unique.

Dans l'exemple décrit, le procédé de gestion conforme à l'invention est appliqué dans un système d'administration et le navigateur 19 est utilisé par une application d'administration 21. Cependant, le navigateur peut constituer une application en tant que telle et être utilisé seul, sans l'intermédiaire d'une application. En outre, il ressort à l'évidence de l'exemple décrit que le procédé peut être utilisé dans tout système informatique incluant un navigateur d'arbre.

D'une manière générale, l'invention a donc pour objet un procédé de gestion, par l'intermédiaire d'un navigateur 19, d'au moins une ressource 11 modélisée en technologie orientée objets dans des groupes (schémas) de classes contenues dans un répertoire (WBEMNamespace), le navigateur ne permettant pas une représentation des groupes. Le procédé comprend les étapes de créer des classes (cimSchema) pour identifier les groupes respectifs (cimSchemal-3) et de lier les classes aux groupes correspondants. Accessoirement, et avantageusement, le procédé comprend en outre une représentation sous la forme d'un arbre (MIB, 30) de classes ou d'objets classés selon leurs groupes respectifs.

Claims

Revendications : 1. Procédé de gestion, par l'intermédiaire d'au moins un processeur (14) et d'un navigateur (19), d'au moins une ressource (11) modélisée en technologie orientée objets dans des groupes (schémas) de classes contenues dans un répertoire (WBEMNamespace) inclus dans des moyens de mémoire (15), le navigateur ne permettant pas une représentation des groupes, caractérisé en ce qu'il comprend les étapes de créer des classes (cimSchema) dans les moyens de mémoire pour identifier les groupes respectifs (cimSchemal-3) et de lier les classes aux groupes correspondants.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une représentation sous la forme d'un arbre (MIB, 30) contenu dans les moyens de mémoire (15) et fait de classes ou d'objets classés selon leurs groupes respectifs.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend la génération, au moyen d'au moins le processeur (14), d'une requête (R) désignant un objet correspondant à une des classes créées pour détecter la présence d'un groupe correspondant à la classe désignée.
4. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comprend la génération, au moyen d'au moins le processeur (14), d'une requête (R) désignant un objet correspondant à une classe liée à un groupe donné pour détecter la présence de ce groupe dans le répertoire.
5. Procédé selon la revendication 3 ou 4, caractérisé en ce que la requête est unique.
6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que les liens sont définis par des règles (NameBinding) de modélisation.

<Desc/Clms Page number 14>
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il comprend la génération, au moyen d'au moins le processeur (14), d'au moins une classe (cimSchema3.1) correspondant à un sous-groupe.
8. Système informatique (10, 11) incluant au moins un processeur (14), des moyens de mémoire (15) et un analyseur (19) d'arbre, caractérisé en ce qu'il met en oeuvre le procédé défini par l'une des revendications précédentes.
9. Système selon la revendication 8, caractérisé en ce qu'il constitue un système d'administration (10) d'au moins une ressource de système d'information (11).