FR2776789A1 - Serveur de requetes generalisees - Google Patents

Abstract

L'invention concerne un serveur de requêtes généralisées (1) caractérisé en ce qu'il permet d'interroger, au travers de requêtes, différentes sources de données (SD) à partir d'une interface unique paramétrable pouvant être activée par des applications et des modules d'administration, une requête étant modélisée dans une base de gestion d'informations (MIB) sous forme d'un objet principal (OP) comportant le type de la source à interroger et un attribut de ce type, et d'objets subordonnés d'entrée (OE) et de sortie (OS), lesdits objets d'entrée (OE) décrivant chacun un paramètre (PE), lesdits objets de sortie (OS) décrivant chacun une variable-résultat (VR).

Description

Serveur de requêtes généralisées Cette invention concerne le domaine de

l'administration de réseaux et systèmes. Dans ce domaine, plusieurs sources de données, utilisant différents types de langage (CMIS, SQL, script, LDAP), coexistent et doivent pouvoir être exploitées différemment par des applications et/ou des modules d'administration. Le problème posé consiste à pouvoir interroger ces différentes sources de données, base de données, base de gestion d'informations (MIB) distantes

1o ou locales, annuaires, fichiers, à partir d'une interface unique et configurable.

Les requêtes, qui doivent être faites sur ces différentes sources de données,

dépendent du langage de requêtes qui est propre à chacune de ces sources.

De plus, ces interrogations, compatibles avec différents langages de requêtes, doivent pouvoir être dynamiquement configurées. Cette configuration consiste à fournir les paramètres d'exécution et de sortie d'une requête déjà définie ou à

définir une nouvelle requête.

Traditionnellement, pour résoudre ce problème, les requêtes permettant d'accéder aux différentes sources de données étaient codées pour chaque application ou module d'administration. Cette solution n'est pas satisfaisante, car elle nécessite de modifier le code pour pouvoir prendre en compte chaque nouvelle requête. En outre, cette solution doit être développée

pour chaque domaine d'utilisation.

Une autre solution consiste à traduire les données que l'on veut exploiter sous forme d'objets d'une base de gestion d'informations (MIB). Cette solution demande de modéliser les données sous forme d'objets et d'écrire un traducteur du format propre à la source de données interrogée vers un format

MIB. Ce travail très coûteux est inutile par rapport aux besoins que l'on a.

L'objectif de l'invention est de masquer les différents types de langages de requêtes associés à différents types de sources de données, sans être obligé de modéliser sous forme d'objets les données provenant des différentes

sources de données.

Pour cela, la présente invention propose un serveur de requêtes caractérisé en ce qu'il permet d'interroger, au travers de la notion de requête généralisée, différentes sources de données à partir d'une interface unique configurable pouvant être activée par n'importe quels applications et modules d'administration, une requête généralisée étant modélisée dans une base de gestion d'informations (MIB) sous forme d'un objet principal comportant le type de la source à interroger, une référence à la requête propre à la source, et d'objets subordonnés d'entrée et de sortie, lesdits objets d'entrée modélisant

les paramètres, lesdits objets de sortie modélisant les variablesrésultats.

Selon une autre particularité, le serveur de requêtes est un gestionnaire d'objets, interrogé via un service commun de gestion

d'informations (CMIS), les requêtes étant exécutées à l'aide d'une opération M-

ACTION.

Selon une autre particularité, ledit objet d'entrée modélisant un paramètre d'entrée de la requête comporte un identifiant, le nom d'une variable qui va être passée à la requête, la syntaxe de ladite variable et une valeur par

défaut du paramètre et des commentaires.

Selon une autre particularité, ledit objet de sortie modélisant une variable-résultat comporte un identifiant, le nom d'une variable, le type de

ladite variable et des commentaires.

Selon une autre particularité, une requête généralisée permet de constituer une liste d'équipements, ladite requête généralisée étant définie en créant un objet principal et des objets subordonnés modélisant d'une part les

paramètres d'entrée et d'autre part les variables-résultats.

Selon une autre particularité, le serveur de requêtes sert à alimenter un

serveur d'ensembles pour la constitution de la liste de ses éléments.

Selon une autre particularité, le serveur d'ensembles comporte en outre un objet de définition d'un ensemble qui peut exploiter une requête généralisée et qui comporte la définition d'un paramètre constituant un opérateur ensembliste dans le cas o l'ensemble est constitué à partir de la

combinaison de sous-ensembles.

Selon une autre particularité, le serveur d'ensembles permet de constituer des domaines contenant des listes d'équipements. Selon une autre particularité, le serveur de requêtes est associé à un serveur d'ensembles stockant des listes d'équipements, ledit serveur d'ensembles étant modélisé sous forme d'objets dans une base de gestion d'informations (MIB), les objets MIB pointant une référence aux objets principaux du serveur de requêtes et comportant des attributs propres aux ensembles. Selon une autre particularité, le serveur d'ensembles comporte des

fonctions ensemblistes et de rafraîchissement.

Selon une autre particularité, le serveur d'ensembles comporte une interface présentant au moins une fenêtre de dialogue proposant différentes modalités de constitution et/ou de modification d'une liste d'équipements, des fonctions ensemblistes, une fonction de rafraîchissement des listes d'équipements pouvant interroger périodiquement des sources de données (SD). Selon une autre particularité, une liste d'équipements peut aussi être constituée en tapant manuellement sur le clavier d'un ordinateur la référence

de chaque équipement.

Selon une autre particularité, une liste d'équipements peut être constituée par la sélection d'une requête généralisée dans une liste de

requêtes existantes.

Selon une autre particularité, une liste d'équipements peut être

constituée par la combinaison de listes existantes.

Selon une autre particularité, une liste d'équipements peut être constituée en sélectionnant au moins un équipement et/ou une liste d'équipements modélisés sous forme d'objet MIB sur une carte du moniteur ISM et en utilisant les fonctions traîner et jeter (drap and drap) du moniteur ISM. Selon une autre particularité, les variables-résultats fournies par différents appels au serveur de requêtes peuvent être combinées afin de

fournir d'autres variables-résultats calculées.

Selon une autre particularité, les variables-résultat fournies par le serveur de requêtes peuvent être utilisées dans des expressions logiques constituant autant d'indicateurs pour le contrôle de la cohérence (CC) entre un

1o équipement et une configuration de référence.

Selon une autre particularité, le contrôle de cohérence (CC) permet d'exécuter une action de configuration sur une liste d'équipements définie dans

un domaine.

D'autres particularités et avantages de la présente invention

apparaîtront plus clairement à la lecture de la description ci-après faite en

référence aux dessins annexés dans lesquels: - la figure 1 représente le fonctionnement d'un serveur de requêtes généralisées, - la figure 2 représente la structure d'une requête, - la figure 3A représente la fenêtre de dialogue permettant d'associer

un ensemble à une requête généralisée.

- la figure 3B représente une fenêtre permettant la saisie d'une liste d'éléments d'un ensemble, - la figure 3C représente une autre fenêtre affichant la liste des éléments d'un ensemble, - la figure 4A représente la fenêtre d'affichage de la définition d'un objet de la classe "requête généralisée", dit " objet principal ", - la figure 4B représente la fenêtre de définition des attributs d'un objet d'entrée, - la figure 4C représente la fenêtre de définition des attributs d'un objet de sortie, la figure 4D représente la fenêtre de définition d'un autre objet de la classe "requête généralisée" dans un autre exemple d'application, - la figure 4E représente la fenêtre de définition des attributs d'un objet d'entrée de l'autre exemple d'application, - la figure 4F représente la fenêtre de définition des attributs d'un

ensemble,-

- les figures 5A, 5B, 5C et 5D représentent respectivement un deuxième exemple d'utilisation des fenêtres d'objet principal (fig. 5A), d'objet d'entrée (fig. 5B), d'objet de sortie (fig. 5C) et d'objet indicateur (fig. 5D) pour la fonction de contrôle de cohérence, - la figure 6 représente une fenêtre de constitution d'un ensemble en

combinant des ensembles existants.

L'invention concerne un "serveur de requêtes généralisées" pouvant interroger différentes sources de données à partir d'une interface unique paramétrable (CMIS). Le serveur de requêtes (SR) est un gestionnaire d'objets (object manager) qui est interrogé via le service (CMIS). Ce serveur de requêtes (SR, fig. 1) est associé à un serveur d'ensembles (SE) qui assure la fonction de stockage des résultats obtenus par requêtes. Le serveur de requêtes est également associé à l'application Configuration Manager par la fonction de contrôle de cohérence qui a pour rôle d'exécuter une action de vérification de cohérence sur une liste d'équipements appelée "ensemble", calculée par le serveur d'ensembles et appartenant à un domaine défini. Le serveur de requêtes (SR), selon l'invention, a été implanté dans le contexte de l'application ISM Configuration Manager qui est une application de gestion de configuration. L'interface paramétrable choisie dans ce contexte est une interface du service commun de gestion d'informations CMIS (Common Management Information Service). Cette interface CMIS est très avantageuse, car elle peut

être sollicitée par des applications et/ou des modules d'administration.

Le service commun de gestion d'informations (CMIS) qui lui est associé, est un service de communication comportant six opérations l'opération GET pour la lecture d'une information, I'opération SET pour la mise à jour d'une information, I'opération M-EVENT pour l'émission d'événements, l'opération M-ACTION pour le lancement d'une procédure, I'opération MCREATE pour la création de nouveaux objets et enfin l'opération M-DELETE pour leur suppression. Quelle que soit la source d'informations, le service utilisé, par les applications du gestionnaire de service intégré ISM pour

administrer les équipements, sera toujours CMIS.

Un exemple d'utilisation du serveur de requêtes (SR) est réalisé par la constitution de listes d'équipements appelés " ensembles " (301, 302) à partir de différentes sources de données (4, 5, 6, 7): base de gestion d'informations, fichiers, base de données relationnelles, annuaires, etc. Ces équipements sont constitués de machines, ponts, routeurs, multiplexeurs, terminaux, etc., formant un réseau et qui peuvent être regroupés dans des domaines. Le serveur de requêtes (SR) est un maillon d'un serveur d'ensembles (SE). Le serveur

d'ensembles (SE) intervient dans la constitution de domaines.

Un ensemble est modélisé sous la forme d'un objet de la base de gestion d'informations (MIB). Chaque objet MIB comporte une référence à un objet principal du serveur de requêtes et des attributs propres à un ensemble d'équipements. Le serveur d'ensembles communique avec le serveur de requêtes via le service commun de gestion d'informations (CMIS). De plus, le serveur d'ensembles (SE) comporte des fonctions ensemblistes (Union, Intersection et Exclusion mutuelle) et de rafraîchissement (refresh). En outre, le serveur d'ensembles (SE) peut interroger périodiquement le serveur de

requêtes (SR) pour mettre à jour ses listes d'équipements (301, 302).

Ainsi, un ensemble peut être constitué ou géré soit selon l'art antérieur en extension, en saisissant les références aux équipements, équipement par équipement, soit selon l'invention en compréhension par l'exécution d'une requête qui peut porter sur différentes sources de données (SD) constituées

7 2776789

par des MIB, des fichiers, des bases de données relationnelles, des annuaires etc. Un second exemple d'utilisation du serveur de requêtes (SR) est réalisé par une opération de contrôle de cohérence. Le contrôle de cohérence consiste à vérifier la conformité d'équipements par rapport à des configurations de référence. Lorsqu'un d'équipement n'est pas conforme, le contrôle de cohérence (CC) peut déclencher une action correctrice sur cet équipement. Une configuration de référence est constituée d'un ensemble de variables et d'expressions logiques sur ces variables qui sont autant io d'indicateurs permettant de vérifier la cohérence d'un équipement avec la configuration de référence. Pour pouvoir vérifier la conformité des équipements, le serveur de requêtes (SR) lance des requêtes sur des sources de données variées (4, 5, 6, 7) pour donner des valeurs aux variables exprimées dans les configurations de référence. Ces variables sont également celles décrites dans les objets de sortie. Les requêtes sont modélisées sous forme de trois objets: un objet principal (OP, fig. 2) comportant les informations permettant d'interroger la source et des objets subordonnés d'entrée (OE) et de sortie (OS) qui vont nous donner des paramètres d'entrée (PE) et des variables résultats (VR au lieu de PS) d'une requête. Les objets d'entrée et les objets de sortie sont reliés à l'objet principal par une liaison de nom "name binding" dans une relation d'objet fils à objet père. Et, à partir du moment o l'objet principal est défini dans une base de gestion d'informations (MIB), il peut être directement exploité à travers des fonctions M-ACTION qui sont définies et exploitables par

lI'interface CMIS.

L'objet principal (OP) appartient à la classe d'objets "request" et comporte le type de langage d'interrogation de la source de données, par exemple CMIS (figure 4A) et un attribut lui correspondant "request CMIS" qui fournit une référence à la requête CMIS, par exemple, celle référencée OSTYPE (figure 4A), que doit exécuter le serveur de requêtes. Si le type de langage d'interrogation est SQL (Structured Query Language), I'attribut correspondant est un accès à la base et une expression de la requête. Si le type de langage d'interrogation est CMIS, I'attribut lui correspondant est une référence à CMIS-Query. Et enfin, lorsque le langage d'interrogation est script,

l'attribut lui correspondant est une référence à ce script.

Les objets de sortie (OS) appartiennent à la classe d'objets "requestResult" et définissent une liste de variables résultats (VR). Chaque objet de sortie comporte un identifiant "request Result Number", le nom d'une

variable "request variable name" (figure 4B), et le type de ladite variable.

Les objets d'entrée (OE, figure 4C)) appartiennent à la classe d'objets "requestParameter" et définissent une liste de paramètres (PE). Chaque objet d'entrée comporte un identifiant "request Parameter Number", le nom d'une variable "request Variable Name", le type de cette variable "request Variable Type" et une valeur par défaut "request Parameter Default". Dans le cas d'une utilisation du serveur de requêtes (SR) pour constituer des ensembles (SE), la valeur par défaut du paramètre d'entrée est prise en compte si aucune valeur

du paramètre n'est saisie à l'écran au moment de la définition de l'ensemble.

La seule modification des objets d'entrée permet de modifier le paramétrage de la requête. On peut aussi facilement définir deux requêtes

généralisées référençant une même requête spécialisée - par exemple CMIS -

mais disposant d'objets d'entrée différents. De cette façon, il est possible

d'exploiter une même requête spécialisée dans des contextes différents.

Ainsi, la modélisation d'une requête sous forme d'objets permet non seulement de paramétrer cette requête et de récupérer des variablesrésultats, mais aussi de modifier ce paramétrage dynamiquement au travers du moniteur

graphique ISM (ISM Monitor).

Il existe trois types d'utilisation du serveur de requêtes généralisées.

Premièrement, I'utilisateur peut sélectionner une requête quelconque pour constituer un domaine ou effectuer un contrôle de cohérence. Deuxièmement, l'utilisateur peut modifier le paramétrage de requêtes déjà existantes. Pour cela, I'utilisateur n'a pas besoin de connaître précisément les langages SQL, CMIS, LDAP ou script; il lui suffit de modifier les valeurs des attributs des trois objets qui modélisent la requête. Troisièmement, le serveur de requêtes peut être étendu pour prendre en compte de nouvelles sources de données. En effet, une plateforme d'administration de réseaux et de systèmes se doit de pouvoir travailler avec plusieurs sources de données qui peuvent être stockées sur des supports différents. A l'aide du serveur de requêtes, il est possible de supporter de nouveaux outils de stockage pour offrir un accès CMIS io paramétrable aux applications ou modules d'administration et ce sans avoir besoin à modéliser sous forme d'objets (MIB) les données qui l'on veut exploiter.

La figure 3A représente la fenêtre de dialogue du serveur d'ensembles.

Cette fenêtre est divisée en deux parties (30, 35). Dans la partie inférieure de cette fenêtre (35), sont proposées les actions applicables à l'ensemble d'équipements. Un champ (356) permet à l'utilisateur de spécifier, par exemple,

en minutes, la période de rafraîchissement (refresh) de la liste d'équipements.

La période de rafraîchissement correspond à la période entre deux interrogations successives des sources de données. Il suffit de cliquer sur le bouton d'application "Appliquer" (353) de cette fenêtre pour que le serveur de requêtes recalcule ces éléments en prenant en compte les modifications apportées. Un bouton "OK' (352) permet de refermer cette dernière fenêtre en enregistrant les modifications apportées à un ensemble. Un autre bouton "Annuler" (Cancel) (354) referme cette fenêtre sans tenir compte des modifications apportées à l'ensemble. Un bouton "Eléments" (355) affiche une fenêtre (260), représentée en figure 3C, et comportant une liste d'éléments d'un ensemble. Il suffit de cliquer le bouton "Refresh" (261) de la fenêtre (260) pour recalculer les éléments. En outre, la partie inférieure (35) de la fenêtre de dialogue du serveur d'ensembles comporte un bouton (combo-box) "Union/Intersection/Exclusion" (351) permettant de sélectionner la manière

dont on veut combiner des ensembles et les résultats de la requête.

Dans la partie supérieure de cette fenêtre (30), différentes modalités de constitution d'un ensemble d'équipements ou liste d'équipements sont proposées. En fait, il existe trois modalités de constitution d'un ensemble: en donnant manuellement un par un tous les éléments de l'ensemble, par l'intermédiaire d'une requête, ou en combinant des ensembles existants. Pour constituer un ensemble manuellement, il suffit de cliquer sur le bouton "List" (31) de la fenêtre de la figure 3A. Une fenêtre déroulante (61), représentée en figure 3B qui permet d'entrer les références des équipements, apparaît. Pour constituer un ensemble, I'utilisateur doit indiquer les références

Le des équipements choisis dans la fenêtre (61).

Une manière plus élégante de constituer un ensemble ou une liste d'équipements est d'utiliser les fonctions traîner et jeter (drag and drop) du moniteur ISM (ISM Monitor) sur des équipements modélisés sous forme de

base de gestion d'informations (MIB).

A partir du moniteur ISM, il est possible de dessiner une icône représentant un ensemble d'équipements. Ensuite, pour inclure un nouvel élément, il suffit de traîner (drag) une icône représentant un équipement et de

la jeter (drop) dans une icône d'ensemble.

Si l'utilisateur traîne (drag) une icône d'un serveur ou d'un PC dans une icône d'ensemble, I'identifiant de ce serveur ou de ce PC est calculé et rajouté à la liste d'équipements et peut être visualisé par la fenêtre de la figure 3A. Pour additionner plusieurs éléments en une seule opération, I'utilisateur doit sélectionner leurs icônes sur la carte du moniteur puis utiliser la fonction d'addition des objets sélectionnés (Add selected objects) de la liste déroulante du menu. Ainsi, toutes les icônes sélectionnées sont automatiquement incluses

dans la liste des équipements.

Pour constituer un ensemble en combinant des listes d'équipements existants, il suffit d'appuyer sur le bouton "NOUVEAU" (33) de la fenêtre représentée en figure 3A. La fenêtre de la figure 6 apparaît. L'utilisateur peut alors sélectionner un ensemble parmi ceux proposés dans le champ (61), ou taper dans le champ (62) le nom d'un autre objet (distinguished name). Cet il 2776789 objet peut être, par exemple, un ensemble ISM distant visualisé à travers un

lien de type supra-management.

D'autre part, I'utilisateur peut utiliser les fonctions traîner et jeter (drag and drop) du moniteur ISM. De la même manière que lors de la création manuelle d'une liste d'équipements, il faut traîner une première icône représentant un ensemble sur une seconde icône représentant un

autre ensemble. L'ensemble qui a été traîné sera référencé comme un sous-

ensemble de l'ensemble dans lequel il est jeté. Pour additionner plusieurs ensembles en une seule opération, I'utilisateur doit sélectionner leurs icônes io dans la carte du moniteur, puis utiliser la fonction d'addition des objets

sélectionnés "Add selected objects" de la liste déroulante du menu général.

Toutes les icônes sélectionnées sont incluses en tant que sous-ensembles.

Les icônes représentant des PCs et des serveurs isolés et les icônes représentant des ensembles peuvent être combinés dans une même sélection. Elles seront traitées en fonction de leur classe. Pour constituer un ensemble ou une liste d'équipements par l'intermédiaire d'une requête, l'utilisateur peut sélectionner une requête dans une liste (32) déroulante

(321) de requêtes existantes.

Lorsque l'utilisateur sélectionne l'édition d'un ensemble d'équipements, le champ (32) de la fenêtre de la figure 3A propose une liste de toutes les instances de requêtes existantes. Le préfixe "PC-", respectivement "UNIX-" indique que la requête concerne une machine de

type PC, respectivement un serveur de type UNIX.

Lors de la création d'une nouvelle requête, I'utilisateur doit définir d'une part la requête en complétant les champs des fenêtres (331, figure 4A) et d'autre part, les paramètres d'entrée (PE) de la requête en appelant par le

bouton (3312) la fenêtre (332, figure 4B) de la définition des paramètres.

La création d'une nouvelle requête fait appel à l'interface graphique du moniteur ISM qui permet l'affichage de n'importe quel objet de la base de gestion d'informations. La fenêtre 331 est un exemple d'affichage d'un objet de la classe "requête généralisée" et permet d'éditer les attributs de cet objet. Un premier attribut (3313) permet d'introduire l'identifiant de la requête (requestld); un deuxième attribut (3314) permet d'introduire le type de la requête (requestType) dans l'exemple représenté figure 3B requête type CMIS; un troisième attribut (3315) permet d'introduire un script de requête (requestScript) qui, dans l'exemple présenté, n'a pas de valeur; un quatrième attribut (3316) permet de préciser s'il s'agit d'une requête SQL (requestSQL) qui, dans le cas de l'exemple présenté, n'a pas de valeur; un cinquième attribut (3317) permet d'introduire le login de la requête SQL 1o (requestSQLLogin) qui, dans le cas représenté, n'a pas de valeur. Un sixième attribut (3318) permet d'introduire l'attribut "requestCMIS" qui fournit

une référence à la requête (CMIS) que doit exécuter le serveur de requêtes.

Dans l'exemple représenté, le nom de la requête (CMIS) référencée est de

type "OSTYPE".

Un avant demrnier attribut (3319) permet de préciser l'attribut "commentaires de la requête" (requestComment) et fournit une explication sur la requête exécutée. Un dernier attribut (3310) permet de préciser la

classe d'objets (objectClass) qui, dans l'exemple représenté, est "request".

Enfin, la fenêtre comporte un premier bouton (requestParameter) (3312) qui, lorsqu'il est activé, permet de déclencher l'apparition d'une fenêtre permettant de préciser les paramètres d'entrée et un deuxième bouton (requestResult) (3302) qui permet de faire apparaître une autre fenêtre permettant de préciser les paramètres de sortie, lorsque ce demrnier

bouton est activé.

Le fenêtre de la requête de la figure 4A représente une requête qui permet de constituer l'ensemble des équipements UNIX en interrogeant les

agents (MIB); le type de requêtes est "CMIS".

Pour remplir les différents champs de la fenêtre (331), I'utilisateur déplace un pointeur (33104) d'activation du champ qui est représenté, par exemple, par une flèche située dans l'exemple en vis-à-vis du sixième

13 2776789

champ (3318). La présence du pointeur en vis-à-vis du champ fait apparaître un curseur clignotant qui indique l'activation de ce champ et la possibilité de remplir la fenêtre correspondante et de stocker les informations ainsi

rentrées dans le serveur de requêtes.

L'activation du bouton "paramètre de requêtes" (3312) permet de faire apparaître la fenêtre (332) de la figure 4B, laquelle comporte un premier champ (3321) qui permet d'y indiquer le numéro du paramètre de requête (requestParameterNumber), un deuxième champ (3322) qui permet d'indiquer le nom de la variable (requestVariableName) qui va être passée à la requête (dans l'exemple "type"), un troisième champ (requestVariableType) (3323) qui foumrnit la syntaxe (dans l'exemple "chaîne" (string)), et un quatrième champ (3324) qui permet d'indiquer une valeur par défaut (requestParameterDefault) pour le paramètre (en l'occurrence dans l'exemple AIX). La fenêtre comporte également un cinquième champ (3325) is qui permet d'indiquer des commentaires (requestComment) et un sixième champ (3326), qui indique la classe de l'objet (objectClass), représenté par

la fenêtre (en l'occurrence "request Parameter").

Le serveur de requêtes comporte également une interface graphique qui permet de visualiser les réponses aux requêtes sous forme de fenêtres comme représenté à la figure 3C après avoir activé le bouton (3313) de la

fenêtre correspondant à l'objet "requête généralisée" (classe "request").

L'objet de sortie, représenté par la fenêtre (333) a la figure 4C,

définit une variable-résultat.

Dans le cas représenté à la figure 4C, l'objet de sortie comporte un identifiant qui est aussi, dans le cas d'un programme en langage de commandes (Shell-Script), le numéro de la colonne de la sortie standard

(requestParameterNumber) (3331).

Un deuxième attribut apparaît dans un deuxième champ (3332) et est constitué du nom de variable (requestVariableName). Un troisième champ (3333) permet de faire apparaître un troisième attribut qui est le type de variable (requestVariableType) et un quatrième champ (3334) permet de faire apparaître un commentaire (requestComment), tel que par exemple, " identifiant IP ", pour l'exemple de requête destiné à constituer l'ensemble d'équipements UNIX. Enfin, un dernier champ (objectClass) (3335) permet de faire apparaître la classe de l'objet qui, dans le cas présent, est une

variable- résultat de requête ("request Result").

La figure 4D représente l'objet de la classe "requête généralisée" (classe "request") correspondant à un deuxième exemple, dans lequel l'utilisateur cherche à constituer l'ensemble des équipements PC pour un certain type desystème d'exploitation à partir d'une base d'inventaire telle qu'ORACLE. Dans cet exemple, la requête généralisée a pour identifiant PC et le type de requête est une requête SQL, puisque faisant appel à la base ORACLE utilisant le langage SQL. Les attributs requête SQL et login sont documentés. En revanche, les attributs "requêtes CMIS" (requestCmis) ou "requêtes script" (requestScript) ne sont pas documentés. Il y a deux liens de nommage permettant, grâce au pavé (nameBinding) (33101) d'indiquer le lien avec les objets d'entrée et de sortie. Pour cet exemple d'utilisation, représenté figure 4E, I'objet d'entrée représentant le paramètre de la requête précise dans le champ "valeur par défaut" (requestParameterDefault) le système d'exploitation WINDOWS 3.11 et dans le champ "nom de variable" (requestVariableName) la valeur "OS". Cette requête permet d'obtenir la liste des équipements PCs pour le système d'exploitation fournit comme

paramètre d'entrée de la requête à partir de la variable dont le nom est "OS".

Comme on peut le comprendre, entre les figures 4A à 4F, la modélisation, sous forme d'objets MIB, des requêtes et des paramètres ainsi que la possibilité d'éditer ces objets à partir de fenêtres, permet à l'utilsiateur de

reconfigurer simplement les requêtes ou d'en créer de nouvelles.

La figure 4F représente la fenêtre permettant de modéliser sous forme 4F d'objets (MIB) I'ensemble qui exploite la requête décrite plus haut donnant l'ensemble des équipements UNIX d'un certain type et d'une

certaine version.

La fenêtre (3200) de la figure 4F comporte un premier champ (3201) qui permet de stocker la valeur de l'opérateur (attribut SetOperator), l'attribut dans l'exemple étant l'union; un deuxième champ (3202) qui permet de donner la référence à une requête généralisée (attribut setRequestPointer); un troisième champ (3203) qui permet de donner une liste de paramètres (attribut setParameter); un quatrième champ (3204) qui donne l'heure du demrnier rafraîchissement (setRefreshTime); un cinquième champ (3205) permet de fixer la période du rafraîchissement automatique (SetRefreshPeriod); un sixième champ (3206) qui permet de fixer le statut du rafraîchissement (setRefreshStatus), en l'occurrence en cours (pending); un septième champ (3207) qui permet de fixer l'attribut d'identification de l'ensemble (SetNodeld) et un huitième champ (3208) qui permet de fixer la classe de l'objet (objectClass), en l'occurrence objet de type "ensemble" (Set). Une deuxième utilisation du serveur de requêtes selon l'invention et des interfaces associées est représentée par les figures 5A à 5D. Cet exemple d'utilisation concemrne le contrôle de cohérence qui est une opération consistant à vérifier la conformité des équipements à des configurations de référence décrits par des objets. Une configuration de référence est constituée d'un ensemble de variables et d'expressions logiques sur ces variables qui sont autant d'indicateurs permettant de vérifier la cohérence d'un équipement. Ces indicateurs sont calculés à partir de différentes sources de données qui sont adressées par le serveur de requêtes. Le contrôle de cohérence s'effectue équipement par équipement et le premier paramètre de la requête est le nom de l'équipement. Le premier champ (3313) est le nom de la requête généralisée " TMP ". Le deuxième champ (3314) définit le type de requêtes, en l'occurrence une requête de type CMIS, les autres champs n'étant pas documentés. Le sixième champ (3318) définit la requête CMIS, le septième champ (3319), les commentaires et un champ de lien de nommage (33101) "Name Binding" est documenté

avec l'information "requêtes" (requests).

Comme représenté à la figure 5B, à cet objet "requête généralisé" est associé un objet d'entrée qui définit un seul paramètre en entrée qui correspond à l'identifiant de l'équipement. A ces deux objets, est associé un objet de sortie, représenté à la figure 5C, qui admet un seul paramètre en sortie, en l'occurrence la variable "taille" (size) qui donne la taille du système de fichiers TMP. Cette taille est évaluée en kilo-octets. Enfin, un demrnier objet, représenté par la fenêtre de la figure 5D, permet de définir dans un champ (51), la valeur de référence de la variable (SetRcVarValuelnt), en l'occurrence 10000 kilo octets.; dans un champ (52), I'expression logique (uctRcVarOperationlnt) à laquelle va être combinée la variable; dans un champ (50), la variable combinée (uctRefConfigVarld) dans l'expression I logique définie par l'objet de la classe définie dans le dernier champ "UCT Ref Config Variant". Cet indicateur, défini par l'objet de la figure 5D, permet de détecter les équipements, dont l'espace disponible pour le système de

fichiers TMP est inférieur à 10000 kilo octets.

Ainsi, I'on comprend l'intérêt de l'invention qui permet, grâce au serveur de requêtes généralisées, associées à l'interface représentative d'objets (MIB) permettant de définir les requêtes sous forme d'au moins 3 objets, de définir une nouvelle requête, ou la modification des paramètres d'exécution de sortie d'une requête par des fonctions de création, suppression ou simplement, mise à jour des objets qui modélisent le concept

de requêtes généralisées.

D'autres modifications à la portée de l'homme de métier font

également partie de l'esprit de l'invention.

17 2776789

Claims (17)

REVENDICATIONS

1. Serveur de requêtes généralisées (SR) caractérisé en ce qu'il comporte des moyens pour interroger, au travers de requêtes, différentes sources de données (SD) à partir d'une interface unique paramétrable pouvant être activée par des applications et des modules d'administration,

une requête étant modélisée dans une base de gestion d'informations (MIB).

2. Serveur de requêtes généralisées selon la revendication 1, caractérisé en ce qu'une requête est modélisée sous forme d'un objet principal (OP) comportant le type de la source à interroger et au moins un attribut propre à ce type, et d'objets subordonnés d'entrée (OE) et de sortie (OS), lesdits objets d'entrée (OE) modélisant les paramètres d'entrée de la requête (PE), lesdits objets de sortie (OS) modélisant les variables-résultats (VR).

3. Serveur de contrôle de cohérence, utilisant le serveur de requêtes généralisées selon la revendication 1, caractérisé en ce qu'il comporte en outre un objet indicateur permettant de définir, pour les variables-résultats d'une requête généralisée, une expression logique constituant un indicateur

pour le contrôle de cohérence.

4. Serveur d'ensembles utilisant le serveur de requêtes généralisées selon la revendication 1, caractérisé en ce qu'il comporte en outre un objet de définition d'un ensemble qui exploite une requête générée par le serveur de requêtes généralisées (SR) et qui comporte la définition d'un paramètre constituant un opérateur ensembliste dans le cas o l'ensemble est constitué

à partir de la combinaison de sous-ensembles.

5. Serveur d'ensembles (SE) selon la revendication 4, caractérisé en ce qu'il permet de constituer des domaines contenant des listes

d'équipements (301, 302).

6. Serveur d'ensembles (SE) selon la revendication 5, caractérisé en ce qu'il est stocke des listes d'équipements (301, 302), ledit serveur d'ensembles (SE) étant modélisé sous forme d'objets d'une base de gestion

18 2776789

d'informations (MIB), les objets (MIB) pointant une référence aux objets principaux (OP) du serveur de requêtes et comportant des attributs propres

aux ensembles.

7. Serveur d'ensembles selon la revendication 6, caractérisé en ce que le serveur d'ensembles (SE) comporte des fonctions ensemblistes et de rafraîchissement.

8. Serveur de requêtes généralisées selon la revendication 1, caractérisé en ce qu'il est un gestionnaire d'objets, interrogé par un service commun de gestion d'informations (CMIS), lesdites requêtes étant exécutées à l'aide d'une opération M-ACTION permettant le lancement d'une procédure.

9. Serveur de contrôle de cohérence, selon les revendications 3,

caractérisé en ce qu'il permet d'exécuter une action de configuration sur une

liste d'équipements (301, 302) définie dans un domaine.

10. Serveur de requêtes généralisées selon la revendication 1, caractérisé en ce que le paramètre (PE) contenu dans ledit objet d'entrée (OE) comporte un identifiant, le nom d'une variable qui va être passée à la

requête, la syntaxe de ladite variable et une valeur par défaut du paramètre.

11. Serveur de requêtes généralisées selon la revendication 1, 2caractérisé en ce que la variable-résultat (VR) définie dans l'objet de sortie (OS) comporte un identifiant, le nom d'une variable, le type de ladite variable

et des commentaires.

12. Serveur d'ensembles selon la revendication 4, caractérisé en ce que le serveur de requêtes CMIS comporte une interface présentant au moins une fenêtre de dialogue proposant différentes modalités de constitution et/ou de modification d'une liste d'équipements (301), des fonctions ensemblistes, une fonction de rafraîchissement des listes d'équipements pouvant interroger périodiquement des sources de données

(SD), par l'intermédiaire du serveur de requêtes généralisées.

13. Serveur d'ensembles selon la revendication 12, caractérisé en ce que une liste d'équipements est constituée en tapant manuellement sur le

clavier d'un ordinateur, la référence de chaque équipement.

14. Serveur de requêtes généralisées, selon les revendications 10 à

11, caractérisé en ce que la création d'une nouvelle requête permet de constituer une liste d'équipements (301), ladite création étant réalisée en

définissant les objets d'entrée (OE) et de sortie (OS).

15. Serveur d'ensembles selon les revendications 12 à 14,

caractérisé en ce que une liste d'équipements (301) est constituée par la

1o sélection d'une requête dans une liste de requêtes existantes.

16. Serveur d'ensembles, selon les revendications 12 à 15,

caractérisé en ce qu'une liste d'équipements (301) est constituée par la

combinaison de listes existantes.

17. Serveur d'ensembles selon les revendications 12 à 16,

caractérisé en ce que une liste d'équipements (301) est constituée en sélectionnant au moins un équipement et/ou une liste d'équipements modélisés sous forme d'objet MIB sur une carte du moniteur ISM et en

utilisant les fonctions traîner et jeter (drap and drop) du moniteur ISM.