FR2785410A1

FR2785410A1 - Procede d'optimisation des acces a l'ensemble des instances d'objets d'une meme classe dans une base de donnees d'administration

Info

Publication number: FR2785410A1
Application number: FR9813646A
Authority: FR
Inventors: Jean Luc Richard
Original assignee: Bull SAS
Current assignee: Bull SAS
Priority date: 1998-10-30
Filing date: 1998-10-30
Publication date: 2000-05-05
Anticipated expiration: 2018-10-30
Also published as: EP1044535A1; WO2000027073A1; FR2785410B1

Abstract

Procédé d'optimisation des accès à l'ensemble de toutes les instances d'objets administrés d'une même classe donnée, existantes dans une base d'information de gestion (MIB : Management information base) hiérarchisée sous forme d'arbre d'instances d'objets de classes diverses, comprenant une étape de création automatique par un gestionnaire (CMIS-DB) de la base locale d'information de gestion (MIB), d'une instance d'objet de classe spécifique " mocExtension " prédéfinie pour représenter l'ensemble de toutes les instances d'une classe d'objets administrés (MOC : Managed Object Classes) existantes dans gestionnaire d'objet CMIS-DB, pour permettre au gestionnaire d'objet (CMIS DB) de maintenir alors automatiquement une copie virtuelle de toutes les instances d'objets de la classe MOC représentée par cette instance de classe spécifique " mocExtension ".

Description

Procédé d'optimisation des accès à l'ensemble des instances d'objets d'une même classe dans une base de données d'administration.

La présente invention concerne un procédé d'optimisation de l'accès à l'ensemble des instances d'objets administrés d'une même classe donnée, dans une base de données d'administration (MIB) stockée sur un disque.

Les services d'accès aux informations d'une MIB repose sur le standard CMIS (Common Management Information Service, recommandation IUT-T X. 710) connu, qui décrit les opérations que l'on peut effectuer sur les objets spécifiés suivant le modèle du standard GDMO (Guidelines for the Définition of Managed Objects, ou Directives pour la définition des objets administrés, recommandation ITU-T X.722). La présente invention utilise le service de gestion d'informations du standard CMIS. Les applications d'administration font appel soit à des agents (43a, 43b et 43c) qui sont des processus installés sur des machines distantes reliées par un réseau (30) avec une machine supportant l'application (4) d'administration, soit à des services locaux d'un système d'administration appelé ultérieurement entité manager qui permettent de gérer localement une base de gestion d'information d'administration MIB (Management Information Base) hiérarchisée sous forme d'arbre d'instances d'objets, sans accès réseau. Dans ces bases de gestion d'informations d'administration (MIB), toutes les ressources sont représentées sous la forme d'objets dans un arbre d'objets tel que représenté en figure 2.

Les objets sont eux-mêmes regroupés en classes. L'objet d'une classe donnée comporte un certain nombre d'attributs et chaque instance d'objet a un nom (N). L'adressage se fait par nom distinctif DN (Distinguished Name), par exemple, le DN de l'objet (51, figure 2) est "alblb".

La figure 4 représente le fonctionnement d'un service de gestion d'informations. Ce service utilise une architecture à deux niveaux. Le premier

niveau est constitué d'une entité manager (4) jouant un rôle d'administrateur qui doit visualiser et contrôler des ressources, consulter des caractéristiques, etc, ..... Le second niveau est constitué d'entités agent (43a à 43c) installés sur des machines distantes ou locales, Ces agents maintiennent les objets sur lesquels doivent s'appliquer les opérations émises par le niveau administrateur. Le but de l'agent est d'entretenir un modèle de la ressource qu'il gère, modèle consigné et normalisé dans une MIB. Au moins, un agent est donc installé sur chaque machine du réseau et peut contrôler un ensemble de ressources locales ou distantes sous la direction d'un ou de plusieurs administrateurs. Un administrateur communique avec chaque agent en utilisant un protocole de gestion standard. Le système d'administration OpenMasterTM commercialisé par la société BULL comprend un ou plusieurs administrateurs ISM-Manager (Integrated System Management) et plusieurs agents (45a à 45c) (ISM/Agent). De plus, d'autres agents commercialisés par d'autres sociétés peuvent être contrôlés par l'administrateur OpenMasterTM via des protocoles standards.

Le mécanisme administrateur-agent est basé sur un modèle objet, dans lequel la modélisation d'une ressource constituée, par exemple, d'éléments du système, de logiciels, d'états, d'utilisateurs, etc., s'appuie sur une approche et une structuration en objets des informations de management. Les équipements "réels" d'un système en réseau (un ordinateur, une imprimante, un circuit, etc. ) sont représentés par des objets abstraits organisés dans une base d'information d'administration (MIB, Management Information Base). Les caractéristiques de ces objets (nom d'un ordinateur, caractéristiques des équipements périphériques, les statuts de ces équipements tels qu'une imprimante, etc. ) sont appelés les attributs des objets.

Les objets sont divisés en classes d'objets administrés plus souvent appelés MOCs (Managed Object Classes), où chaque MOC représente un type de ressources. Les MOCs définissent les informations que la MIB va

contenir pour chaque type de ressources, c'est-à-dire quels attributs l'objet va avoir. Les MOCs peuvent être interprétées comme une partie du "schéma" de la MIB. Chaque MOC est instanciée en plusieurs instances d'objets administrés (MOIs, Managed Object Instances) représentant les occurrences réelles de ce type de ressources.

Prenons l'exemple de trois imprimantes (Imprim1, Imprim2, Imprim3) représentées par trois instances d'objets (P1, P2, P3) dans une base d'information d'administration (MIB), Les attributs de l'objet représentant l'imprimante sont "état de l'imprimante" et "utilisateur". Une classe d'objets MOC "imprimante" (printers) peut donc être définie ayant pour attributs "état de l'imprimante" et "utilisateur actuel". Les instances d'objets (MOIs) de la classe "imprimante" peuvent être les suivantes :

<tb> MOI <SEP> MOC <SEP> ATTRIBUTS
<tb>
<tb>
<tb> (instance) <SEP> Classe <SEP> état <SEP> de <SEP> l'imprimante <SEP> utilisateur
<tb>
<tb>
<tb> Imprim <SEP> 1 <SEP> Printer <SEP> activée <SEP> aucun
<tb>
<tb>
<tb> Imprim <SEP> 2 <SEP> Printer <SEP> désactivée <SEP> aucun
<tb>
<tb>
<tb> Imprim <SEP> 3 <SEP> Printer <SEP> activée <SEP> Joe
<tb>

L'état (status) de la ressource Imprimante 1 est activée et sans utilisateur actuel dans l'instanciation de l'exemple ci-dessus. Cet exemple comporte encore les instances Imprim 2 et Imprim 3. Une application telle que "ISM-Monitor" fournit par le système d'administration OpenMasterTM (4) permet d'afficher les MOIs et leurs états. De même, ISM-Monitor peut afficher sous forme de tableau les attributs de n'importe quelle MOI : par exemple les attributs "état de l'imprimante" et "utilisateur" pour une MOI quelconque de la MOC "Printers".

L'ensemble des objets administrés forme une base d'information d'administration (MIB).

On appelle "MIBIet" un sous arbre directement attaché à la racine de l'arbre distinct d'une base de gestion d'information (MIB). Malgré la division en MIBlets, la base d'information d'administration (MIB) du système d'administration OpenMasterTM est reconnue comme une entité composite unique, avec tous les MIBlets attachés à la même MIB. On appelle "Rootlet" un objet MOI à la racine d'un sous-arbre MIBIet. L'administrateur OpenMasterTM voit le système distribué à travers les objets de la MIB et le contrôle du système se fait par des manipulations des objets de la MIB et de leurs attributs. Les objets sont visibles grâce aux agents ou au gestionnaire d'objets attachés à l'administrateur OpenMasterTM qui cartographient (mapping) les équipements en MIB sous forme d'arbre d'objets. Un agent peut représenter l'état d'un équipement par la voie d'un objet associé correspondant représenté dans la MIB. Cette cartographie peut associer un objet avec plusieurs équipements "réels", de même qu'un équipement peut être modélisé sous la forme de plusieurs objets. L'administrateur OpenMasterTM envoie des commandes aux agents (43a à 43c) et les agents envoient des réponses à ses commandes et notifient des événements à l'administrateur OpenMasterTM (4) à travers des agents intégrateurs (45) en utilisant un protocole tel que SNMP (Simple Network Management Protocol, 45a), CMIP (Common Management Information Protocol, 45b), ou autres tels que DSAC/AEP (Distributed systems Administration and Control / Administrative Exchange Protocol, 45c). Chaque protocole d'administration fournit un certain nombre d'opérations simples, par exemple le protocole CMIP fournit toutes les fonctions du standard CMIS à savoir les suivantes : - l'administrateur (41) peut lire les attributs d'un objet MIB par l'opération M-GET. L'agent (43) répond à une requête M-GET en donnant des informations sur l'équipement.

- l'administrateur (41) peut modifier les attributs d'un objet MIB (l'opération M-SET). L'agent modifie l'équipement "réel" en fonction des nouvelles valeurs d'attributs fournies par l'administrateur;

- l'administrateur (41) peut exécuter une action sur un objet MIB par l'opération M-ACTION. L'agent (43) exécute une action sur l'équipement en fonction de l'action demandée par l'administrateur sur l'objet abstrait ; - l'administrateur (41) peut créer et supprimer des objets de la MIB par les opérations M-CREATE et M-DELETE; - l'agent (43) peut notifier un événement survenant sur un objet de la MIB à l'administrateur par l'opération M-EVENT. L'agent envoie des informations d'un événement concernant un objet abstrait pour décrire un événement survenu sur un équipement "réel".

Une base d'information d'administration (MIB) a une hiérarchie d'arborescence stricte, c'est-à-dire que chaque instance d'objet (MOI) a exactement une et une seule MOI supérieure. L'arbre formé par la base d'information d'administration MIB est appelé "arbre de contenance" (containment tree). Les instances d'objets administrés (MOIS) sont nommées par leur position dans l'arbre de contenance de la façon suivante:
Chaque MOI possède un nom distinctif relatif (relative distinguished name, RDN) qui différencie les MOIs ayant un même et unique MOI supérieur (père). Un des attributs de chaque classe d'objets administrés (MOC) est choisi pour spécifier le RDN de l'instance pour un MOI supérieur donné. Cet attribut appelé l'attribut de nommage (naming attribute) est identifié dans les formulaires (templates) GDMO appelés liens de nommage (name binding). Une MOC peut avoir plusieurs liens de nommage supérieurs potentiels, mais chaque MOI utilisera uniquement l'un d'entre eux. Chaque MOI a également un nom distinctif complet (Full Distinguished Name) unique pour la totalité de la MIB. Le nom distinctif global (DN) d'un objet consiste en son nom distinctif relatif (RDN) joint au nom distinctif (DN) de son supérieur c'est-à-dire que le nom distinctif (DN) d'une instance d'objets administrés (MOI) contient son propre nom distinctif relatif (RDN) plus les noms distinctifs relatifs (RDNs) de tous ses supérieurs dans l'arbre de contenance jusqu'à la racine.

Un des administrateurs d'objet local à l'administrateur ISM-Manager s'appelle CMIS-DB. Il est chargé de stocker une partie de la MIB locale. La rémanence de ces objets stockés est assurée par des fichiers ISAM (Index Sequential Access Method). Cette technologie (ISAM) qui décrit les structures d'articles (records) est une méthode d'accès aux fichiers structurés sous forme d'articles découpés sur un ou plusieurs index et des informations de donnée.

Lorsque l'application de l'administrateur veut sélectionner un des objets pour poser une opération CMIS comme par exemple un M-GET, il doit spécifier l'instance d'objet de base (BOI, Base Object Instance), la portée (scope) et le "filtre" comme argument de l'opération .

L'instance d'objet de base BOI permet d'identifier un objet dans une base d'information d'administration (MIB) qui est le point de départ d'une évaluation du couple portée-filtre dans l'arbre d'objets. La portée (scope) sélectionne une portion de l'arbre depuis cet objet de base. Par exemple, la portée (scope) tous les sous arbres ( Whole subtree ) permet de sélectionner tous les sous arbres d'un objet donné. Parmi tous les objets de la portée (scope), les objets sélectionnés sont ceux pour lesquels l'évaluation du filtre est vraie. L'opération est effectuée sur les objets réellement sélectionnés. L'administrateur envoie un M-GET sur des objets et CMIS-DB lit et retourne à l'application la valeur des attributs des objets sélectionnés.

Pour atteindre une instance d'objet de base (BOI), l'administrateur local CMIS-DB doit passer d'objet père en objet fils jusqu'à atteindre le noeud de l'objet de base. Cette opération de navigation peut être longue, si pour passer d'un noeud à l'autre, il faut lire physiquement l'ensemble des fils d'un noeud et parmi ceux-là choisir celui qui a le bon RDN, et ainsi de suite.

Une fois, que l'ordinateur a atteint l'instance de base objet, il doit lire les attributs des objets de la base qui correspondent à la portée (scope) pour

pouvoir évaluer le filtre en mémoire, alors que la lecture des instances se fait sur le disque de la machine.

Un but de la présente invention est de proposer un procédé d'optimisation des lectures dans une base d'information d'administration (MIB) organisée en arbres d'instances d'objets de classes diverses, de l'ensemble des instances d'une classe donnée existantes dans cette MIB.

De plus le procédé selon l'invention fourni par le processus CMIS- DB de l'entité ISM-Manager permet d'appliquer une sélection par les arguments portée/filtre (scope/filter) des opérations standard du service CMIS pour offrir l'avantage de sélectionner ces objets de classe donnée à travers une seule opération. Sans cette invention la seule portée (scope) CMIS qui pourrait atteindre en une seule opération CMIS ces instances d'objets, est une portée (scope) de type (whole-subtree) tout le sous- arbre à partir de la racine de la MIB globale, hors celle-ci contient également des sous-arbres qui n'appartiennent pas à l'administrateur local CMIS-DB. L'autre alternative est de soumettre autant d'opérations CMIS qu'il y a d'objet MOI racine de sous-arbres (rootlet) stockés dans l'administrateur local CMIS-DB avec une portée (scope) de type tout le sous-arbre (whole- subtree) et une baseObjectlnstance égale à chacune de ces rootlets.

L'idée de l'invention est de représenter l'ensemble des instances, d'une classe donnée d'objets administrés MOC, existante dans le service commun de gestion d'informations (CMIS-DB) par un objet de classe spécifique appelée mocExtension géré automatiquement par le service commun de gestion d'informations CMIS-DB pour être la racine d'une copie virtuelle de toutes les instances de la même classe. On peut soumettre alors une opération CMIS avec une portée (scope) de niveau 1 sous l'instance qui représente la classe recherchée, sur l'objet de classe spécifique mocExtension .

Un autre avantage de cette invention est de pouvoir utiliser les index physiques qui ont été éventuellement configuré par l'utilisateur comme décrit

ci-après, pour diminuer le coût temporel de l'évaluation de l'argument CMIS filtre, lorsqu'il doit être appliqué à l'ensemble de toutes les instances d'une classe donnée. En effet, si les index sont configurés sur des attributs identifiés dans le filtre on peut les utiliser pour ne lire physiquement qu'un sous-ensemble des instances comme décrit ci-après. Il suffit simplement de reconfigurer en ligne (on-line) les index pour ne plus utiliser la partie de la clé qui mémorise la position de l'instance dans l'arbre de contenance.

Ces buts sont atteints par le fait que le service CMIS-DB définit et réalise une classe spécifique d'objet administré (MOC) appelée mocExtension . Une instance d'objet de cette classe spécifique mocExtension est automatiquement créée par CMIS-DB pour chaque classe d'objet administré que l'utilisateur déclare au service CMIS-DB. Cette déclaration permet à l'utilisateur de spécialiser par configuration, comme décrit ci-après, la structure de stockage sur disque des instances d'objet d'une classe donnée qui sinon reste générique. La représentation générique n'indexe physiquement que l'attribut obligatoire objectClass dans les fichiers ISAM de stockage de la MIB sur le disque. Alors que la spécialisation du stockage d'une MOC permet à l'utilisateur de déclarer un certain nombre de l'ensemble des attributs spécifiques de cette MOC, comme devant être indexés dans les fichiers ISAM de stockage sur le disque. La structure de ces index comporte la référence de l'objet père dans l'arbre de contenance (containement tree), mais CMIS-DB permet de ne pas inclure cette référence dans la clé de lecture physique indexée dans le cas précis où la sélection des objets sur lesquels doivent être appliquées les opérations CMIS se fait par une portée (scope) de premier niveau directement sous une instance de classe spécifique mocExtension et un filtre dont l'expression est telle que la valeur d'un ou de plusieurs attributs indexés de la MOC puisse être donnée comme clé de lecture indexée. De plus, lorsque la spécialisation du stockage d'une MOC est demandée par l'utilisateur, (par la création d'un objet de classe mocStorageConfig, voir demande de brevet N 9809825

intitulée Procédé pour l'optimisation des accès à une base de données"), CMIS-DB crée un nouveau fichier ISAM destiné à contenir toutes les instances de cette MOC et uniquement celle-ci. En conséquence, lorsque l'utilisateur veut sélectionner tout ou partie des instances de cette MOC en utilisant un argument baseObjectlnstance BOI égal à l'instance de classe spécifique mocExtension qui représente cette MOC, CMIS-DB n'accède qu'aux éléments de ce fichier et évite ainsi de visiter des noeuds de l'arbre de contenance (contaiment tree) qui ne sont pas des instances de cette MOC et qui sont par construction dans des fichiers ISAM différents.

1. L'invention a pour objet un p Procédé d'optimisation des accès à l'ensemble des instances d'objets administrés d'une même classe donnée, existantes dans une base d'information de gestion (MIB) hiérarchisée sous forme d'arbre d'instances d'objets de classes diverses, caractérisé en ce qu'il comprend une étape de création automatique, par un gestionnaire (CMIS-DB) d'objet de la base d'information de gestion (MIB), d'une instance d'objet de classe spécifique "mocExtension" prédéfinie pour représenter l'ensemble des instances d'une classe d'objets administrés (MOC) existantes dans le gestionnaire, pour permettre au gestionnaire de maintenir automatiquement une copie virtuelle de toutes les instances d'objets de la classe (MOC) représentée par l'instance de classe spécifique "mocExtension".

Selon une autre particularité, le procédé comporte une étape de consultation d'une collection de tous les objets d'une même classe donnée référencée par l'instance de classe spécifique mocExtension automatiquement créée par CMIS-DB pour contenir virtuellement les éléments de cette collection, par l'intermédiaire d'une requête d'obtention (M-GET) du service commun de gestion d'information comportant les arguments suivants : objet de base, portée et filtre dans lesquels l'objet de base est l'instance de la classe spécifique mocExtension identifiée par l'identifieur d'objet OBJECT IDENTIFIER de la classe recherchée, la portée

(scope) est la portée de premier niveau subordonné, et le filtre est de structure déterminée.

Selon une autre particularité, le procédé comporte une étape de détermination du type de nommage à utiliser dans les réponses aux consultations par des requêtes portées (scoped) sous cette instance de classe spécifique mocExtension par la mise à jour d'un attribut de fixation de nommage (typeOfReplyNaming) indiquant au service de gestion quel est le type de nommage à utiliser.

Selon une autre particularité, le procédé comporte une étape de renvoi des réponses aux requêtes par le service commun de gestion d'information (CMIS-DB) en fonction de l'attribut fixant le type de nommage à utiliser pour identifier les copies virtuelles d'instance d'objet subordonnées à l'instance d'objet de classe spécifique mocExtension .

Selon une autre particularité, lorsque l'objet de base (baseObject) est de classe spécifique mocExtension , le paramètre portée (scope) est détecté par ledit service commun de gestion d'objets (CMIS-DB) de la MIB qui évalue cet argument de portée (scope) comme un parcours des objets appartenant à la collection de toutes les instances d'objet de la classe représentée par l'objet de base (baseObject) de classe spécifique mocExtension .

Selon une autre particularité, l'étape de renvoi des réponses transmet le nom distinct complet (FDN : Full Distinguished Name) de l'objet réel référencé dans l'argument instance d'objets managés (MOI) de chaque réponse si le type de nommage choisi est d'un premier type (natureIFDN); ou le FDN de la copie virtuelle si le type de nommage est d'un second type (spécificFDN) ou encore un adressage direct au stockage physique dans le cas où le type de nommage est d'un troisième type (nonSpecificForm).

Selon une autre particularité, le nom distinctif d'une instance d'objet administrés contient son propre nom distinctif relatif plus les noms distinctifs relatifs de tous ses supérieures dans l'arbre de contenance jusqu'à la racine.

Selon une autre particularité, le procédé comporte une étape de préfixation de la valeur de l'attribut à indexer par l'adresse physique "fatherMOInodRef' d'un père de l'objet dans l'arbre de contenance (containment tree) et d'indexer le tout.

Selon une autre particularité, le procédé est mis en oeuvre par l'administrateur CMIS-DB pour offrir la possibilité de désactiver la présence de "fatherMOInodRef' dans les index des attributs, lorsque la recherche optimisée se fait sous les objets mocExtension introduits précédemment.

Un autre but de l'invention est de proposer un dispositif pour délivrer un gestionnaire d'objet (CMIS-DB) pour une base d'information d'administration (MIB) sur un serveur mettant en oeuvre le procédé selon l'invention.

Ce but est atteint par le fait que le dispositif comporte une classe d'objet managé (MOC) de classe spécifique mocExtension qui optimise le parcours de la collection contenant toutes les instances de la même classe donnée, créées et encore existantes dans la MIB gérée par le gestionnaire d'objet (CMIS-DB) indépendamment de leur position dans l'arbre et sans avoir à accéder physiquement sur le disque a une quelconque des autres instances d'objet qui ne soient pas de la classe recherchée..

Selon une autre particularité, lorsque l'objet de base (baseObject) est de la classe spécifique mocExtension , le paramètre portée (scope) est détecté par ledit service commun de gestion d'informations (CMIS) qui évalue cet argument de portée (scope) comme un parcours de l'ensemble des objets de la classe identifiée par cette instance d'objet de classe spécifique mocExtension .

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 un exemple de base d'information (MIB) dans laquelle deux classes ont été déclarées par l'utilisateur pour être optimisée et donc dans laquelle deux instances de classe spécifique mocExtension ont été automatiquement créée par le gestionnaire d'objet CMIS-DB, - la figure 2 représente un arbre d'objets constituant une MIB, - la figure 3 représente l'architecture du process CMIS-DB, - la figure 4 représente l'architecture du manager OpenMasterTM dont un des composants est CMIS-DB, - la figure 5 représente un schéma présentant les différentes fonctions de translation et de comparaison entre différentes alternatives de nommage des objets appartenant aux ensembles identifiés par les objets de classe spécifique mocExtension, - la figure 6 représente une fenêtre d'affichage d'une instance d'objet de classe spécifique mocExtension générée par une interface graphique utilisateur faisant partie de l'application ISM-Monitor.

- la figure 7 représente la spécialisation des stockages pour les MOC optimisées
La présente invention permet à l'utilisateur d'optimiser les accès à l'ensemble des instances d'objets administrés d'une même classe donnée, et existantes dans la MIB entre des instances de l'objet managé (MOI) appartenant à la même instance de serveur de gestion d'objet de la MIB gérée par le serveur CMIS-DB.

La figure 1 représente un exemple d'une base d'information d'administration (MIB) stockée dans un gestionnaire d'objet(CMIS-DB).

Dans cette arborescence de la figure 1, les classes X représentées par des carrés aux angles arrondis (11a à 11d) et appartenant à un premier arbre (11) sont définies par l'utilisateur et représentées par le noeud

générique. Un autre arbre (17) comporte également des classes Y et Z appartenant également au premier arbre (11). A ces classes, l'utilisateur peut ajouter des classes d'objets représentées par un noeud spécifique indexé par les attributs choisis et ce type de classe est représentée par des rectangles à angles aigus (17,18). Lorsqu'on veut effectuer une recherche sur deux arbres (11,12) ayant chacun deux racines différentes d'arbres de contenance, l'administrateur CMIS-DB pourra utiliser la classe de collection Le type de classe spécifique d'extension d'objet (14.1,) mocExtension est prédéfini par l'administrateur CMIS-DB et permet de représenter l'ensemble (18a à 18g) des objets de la classe Y définie dans l'attribut de nommage "moclD" de la classe spécifique d'extension d'objets (14.1) mocExtension .

Une instance de classe déterminée mocExtension est automatiquement créée par le gestionnaire d'objet(CMIS-DB) pour chacune des classes spécialisées d'objets managés (MOC). C'est une extension du principe de collection décrit dans la demande de brevet français N 9808294 intitulée Procédé de référencement dans une MIB d'un ensemble d'instance d'objet à partir d'une autre instance d'objet n'appartenant pas à un même sous-arbre. . Cette collection est représentée par un objet de la MIB, et le principe est appliqué ici à l'ensemble des instances d'une classe donnée, ces instances étant présentes dans un serveur CMIS-DB. Toutes les instances de mocExtension sont subordonnées à l'instance de classe ODS créée sous la racine (root) par chaque instance de CMIS-DB. Le nom distingué (DN) de l'instance de ODS est hostname :OMname hostname est celui du système hôte et OMname est le nom de l'instance du gestionnaire d'objet CMIS-DB.

Les seules opérations autorisées sur les objets de classe spécifique mocExtension sont : - les opérations M-GET, - les opérations M-SET sur les attributs.

La définition GDMO de la classe spécifique mocExtension est : mocExtension MANAGED OBJECT CLASS
DERIVED FROM "Rec. X.721 I ISO/IEC 10165-2 : 1992":top;
CHARACTERIZED BY mocExtensionPkg PACKAGE
BEHAVIOUR mocExtensionBehaviour ;
ATTRIBUTES moclD GET, typeOfReplyNaming GET-REPLACE ,
REGISTEREDAS {ODS-ASN1Module.ods-objectClass11} ;
La classe d'objet spécifique mocExtension est une classe prédéfinie par le gestionnaire d'objet(CMIS-DB) pour représenter l'ensemble des instances optimisées de chacune des classes d'objets administrés (MOC) de l'utilisateur. Elle dérive de la classe "top" et a comme attributs : - un attribut de nommage "moclD" égal à l'OBJECT IDENTIFIER de la classe d'objets managés (MOC) représentée par cette instance de la classe spécifique mocExtension . Dans l'exemple de la figure 1, l'attribut de nommage de la classe d'objet managé (MOC) (11) se nomme Y (moclD=Y). Comme le montre les traits (20) sur la figure 1, elle rassemble tous les objets de la classe Y.

- un attribut "typeOfReplyNaming" de type ENUMERATED {naturaIFDN(0), specificFDN(1), nonspecificForm(2)} indiquant au gestionnaire d'objet (CMIS-DB) quel est le type de nommage à utiliser dans les réponses aux requêtes portées (scoped) sous cette instance de mocExtension . La valeur par défaut de cet attribut est configurable par option.

Ainsi, l'utilisateur a la possibilité de choisir le type de nommage utilisé dans les réponses du gestionnaire d'objet (CMIS-DB) pour identifier les instances d'objets managés (MOI) qui appartiennent aux collections de classe spécifique mocExtension ou en utilisant un attribut "typeOfReplyNaming" de type ENUMERATED {naturalFDN(O), specificFDN( 1 ), nonspecificForm(2)}.

Le premier type de nommage donne le nom distinct complet naturel naturalFDN (Full Distinguish Name) qui correspond au nom distinct

"DistinguishedName" choisi par l'utilisateur pour nommer l'objet réel créé, tel qu'il est créé dans l'arbre de contenance (containment tree).

Le deuxième type de nommage donne le nom distinct complet spécifique specificFDN qui correspond au nom distingué (DN, distinguishedName ) de la copie virtuelle de l'objet référencé, ce nom est calculé par le gestionnaire d'objet (CMIS-DB) à partir de la valeur du nom distinct complet naturel, natural FDN . Sa valeur est la concaténation du DN de l'objet de classe spécifique mocExtension représentant la collection et d'un RDN (Référence Du Noeud) fabriqué automatiquement par gestionnaire d'objet CMIS-DB pour nommer la copie virtuelle.

Le format nonSpecificForm est un nommage qui contient la référence interne au gestionnaire d'objet (CMIS-DB) de l'objet noeud de l'instance, c'est un pointeur direct sur l'objet de stockage de l'instance d'objets référencée.

Pour accéder à l'ensemble des instances d'une classe spécialisée indépendamment de leur position dans l'arbre de contenance, l'utilisateur soumet sa requête M-GET avec la définition de l'objet de base (baseObject), un scope et un filtre. Soit, par exemple, un M-GET avec les arguments suivants : base Object Class = mocExtension base object Instance : odsID=ODSname/mocID=la classe recherchée, par exemple Z scope = Premier niveau subordonné filtre = Quelconque.

Le gestionnaire d'objet (CMIS-DB) retourne alors une réponse multiple, avec suivant l'option indiquée par l'attribut "typeOfReplyNaming", le nom de l'instance d'objets (16a, 16b, 16c) (MOI) retournée dans chaque réponse CMIS égal au FDN de l'objet réel référencé dans la collection ou, le

FDN de la copie virtuelle tel que l'attribut de nommage moclD - LaClasseRecherchée/RDN choisi Par CMISDB, ou encore à la référence interne de l'instance d'objet permettant un adressage direct au stockage, sans utiliser la navigation dans l'arbre. Dans l'exemple de la figure 1, cela donnerait :
1. /a/a/c/b, correspondant au le nom distinct complet "naturaIFDN"
2. / ODSname/LaClasseRecherchée/1234 correspondant au nom distinct complet spécifique "spécifiqueFDN",
3.1234, correspondant à un exemple de numéro d'article dans le fichier ISAM et représentant le format "nonSpecifiqueForm".

Le gestionnaire d'objet (CMIS-DB) offre des actions de translation et de comparaison entre certaines de ces différentes alternatives de nommage.

Les translations autorisées sont spécifiées par la figure 5, où les flèches en traits pointillés indiquent que la translation nécessite un accès physique aux objets de stockage et les flèches en trait continu indiquent que la translation est un simple calcul et est donc plus rapide que dans le premier cas.

Remarquons que l'accès du naturalFDN au nonSpecificForm est indexé sur le FDN.

Toutes les opérations CMIS relatives à la MIB gérées par CMIS-DB sont acheminées entre l'application de gestion et CMIS-DB par l'infrastructure de communication ISM (CDSP). Ainsi, CMIS-DB est considéré par ses applications comme un administrateur d'objets (object manager) qui stocke et gère une partie de la MIB dans une base de donnée.

Le serveur CMIS-DB interagit avec le routeur CDSP (33) à travers une interface (32). Les interactions entre tous les composants de l'administrateur ISM sont réalisés à l'aide de messages CMIS acheminés par le routeur CDSP.

La figure 3 représente le gestionnaire d'objet CMIS-DB selon l'invention qui comprend un gestionnaire d'opérations CMIS (CMIS opérations handler) (31) dialoguant selon le protocole du (CDSP) (33) avec

l'infrastructure de communication, un module programmable d'extension utilisateur codé en SML (SML MIB toolkit) (34), un module (37) découpé en un sous module exécuteur de requête (MIB queries performer), un sous module de navigation, d'évaluation de portée, de filtre, et un sous module optimiseur par préfiltrage (372), un traducteur de forme globale en forme locale (38), un module d'import/export (39), une antémémoire de l'arbre de contenance d'objets (cache of containment tree) (40), une antémémoire des instances de gestion d'objet (cache of MOIs)(49), un module d'accès à la mémoire physique (50) qui interface le serveur de la base de donnée sous- jacente (51), un module administrateur de transactions d'accès physique (storage transaction manager) (48) et un disque physique (47).

Le kit de programme de développement (SML MIB toolkit) (34) charge les éventuelles extensions SML (Systems Management Language) (341) de l'utilisateur et fournit en SML les primitives d'accès à la base d'information d'administration (MIB) gérée par le gestionnaire d'objet CMIS- DB. En outre, le kit de développement de programme (SML MIB toolkit) (34) évalue les pré-conditions et les post-conditions posées par l'utilisateur, lors de chaque opération sur la base d'information d'administration (MIB) et exécute les extensions SML qui sont déclenchées sur ces conditions.

L'exécuteur des requêtes (37) sur la base d'information d'administration effectue réellement la requête ou l'opération sur la représentation logique de la base d'information d'administration (MIB). Il navigue en fonction de l'argument de l'instance d'objet de base (BOI, baseObjectlnstance) de la requête, pour obtenir l'instance initiale de l'évaluation de la portée (scope) et du filtre.

Le mode de fonctionnement de l'exécuteur des requêtes (37) de la base d'information d'administration (MIB query performer) dépend des arguments portée (scope) et filtre de l'opération. Lorsqu'aucun préfiltrage par les attributs indexés dans la base de données sous-jacente n'est utilisable, l'exécuteur des requêtes de la base d'information d'administration (MIB

query performer) (37) parcourt la liste de tous les fils pour lire les instances de gestion d'objets (MOI) correspondant à la portée (scope). La décision de savoir si un préfiltrage peut être exécuté ou non, dépend de l'analyse de la structure du filtre.

La recherche optimisée des MOI sélectionnés par un filtre consiste à ne pas lire physiquement toutes les MOIs appartenant à la portée (scope) CMIS pour leur appliquer l'évaluation du filtre mais à utiliser lorsque c'est possible, les index qui sont positionnés sur leur MOC dites optimisées, afin de ne lire qu'un sous-ensemble de ces instances MOIS. Cette dernière opération est appelée "présélection ou préfiltrage" elle ne remplace pas l'étape d'évaluation du filtre sur chaque MOI remontée en mémoire qui a lieu systématiquement dans les deux cas. Le préfiltrage par les index peut donc remonter des MOIs qui au final seront rejetées par l'étape d'évaluation du filtre CMIS, mais il ne doit pas oublier de lire une seule des MOIs de la portée qui vérifient le filtre.

Les filtres CMIS doivent obligatoirement se conformer à une structure définie pour être reconnus par l'optimiseur de recherche des MOIs que ces filtres sélectionnent.

Excepté la portée (scope) "base object only" qui n'est pas concernée par le mécanisme d'optimisation, le type de portée (scope) utilisé dans les requêtes n'a aucune influence sur les règles permettant de décider si une première sélection par les index est plus optimum qu'une lecture physique de toutes les MOIs appartenant au scope.

Un filtre CMIS reconnu par l'optimiseur doit être une expression logique qui sélectionne uniquement des MOIs de la même classe. Cette classe qui doit être une des MOC optimisées déclarées au module CMIS- DB.

d'une des MOC optimisées.

- une expression logique constituée uniquement de clauses ET (AND) englobant des items de comparaison sur les attributs déclarés dans les index de la MOC optimisée. Ces comparaisons sur les attributs indexés ne peuvent être que des égalités, sauf lorsqu'une des opérations greaterOrEqual, lessOrEqual ou initialString porte sur le dernier élément de l'index (ou de la partie initiale de l'index) sélectionné. Par exemple pour une MOC optimisée construite avec plusieurs index constitués avec les attributs (att.1; att.2 ; att. 3) l'expression logique pourra être la suivante : att. 1 = value1 & att. 2 = value2 & att. 3 = value3 - et éventuellement une autre expression logique qui porte sur les attributs qui ne sont pas déclarés dans les index de la MOC identifiée.

Plus formellement, la description des filtres CMIS reconnus par le préfiltrage est donnée par la grammaire suivante : optimumCMISFilter # and mocFilterltems indexFllterPart anyFilterltems mocFilterltems # equality <X.721:objectClass> <CMIP- 1.0bjectClass> indexFilterPart # indexFilterltem indexFilterEqualities indexFilterltem indexFilterEqualities # indexFilterEquality indexFilterEqualities indexFilterEquality # equality <anlndexedAttributeld> <AttributeValue>

indexFilterltem # indexFilterEquality indexFilterGreaterOrEqual indexFilterLessOrEqual indexFilterSubstringlnitial indexFilterGreaterOrEqual # greaterOrEqual <anlndexedAttribueld> <AttributeValue> indexFilterLessOrEqual # lessOrEqual <anlndexedAttribueld> <AttributeValue> indexFilterSubstringlnitial # substrings initialString <anlndexedAttribueld> <AttributeValue> anyFilterltems # <CMIP-1.CMISFilter>
Dans cette grammaire, l'ordre introduit entre les différents items ne reflète pas un ordre syntaxique dans l'expression du filtre CMIS qui peut être quelconque, mais plutôt l'ordre physique des attributs tels qu'ils existent dans les index de la MOC optimisée.

Lorsqu'un préfiltrage est utilisable, l'exécuteur des requêtes (37) de la base d'informations d'administration (MIB query performer) lit dans la base sous-jacente les seuls subordonnés qui sont indexés par les valeurs des attributs sélectionnés pour le préfiltrage. Puis l'exécuteur des requêtes (37) de la base d'informations d'administration (MIB query performer) évalue le filtre sur chaque instance précédemment sélectionnée. Si l'évaluation est positive, il exécute l'opération sur la représentation logique de la base d'informations d'administration (MIB) et retourne la réponse individuelle au gestionnaire dudit service commun de gestion d'informations (CMIS handler) (31) ou au kit de développement de programme (MIB toolkit) (34).

Si aucun préfiltrage par les attributs indexés dans la base de données sous-jacente n'est utilisable, alors l'exécuteur de requête (37) parcourt la liste de tous les fils pour lire les MOI correspondant à la portée (scope). Dans les cas particuliers des instances d'objet de classe spécifique mocExtension , on utilise la pseudo-portée (pseudo-scope) des relations

transversales à la place de la liste des fils. Cette pseudo-portée (pseudoscope) est définie comme étant la copie virtuelle de toutes les instances d'objets gérés MOIs de la classe identifiée par la classe spécifique mocExtension . Puis l'exécuteur des requêtes (37) de la base d'information d'administration (MIB query performer) évalue le filtre sur chaque instance précédemment sélectionnée. Si l'évaluation est positive, il exécute l'opération sur la base d'information d'administration (MIB) et retourne les réponses individuelles au gestionnaire dudit service commun de gestion d'informations (CMIS handler) (31) ou au kit de programme de développement (MIB toolkit) (34).

La structure des pseudo-portées (pseudo-scope) accessibles depuis les objets de classe spécifique mocExtension est définie par l'utilisateur en enregistrant dans la description GDMOD MIB des liens de nommage (Name Binding) suivants : - pour chaque instance de classe spécifique mocExtension , le nom tel que, par exemple, mocLabel, et dont l'identifieur d'objets OID est donné par l'attribut "moclD", on ajoute le lien de nommage suivant dans le module GDMO CMIS-DB collections-NB : ExtensionOf <mocLabel> NAME BINDING
SUBORDINATE OBJECT CLASS <moduleName>:<mocTemplateName>
NAMED BY
SUPERIOR OBJECT CLASS mocExtension;
WITH ATTRIBUTE cmisDbMOIAttid; REGISTERED AS { CMisdbCollections-NB.nameBindings unique Number!!!}
La structure des records d'enregistrement des MOI des classes optimisées (fichiers ISAM suffix-Moi-1, , suffix-Moi-n, dans lequel 1 ou n est la forme locale de la MOC optimisée) est celle de la représentation

générique des MOIs à laquelle on concatène le ou les attributs à utiliser dans les index secondaires spécifiés par l'utilisateur via les objets mocStorageDefinition. La structure de ces champs "indexableAttributeList" supplémentaires est comme spécifiée ci-dessous :

<tb> byte <SEP> 0 <SEP> 3 <SEP> 4 <SEP> N
<tb>
<tb> fjeld <SEP> fatherMOInodeRef <SEP> IndexableAttributeList <SEP> FDNofMOI <SEP> AttributeList <SEP> OPmask
<tb>
<tb>
<tb> 4 <SEP> bytes(long <SEP> ) <SEP> N@N=4 <SEP> + <SEP> add <SEP> length <SEP> of <SEP> each <SEP> n <SEP> bytes <SEP> m <SEP> bytes <SEP> 10 <SEP> bytes <SEP>
<tb>
<tb>
<tb> attribute
<tb>
<tb>
<tb>
<tb> index <SEP> primary <SEP> index <SEP> M <SEP> seocndarv <SEP> indexes
<tb>
<tb> ISDUPS <SEP> DCOMPRESS <SEP>
<tb>
<tb>
<tb> LONGTYPE+LONGTYPE
<tb>
où indexableAttributeList a la structure suivante :

<tb> 4 <SEP> 7 <SEP> 8
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb> fatherMOInodeRef <SEP> Attribut <SEP> 1 <SEP> ... <SEP> Attribut <SEP> i
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb> 4 <SEP> octets <SEP> (long) <SEP> n1 <SEP> octets <SEP> n2 <SEP> octects <SEP>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb> ISDUPS <SEP> DCOMPRESS <SEP> les <SEP> index <SEP> dépend <SEP> des <SEP> valeurs <SEP> types
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb> LONGTYPE <SEP> secondaires
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb> dépendent <SEP> des <SEP>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb>
<tb> valeurs <SEP> types
<tb>
Dans le champ indexableAttributeList utilisable pour activer des index secondaires, les valeurs des attributs indexables sont stockés.

La figure 7 représente la spécialisation des stockage pour les MOC.

Un type d'objet de stockage est un objet dérivé de la classe ManagedObjectlnstance (74) et les éventuelles sous-classes, "genericMOI" (71), "optimizedMocMOI" (73), mocExtension (76), de cette classe pour

les représentations des classes optimisées. Ce type d'objet contient une instance avec tous ses attributs et des attributs cachés (FDN du MOI, ....).

La liste d'attributs est en fait une nouvelle collection d'objets de classe moiattributes (qui contient un couple Attributld, AttributeValue).

Ainsi, grâce à cette structure de stockage, la valeur de l'attribut à indexer est préfixée par l'adresse physique fatherMOInodeRef d'un père de l'objet dans l'arbre de contenance et où FDNofMOI est indexé par les RDN.

Enfin, gestionnaire d'objet CMIS-DB offre la possibilité par l'opération M-SET de désactiver la présence de fatherMOInodeRef dans les index des attributs, lorsque la recherche à optimiser se fait sous les objets mocExtension introduits précédemment.

Le fait de ne plus utiliser la référence fatherMOInodeRef du père dans le calcul des attributs indexés permet de faire un préfiltrage des instances d'une classe donnée par lecture indexée
La figure 6 représente une instance de la classe spécifique mocExtension affichée à l'écran du terminal par une interface graphique permettant à l'utilisateur d'accéder à l'administrateur de CMIS-DB. Cette fenêtre permet à l'utilisateur de définir les différents attributs de la classe spécifique mocExtension . Un premier pavé (91) permet d'afficher l'identifieur OpclassO de la MOC ainsi représentée
Un deuxième pavé (92) permet de définir l'attribut de nommage du type réponse typeOfReplyNaming qui détermine le type de nommage à utiliser dans les réponses aux requêtes CMIS M-GET de consultations de l'ensemble des instances qui sont de classe opClassO dans cet exemple, et l'utilisateur pourra avoir le choix entre les trois valeurs "naturaIFDN", "specificFDN", "nonSpecificForm".

Un troisième pavé (93) permet de définir la classe de l'objet et d'indiquer qu'elle est du type de la classe spécifique mocExtension .

Un troisième pavé (94) permet d'indiquer le lien de nommage utilisé, en l'occurrence qu'il appartient au sous-arbre des classes de collections (MOCcollection).

On comprend donc que la solution de l'invention consiste en l'introduction d'une classe spécifique mocExtension qui est un objet qui référence automatiquement, par copie virtuelle, toutes les instances de la classe d'objet (MOC) qu'il représente et qui existent dans le serveur CMIS- DB et ceci indépendamment de leur position dans l'arbre de contenance (containment tree). Normalement dans un cadre purement CMIS, CMIS-DB doit répondre à la portée (scope) sous une instance de classe spécifique mocExtension avec le nom des copies virtuelles des objets référencés, ce qu'il fait (voir le mode specificFDN), mais, sous option, il a possibilité de répondre avec le nom réel (i.e. naturalFDN) des objets référencés pour permettre à l'application de s'y retrouver plus facilement dans les réponses.

Une troisième possibilité de nommage (i.e. objectlnstance au format nonSpecificForm) permet d'utiliser directement l'adresse physique des instances pour accélérer les accès à ces instances lors de recherches ou de parcours particuliers qui pourraient être programmés dans la mib-toolkit et uniquement là, car ce type d'adresse physique n'est pas un adressage global valide hors du serveur CMIS-DB.

D'autres modifications à la portée de l'homme de métier font également partie de l'esprit de l'invention.

Claims

REVENDICATIONS

1. Procédé d'optimisation des accès à l'ensemble des instances d'objets administrés d'une même classe donnée, existantes dans une base d'information de gestion (MIB) hiérarchisée sous forme d'arbre d'instances d'objets de classes diverses, caractérisé en ce qu'il comprend une étape de création automatique, par un gestionnaire (CMIS-DB) d'objet de la base d'information de gestion (MIB), d'une instance d'objet de classe spécifique (mocExtension) prédéfinie pour représenter l'ensemble des instances d'une classe d'objets administrés (MOC) existantes dans le gestionnaire, pour permettre au gestionnaire de maintenir automatiquement une copie virtuelle de toutes les instances d'objets de la classe (MOC) représentée par l'instance de classe spécifique (mocExtension).

2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape de consultation d'une collection de tous les objets d'une même classe donnée référencée par l'instance de classe spécifique (mocExtension) automatiquement créée par le gestionnaire d'objet (CMIS- DB) pour contenir virtuellement les éléments de cette collection, par l'intermédiaire d'une requête (M-GET) du gestionnaire d'objet (CMIS-DB) avec les arguments suivants : objet de base l'instance de classe spécifique (mocExtension) identifiée par l'attribut d'identificateur d'objet (OBJECT IDENTIFIER) de la classe recherchée, portée (scope) de premier niveau subordonné, et filtre de structure déterminée.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comporte une étape de détermination du type de nommage à utiliser dans les réponses aux consultations par des requêtes portées (scoped) sous cette instance de classe spécifique (mocExtension) par la mise à jour d'un attribut de nommage (typeOfReplyNaming) indiquant au service de gestion quel est le type de nommage à utiliser.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comporte une étape de renvoi des réponses aux requêtes par le

gestionnaire d'objet (CMIS-DB) en fonction de l'attribut fixant le type de nommage à utiliser pour identifier les copies virtuelles d'instance d'objet subordonnées à l'instance d'objet de classe spécifique (mocExtension).

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que lorsque l'objet de base (baseObject) est de la classe spécifique (mocExtension), le paramètre portée (scope) est détecté par ledit gestionnaire d'objet (CMIS-DB) de la base (MIB) qui évalue cet argument de portée (scope) comme un parcours des objets appartenant à la collection de toutes les instances d'objet de la classe représentée par l'objet de base (baseObject) de classe spécifique (mocExtension).

6. Procédé selon la revendication 4, caractérisé en ce que l'étape de renvoi des réponses transmet le nom distinct complet (FDN) de l'objet réel référencé dans un argument (instance d'objets managés) de chaque réponse si le type de nommage choisi est d'un premier type (natureIFDN); ou le nom distinct complet (FDN) de la copie virtuelle si le type de nommage est d'un second type (spécificFDN) ou encore un adressage direct au stockage physique dans le cas où le type de nommage est d'un troisième type (nonSpecificForm).

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'il comporte une étape de préfixation de la valeur de l'attribut à indexer par l'adresse physique d'un père de l'objet (fatherMOInodRef) dans l'arbre de contenance et d'indexer le tout.

8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il est mis en oeuvre par le gestionnaire d'objet (CMIS-DB) pour désactiver la présence du père (fatherMOInodRef) dans les index des attributs, lorsque la recherche optimisée se fait sous les objets (mocExtension) introduits précédemment.

9. Dispositif pour délivrer un gestionnaire d'objet (CMIS-BD) pour une base d'information d'administration (MIB) sur un serveur mettant en oeuvre le procédé selon l'une des revendications 1 à 8, caractérisé en ce

qu'il comporte une classe d'objet managé (MOC) de classe spécifique (mocExtension) qui optimise le parcours de la collection contenant toutes les instances de la même classe donnée créées et encore existantes dans la base (MIB) gérée par le gestionnaire d'objet (CMIS-DB).

10. Dispositif selon la revendication 9, caractérisé en ce que lorsque l'objet de base (baseObject) est de la classe spécifique (mocExtension), le paramètre portée (scope) est détecté par ledit service commun de gestion d'informations (CMIS) qui évalue cet argument de portée (scope) comme un parcours de l'ensemble des objets de la classe identifiée par cette instance d'objet de classe spécifique (mocExtension).