Method and apparatus for shared management information via a common repository

Abstract

A method and associated data constructs for sharing management information, stored in a common repository among multiple application programs. The present invention provides methods and structures for maintaining consistency and integrity of information shared among multiple application programs while allowing easier integration of management information relating to disparate aspects of enterprise management. Standard server programs are provided to serve client application programs by manipulating and retrieving information stored in the common repository. A meta-schema defines the structure of information stored in the common repository and permits extension of the information to incorporate data relevant to new application programs. In addition, tools are defined to permit developers to automate the creation of new server programs which manipulate and retrieve information stored in the common repository. The automatic generation of new server programs helps retain the consistency and integrity of management information achieved by application of the meta-schema structures.

Claims

What is claimed is:

1. A computer based data management system for managing information regarding objects, each object belonging to an object class and utilized by application programs; said data management system comprising:

memory means for storing said information;

a meta-schema for defining standard structures for storing said information managed by said system in said memory means, said information comprising attributes of said objects and relationships between said objects;

a plurality of integrated server programs for servicing requests received by said plurality of integrated server programs from said application programs to manipulate said information regarding objects stored in said memory means in accordance with the standard structures defined by said meta-scheme and in accordance with standard object class definitions; and

server program generation means, independent of the application programs, but cooperative with said meta-schema and standard object class definitions, for generating additional ones of said server programs and integrating said additional ones of said server programs with said plurality of integrated server programs so as to maintain information integrity within the memory means and reduce unintended duplication of information within the memory means.

2. The data management system of claim 1 wherein said server program generation means is responsive to said meta-schema to control the structure of server programs generated by said server program generation means.

3. The data management system of claim 1 further comprising:

database schema generation means for generating database schemas used by said server programs and by said application programs to manipulate information stored in said memory means.

4. The data management system of claim 3 wherein said database schema generation means is responsive to said meta-schema to control the structure of said database schemas generated by said database schema generation means.

5. A computer based data management method for managing information regarding objects, each belonging to an object class and utilized by application programs; said data management method comprising the steps of:

(a) providing a memory means for storing said information;

(b) providing a meta-schema;

(c) defining, according to the meta-schema, standard structures for storing said information managed by said method in said memory means, said information comprising attributes of said objects and relationships between said objects;

(d) providing an object model;

(e) defining, according to the object model, standard object classes of objects utilized by said application programs according to the structure defined by said meta-schema;

(f) providing a plurality of integrated server programs;

(g) operating said server programs to service application program requests to manipulate said information regarding objects stored in said memory means in accordance with the standard structures provided by said meta-schema and in accordance with the standard object class definitions;

(h) generating additional ones of said server programs, independently of the application programs, but cooperatively with said meta-schema and with said standard object class definitions; and

(i) integrating said additional ones of said server programs with said plurality of integrated server programs so as to maintain information integrity within the memory means and reduce unintended duplication of information within the memory means.

6. The data management method of claim 5 wherein the server program generation step is responsive to said meta-schema to control the structure of server programs generated by said server program generation means.

7. The data management method of claim 5 further comprising the step of:

generating database schemas used by said server programs and by said application programs to manipulate information stored in said memory means.

8. The data management method of claim 7 wherein the database schema generation step is responsive to said meta-schema to control the structure of the generated database schemas.

9. In a computer based environment comprising multiple application programs needing access to information stored in a common repository, access to the common repository being provided via a database management system, apparatus for ensuring that information in the common repository is stored and manipulated in a consistent manner, thereby facilitating improved data integrity and improved sharing of information between the multiple application programs, comprising:

a) a meta-schema defining rules and constructs pertaining to storage and manipulation of information stored in the common repository;

b) a plurality of integrated server programs through which all of the multiple application programs gain access to the database management system, each server program providing access, via the database management system, to a particular managed aspect of information stored in the common repository, each server program adhering to the rules and constructs of the meta-schema;

c) means for generating:

i) additional server programs, said additional server programs being integrated with the plurality of integrated server programs, said additional server programs providing access, via the database management system, to additional managed aspects of information stored in the common repository, and said additional server programs adhering to the rules and constructs of the meta-schema:

ii) DBMS schemas, said DBMS schemas adhering to the rules and constructs of the meta-schema; and

iii) code segments, adhering to the rules and constructs of the meta-schema, which can be incorporated into one or more application programs which require access, via the additional server programs and the database management system, to the additional managed aspects of information stored in the common repository; and

d) means for incorporating the DBMS schemas into DBMS tables of the database management system.

10. Apparatus for developing new server programs when it is determined that an application program requires storage or manipulation of information in a common repository which is not supported by standard server programs, comprising:

a) a server generation tool having an input for accepting a preliminary object class definition of information to be manipulated by an application program; an input for accepting a meta-schema; and outputs for generating, in response to its inputs, database (DBMS) schemas for the information to be manipulated; an IDL which adheres to the constructs and rules defined by the meta-schema; and first source code segments for a server program to perform basic manipulations of objects defined by the preliminary object class definition;

b) an IDL compiler having an input for accepting the IDL; and an output for generating second source code segments for a server program to perform basic manipulations of objects defined by the preliminary object class definition; and

c) a build server process which compiles the first and second source code segments for a server program to create an executable server program.

11. Apparatus as in claim 10, wherein the preliminary IDL object class definition is compiled by the IDL compiler to generate source code segments to be integrated into an application program to access the executable server program.

12. Apparatus as in claim 10, wherein the first and second source code segments for a server program only provide for creating, destroying, updating and retrieving information.

13. In a system wherein application programs access information stored in a common repository via defined, integrated server programs, a method of providing an application program with access to information in the common repository which is not supported by the defined server programs, the method comprising the steps of:

a) generating an IDL, a skeleton server, and DBMS schemas in response to a preliminary object class IDL and standards defined by a meta-schema;

compiling the IDL;

c) generating an executable server from the compiled IDL and the skeleton server;

d) creating a DBMS from the DBMS schemas; and

e) providing, via the executable server, access to the information in the common repository which is not supported by the defined server programs.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of enterprise management systems and in particular to a computer based, object oriented common repository for the storage of information managed by enterprise management servers on behalf of application program clients.

2. Description of the Related Art

Management systems utilized in an enterprise frequently apply computing systems to automate aspects of the enterprise management. Enterprise management, as used herein, relates to the management of any objects used by the enterprise, and the various attributes of, and associations between, the objects. Enterprise management encompasses many different aspects of objects within an enterprise. Enterprise management application programs in the past have managed a specific aspect of the entire enterprise management task. For example, some applications are concerned with topological information regarding objects in the enterprise (also referred to as relationship information). Another typical application program is concerned with attribute information regarding objects in the enterprise. An inventory control program is exemplary of an application program concerned with attributes (inventory count) of managed objects. Other application programs are concerned with trend information regarding objects in the enterprise. Yet other application programs manage events and historical attribute information regarding objects in the enterprise.

It is desirable that the information managed by a management application program be:

available--open to other applications and end users

consistent--the structure of managed information is well known and easy to manipulate

accurate--has integrity, is accurate, and is meaningful

In prior designs it is common to achieve the latter two goals above, namely consistency and accuracy, by sacrificing, in part, the availability of the information. Restricting the use of the stored information by other application programs or by end users helps assure the accuracy and consistency of the information managed by a particular application program. It is common in prior designs that each application program creates and manages its own data structures for representing, storing, and retrieving the information manipulated by the application program (typically with the aid of database management subsystems). Each specific application program is therefore independent of all other application programs.

A first problem with the design of independent application programs for each management task arises in the wasted, often redundant, effort to create each management application program. In the prior designs, it would be required that independent development groups, possibly representing independent vendors, agree to integrate their respective application programs at some early point in their design phase. Even if such cooperation were common in competing vendor relations, the time schedules associated with development efforts of different vendors may not overlap sufficiently to permit effective cooperation between the respective development groups.

Similar application integration problems may arise even where independent application programs are developed by a single group. Frequently the various management application programs are developed over a span of time. Each application program tends to develop its own unique structures and methods for representing the managed objects. This redundant development effort may increase the complexity and related costs for development of such management application programs.

Therefore, second problem with the design of disparate management application programs arises in the difficulty of integrating the information managed by potentially several independent application programs. In view of independent development efforts such as described above, the variety of independently developed structures and methods for representing managed objects tends to lead toward incompatible designs which may be difficult to integrate. The isolated management application program, such as described above and common in prior designs, is adequate for a manager or management task isolated from other management issues. However, when an operator or manager requires the integration of information from several different aspects of the enterprise, the isolated, disparate application programs, typical in prior designs, are incapable of providing an integrated view of the objects stored in their respective databases. The integration of information often becomes a manual process left to the mangers using the applications. The disparate application programs cannot easily integrate the information managed by other application programs.

A third problem with the use of disparate systems for different management tasks utilizing common elements of information arises in the inevitable duplication of stored information and resulting loss of data integrity. Since each of the disparate management tasks typically is associated with its own unique format and structure for storage of information, it is common that similar information is duplicated in the information storage of several management application. For example, one management application may require information regarding an employee with respect to payroll issues, while another application may store information regarding the same employee useful to business travel planning. Both management applications may need access to common information such as office mail stop and phone extension, etc. Both disparate management applications may therefore store this common information for use in different operations (i.e. payroll deposits or travel scheduling).

This duplication of stored information increases the aggregate storage capacity needs of the enterprise. More importantly, when such common information is modified, (i.e. the employee moves to a new office mail stop), the information may be updated in one application but not another. Such potential inconsistencies in information managed by enterprise management applications creates problems for information managers. Each disparate management application must take responsibility for updating its own stored version of all common elements of information. As discussed above, each independent application program attempts to assure accuracy and integrity of managed information by limiting the accessibility of the managed information to other applications. The disparate application programs attempt to maintain the data integrity of their private copies of common data by restricting any possibility for access by other application programs. However, when viewed more broadly as an enterprise wide collection of managed information, the above described inconsistencies between duplicate copies of related data reduces the overall integrity of the enterprise store of information.

An enterprise could attempt to initially integrate all possible enterprise information management subsystems early in their design phases to avoid such information duplication problems. Such planning could produce a totally integrated, enterprise wide, information storage base which can avoid unnecessary duplication of stored data. Clearly, regardless of the degree of planning applied to the initial design of an integrated management information storage base, the need for new management information applications will arise. Such new applications will require significant re-design of the initially integrated information base. This requires significant efforts to re-design the information storage base. The re-design effort frequently requires the resources of a centralized management information technology group coordinating the required changes to maintain the desired information integration. Such centralized integration control based and human re-design intervention is inconsistent with the evolving de-centralization of data processing resources within an enterprise.

From the above discussion it can be seen that there exists a need for improved information storage and retrieval methods for enterprise management application programs.

SUMMARY OF THE INVENTION

The present invention solves the above identified problems to thereby advance the art by providing for a common repository of information which is shared by management information system application programs. The methods and data constructs of the present invention present an application programming interface (hereinafter referred to as API) used by application program developers to provide a common structure for stored information and to reduce duplication of information utilized by multiple application programs.

The methods and data constructs of the present invention store information in such a manner as to permit reuse and sharing of information among several application programs. A portion of the data constructs manipulated by the methods of the present invention stores an object identifier which uniquely identifies an object provided to the methods of the present invention. The objects so identified are initially provided to the present invention by application programs using the shared common repository. Other information stored with the object identifier serves to provide common information in a predefined structure which is known to and usable by other application programs.

A server program is associated with each usage of the information stored in the common repository. The server programs provide an API standard for application programs to utilize the shared data in the common repository. For example, the topology management service (also referred to as a relationship management service), disclosed in co-pending U.S. patent application Ser. No. HPDN 1094626, provides management information relating to topological associations (also referred to herein as "associations") among stored objects. Other standard servers are defined to provide object attribute information (such as inventory data), trend and event related information, as well as historical attribute information. The use of a server program API for each managed aspect of objects stored in the common repository improves data integrity by enforcing rules, embedded within the server, which define legal operations on the objects managed by the server.

Methods and structure within the scope of the present invention also provide tools to aid in the development of new server programs. A meta-schema is used to define rules for creating new databases stored within the common repository. Other methods utilize the meta-schema in conjunction with developer directions to generate server program source code. The program generator feature of the present invention creates a functional server which is integrated with other defined servers through the rules of the meta-schema to permit simpler sharing of information. Application programs may then be designed by the developer to utilize the API interface for each server to manipulate information stored in the common repository. The collection of server programs, integrated by the common definition of the meta-schema used in creating the servers, permits application programs to easily integrate information managed by several server programs.

The storage of all information in the common repository, managed by the integrated server programs, also permits reduction of duplicated information stored in common repository. Since all information for the enterprise management is in a single repository, methods of the present invention can enforce rules which reduce the unintended duplication of information.

The present invention manages the common repository utilizing a standard API independent of the specific database management engine (also referred to herein as database management means) which manages the physical storage of the information on storage media. The structure and methods of the present invention are built upon open standard database APIs (also referred to herein as database management interface means) such as Microsoft.RTM. ODBC or X/Open.RTM. DATA MANAGEMENT: SQL CALL LEVEL INTERFACE (X/Open.RTM. Preliminary Specification P303 ISBN 1-85912-015-6--was previously publication S203--will become publication C451 available from X/Open Company Ltd, Berks, United Kingdom). These standards permit the server programs of the present invention to utilize any underlying database engine which conforms to these standards for the permanent physical storage of the managed information. End user installations using the present invention may therefore utilize any presently installed database management subsystem

Numerous other features, objects and advantages of the present invention will become apparent from the following description when read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a general purpose data processing system which may embody the structures and methods of the present invention;

FIG. 2 shows an overview of the structure of application programs, typical of prior designs, each of which manages its own information structure as a private database;

FIG. 3 shows an overview of the structure of application programs structured so as to share information managed by server programs and stored in a common repository in accord with the structure and methods of the present invention;

FIG. 4 depicts the class inheritance structure of exemplary common class definitions which reflect physical attributes of an object managed in the common repository of FIG. 3;

FIG. 5 depicts the class inheritance structure of exemplary common class definitions which reflect logical attributes of an object managed in the common repository of FIG. 3;

FIG. 6 shows the structure of tables for storing relationships between managed objects in accord with the meta-schema of the common repository of FIG. 3;

FIG. 7 shows the structure of tables for storing class definitions of managed objects in accord with the meta-schema of the common repository of FIG. 3;

FIG. 8 shows the structure of tables for storing object instance specific attribute information for managed objects in accord with the meta-schema of the common repository of FIG. 3;

FIG. 9 shows the structure of tables for storing object trend analysis information for managed objects in accord with the meta-schema of the common repository of FIG. 3; and

FIG. 10 shows the general flow of information in operation of the server program generation tool of the present invention for creating new server programs to manipulate objects stored in the common repository of FIG. 3.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention comprises an application program interface (API) for server programs which manage objects in a common repository on behalf of client application programs. In addition, the present invention comprises a meta-schema which defines standard data constructs and associated tools for automating the construction of server programs to manage new aspects of objects in the common repository.

FIG. 2 provides an overview of typical methods applied by prior designs for enterprise management. Each distinct enterprise management task is designed with a customized application program. Each application program typically had its own database providing information and associated structure as appropriate to the specific application. As shown in FIG. 2, four disparate application programs 200, 202, 204, and 206 are designed to manage various aspects of an enterprise. Each application is shown to interact with its own database structures 208 through 218. SNMP TRAPS 200 is an application program which, for example, manages event related information by logging Simple Network Management Protocal(SNMP) information received from systems on a network in the TRAPD.LOG database structure 208. APPLICATION B 206 is an application program which, for example, manages the associations between objects. As is common in prior designs, the information representing the objects is stored in database 216 while the topological associations are stored separately in database structure 218. As is shown in FIG. 2, only limited sharing of information is possible in prior design due to the independence of the database storage associated with each application program. Application programs 202 and 204 are shown to be sharing the NETWORK DB database 212. Such sharing may occur when multiple application programs are designed by a single vendor or by multiple vendors closely cooperating as discussed above.

FIG. 3 shows application programs 300-306 similar to those of FIG. 2 interfaced through server programs 308-314 of the present invention to the common repository 316 of the present invention. In this architecture, all information representing associations between objects is stored in the common repository 316 according to standards defined by the meta-schema. The manipulation of the common repository 316 is performed by standard server programs 308-314. As discussed above, server programs 308-314 are each constructed according to standards including the meta-schema which defines all supported associations between objects in the common repository 316.

FIG. 1 shows a block diagram of the computer hardware that contains the enterprise management services system of the present invention. In FIG. 1, a computer system 100 contains a processing element 102 which communicates to other elements within the computer system 100 over a system bus 104. A keyboard 106 is used to input information from a user of the system, and a display 108 is used to output information to the user. A network interface 112 is used to interface the computer system 100 to a network 118 to allow the computer system 100 to act as a node on a network and to thereby communicate with other nodes on the network. A disk 114 is used to store the software of the enterprise management system of the present invention and to store the information which comprises the common repository 316. A printer 116 can be used to provide a hard copy output of the information managed by the present invention.

A main memory 110 within computer system 100 contains the enterprise management system 120 of the present invention. An application program 126, developed by a user of the present invention communicates with the enterprise management system 120, both of which, in turn, communicate with an operating system 122 and storage management software 124 to perform the enterprise management services on behalf of client application programs. The present invention comprises methods and structures which define the interactions between the application program 126, the enterprise management system 120, and the storage management software 124 to store and manipulate information in a consistent manner to facilitate improved data integrity and improved sharing of information between multiple application programs. Other methods of the present invention aid in the automated generation of application programs 126, server programs within the enterprise management system 120, and database management subsystem (DBMS) schemas to define the structure of information manipulated by the storage management software 124.

The client application programs 126 may operate locally, within computer system 100 or may operate on other computer systems attached to, and communicating over, network 118. It will also be recognized by those of ordinary skill in the art that the information stored in the enterprise common repository 316 may be stored locally on disk 114, or may be stored locally in main memory 110, or may be distributed over other computer systems accessible via network 118, or in any combination of storage devices. More generally, the information stored in the common repository 316 may be stored in any memory device or memory means having suitable capacity and performance characteristics. For example, disk 114 may also be implemented as a collection of memory devices distributed over a plurality of computing systems 100 attached via network 118.

COMMON CLASSES

The present invention includes standard object class definitions called common classes (also referred to herein as object models and object model means) which are utilized by the methods of the present invention. The present invention includes several common class (object model) definitions for many types of objects which are supported in typical enterprise management application programs. The common class definitions are used in two ways by application program developers. First, the common class definition may be used by application programs in conjunction with server programs (discussed below) which manipulate information relating to that class of objects. Second, a server program may define specialized subclasses of the common class object definitions to define special objects to be managed by the server programs and stored in the common repository 316. Such specializations of common classes may provide added detail required by a particular management application program.

Enforcing the common class, or common class subclass definitions on objects stored in the common repository 316 and managed by server programs helps assure that all data stored in the common repository 316 has a consistent organization and that otherwise diverse pieces of data are relatable by an application program. These common classes are interface specifications for object classes which are deemed to be useful to a broad array of application program and server program developers. These specifications encapsulate data which is common to various enterprise management tasks. From these specifications, program developers will implement subclasses which can be used as a basis for more specific classes of objects to be managed in a particular management application. Conversely, application program developers can design application programs which utilize the more general interfaces defined by the common class.

FIGS. 4 and 5 depict object class types which are typical of common class definitions for object types whose topological associations are to be managed by a topology server manipulating information in the common repository 316. A topology server is discussed in co-pending U.S. patent application Ser. No. HPDN 1,094,626. The same objects may also be managed by other server programs of the present invention to manipulate the objects on behalf of other application programs.

An object type definition in FIGS. 4 and 5 is indicated by a box labelled with the object type name. If a first object is a specialization of a second object class type, an arrow is directed from the first object type box to the second to indicate it inheritance of the more general object type attributes.

In FIGS. 4 and 5, a general object type labelled OBJECT CLASS 400 is shown. OBJECT CLASS 400 is the most general object type definition for objects which are managed by server programs of the present invention. Examples of several specializations of OBJECT CLASS 400 are shown in FIGS. 4 and 5 which are useful to computing and network management application programs which may in turn utilize the service of the topology (relationship) server program of the present invention.

Object types in FIG. 4 are typical of specialized objects which represent physical aspects of objects to be managed by an asset/inventory management application program. PORT 402, SLOT 404, CARD 406, BACKPLANE 408, and CHASSIS 410 are examples of specialized object types, derived from OBJECT CLASS 400, which are useful to application programs designed for management of network and computing resources. Other exemplary object types 412-428 of FIG. 4 are useful for application programs which manage other topological associations among objects or attributes thereof. Object types TERMINATOR 420, CONNECTOR 422, and MEDIUM 424 are specializations of the object type MEDIA HARDWARE 418. These specialization object types are defined for the specific needs of one or more application programs which require specific knowledge of different types of MEDIA HARDWARE 418 objects. Similarly, object types CABLE 426 and OPTICAL LINK 428 are specializations of the MEDIUM 424 object type to provide further detail as to objects which identify different types of interconnection media.

Object types depicted in FIG. 5 are further examples of specialized objects useful in a hypothetical enterprise management application program. The object types of FIG. 5 represent logical characteristics of objects manipulated by a server program on behalf of a management application program. USER 502, INTERFACE 504, and NETWORK PROTOCOL 506 object types, as well as object types 508-558 of FIG. 5, are examples of object types managed by a server program on behalf of a hypothetical enterprise management application program.

The object type depicted in FIGS. 4 and 5 are not intended to limit the object types definable as common class objects. Rather, the object types of FIGS. 4 and 5 are intended only as examples means to suggest the types of objects which may be usefully managed by one exemplary server program of the present invention, a topology server.

META-SCHEMA

The types of objects managed as defined by the common classes (and specializations thereof) and the types of managed information associated with managed objects is defined by the meta-schema of the present invention. The purpose of the meta-schema is to define standard structure for the storage of management information in the common repository 316 of the present invention. In addition, the meta-schema provides a framework for the standard semantic interpretation of the management information associated with managed objects managed by the server programs of the present invention.

The purpose of the meta-schema is to define standard structure for the storage of information associated with managed objects in the common repository 316. This standardized structure permits improved integration of otherwise disparate management application programs by assuring that similar information is stored in similar ways.

Management data which is shared by disparate application programs through the standard structure and semantics of the meta-schema includes:

Topology--information which describes associations between managed objects,

Attribute--basic information about a managed object which describes attributes of the object which are of interest to one or more application programs,

Historical and trend--information used by application programs which is used to record historical changes in the managed object and to detect trends in parameters associated with the managed object, and

Notification--information which relates to events of relevance to multiple objects and multiple application programs.

The meta-schema defines standard structures for storing this information and associating the information with a managed object. The meta-schema comprises a number of database schema definitions for tables which store the above types of management data. Fields in each of the tables defined by the schemas are associated with an atomic data type including:

Numeric--including integer, fixed point decimal, and floating point numbers represented in various levels of precision,

Boolean--indicating TRUE or FALSE

Date--indicating a date in an implementation dependent format,

Timestamp--indicating elapsed time in seconds since Jan. 1, 1970,

Enumerated--indicating one of a finite set of mutually exclusive values (often represented as an integer with a limited range of legal values),

Character--representing a fixed length string of bytes,

Varchar--representing a variable length string of bytes, and

UUID--a value which is generated as a universally unique ID.

Using these atomic data types, the standard representation of management information may be defined as database schemas.

TOPOLOGY SCHEMAS

A topology is a collection of specific topological associations among a selected set of managed objects. These topological associations are managed by a topology service program. The topological associations reveal how objects are related to one another. For example, which managed objects contain other managed objects and how managed objects are connected to one another. The topology service, strictly speaking, does not contain the managed objects themselves. Rather, the topology is the information which describes the associations between the managed topological objects and merely refers to the managed objects indirectly.

The topology schemas achieve the following goals:

1. The ability to represent any collection of manageable objects, regardless as to whether physical or logical in nature (as discussed above with reference to FIGS. 4 and 5), and regardless of the actual objects and topologies represented (i.e. networks, systems, services, etc.).

2. Allow for the representation of completely arbitrary collections of objects (i.e. wherein the criteria by which a set of objects are associated with another set cannot necessarily be deduced from the object attributes stored and managed in the common repository 316).

3. Allow for objects to simultaneously belong to multiple, possibly independent, sets of topological associations.

4. Allow for multiple types of topological associations between managed objects, including, for example: containment, connectivity, and dependency.

A common service in enterprise management is the management of topological information. As used herein, topological information relates to the relationships between managed objects. Such topological information is often presented in a graphical form to reflect hierarchical and other associations between managed objects. In modeling associations among objects as described herein, the topological aspects of the objects are referred to as resources or resource aspects. The relationships among the resources are referred to as associations. The common repository database schemas of the present invention define the standard structure of topological information managed by server programs of the present invention. FIG. 6 depicts how the tables defined by the topology schemas are organized.

RATYPE table

An RATYPE table 600 of FIG. 6 contains the name of each defined resource aspect type. Entries in other tables are keyed to this type name and thereby associated with the particular defined resource aspect type.

Each entry in an RATYPE table 600 contains a type.sub.-- name attribute 602 which uniquely identifies the resource aspect type in the common repository 316. The attributes of the containment table 620 are defined as follows:

    ______________________________________
    Attribute name
              Description        Type    Index
    ______________________________________
    type.sub.-- name
              field which identifies a particular
                                 Varchar Key
              resource aspect type
    ______________________________________

    ______________________________________
    Attribute name
             Description         Type    Index
    ______________________________________
    type.sub.-- name
             field identifying the resource aspect
                                 Varchar Key
             type of the resource aspect
    ra.sub.-- id
             object identifier of the managed
                                 UUID    Key
             resource aspect
    ______________________________________

    ______________________________________
    Attribute name
              Description        Type    Index
    ______________________________________
    ra.sub.-- id
              object identifier of the managed
                                 UUID    Key
              resource aspect
    aspect.sub.-- name
              user supplied identifier for the
                                 Varchar Key
              resource aspect
    ______________________________________

    ______________________________________
    Attribute name
               Description       Type    Index
    ______________________________________
    type.sub.-- name
               field identifying the resource
                                 Varchar Key
               aspect type of the inheritance
               entry
    type.sub.-- name.sub.-- parent
               field identifying the resource
                                 Varchar Key
               aspect type of the parent of
               the resource aspect type of
               the inheritance record
    ______________________________________

    ______________________________________
    Attribute name
               Description       Type     Index
    ______________________________________
    type.sub.-- name
               field identifying the resource
                                 Varchar  Key
               aspect type of the association
               rule
    role       entry identifier for the role
                                 Varchar  Key
               which the identified resource
               aspect fulfills in forming
               the defined association
    min        minimum number of Numeric
               associations the identified
               resource aspect type
               must form according to
               this rule
    max        maximum number of Numeric
               associations the identified
               resource aspect type may
               form according to this rule
    assoc.sub.-- type.sub.-- name
               field identifying the resource
                                 Varchar  Key
               aspect type of the resource
               aspect type with which the
               defined association must be
               formed
    ______________________________________

    ______________________________________
    Attribute name
             Description          Type    Index
    ______________________________________
    ra.sub.-- id.sub.-- 1
             object identifier of the first managed
                                  UUID    Key
             resource aspect participating in the
             association
    role.sub.-- 1
             identifier for the role which the first
                                  Varchar Key
             identified resource aspect fulfills in the
             defined association
    ra.sub.-- id.sub.-- 2
             object identifier of the second managed
                                  UUID    Key
             resource aspect participating in the
             association
    role.sub.-- 2
             identifier for the role which the second
                                  Varchar Key
             identified resource aspect fulfills in the
             defined association
    ______________________________________

    ______________________________________
    Attribute name
              Description         Type    Index
    ______________________________________
    type.sub.-- name
              field identifying the resource aspect
                                  Varchar Key
              type of the resource aspect
    type.sub.-- enforcer.sub.-- id
              user supplied identifier for the
                                  UUID    Key
              enforcer object
    ______________________________________

    ______________________________________
    Attribute name
              Description        Type    Index
    ______________________________________
    ra.sub.-- id
              object identifier of the managed
                                 UUID    Key
              resource aspect
    ra.sub.-- enforcer.sub.-- id
              user supplied identifier for the
                                 UUID    Key
              enforcer object
    ______________________________________

    ______________________________________
    Attribute name
                Description     Type      Index
    ______________________________________
    class.sub.-- name
                textual name of the class
                                Varchar   Key
    creation.sub.-- time
                date that the class was
                                Date
                created
    specification.sub.-- type
                type of the     Enumerated
                specification tool used to
                define the class
    metadata.sub.-- provider
                name of entity which
                                Varchar
                defined the class
    metadata.sub.-- key.sub.-- table
                name of class-to-
                                Varchar
                metadata-key table for this
                class name and
                metadata.sub.-- provider
                combination
    ______________________________________

    ______________________________________
    Attribute name
              Description        Type     Index
    ______________________________________
    class.sub.-- name
              textual name of the class
                                 Varchar  Key
    subtable.sub.-- no
              a sequential count of subtable, the
                                 Numeric
              first is set to 1
    page.sub.-- no
              page number for attribute sets
                                 Numeric  Key
              which exceed per-entry length,
              initially set to 0 for new
              subtable, incremented for each
              additional page of a subtable
    parent.sub.-- attribute
              if subtable.sub.-- no >1,
                                 Varchar
              this identifies the parent
              attribute containing the SET OF,
              SEQUENCE OF or Table of
              attributes
    instance.sub.-- table
              name of the table containing the
                                 Varchar
              attribute values for this
              subtable attribute set
    history.sub.-- table
              name of the history table of
                                 Varchar
              attribute values, if any,
              corresponding to the subtable
              attribute set
    ______________________________________

    ______________________________________
    Attribute name
               Description      Type      Index
    ______________________________________
    class.sub.-- name
               textual name of the class
                                Varchar   Key
    retention.sub.-- threshold
               Age beyond which entry may
                                Timestamp
               be purged
    snapshot.sub.-- interval
               minimum time interval
                                Numeric
               between creation of new
               entries
    ______________________________________

    ______________________________________
    Attribute name
               Description        Type    Index
    ______________________________________
    class.sub.-- name
               textual name of the class
                                  Varchar Key
    encode.sub.-- data.sub.-- table
               name of table containing encoded
                                  Varchar
               data
    encode.sub.-- history.sub.--
               name of table containing encoded
                                  Varchar
    table      history
    ______________________________________

    ______________________________________
    Attribute name
             Description         Type    Index
    ______________________________________
    class.sub.-- name
             textual name of the class
                                 Varchar Key
    metadata.sub.-- key
             key to access provider of metadata
    other attributes
             other provider specific attributes
    ______________________________________

    ______________________________________
    Attribute name
               Description      Type      Index
    ______________________________________
    oid        object identifier of the object
                                UUID      Key
    class.sub.-- name
               instance textual name of the
                                Varchar   Key
               class
    creation.sub.-- time
               time at which the object
                                Date
               instance was created
    modification.sub.-- time
               time of last modification
                                Timestamp
               of the object instance
    ______________________________________

    ______________________________________
    Attribute name
             Description          Type    Index
    ______________________________________
    oid      object identifier of the object instance
                                  UUID    Key
    other attributes
             other attributes specific to the object
             instance
    ______________________________________

    ______________________________________
    Attribute name
             Description          Type    Index
    ______________________________________
    oid      object identifier of the object instance
                                  UUID    Key
    date     date at which object instance had the
                                  Date    Key
             following attribute values
    other attributes
             other attributes specific to the object
             instance
    ______________________________________

    ______________________________________
    Attribute name
             Description         Type     Index
    ______________________________________
    oid      object identifier of the object instance
                                 UUID     Key
    segment.sub.-- no
             segment number of this portion of the
                                 Numeric  Key
             encoded.sub.-- value if its total length
             exceeds one entry's maximum length
    encoded.sub.-- value
             other attributes specific to the object
             instance in an encoded form
    ______________________________________

    ______________________________________
    Attribute name
             Description         Type     Index
    ______________________________________
    oid      object identifier of the object instance
                                 UUID     Key
    date     the date at which this object had these
                                 Date     Key
             encoded attribute values
    segment.sub.-- no
             segment number of this portion of the
                                 Numeric  Key
             encoded.sub.-- value if its total length
             exceeds one entry's maximum length
    encoded.sub.-- value
             other attributes specific to the object
             instance in an encoded form
    ______________________________________

    ______________________________________
    Attribute name
              Description        Type     Index
    ______________________________________
    descript.sub.-- id
              a unique identifier for this trend
                                 Numeric  Key
              variable
    . . . attributes . . .
              other attributes specific to the
              measured variable
    ______________________________________

    ______________________________________
    Attribute name
              Description        Type     Index
    ______________________________________
    oid       identifier of the managed object to
                                 UUID     Key
              be monitored
    descript.sub.-- id
              identifier for the trend variable
                                 Numeric  Key
              to be monitored
    other.sub.-- attributes
              other attributes unique to the
              specific variable or object
              being monitored
    dataset.sub.-- id
              a unique identifier of the dataset
                                 Numeric
              tables in which to collect trend data
    ______________________________________

    ______________________________________
    Attribute name
             Description        Type      Index
    ______________________________________
    dataset.sub.-- id
             identifier of this dataset
                                Numeric   Key
    sample.sub.-- time
             time at which this measurement
                                Timestamp Key
             ended
    period   length of time period of this
                                Numeric
             measurement
    value    value of this measurement
                                Numeric
    ______________________________________

    ______________________________________
    Attribute name
             Description        Type      Index
    ______________________________________
    dataset.sub.-- id
             identifier of this dataset
                                Numeric   Key
    sample.sub.-- time
             time at which this measurement
                                Timestamp Key
             ended
    period   length of time period of this
                                Numeric
             measurement
    min.sub.-- value
             minimum value of this measure-
                                Numeric
             ment over the specified period
    max.sub.-- value
             maximum value of this measure-
                                Numeric
             ment over the specified period
    avg.sub.-- value
             average value of this measure-
                                Numeric
             ment over the specified period
    ______________________________________

    ______________________________________
    Attribute name
             Description         Type     Index
    ______________________________________
    descript.sub.-- id
             a unique identifier for this trend
                                 Numeric  Key
             variable
    mib.sub.-- oid
             SNMP MIB variable object identifier
                                 Varchar  Key
    units    units of measure of the monitored
                                 Varchar
             variable
    title    title for this SNMP MIB variable
                                 Varchar
    descript description for this SNMP MIB
                                 Varchar
             variable
    ______________________________________

    ______________________________________
    Attribute name
             Description         Type     Index
    ______________________________________
    oid      identifier of the managed object to be
                                 UUID     Key
             monitored
    descript.sub.-- id
             identifier for the trend variable to be
                                 Numeric  Key
             monitored
    instance the instance of the SNMP MIB object
                                 Numeric  Key
             id
    dataset.sub.-- id
             a unique identifier of the dataset
                                 Numeric
             tables in which to collect trend data
    ______________________________________

• Inventors
  Potterveld, Robert A.; Bartz, Thomas G.;
• Assignee
  Hewlett-Packard Company (Palo Alto, CA)
• Published
  Jul-28-1998
• Current US Classes:
  707/100
  707/103R
  707/104.1
• Application #
  741152
• International Classes
  G06F 017/30
• Field of Search
  395/601-9 395/614 707/103
• Examiner
  Black; Thomas G.
• US Patent References:
  5295256
  5307484
  5550971
  5596745
  5659735