WO1999049401A1

WO1999049401A1 - Extensive request server

Info

Publication number: WO1999049401A1
Application number: PCT/FR1999/000668
Authority: WO
Inventors: Christian Ritter; Marc Simon
Original assignee: Bull S.A.
Priority date: 1998-03-24
Filing date: 1999-03-22
Publication date: 1999-09-30
Also published as: EP0985187A1; FR2776789B1; FR2776789A1

Abstract

The invention concerns an extensive request server characterised in that it enables to query, through requests, different data sources (SD) from a single parameterable interface capable of being activated by applications and administration modules, a request being modelled in a management information base (MIB) in the form of a main object (OP) comprising the type of the source to be queried and an attribute of said type, and subordinate input (OE) or output (OS) objects, said input objects (OE) defining each a parameter (PE), said output objects (OS) defining each a result-variable (VR).

Description

Generalized query server

This invention relates to the field of network and system administration. In this area, several data sources, using different types of language (CMIS, SQL, script, LDAP), coexist and must be able to be exploited differently by applications and / or administration modules.

The problem is to be able to query these different data sources, database, remote or local information management database (MIB), directories, files, from a single, configurable interface.

The queries, which must be made on these different data sources, depend on the query language that is specific to each of these sources.

In addition, these queries, compatible with different query languages, must be able to be dynamically configured. This configuration consists in supplying the execution and output parameters of an already defined request or in defining a new request.

Traditionally, to solve this problem, the requests allowing access to the different data sources were coded for each application or administration module. This solution is not satisfactory, because it requires modifying the code to be able to take into account each new request. In addition, this solution must be developed for each area of use.

Another solution consists in translating the data which one wants to exploit in the form of objects of an information management base (MIB). This solution requires modeling the data in the form of objects and writing a translator from the format specific to the data source queried into a format.

MIB. This very expensive work is useless compared to the needs that one has.

The objective of the invention is to mask the different types of query languages associated with different types of data sources, without being forced to model as objects the data from different data sources.

For this, the present invention provides a request server characterized in that it makes it possible to interrogate, through the concept of generalized request, different data sources from a single configurable interface that can be activated by any which applications and administration modules, a generalized request being modeled in an information management database (MIB) in the form of a main object comprising the type of source to be interrogated, a reference to the request specific to the source, and subordinate input and output objects, said input objects modeling the parameters, said output objects modeling the result variables.

According to another particular feature, the request server is an object manager, interrogated via a common information management service (CMIS), the requests being executed using an M-ACTION operation.

According to another particular feature, said input object modeling an input parameter of the request comprises an identifier, the name of a variable which will be passed to the request, the syntax of said variable and a default value of the parameter and comments. According to another particular feature, said output object modeling a result variable includes an identifier, the name of a variable, the type of said variable and comments.

According to another particularity, a generalized request makes it possible to constitute a list of equipment, said generalized request being defined by creating a main object and subordinate objects modeling on the one hand the input parameters and on the other hand the result variables .

According to another particular feature, the request server is used to supply a set server for the constitution of the list of its elements. According to another particular feature, the assembly server also includes an object for defining an assembly which can use a request. generalized and which includes the definition of a parameter constituting a set operator in the case where the set is made up from the combination of subsets.

According to another particular feature, the assembly server makes it possible to constitute domains containing lists of equipment.

According to another particular feature, the request server is associated with an assembly server storing equipment lists, said assembly server being modeled in the form of objects in an information management base (MIB), the objects MIB pointing to a reference to the main objects of the request server and having attributes specific to the sets.

According to another particular feature, the set server includes set and refresh functions.

According to another particularity, the assembly server comprises an interface presenting at least one dialog window proposing different methods of constituting and / or modifying a list of equipment, set functions, a function for refreshing lists of equipment that can periodically query data sources (SD). According to another particularity, a list of equipment can also be created by manually typing the reference of each equipment on the keyboard of a computer.

According to another particular feature, a list of equipment can be formed by selecting a generalized request from a list of existing requests.

According to another particularity, a list of equipment can be constituted by the combination of existing lists.

According to another particular feature, a list of equipment can be formed by selecting at least one equipment and / or a list of equipment modeled as a MIB object on a monitor card. ISM and using the drap and drop functions of the ISM monitor.

In another feature, the result variables provided by different calls to the query server can be combined to provide other calculated result variables.

According to another particularity, the result variables provided by the request server can be used in logical expressions constituting as many indicators for checking the consistency (CC) between an item of equipment and a reference configuration.

According to another particularity, the consistency check (CC) makes it possible to execute a configuration action on a list of equipment defined in a domain.

Other features and advantages of the present invention will appear more clearly on reading the description below made with reference to the accompanying drawings in which:

FIG. 1 represents the operation of a generalized request server,

FIG. 2 represents the structure of a request,

- Figure 3A shows the dialog window for associating a set with a generalized request.

FIG. 3B represents a window allowing the entry of a list of elements of a set,

FIG. 3C represents another window displaying the list of elements of a set,

FIG. 4A represents the window for displaying the definition of an object of the class “generalized request”, called “main object”, FIG. 4B represents the window for defining the attributes of an input object, FIG. 4C represents the window for defining the attributes of an output object,

- Figure 4D represents the window for defining another object of the class "generalized request" in another example application, - Figure 4E represents the window for defining the attributes of an input object of the another application example,

FIG. 4F represents the window for defining the attributes of a set,

- Figures 5A, 5B, 5C and 5D respectively represent a second example of the use of the main object windows (fig. 5A), input object (fig. 5B), output object (fig. 5C) and indicator object (fig. 5D) for the consistency check function,

- Figure 6 shows a window for constituting an assembly by combining existing assemblies. The invention relates to a "generalized query server" which can query different data sources from a single configurable interface (CMIS). The request server (SR) is an object manager which is queried via the service (CMIS). This request server (SR, fig. 1) is associated with a set server (SE) which performs the function of storing the results obtained by requests. The request server is also associated with the Configuration Manager application by the consistency check function, which has the role of executing a consistency check action on a list of devices called "assembly", calculated by the together and belonging to a defined domain. The request server (SR), according to the invention, was implemented in the context of the ISM Configuration Manager application which is a configuration management application.

The configurable interface chosen in this context is an interface of the common information management service CMIS (Common Management Information Service). This CMIS interface is very advantageous, because it can be requested by applications and / or administration modules. The common information management service (CMIS) associated with it, is a communication service comprising six operations: the GET operation for reading information, the SET operation for updating information , the operation M-EVENT for the emission of events, the operation M-ACTION for the launching of a procedure, the operation M-CREATE for the creation of new objects and finally the operation M-DELETE for their removal. Whatever the source of information, the service used by the ISM integrated service manager applications to administer the equipment will always be CMIS. An example of use of the request server (SR) is achieved by the constitution of lists of equipment called “sets” (301, 302) from different data sources (4, 5, 6, 7): database of management of information, files, relational database, directories, etc. This equipment consists of machines, bridges, routers, multiplexers, terminals, etc., forming a network and which can be grouped in fields. The request server (SR) is a link in a set server (SE). The set server (SE) is involved in the creation of domains.

A set is modeled as an object of the information management base (MIB). Each MIB object includes a reference to a main object of the request server and attributes specific to a set of equipment. The assembly server communicates with the request server via the common information management service (CMIS). In addition, the set server (SE) includes set (Union, Intersection and Mutual exclusion) and refresh (refresh) functions. In addition, the assembly server (SE) can periodically interrogate the request server (SR) to update its equipment lists (301, 302).

Thus, an assembly can be constituted or managed either according to the prior art in extension, by entering the references to the equipment, equipment by equipment, or according to the invention in understanding by the execution of a request which can relate to different sources of data (SD) made up by MIBs, files, relational databases, directories etc.

A second example of using the request server (SR) is carried out by a consistency check operation. The consistency check consists in verifying the conformity of equipment with respect to reference configurations. When <A ^ equipment does not conform, the consistency check (CC) can trigger a corrective action on this equipment. A reference configuration is made up of a set of variables and logical expressions on these variables which are all indicators making it possible to check the consistency of an item of equipment with the reference configuration. To be able to check the conformity of the equipment, the request server (SR) launches requests on various data sources (4, 5, 6, 7) to give values to the variables expressed in the reference configurations. These variables are also those described in the output objects. The requests are modeled in the form of three objects: a main object (OP, fig. 2) comprising the information making it possible to interrogate the source and subordinate input (OE) and output (OS) objects which will give us input parameters (PE) and result variables (VR instead of PS) of a query. The input objects and the output objects are linked to the main object by a name binding "name binding" in a relation of child object to parent object. And, from the moment the main object is defined in an information management database (MIB), it can be directly exploited through M-ACTION functions which are defined and exploited by the CMIS interface (for more details on the CMIS, CMIS-DB modules, we can refer to the two patent applications respectively entitled "server architecture to deliver an information management service and" method of optimizing information management for a database data (to be completed with deposit numbers).

The main object (OP) belongs to the object class "request" and includes the type of interrogation language of the data source, for example CMIS (FIG. 4A) and an attribute corresponding to it "request CMIS" which provides a reference to the CMIS request, for example, that referenced OSTYPE (Figure 4A), which must be executed by the request server. If the query language type is SQL (Structured Query Language), the corresponding attribute is access to the database and an expression of the query. If the type of query language is CMIS, the corresponding attribute is a reference to CMIS-Qùery. And finally, when the query language is script, the attribute corresponding to it is a reference to this script.

The output objects (OS) belong to the object class "requestResult" and define a list of result variables (VR). Each output object comprises an identifier "request Resuit Number", the name of a variable "request variable name" (FIG. 4B), and the type of said variable.

The input objects (OE, Figure 4C)) belong to the "requestParameter" object class and define a list of parameters (PE). Each input object has a "request Parameter Number" identifier, the name of a "request Variable Name" variable, the type of this variable "request Variable Type" and a default value "request Parameter Default". When using the request server (SR) to build sets (SE), the default value of the input parameter is taken into account if no value of the parameter is entered on the screen at the time of the definition of the whole. The only modification of the input objects makes it possible to modify the configuration of the request. We can also easily define two generalized queries referencing the same specialized query - for example CMIS - but having different input objects. In this way, it is possible to exploit the same specialized request in different contexts. Thus, modeling a request in the form of objects makes it possible not only to configure this request and retrieve result variables, but also to modify this setting dynamically through the ISM Graphic Monitor.

There are three types of use of the generalized query server. First, the user can select any request to constitute a domain or perform a consistency check. Secondly, the user can modify the configuration of already existing requests. For this, the user does not need to know precisely the SQL, CMIS, LDAP or script languages; it just needs to modify the values of the attributes of the three objects that model the query. Third, the query server can be extended to accommodate new data sources. Indeed, a network and systems administration platform must be able to work with several data sources which can be stored on different media. With the help of the request server, it is possible to support new storage tools to offer configurable CMIS access to applications or administration modules and this without the need to model in the form of objects (MIB) the data which we want to exploit.

FIG. 3A shows the dialog window of the assembly server. This window is divided into two parts (30, 35). In the lower part of this window (35), the actions applicable to the set of equipment are proposed. A field (356) allows the user to specify, for example, in minutes, the refresh period (refresh) of the equipment list. The refresh period corresponds to the period between two successive interrogations of the data sources. Just click on the application button "Apply" (353) in this window for the request server to recalculate these elements taking into account the modifications made. An "OK" button (352) closes this last window by saving the modifications made to an assembly. Another "Cancel" button (354) closes this window without taking into account the modifications made to the assembly. A "Elements" button (355) displays a window (260), represented in FIG. 3C, and comprising a list of elements of a set. Just click the "Refresh" button (261) in the window (260) to recalculate the elements. In addition, the lower part (35) of the dialog window of the sets server includes a button (combo-box) "Union / Intersection / Exclusion" (351) allowing to select the way in which one wants to combine sets and the query results. In the upper part of this window (30), various methods of constituting a set of equipment or list of equipment are proposed. In fact, there are three methods of constituting a set: by manually giving one by one all the elements of the set, via a query, or by combining existing sets.

To constitute an assembly manually, it suffices to click on the "List" button (31) in the window of FIG. 3A. A drop-down window (61), represented in FIG. 3B which makes it possible to enter the references of the equipment, appears. To constitute an assembly, the user must indicate the references of the equipment chosen in the window (61).

A more elegant way to constitute a set or a list of equipment is to use the drag and drop functions (drag and drop) of the ISM Monitor (ISM Monitor) on equipment modeled in the form of basic information management (MIB ). From the ISM monitor, it is possible to draw an icon representing a set of equipment. Then, to include a new element, just drag (drag) an icon representing an item of equipment and drop it (drop) in an overall icon.

If the user drags an icon of a server or a PC in an overall icon, the identifier of this server or this PC is calculated and added to the equipment list and can be viewed through the window of Figure 3A. To add several elements in a single operation, the user must select their icons on the monitor card and then use the Add selected objects function from the drop-down list in the menu. Thus, all the selected icons are automatically included in the list of equipment.

To constitute an assembly by combining lists of existing equipment, it suffices to press the "NEW" button (33) in the window shown in FIG. 3A. The window in Figure 6 appears. The user can then select a set from those proposed in the field (61), or type in the field (62) the name of another object (distinguished name). This object can be, for example, a remote ISM set viewed through a supra-management type link.

On the other hand, the user can use the drag and drop functions of the ISM monitor. In the same way as when manually creating a list of equipment, you must drag a first icon representing a set onto a second icon representing another set. The set that has been dragged will be referenced as a subset of the set in which it is thrown. To add several sets in a single operation, the user must select their icons in the monitor map, then use the function for adding the selected objects "Add selected objects" from the drop-down list in the general menu. All selected icons are included as subsets. The icons representing individual PCs and servers and the icons representing sets can be combined in the same selection. They will be treated according to their class. To constitute a set or a list of equipment via a request, the user can select a request from a drop-down list (32) (321) of existing requests.

When the user selects the edition of a set of equipment, the field (32) of the window in FIG. 3A offers a list of all the existing request instances. The prefix "PC-", respectively "UNIX-" indicates that the request concerns a machine of type PC, respectively a server of type UNIX.

When creating a new request, the user must firstly define the request by completing the window controls (331, FIG. 4A) and secondly, the input parameters (PE) of the request by calling the button (3312) the window (332, FIG. 4B) for defining the parameters.

The creation of a new request uses the graphical interface of the ISM monitor which allows the display of any object in the information management database. Window 371 is an example of displaying an object of the class "generalized query" and allows the attributes of this object to be edited. A first attribute (3313) makes it possible to introduce the identifier of the request; a second attribute (3314) allows the type of the request to be introduced in the example shown in FIG. 3B CMIS type request; a third attribute (3315) makes it possible to introduce a request script which, in the example presented, has no value; a fourth attribute (3316) makes it possible to specify whether it is an SQL query which, in the case of the example presented, has no value; a fifth attribute (3317) makes it possible to introduce the login of the SQL request which, in the represented case, has no value. A sixth attribute (3318) makes it possible to introduce the attribute "Request CMIS" which provides a reference to the request (CMIS) to be executed by the request server. In the example shown, the name of the query (CMIS) referenced is of type "OSTYPE".

A penultimate attribute (3319) makes it possible to specify the attribute "comments on the request" and provides an explanation of the request s _. executed. A final attribute (331) 8) makes it possible to specify the class of objects which, in the example shown, is "request".

Finally, the window comprises a first button (3312) which, when activated, makes it possible to trigger the appearance of a window making it possible to specify the input parameters and a second button (3302) which makes it possible to bring up a another window allowing to specify the output parameters, when this last button is activated.

The request window of FIG. 4A represents a request which makes it possible to constitute all of the UNIX equipments by interrogating the agents (MIB); the type of requests is "CMIS".

To fill in the various fields of the window (331), the user moves a pointer (33108) for activating the field which is represented, for example, by an arrow situated in the example opposite the sixth field (3318). The presence of the pointer opposite the field brings up a blinking cursor which indicates the activation of this field and the possibility of filling the corresponding window and of storing the information thus entered in the request server. Activation of the "query parameter" button (3312) makes it possible to display the window (332) of FIG. 4B, which includes a first field (3321) which makes it possible to indicate there the number of the query parameter, a second field (3322) which allows to indicate the name of the variable which will be passed to the request (in the example "type"), a third field (3323) which provides the syntax (in the example "string" ( string)), and a fourth field (3324) which allows you to specify a default value for the parameter (in this case in the AIX example). The window also includes a fifth field (3325) which makes it possible to indicate comments and a sixth field (3326), which indicates the class of the object, represented by the window (in this case "request Parameter").

The request server also includes a graphical interface which makes it possible to view the responses to requests in the form of windows as shown in FIG. 3C after having activated the button (3313) of the window corresponding to the object "generalized request" (class " request ").

The output object, represented by the window (333) in FIG. 4C, defines a result variable.

In the case represented in FIG. 4C, the output object includes an identifier which is also, in the case of a command language program (Shell-Script), the column number of the standard output (3331) .

A second attribute appears in a second field (3332) and consists of the variable name. A third field (3333) allows to display a third attribute which is the type of variable and a fourth field (3334) allows to display a comment, such as for example, "IP identifier", for the example request intended to constitute the set of UNIX equipment. Finally, a last field (3335) makes it possible to display the class of the object which, in the present case, is a variable - result of request ("request Resuit"). FIG. 4D represents the object of the class "generalized request"

(class "request") corresponding to a second example, in which the user seeks to constitute all the PC equipment for a certain type of operating system from an inventory base such as ORACLE. In this example, the generalized query has the identifier PC and the type of query is an SQL query, since it uses the ORACLE database using the SQL language. The SQL query and login attributes are documented. However, the attributes "CMIS requests" or "script requests" are not documented. There are two naming links allowing, thanks to the block (33101) to indicate the link with the input and output objects. For this example of use, the input object representing the parameter of the query specifies in the "default value" field the WINDOWS 3.11 operating system and in the "variable name" field the value "OS". This request makes it possible to obtain the list of PCs equipment for the operating system provided as input parameter of the request from the variable whose name is "OS". As can be understood, between FIGS. 4A to 4F, the modeling, in the form of MIB objects, of the requests and parameters as well as the possibility of editing these objects from windows, allows the user to reconfigure simply queries or create new ones.

FIG. 4F represents the window making it possible to model in the form of objects 4F (MIB) the assembly which exploits the request described above giving the set of UNIX equipment of a certain type and a certain version.

The window (3200) of FIG. 4F comprises a first field (3201) which makes it possible to store the value of the operator (attribute SetOperator), the attribute in the example being the union; a second field (3202) which makes it possible to give the reference to a generalized request (attribute setRequestPointer); a third field (3203) which makes it possible to give a list of parameters (attribute setParameter); a fourth field (3204) which gives the time of the last refresh; a fifth field (3205) makes it possible to fix the period of the automatic refresh; a sixth field (3206) which makes it possible to fix the status of the refreshment, in this case in progress; a seventh field (3207) which makes it possible to set the attribute for identifying the assembly and an eighth field (3208) which makes it possible to fix the class of the object, in this case object of type "set" (Set).

A second use of the request server according to the invention and of the associated interfaces is represented by FIGS. 5A to 5D. This example of use concerns the consistency check which is an operation consisting in verifying the conformity of the equipment with reference configurations described by objects. A reference configuration is made up of a set of variables and logical expressions on these variables which are all indicators allowing to check the coherence of an equipment. These indicators are calculated from different data sources which are sent by the request server. The consistency check is carried out device by device and the first parameter of the request is the name of the device. The first field (3313) is the name of the generalized query "TMP". The second field (3314) defines the type of requests, in this case a CMIS type request, the other fields not being documented. The sixth field (3318) defines the CMIS request, the seventh field (3319), the comments and a name link field (33101) "Name Binding" is documented with the information "requests".

As shown in FIG. 5B, this “generalized request” object is associated with an input object which defines a single input parameter which corresponds to the identifier of the equipment. With these two objects, there is associated an output object, represented in FIG. 5C, which admits a single output parameter, in this case the variable "size" (size) which gives the size of the TMP file system. This size is evaluated in kilobytes. Finally, a last object, represented by the window in FIG. 5D, makes it possible to define in a field (51), the reference value of the variable, in this case 10,000 kilobytes. ; in a field (52), the logical expression with which the variable will be combined; in a field (50), the variable combined in the logical expression defined by the object of the class defined in the last field "UCT Ref Config Variant". This indicator, defined by the object of FIG. 5D, makes it possible to detect the devices, where the space available for the TMP file system is less than 10,000 kilobytes.

Thus, one understands the interest of the invention which makes it possible, thanks to the generalized request server, associated with the representative object interface (MIB) making it possible to define the requests in the form of at least 3 objects, define a new query, or modify the parameters for executing the output of a query by functions for creating, deleting or simply updating objects that model the concept of generalized queries.

Other modifications within the reach of the skilled person are also part of the spirit of the invention.

Claims

1. Generalized request server (SR) characterized in that it makes it possible to interrogate, through requests, different data sources (SD) from a single configurable interface which can be activated by applications and modules 'administration, a request being modeled in an information management database (MIB).

2. Generalized request server according to claim 1, characterized in that a request is modeled in the form of a main object (OP) comprising the type of the source to be interrogated and at least one attribute specific to this type, and d subordinate input (OE) and output (OS) objects, said input objects (OE) modeling the request input parameters (PE), said output objects (OS) modeling the result variables ( VR).

3. Consistency check server, using the generalized request server according to claim 1, characterized in that it also comprises an indicator object making it possible to define, for the result variables of a generalized request, a logical expression constituting an indicator for consistency control.

4. Set server using the generalized request server according to claim 1, characterized in that it further comprises an object for defining a set which exploits a request defined according to claim

1 and which includes the definition of a parameter constituting a set operator in the case where the set is made up from the combination of sub-sets.

5. Ensemble server (SE) according to claim 4, characterized in that it makes it possible to constitute domains containing lists of equipment.

(301, 302).

6. Assembly server (SE) according to claim 5, characterized in that it stores equipment lists (301, 302), said assembly server (SE) being modeled in the form of objects of an information management database (MIB), the objects (MIB) pointing to a reference to the objects main (OP) of the request server and containing attributes specific to the sets.

7. Ensemble server according to claim 6, characterized in that the ensemble server (SE) includes set and refresh functions.

8. Generalized request server according to claim 1, characterized in that it is an object manager, interrogated by a common information management service (CMIS), said requests being executed using an operation M-ACTION.

9. Consistency check server, according to claims 3 to 8, characterized in that it makes it possible to execute a configuration action on a list of equipment (301, 302) defined in a domain.

10. Generalized request server according to claim 1, characterized in that the parameter (PE) contained in said input object (OE) comprises an identifier, the name of a variable which will be passed to the request, the syntax of said variable and a default value of the parameter.

11. Generalized request server according to claim 1, characterized in that the result variable (VR) defined in the output object (OS) comprises an identifier, the name of a variable, the type of said variable and comments.

12. Ensemble server according to claim 4, characterized in that the CMIS request server comprises an interface presenting at least one dialog window proposing different methods of constituting and / or modifying a list of equipment (301) , set functions, a refresh function for equipment lists that can periodically query data sources (SD), via the generalized query server.

13. Ensemble server according to claim 12, characterized in that a list of equipment is formed by manually typing on the keyboard of a computer, the reference of each equipment.

14. Generalized request server, according to claims 10 to 11, characterized in that the creation of a new request makes it possible to constitute a list of equipment (301), said creation being carried out by defining the input objects (OE) ) and output (OS).

15. Ensemble server according to claims 12 to 14, characterized in that a list of equipment (301) is constituted by the selection of a request from a list of existing requests.

16. Ensemble server, according to claims 12 to 15, characterized in that a list of equipment (301) is constituted by the combination of existing lists.

17. Ensemble server according to claims 12 to 16, characterized in that a list of equipment (301) is formed by selecting at least one equipment and / or a list of equipment modeled as a MIB object on a ISM monitor card and using the ISM monitor's drap and drop functions.