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

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

Info

Publication number
WO2000027073A1
WO2000027073A1 PCT/FR1999/002647 FR9902647W WO0027073A1 WO 2000027073 A1 WO2000027073 A1 WO 2000027073A1 FR 9902647 W FR9902647 W FR 9902647W WO 0027073 A1 WO0027073 A1 WO 0027073A1
Authority
WO
WIPO (PCT)
Prior art keywords
class
cmis
mocextension
objects
instance
Prior art date
Application number
PCT/FR1999/002647
Other languages
English (en)
Inventor
Jean-Luc Richard
Original Assignee
Bull S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull S.A. filed Critical Bull S.A.
Priority to EP99950878A priority Critical patent/EP1044535A1/fr
Publication of WO2000027073A1 publication Critical patent/WO2000027073A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/289—Object oriented databases

Definitions

  • the present invention relates to a method for optimizing access to all of the instances of administered objects of the same given class, in an administration database (MIB) stored on a disk.
  • MIB administration database
  • the information access services of a MIB are based on the known CMIS standard (Common Management Information Service, IUT-T recommendation X.710), which describes the operations that can be performed on the specified objects according to the model of the standard G DMO (Guidelines for the Definition of Managed Objects, or ITU-T Recommendation X.722 recommendation).
  • CMIS standard Common Management Information Service, IUT-T recommendation X.710
  • G DMO Guidelines for the Definition of Managed Objects, or ITU-T Recommendation X.722 recommendation.
  • the present invention uses the information management service of the CMIS standard.
  • the administration applications call either on agents (43a, 43b and 43c) which are processes installed on remote machines connected by a network (30) with a machine supporting the administration application (4), or on local services of an administration system subsequently called “entity manager” which make it possible to locally manage a management information base MIB (Management Information Base) hierarchical in the form of a tree of object instances, without network access.
  • MIB Management Information Base
  • MIB administrative information management
  • all the resources are represented in the form of objects in an object tree as shown in FIG. 2.
  • the objects are themselves grouped into classes.
  • the object of a given class has a number of attributes and each object instance has a name (N). Addressing is by distinguished name DN
  • the DN of the object (51, figure 2) is "a / b / b".
  • Figure 4 shows the operation of an information management service.
  • This service uses a two-level architecture.
  • the first level consists of a manager entity (4) playing the role of administrator who must view and control resources, consult characteristics, etc.
  • the second level consists of agent entities
  • the OpenMaster TM administration system marketed by BULL comprises one or more ISM-Manager administrators (Integrated System Management) and several agents (45a to 45c) (ISM / Agent).
  • ISM / Agent agents marketed by other companies can be controlled by the OpenMaster TM administrator via standard protocols.
  • the administrator-agent mechanism is based on an object model, in which the modeling of a resource consisting, for example, of system elements, software, states, users, etc., is based on a management information approach and structuring into objects.
  • the "real" equipment of a networked system (a computer, a printer, a circuit, etc.) is represented by abstract objects organized in an administration information base (MIB, Management Information Base).
  • MIB administration information base
  • the characteristics of these objects name of a computer, characteristics of peripheral equipment, the status of this equipment such as a printer, etc.
  • attributes of the objects are called the attributes of the objects.
  • MOCs Managed Object Classes
  • MIB Management Entity
  • MOCs define the information that the MIB will contain for each type of resource, that is to say which attributes the object will have. MOCs can be interpreted as part of the MIB "scheme”.
  • Each MOC is instantiated into several instances of managed objects (MOIs, Managed Object Instances) representing the actual occurrences of this type of resource.
  • the attributes of the object representing the printer are "printer status" and "user”.
  • a MOC object class "printer” can therefore be defined with the attributes "printer status” and "current user”.
  • the object instances (MOIs) of the "printer” class can be the following:
  • the status of the Printer 1 resource is activated and there is no current user when instantiating the example above.
  • This example also includes the instances Imprim 2 and Imprim 3.
  • An application such as "ISM-Monitor” provided by the OpenMaster TM administration system (4) makes it possible to display the MOIs and their states.
  • ISM-Monitor can display in the form of a table the attributes of any MOI: for example the attributes "printer status" and "user” for any MOI of the "Printers" MOC.
  • the set of administered objects forms an administration information base (MIB).
  • MIBIet a subtree directly attached to the root of the separate tree of an information management base (MIB).
  • MIB information management base
  • Root a MOI object at the root of a MIBIet subtree.
  • the OpenMaster TM administrator sees the system distributed through the MIB objects and the control of the system is done by manipulating the MIB objects and their attributes.
  • the objects are visible thanks to the agents or the object manager attached to the OpenMaster TM administrator who map (mapping) the equipment in MIB in the form of an object tree.
  • An agent can represent the state of a device by means of a corresponding associated object represented in the MIB.
  • This cartography can associate an object with several "real" equipments, just as an equipment can be modeled in the form of several objects.
  • the OpenMaster TM administrator sends commands to the agents (43a to 43c) and the agents send responses to his commands and notify events to the OpenMaster TM administrator (4) through integrating agents (45) using a protocol such as SNMP (Simple Network Management Protocol, 45a), CMIP (Common Management Information Protocol, 45b), or others such as DSAC / AEP (Distributed Systems Administration and Control / Administrative Exchange Protocol, 45c).
  • SNMP Simple Network Management Protocol
  • CMIP Common Management Information Protocol
  • DSAC / AEP Distributed Systems Administration and Control / Administrative Exchange Protocol, 45c.
  • Each administration protocol provides a certain number of simple operations, for example the CMIP protocol provides all the functions of the CMIS standard, namely the following:
  • the administrator (41) can read the attributes of a MIB object by the M-GET operation.
  • the agent (43) responds to an M-GET request by giving information on the equipment.
  • the administrator (41) can modify the attributes of a MIB object (the M-SET operation).
  • the agent modifies the "real" equipment according to the new attribute values provided by the administrator;
  • the administrator (41) can execute an action on a MIB object by the M-ACTION operation.
  • the agent (43) performs an action on the equipment according to the action requested by the administrator on the abstract object;
  • the administrator (41) can create and delete objects from the MIB by the operations M-CREATE and M-DELETE;
  • the agent (43) can notify an event occurring on an object of the MIB to the administrator by the operation M-EVENT.
  • the agent sends information about an event concerning an abstract object to describe an event that occurred on "real" equipment.
  • MIB administration information base
  • MOI object instance
  • containment tree Instances of administered objects (MOIs) are named by their position in the containment tree as follows:
  • Each MOI has a relative distinguished name (RDN) which differentiates MOIs with the same and unique superior MOI ( father).
  • RDN relative distinguished name
  • MOC managed object class
  • One of the attributes of each managed object class (MOC) is chosen to specify the instance's RDN for a given higher MOI. This attribute called the naming attribute is identified in GDMO forms called name binding.
  • An MOC can have multiple potential superior naming links, but each MOI will use only one of them.
  • Each MOI also has a unique Full Distinguished Name for the entire MIB.
  • the global distinguished name (DN) of an object consists of its relative distinguished name (RDN) joined to the distinguished name (DN) of its superior, that is to say that the distinguished name (DN) of an instance of administered objects (ME) contains its own relative distinguished name (RDN) plus the relative distinguished names (RDNs) of all of its superiors in the containment tree down to the root.
  • CMIS-DB One of the object administrators local to the ISM-Manager administrator is called CMIS-DB. It is responsible for storing part of the local MIB. The remanence of these stored objects is ensured by ISAM files (Index Sequential Access Method).
  • ISAM Index Sequential Access Method
  • This technology which describes the article structures (records) is a method of accessing files structured in the form of articles cut from one or more indexes and data information.
  • the base object instance BOI makes it possible to identify an object in an administration information base (MIB) which is the starting point for an evaluation of the carried-filter pair in the object tree.
  • MIB administration information base
  • the scope selects a portion of the tree from this base object. For example, the scope “all sub trees” (“Whole subtree”) allows you to select all the sub trees of a given object. Among all the objects in the scope, the objects selected are those for which the evaluation of the filter is true. The operation is performed on the objects actually selected.
  • the administrator sends an M-GET on objects and CMIS-DB reads and returns to the application the value of the attributes of the selected objects.
  • the local CMIS-DB administrator To reach a base object instance (BOI), the local CMIS-DB administrator must pass from parent object to child object until reaching the node of the base object. This navigation operation can be long, if to move from one node to another, it is necessary to physically read all the threads of a node and among these choose the one with the right RDN, and so on .
  • the computer Once the computer has reached the base object instance, it must read the attributes of the base objects that correspond to the scope in order to be able to evaluate the filter in memory, while the instances are read. on the machine disc.
  • An object of the present invention is to propose a method for optimizing readings in an administration information base (MIB) organized in trees of instances of objects of various classes, of all the instances of a given class existing in this MIB.
  • MIB administration information base
  • the method according to the invention provided by the CMIS-DB process of the ISM-Manager entity makes it possible to apply a selection by the arguments scope / filter (scope / filter) of the standard operations of the CMIS service to offer the advantage to select these objects of given class through a single operation.
  • the only CMIS scope which could reach these object instances in a single CMIS operation is a scope (type) "whole-subtree" starting from the root of the global MIB, apart from this, also contains sub-trees which do not belong to the local CMIS-DB administrator.
  • the other alternative is to submit as many CMIS operations as there are MOI rootlet objects stored in the local CMIS-DB administrator with a scope of type all sub- tree (whole-subtree) and a baseObjectlnstance equal to each of these rootlets.
  • the idea of the invention is to represent all the instances, of a given class of MOC administered objects, existing in the common information management service (CMIS-DB) by an object of specific class called " mocExtension ”automatically managed by the common information management service CMIS-DB to be the root of a virtual copy of all the instances of the same class.
  • CMIS-DB common information management service
  • mocExtension object of specific class
  • Another advantage of this invention is to be able to use the physical indexes which have been optionally configured by the user as described below, in order to reduce the time cost of evaluating the argument CMIS filter, when it must be applied to the set of all instances of a given class.
  • the indexes are configured on attributes identified in the filter, they can be used to physically read only a subset of the instances as described below. It is enough simply to reconfigure on-line (on-line) the indexes to no longer use the part of the key which memorizes the position of the instance in the capacity tree.
  • An object instance of this specific class "mocExtension" is automatically created by CMIS-DB for each managed object class that the user declares to the CMIS-DB service.
  • This declaration allows the user to specialize by configuration, as described below, the storage structure on disk of object instances of a given class which otherwise remains generic.
  • the generic representation physically indexes only the mandatory objectClass attribute in the ISAM files for storing the MIB on disk.
  • the specialization of the storage of an MOC allows the user to declare a certain number of the set of specific attributes of this MOC, as having to be indexed in the ISAM files for storage on disk.
  • indexes includes the reference of the parent object in the containment tree, but CMIS-DB allows not to include this reference in the physical read key indexed in the precise case where the selection of objects on which CMIS operations must be applied is done by a first level scope directly under an instance of specific class "mocExtension" and a filter whose expression is such that the value of one or more indexed attributes of the OMC can be given as an indexed read key.
  • CMIS-DB creates a new ISAM file intended to contain all the instances of this MOC and only this one. Consequently, when the user wants to select all or part of the instances of this MOC using a baseObjectlnstance argument BOI equal to the specific class instance "mocExtension" which represents this MOC, CMIS-DB only accesses the elements of this file and thus avoids visiting nodes of the tree containment (contaiment tree) which are not instances of this MOC and which are by construction in different ISAM files.
  • the subject of the invention is a method for optimizing access to all the instances of administered objects of the same given class, existing in a hierarchical management information base (MIB) in the form of tree of instances of objects of various classes, characterized in that it comprises a step of automatic creation, by a manager (CMIS-DB) of an object of the management information base (MIB), of a instance of object of specific class "mocExtension" predefined to represent all the instances of a class of administered objects (MOC) existing in the manager, to allow the manager to automatically maintain a virtual copy of all the instances of objects of the class (MOC) represented by the specific class instance "mocExtension".
  • CMIS-DB manager
  • MIB management information base
  • MOC administered objects
  • the method comprises a step of consulting a collection of all the objects of the same given class referenced by the specific class instance "mocExtension" automatically created by CMIS-DB to virtually contain the elements of this collection, via a request for obtaining (M-GET) of the common information management service comprising the following arguments: base object, scope and filter in which the base object is the instance of the specific class "mocExtension" identified by the object identifier OBJECT IDENTIFIER of the sought class, the scope is the first level subordinate scope, and the filter is of determined structure.
  • the method comprises a step of determining the type of naming to be used in the responses to the consultations by requests carried (scoped) under this instance of specific class "mocExtension” by updating a fixing attribute name (typeOfReplyNaming) telling the management service which type of naming to use.
  • the method includes a step of returning responses to requests by the common information management service (CMIS-DB) according to the attribute fixing the type of naming to be used to identify the virtual copies of object instance subordinate to the object instance of specific class "mocExtension".
  • CMIS-DB common information management service
  • the scope parameter is detected by said common object management service (CMIS-DB) of the MIB which evaluates this scope argument as a browse of the objects belonging to the collection of all object instances of the class represented by the base object (baseObject) of specific class "mocExtension”.
  • CMIS-DB common object management service
  • the step of returning the responses transmits the full distinguished name (FDN: Full Distinguished Name) of the real object referenced in the argument "instance of managed objects" (MOI) of each response if the type of naming chosen is of a first type (naturalFDN); or the FDN of the virtual copy if the naming type is of a second type (specificFDN) or even direct addressing to physical storage in the case where the naming type is of a third type (nonSpecificForm).
  • FDN Full Distinguished Name
  • the distinguished name of an administered object instance contains its own relative distinguished name plus the relative distinguished names of all of its superiors in the containment tree down to the root.
  • the method comprises a step of prefixing the value of the attribute to be indexed by the physical address "fatherMOInodRef of a father of the object in the containment tree) and of indexing the whole thing.
  • the method is implemented by the CMIS-DB administrator to offer the possibility of deactivating the presence of "fatherMOInodRef in the attribute indexes, when the optimized search is done under the mocExtension objects introduced previously.
  • Another object of the invention is to propose a device for delivering an object manager (CMIS-DB) for an administration information base (MIB) on a scent implementing the method according to the invention.
  • CMIS-DB object manager
  • MIB administration information base
  • the device includes a managed object class (MOC) of specific class "mocExtension" which optimizes the browsing of the collection containing all the instances of the same given class, created and still existing in the MIB managed by the object manager (CMIS-DB) regardless of their position in the tree and without having to physically access the disk from any of the other object instances which are not of the desired class.
  • MOC managed object class
  • MIB MIB managed by the object manager
  • the scope parameter is detected by said common information management service (CMIS) which evaluates this scope argument ( scope) as a browse of all the objects of the class identified by this instance of an object of specific class "mocExtension”.
  • CMIS common information management service
  • FIG. 1 represents an example of information base (MIB) in which two classes were declared by the user to be optimized and therefore in which two instances of specific class "mocExtension" were automatically created by the manager CMIS-DB object
  • - Figure 2 represents a tree of objects constituting a MIB
  • FIG. 4 represents the architecture of the OpenMaster TM manager, one of the components of which is CMIS-DB,
  • FIG. 5 shows a diagram showing the different functions of translation and comparison between different alternatives of naming of the objects belonging to the sets identified by the objects of specific class mocExtension,
  • FIG. 6 represents a window for displaying an instance of an object of specific class "mocExtension" generated by a graphical user interface forming part of the ISM-Monitor application.
  • the present invention allows the user to optimize access to all of the instances of administered objects of the same given class, and existing in the MIB between instances of the managed object (MOI) belonging to the same MIB object management server instance managed by the CMIS-DB server.
  • MOI managed object
  • Figure 1 shows an example of an administration information base (MIB) stored in an object manager (CMIS-DB).
  • MIB administration information base
  • CMIS-DB object manager
  • the classes X represented by squares with rounded angles (1 1 a to 1 1 d) and belonging to a first tree (1 1) are defined by the user and represented by the generic node.
  • Another tree (17) also includes classes Y and Z also belonging to the first tree (1 1).
  • the user can add classes of objects represented by a specific node indexed by the attributes chosen and this type of class is represented by rectangles with acute angles (17, 18).
  • the CMIS-DB administrator can use the collection class
  • the specific class type of object extension (14.1,) "mocExtension” is predefined by the CMIS-DB administrator and makes it possible to represent the set (18a to 18g) of objects of class Y defined in the naming attribute "moclD" of the specific class of object extension (14.1) "mocExtension”.
  • An instance of a specific class "mocExtension” is automatically created by the object manager (CMIS-DB) for each specialized classes of managed objects (MOC).
  • the specific object class "mocExtension” is a class predefined by the object manager (CMIS-DB) to represent the set of optimized instances of each of the user's managed object classes (MOC). It derives from the "top” class and has as attributes:
  • a naming attribute "moclD" equal to the OBJECT IDENTIFIER of the managed object class (MOC) represented by this instance of the specific class "mocExtension".
  • the naming attribute of the managed object class (MOC) (11) is named Y (mocID ⁇ Y). As shown by the lines (20) in Figure 1, it brings together all the objects of class Y.
  • CMIS-DB object manager
  • the second type of naming gives the specific full distinguished name "specificFDN” which corresponds to the distinguished name (DN, "distinguishedName") of the virtual copy of the referenced object, this name is calculated by the object manager (CMIS-DB ) from the value of the natural full distinguished name, "natural FDN”. Its value is the concatenation of the DN of the specific class object mocExtension representing the collection and an RDN (Node Reference) made automatically by CMIS-DB object manager to name the virtual copy.
  • CMIS-DB object manager
  • NonSpecificForm is a name that contains the internal reference to the object manager (CMIS-DB) of the node object of the instance, it is a direct pointer to the storage object of the instance d 'objects referenced.
  • CMIS-DB object manager
  • baseObject definition of the base object
  • scope a filtered.
  • CMIS-DB The object manager (CMIS-DB) offers translation and comparison actions between some of these different naming alternatives.
  • CMIS-DB is considered by its applications as an object manager (object manager) which stores and manages part of the MIB in a database.
  • the CMIS-DB server interacts with the CDSP router (33) through an interface (32). Interactions between all the components of the ISM administrator are carried out using CMIS messages carried by the CDSP router.
  • FIG. 3 represents the CMIS-DB object manager according to the invention which comprises a CMIS operations manager (CMIS operations handier) (31) dialoguing according to the protocol of the (CDSP) (33) with the communication infrastructure, a programmable user extension module coded in SML (SML MIB toolkit) (34), a module (37) divided into a query executor sub-module (MIB queries performer), a navigation and range evaluation sub-module, filter, and an optimizer pre-filtering sub-module (372), a translator of global form into local form (38), an import / export module (39), a cache of the object containment tree (cache of containment tree) (40), a cache of object management instances (cache of MOIs) (49), a physical memory access module (50) that interfaces the server to the underlying database (51), a physical access transaction administrator module (storage transaction manager) (48) and a disk e physics (47).
  • CMIS operations manager CMIS operations handier
  • CDSP programmable user
  • the development program kit (SML MIB toolkit) (34) loads any SML (Systems Management Language) extensions (341) for the user and provides primitives for accessing the administration information base in SML ( MIB) managed by the CMIS-DB object manager.
  • SML MIB toolkit evaluates the pre-conditions and post-conditions posed by the user, during each operation on the administration information base (MIB) and executes the SML extensions which are triggered on these conditions.
  • the request executor (37) on the administration information base actually performs the request or operation on the logical representation of the administration information base (MIB). It navigates according to the argument of the base object instance (BOI, baseObjectlnstance) of the request, to obtain the initial instance of the evaluation of the scope and the filter.
  • the mode of operation of the request executor (37) of the administration information base (MIB query performer) depends on the arguments carried (scope) and filter of the operation.
  • the executor of the requests of the administration information base (MIB query performer) searches the list of all the children to read the object management instances (MOI) corresponding to the scope.
  • the decision as to whether a pre-filtering can be performed or not, depends on the analysis of the structure of the filter.
  • the optimized search for MOIs selected by a filter consists in not physically reading all the MOIs belonging to the CMIS scope to apply the evaluation of the filter to them, but in using them when possible, the indexes which are positioned on their MOCs said to be optimized, in order to read only a subset of these MOIs instances.
  • This last operation is called “preselection or pre-filtering”; it does not replace the step of evaluating the filter on each MOI returned to memory which takes place systematically in both cases.
  • Pre-filtering by the indexes can therefore raise MOIs which in the end will be rejected by the evaluation stage of the CMIS filter, but it must not forget to read only one of the MOIs in the scope which check the filter.
  • CMIS filters must conform to a defined structure to be recognized by the MOI search optimizer that these filters select.
  • a CMIS filter recognized by the optimizer must be a logical expression that selects only MOIs of the same class. This class which must be one of the optimized MOCs declared to the CMIS-DB module.
  • indexFilterPart indexFilterltem
  • the order introduced between the different items does not reflect a syntactic order in the expression of the CMIS filter which can be arbitrary, but rather the physical order of the attributes as they exist in the indexes of the optimized JI .
  • the executor of the requests of the administration information base (MIB query performer) reads in the underlying base the only subordinates which are indexed by the values attributes selected for pre-filtering. Then the request executor (37) of the administration information base (MIB query performer) evaluates the filter on each previously selected instance. If the evaluation is positive, it executes the operation on the logical representation of the administration information base (MIB) and returns the individual response to the manager of said common information management service (CMIS handier) (31) or the program development kit (MIB toolkit) (34).
  • CMIS handier common information management service
  • MIB toolkit the program development kit
  • the query executor (37) goes through the list of all the children to read the MOIs corresponding to the scope.
  • the pseudo-scope of the transversal relations instead of the list of children. This pseudo-scope is defined as being the virtual copy of all the instances of MOIs managed objects of the class identified by the specific class "mocExtension”.
  • the request executor (37) of the administration information base (MIB query performer) evaluates the filter on each previously selected instance. If the evaluation is positive, it executes the operation on the basis of administration information (MIB) and returns the individual responses to the manager of said common information management service (CMIS handier) (31) or to the development program (MIB toolkit) (34).
  • MOI registration records of optimized classes (ISAM files suffix-Me-1,, suffix-Me-n, in which 1 or n is the local form of the optimized MOC) is that of the generic representation of MOIs to which we concatenate the attribute or attributes to be used in the secondary indexes specified by the user via the mocStorageDefinition objects.
  • the structure of these additional "indexableAttributeList" fields is as specified below:
  • N 4 + add length of eac n bytes m bytes 10 bytes attribute index primarv index M seocndarv indexes
  • indexableAttributeList has the following structure
  • indexableAttributeList field which can be used to activate secondary indexes, the values of the indexable attributes are stored.
  • FIG. 7 shows the specialization of storage for MOCs.
  • a type of storage object is an object derived from the ManagedObjectlnstance (74) class and any subclasses, "genericMOI” (71), “optimizedMocMOI” (73), “mocExtension” (76), of this class for representations of optimized classes.
  • This type of object contains an instance with all its attributes and hidden attributes (FDN of ME, .).
  • the attribute list is actually a new collection of objects of class me-attributes (which contains a couple Attributld, AttributeValue).
  • the value of the attribute to be indexed is prefixed by the physical address fatherMOInodeRef of a father of the object in the containment tree and where FDNofMOI is indexed by RDN.
  • the CMIS-DB object manager offers the possibility, through the M-SET operation, of deactivating the presence of fatherMOInodeRef in the attribute indexes, when the search to optimize is done under the mocExtension objects introduced previously.
  • FIG. 6 represents an instance of the specific class
  • a first block (91) makes it possible to display the “OpclassO” identifier of the MOC thus represented.
  • a second block (92) makes it possible to define the naming attribute of the type of response typeOfReplyNaming which determines the type of naming to be used in the responses to CMIS M-GET requests for consultations of all the instances which are of class "opClassO" in this example, and the user will have the choice between the three values "naturalFDN", “specificFDN”, "nonSpecificForm”.
  • a third block (93) makes it possible to define the class of the object and to indicate that it is of the type of the specific class "mocExtension".
  • a third block (94) is used to indicate the naming link used, in this case that it belongs to the sub-tree of the collection classes (MOCcollection).
  • MOCcollection the sub-tree of the collection classes
  • CMIS-DB Normally in a purely CMIS framework, CMIS-DB must respond to the scope under a specific class instance "mocExtension" with the name of the virtual copies of the referenced objects, which it does (see specificFDN mode), but , under option, it has the possibility of responding with the real name (ie naturalFDN) of the referenced objects to allow the application to navigate more easily in the responses.
  • a third naming possibility ie objectlnstance in nonSpecificForm format
  • Other modifications within the reach of the skilled person are also part of the spirit of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

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 G DMO (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 "a/b/b".
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 OpenMaster™ 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 OpenMaster™ 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 (Impriml , Imphm2, 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:
MOI MOC ATTRIBUTS
(instance) Classe état de l'imprimante utilisateur
Imprim 1 Printer activée aucun
Imprim 2 Printer désactivée aucun
Imprim 3 Printer activée Joe
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 OpenMaster™ (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 MIBIets, la base d'information d'administration (MIB) du système d'administration OpenMaster™ est reconnue comme une entité composite unique, avec tous les MIBIets attachés à la même MIB. On appelle "Rootlet" un objet MOI à la racine d'un sous-arbre MIBIet. L'administrateur OpenMaster™ 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 OpenMaster™ 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 OpenMaster™ envoie des commandes aux agents (43a à 43c) et les agents envoient des réponses à ses commandes et notifient des événements à l'administrateur OpenMaster™ (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 remanence 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 (naturelFDN); 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 senteur 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 OpenMaster™ 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 (1 1 a à 1 1 d) et appartenant à un premier arbre (1 1 ) 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 (1 1 ). 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 (1 1 , 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 où 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écifιque»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 ,
REGISTERED AS {ODS-ASN1 Module.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 (mocID≈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 {naturalFDN(O), specificFDN(l ), 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 odslD=ODSname/moclD=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 "naturalFDN"
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 handier) (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.
Cette expression logique doit être constituée d'une clause ET (AND) englobant :
- un item d'égalité sur l'attribut objectClass, valeur égale à l'identifiant 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 = valuel & 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.ObjectClass> indexFilterPart → indexFilterltem
I indexFilterEqualities indexFilterltem
indexFilterEqualities -» indexFilterEquality indexFilterEqualities indexFilterEquality → equality <anlndexedAttributeld>
<AttributeValue> indexFilterltem → indexFilterEquality
I indexFilterGreaterOrEqual I indexFilterLessOrEqual
I 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éfiitrage 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 handier) (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 (pseudo- scope) 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 handier) (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 { CMisdbCollectioπs-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 :
byte 0 3 4 N field fatherMOInodeRef IndexableAttributeList FDNofMOI AttributeList OPmask
4 bytes(long ) .
N=4 + add length of eac n bytes m bytes 10 bytes attribute index primarv index M seocndarv indexes
ISDUPS DCOMPRESS
LONGTYPE+LONGTYPE
où indexableAttributeList a la structure suivante
Figure imgf000023_0001
Figure imgf000024_0001
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 moi- attributes (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 "naturalFDN", "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 senteur 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 (naturelFDN); ou le nom distinct complet (FDN) de la copie virtuelle si le type de nommage est d'un second type (specificFDN) 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).
PCT/FR1999/002647 1998-10-30 1999-10-28 Procede d'optimisation des acces a l'ensemble des instances d'objets d'une meme classe dans une base de donnees d'administration WO2000027073A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP99950878A EP1044535A1 (fr) 1998-10-30 1999-10-28 Procede d'optimisation des acces a l'ensemble des instances d'objets d'une meme classe dans une base de donnees d'administration

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR98/13646 1998-10-30
FR9813646A FR2785410B1 (fr) 1998-10-30 1998-10-30 Procede d'optimisation des acces a l'ensemble des instances d'objets d'une meme classe dans une base de donnees d'administration

Publications (1)

Publication Number Publication Date
WO2000027073A1 true WO2000027073A1 (fr) 2000-05-11

Family

ID=9532189

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1999/002647 WO2000027073A1 (fr) 1998-10-30 1999-10-28 Procede d'optimisation des acces a l'ensemble des instances d'objets d'une meme classe dans une base de donnees d'administration

Country Status (3)

Country Link
EP (1) EP1044535A1 (fr)
FR (1) FR2785410B1 (fr)
WO (1) WO2000027073A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04199933A (ja) * 1990-11-29 1992-07-21 Hitachi Ltd ネットワーク管理システムおよびその運用方法
WO1995034975A1 (fr) * 1994-06-13 1995-12-21 Telefonaktiebolaget Lm Ericsson Element de reseau pour reseau de telecommunication
JPH08181772A (ja) * 1994-12-21 1996-07-12 Nippon Telegr & Teleph Corp <Ntt> ネットワークオペレーションシステムにおけるｍｉｂ構成方法及びそのバックアップ方法
US5586255A (en) * 1992-03-17 1996-12-17 Tanaka; Yasuhiro Network management operation system and network management operation method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04199933A (ja) * 1990-11-29 1992-07-21 Hitachi Ltd ネットワーク管理システムおよびその運用方法
US5586255A (en) * 1992-03-17 1996-12-17 Tanaka; Yasuhiro Network management operation system and network management operation method
WO1995034975A1 (fr) * 1994-06-13 1995-12-21 Telefonaktiebolaget Lm Ericsson Element de reseau pour reseau de telecommunication
JPH08181772A (ja) * 1994-12-21 1996-07-12 Nippon Telegr & Teleph Corp <Ntt> ネットワークオペレーションシステムにおけるｍｉｂ構成方法及びそのバックアップ方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
PATENT ABSTRACTS OF JAPAN vol. 016, no. 535 (E - 1288) 5 November 1992 (1992-11-05) *
PATENT ABSTRACTS OF JAPAN vol. 1996, no. 11 29 November 1996 (1996-11-29) *
YODA I ET AL: "METHODS FOR CONSTRUCTING A MANAGEMENT INFORMATION BASE (MIB) IN TRANSMISSION NETWORK OPERATIONS", ELECTRONICS & COMMUNICATIONS IN JAPAN, PART I - COMMUNICATIONS,US,SCRIPTA TECHNICA. NEW YORK, vol. 76, no. 9, 1 September 1993 (1993-09-01), pages 21-33, XP000449114, ISSN: 8756-6621 *

Also Published As

Publication number Publication date
FR2785410B1 (fr) 2002-01-25
EP1044535A1 (fr) 2000-10-18
FR2785410A1 (fr) 2000-05-05

Similar Documents

Publication Publication Date Title
US5787437A (en) Method and apparatus for shared management information via a common repository
US7673340B1 (en) System and method for analyzing system user behavior
US7925616B2 (en) Report system and method using context-sensitive prompt objects
US7945584B2 (en) Report system and method using prompt object abstraction
FR2780529A1 (fr) Procede pour l&#39;optimisation des acces a une base de donnees
US10248473B2 (en) Discovering object definition information in an integrated application environment
US20050015383A1 (en) Method and system for accessing database objects in polyarchical relationships using data path expressions
Rossi et al. Method rationale in method engineering
FR2888018A1 (fr) Procede et systeme de realisation d&#39;une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes
WO2003048994A2 (fr) Systeme et procede de gestion active d&#39;une entreprise de composants configurables
EP1193625A1 (fr) Moteur de recherche collaboratif
EP1129403A1 (fr) Systeme de gestion d&#39;objets permettant la mise en correspondance de connaissances de domaines d&#39;applications avec des connaissances de domaines de technologies
WO1997017660A1 (fr) Interface administrateur pour base de donnees dans un environnement informatique distribue
US8185562B2 (en) Business object browser for business query language
US20040133537A1 (en) Method and structure for unstructured domain-independent object-oriented information middleware
US7356758B1 (en) System and method for run-time report resolution of reports that include prompt objects
FR2931272A1 (fr) Procede d&#39;import export de donnees d&#39;une base de donnees
US7302639B1 (en) Report system and method using prompt in prompt objects
GB2402294A (en) Data collection in a computer network
EP1044535A1 (fr) Procede d&#39;optimisation des acces a l&#39;ensemble des instances d&#39;objets d&#39;une meme classe dans une base de donnees d&#39;administration
FR2781903A1 (fr) Procede de referencement dans une base d&#39;information d&#39;administration d&#39;un ensemble d&#39;instances d&#39;objet
Egyhazy et al. Interoperability architecture using RM-ODP
EP0750253A1 (fr) Procédé et dispositif pour partager des informations de gestion par une mémoire commune
Quasthoff et al. Design pattern for object triple mapping
Ruiz et al. Applying a web engineering method to design web services

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1999950878

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09582758

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1999950878

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1999950878

Country of ref document: EP