Method and apparatus for providing topology based enterprise management services

Abstract

A method and system with associated data structures for providing management of topological associations between objects. The methods define an application programs interface (API) which specifies a consistent approach for the design of application programs to manage topological associations between objects. Objects each represent an aspect of a resource which is useful to a particular application program. Application programs define a resource aspect type for each object to be managed by the API. Objects are specified to the API by application programs along with resource names to identify a resource. The methods and structures of the present invention automatically recognize when the resource names of an object to be managed identify the same resource as other managed objects to thereby allow information to be more readily shared among disparate application programs and to reduce redundant storage of information by those programs.

Claims

What is claimed is:

1. A computer based method for managing topological associations among objects, comprising:

a) storing a number of objects in an information base, each of the number of objects possessing a number of resource names; and

b) determining one or more resource name closure sets encompassing the number of objects stored in the information base, each of the one or more resource name closure sets comprising a largest subset of the number of objects stored in the information base such that each object of the largest subset shares a resource name with at least one other object of the largest subset, wherein the objects of each resource name closure set define a resource, and the resource names of said objects uniquely identify said resource.

2. A computer based method as in claim 1, further comprising:

a) receiving a request to manage a new object, the new object possessing a number of resource names; and

b) determining whether the new object possesses one or more resource names which uniquely identify one or more known resources; and

i) if not, defining a new resource by a resource name closure set comprising the new object, said new resource being uniquely identified by the number of resource names possessed by the new object;

ii) if so, and only one known resource is identified, adding the new object to the resource name closure set of the one known resource, said known resource now being uniquely identified by the number of resource names possessed by the new object and each of the objects in the resource name closure set of the identified known resource; and

iii) if so, and more than one known resource is identified,

A) defining a new resource by a resource name closure set comprising the new object and each of the objects in the resource name closure sets of the identified known resources, said new resource being uniquely identified by the number of resource names possessed by the new object and each of the objects in the resource name closure sets of the identified known resources; and

B) deleting the resource name closure sets of the identified known resources.

3. A computer based method as in claim 1, further comprising:

a) receiving a request to unmanage one of the number of objects stored in the information base; and

b) determining whether the existing resource name closure set to which the object to be unmanaged belongs comprises additional objects; and

i) if not, granting the request to unmanage, and deleting the existing resource name closure set;

ii) if so, and each of the additional objects shares a resource name with at least one other of the additional objects, granting the request to unmanage; and

iii) if so, and one or more of the additional objects does not share a resource name with at least one other of the additional objects,

A) granting the request to unmanage;

B) determining a plurality of new resource name closure sets encompassing the additional objects; and

C) deleting the existing resource name closure set.

4. A computer based method as in claim 1, further comprising:

a) receiving a request to add a resource name to a given one of the number of objects stored in the information base;

b) adding the resource name to the given object; and

c) determining whether the added resource name identifies one or more resources in addition to a first resource defined by the resource name closure set to which the given object belongs, and if so,

i) defining a new resource by a resource name closure set comprising each of the objects in the resource name closure sets of each of the first and additional one or more resource name closure sets; and

ii) deleting the resource name closure sets of each of the first and additional one or more resource name closure sets.

5. A computer based method as in claim 1, further comprising:

a) receiving a request to remove a resource name from a given one of the number of objects stored in the information base;

b) removing the resource name from the given object;

c) determining one or more new resource name closure sets encompassing the number of objects in the existing resource name closure set to which the given object belongs; and

d) deleting the existing resource name closure set.

6. A computer based method as in claim 1, further comprising:

a) receiving a request to explicitly combine at least two resources;

b) generating a unique resource name;

c) adding the unique resource name to an object in the resource name closure sets of each of the at least two resources;

d) defining a new resource by a resource name closure set comprising each of the objects in the resource name closure sets of the at least two resources, said new resource being uniquely identified by the number of resource names possessed by each of the objects in the resource name closure sets of the at least two resources; and

e) deleting the resource name closure sets of the at least two resources.

7. A computer based method as in claim 1, further comprising storing a number of resource aspect types in a resource aspect type store, wherein:

a) a resource aspect type comprises a number of rules defining permitted associations for object instances of the resource aspect type; and

b) each of the number of objects stored in the information base is an instance of one of the resource aspect types.

8. A computer based method as in claim 7, wherein the number of resource aspect types are hierarchical in nature, and a given resource aspect type which is a specialization of at least one other resource aspect type inherits the number of rules of the at least one other resource aspect type, in addition to the number of rules of the given resource aspect type.

9. A computer based method as in claim 8, further comprising:

a) configuring a number of enforcer objects, each of which comprises at least one trigger condition associated with at least one constraint, and each of which is related to a resource aspect type; and

b) when a request to change the information base is received, and the request meets a trigger condition of any enforcer object, ensuring that the change to the information base complies with the constraints of the met trigger conditions;

wherein the trigger conditions of an enforcer object related to a given resource aspect type are inherited by resource aspect types which are specializations of the given resource aspect type.

10. A computer based method as in claim 8, further comprising:

a) configuring a number of notification receiver objects, each of which comprises at least one trigger condition, and each of which is related to a resource aspect type; and

b) when a request to change the information base is received, and the request meets a trigger condition of any notification receiver object, logging the change to the information base with the notification receiver object comprising the met trigger condition;

wherein the trigger conditions of a notification receiver object related to a given resource aspect type are inherited by resource aspect types which are specializations of the given resource aspect type.

11. A computer based method as in claim 8, further comprising:

a) configuring a number of notification receiver objects, each of which comprises at least one trigger condition, and each of which is related to an object stored in the information base; and

b) when a request to change the information base is received, and the request meets a trigger condition of any notification receiver object, logging the change to the information base with the notification receiver object comprising the met trigger condition;

wherein the trigger conditions of a notification receiver object related to a given resource aspect type are inherited by resource aspect types which are specializations of the given resource aspect type.

12. A computer based method as in claim 7, wherein the number of rules for a given resource aspect type comprise a number of configurable rules, each configurable rule comprising:

a) a role;

b) a minimum and a maximum number of associations in which an object instance of the given resource aspect type must participate; and

c) a resource aspect type indicating a type of object with which an association pursuant to the configurable rule must be performed.

13. A computer based method as in claim 7, further comprising:

a) configuring a number of enforcer objects, each of which is related to a resource aspect type; and

b) when a request to change the information base is received, and the request meets a trigger condition of any enforcer object, ensuring that the change to the information base complies with the constraints of the met trigger conditions.

14. A computer based method as in claim 7, further comprising:

a) configuring a number of notification receiver objects, each of which comprises at least one trigger condition, and each of which is related to a resource aspect type; and

b) when a request to change the information base is received, and the request meets a trigger condition of any notification receiver object, logging the change to the information base with the notification receiver object comprising the met trigger condition.

15. A computer based method as in claim 7, further comprising:

a) configuring a number of notification receiver objects, each of which comprises at least one trigger condition, and each of which is related to an object stored in the information base; and

b) when a request to change the information base is received, and the request meets a trigger condition of any notification receiver object, logging the change to the information base with the notification receiver object comprising the met trigger condition.

16. A computer based method as in claim 7, wherein:

a) the number of rules for a given resource aspect type comprise rules comprising:

i) a role;

ii) a minimum and a maximum number of associations in which an object instance of the given resource aspect type must participate; and

iii) a resource aspect type indicating a type of object with which an association pursuant to the configurable rule must be performed; and

b) the resource aspect types and rules comprise those in the following

    __________________________________________________________________________
                  Rules
    Resource Aspect Type
                  Role    Min.
                             Max.
                                Associated Resource Aspect Type
    __________________________________________________________________________
    logical.sub.-- network
                  network 0  1  logical.sub.-- network.sub.-- containment
                  network 0  1  logical.sub.-- segment.sub.-- containment
    logical.sub.-- network.sub.-- containment
                  container
                          0  1  logical.sub.-- network
                  container
                          0  N  logical.sub.-- segment
    logical.sub.-- segment.sub.-- containment
                  container
                          0  1  logical.sub.-- segment
                  container
                          0  N  logical.sub.-- network
    logical.sub.-- node
                  logical.sub.-- device
                          0  1  logical.sub.-- node.sub.-- containment
    logical.sub.-- node.sub.-- containment
                  container
                          0  1  logical.sub.-- node
                  container
                          0  N  logical.sub.-- if
    logical.sub.-- if
                  interface
                          0  1  logical.sub.-- node.sub.-- containment
                  interface
                          0  1  logical.sub.-- interface.sub.-- connection
    logical.sub.-- interface.sub.-- connection
                  connector
                          0  1  logical.sub.-- if
                  connector
                          0  1  logical.sub.-- segment
    logical.sub.-- segment
                  segment 0  N  logical.sub.-- interface.sub.-- connection
                  segment 0  1  logical.sub.-- boundary
                  segment 0  1  logical.sub.-- network.sub.-- containment
                  segment 0  1  logical.sub.-- segment.sub.-- containment
    logical.sub.-- boundary
                  bounds  0  N  logical.sub.-- segment
                  bounds  0  N  logical.sub.-- connector (inherited)
    logical.sub.-- connector
                  connection device
                          0  1  logical.sub.-- boundary
    __________________________________________________________________________

    ______________________________________
              Rules
                                      Associated Resource
    Resource Aspect Type
                Role     Min.   Max.  Aspect Type
    ______________________________________
    logical.sub.-- segment
                segment  0      1     physical.sub.-- network
    ______________________________________

    __________________________________________________________________________
                  Rules
    Resource Aspect Type
                  Role   Min.
                            Max.
                               Associated Resource Aspect Type
    __________________________________________________________________________
    physical.sub.-- network
                  phy.sub.-- network
                         0  1  logical.sub.-- segment
                  phy.sub.-- network
                         0  1  physical.sub.-- segment.sub.-- containment
    physical.sub.-- segment.sub.-- containment
                  container
                         0  1  physical.sub.-- network
                  container
                         0  N  physical.sub.-- segment
    physical.sub.-- node
                  chasis 0  1  physical.sub.-- node.sub.-- containment
    physical.sub.-- node.sub.-- containment
                  container
                         0  N  physical.sub.-- if
                  container
                         0  1  physical.sub.-- node
    physical.sub.-- if
                  interface
                         0  1  physical.sub.-- node.sub.-- containment
                  interface
                         0  1  physical.sub.-- interface.sub.-- connection
    physical.sub.-- interface.sub.-- connection
                  connector
                         0  1  physical.sub.-- if
                  connector
                         0  1  physical.sub.-- segment
    physical.sub.-- segment
                  segment
                         0  N  physical.sub.-- interface.sub.-- connection
                  segment
                         0  1  physical.sub.-- boundary
                  segment
                         0  1  physical.sub.-- segment.sub.-- containment
    physical.sub.-- boundary
                  bounds 0  N  physical.sub.-- segment
                  bounds 0  N  physical.sub.-- connector (inherited)
    physical.sub.-- connector
                  bounds 0  1  physical.sub.-- boundary
    __________________________________________________________________________

    ______________________________________
              Rules
                                      Associated Resource
    Resource Aspect Type
                Role     Min.   Max.  Aspect Type
    ______________________________________
    physical.sub.-- segment
                segment  0      1     media.sub.-- containment
    ______________________________________

    __________________________________________________________________________
              Rules
    Resource Aspect Type
              Role    Min.
                         Max.
                            Associated Resource Aspect Type
    __________________________________________________________________________
    media.sub.-- containment
              attachment
                      0  1  physical.sub.-- segment
              container
                      0  1  media.sub.-- network
    media.sub.-- network
              media.sub.-- network
                      0  1  media.sub.-- containment
              media.sub.-- container
                      0  N  media.sub.-- cable
    media.sub.-- terminator
              termination
                      0  1  media.sub.-- cable
    media.sub.-- cable
              physical.sub.-- wire
                      0  1  media.sub.-- terminator
              physical.sub.-- wire
                      0  1  media.sub.-- fitting
              physical.sub.-- wire
                      0  2  media.sub.-- connector
              physical.sub.-- wire
                      0  1  media.sub.-- network
    media.sub.-- fitting
              cable.sub.-- ink
                      0  1  media.sub.-- cable
    media.sub.-- connector
              connector
                      0  1  media.sub.-- cable
    __________________________________________________________________________

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, model of enterprise management which may be utilized to manage any objects which can be characterized by topological associations.

2. Description of the Related Art

Management systems utilized in a business or other 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 topological associations between those objects. As used herein, "topological associations" refer to associations or relationships between objects. These associations or relationships are frequently represented graphically. A collection of objects and the topological associations between them is referred to herein as a "topology." A system which manages such topologies is referred to herein as a "topological" management system. Typical examples of such topological enterprise management computing systems are personnel management systems, asset management systems, network/computing management systems, communications management systems, and site management systems. It is common for large enterprises to use computing systems to aid in the management of these and other aspects of the enterprise.

For example, an enterprise may manage payroll functions through the management of objects such as payroll checks, employees, withholding accounts, retirement accounts, and the associations therebetween. An employee is associated with one withholding account and one retirement account but with several payroll checks. Or, in a further example, the management of an enterprise network may involve associations between several subnets, between a node and its neighbors, between a node and its users, or between a particular program and its users.

In general, prior management information application programs which attempt to manage topological aspects of an enterprise can be characterized as managing the objects in isolation and the associations between the managed objects. The rules that govern the associations between objects essentially define the topology. For example, the rules that define the associations between nodes and protocol layers in a Transmission Control Protocol/Internet Protocol (TCP/IP) network define a TCP/IP topology. Enterprise management applications which relate to TCP/IP network management therefore seek to enforce compliance with rules which define the TCP/IP topology. In all known prior management applications, there is no enterprise-wide standard for defining such topologies. Instead, a variety of disparate solutions tend to evolve, each of which manages a particular topology within the enterprise.

The types of objects managed and the managed associations between those objects varies widely among these enterprise topology management systems. It is common practice in the art to utilize different computer based management tools for each of the several management tasks common within an enterprise. A tool which is well tuned for a particular use, a particular aspect of enterprise management, is often preferred to a general purpose tool which attempts to incorporate more features in a generalized manner. Due to this preference it is common to use a plurality of management tools, often produced by disparate vendors, each well tuned to a different management task. By way of example, a personnel management task may select one computing system well tuned to payroll generation. A different tool may be preferred for maintaining other personnel records and enterprise organizational matters relating to staffing (i.e. organization charts).

A first problem with the use of disparate applications programs is the increase in development effort to create the needed applications. Frequently the various management applications are developed over a span of time by diverse development groups. Each application tends to develop its own unique structures and methods for managing the topological associations between the managed objects. This redundant development may increase the complexity and related costs for development of such topological management applications. In addition, the variety of independently developed structures and methods for managing topological associations between managed objects tends to lead toward incompatible designs which may be difficult to integrate.

A second problem with the use of disparate systems for different management tasks utilizing common elements of information arises in the inevitable duplication of stored information. 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 applications. 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 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 manager. Each disparate management application must take responsibility for updating its own stored version of all common elements 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 topological information management systems which automate the maintenance of topological associations between objects. Such improved systems would assist in reducing duplication of information stored within the topological management system in such a way that new management information applications could be more easily integrated with existing applications than is possible under known prior approaches.

SUMMARY OF THE INVENTION

The present invention solves the above identified problems and thereby advances the art by providing methods and related structures to manage topological associations between objects used in information management data processing applications. The methods and structures of the present invention permit an application designer to create management information application programs to manage disparate aspects of topological information.

The present invention provides an application program interface (hereinafter referred to as API) which is utilized by application programmers to create topological information management applications. The API of the present invention permits the creation, deletion, and modification of associations between objects supplied by the application program. These associations represent the topological association between the associated objects supplied by the application program. Objects known to the API by virtue of the creation of an association become "managed objects."

Topological rules, defined by the application programs, govern the creation, deletion, and modification of these topological associations between objects. These topological rules are stored and enforced by the API to govern the manipulation by application programs of associations between managed objects. The API of the present invention thereby enforces consistent rules for the manipulation of topologies managed by the API on behalf of several application programs.

Since the API provides a common structure and method for the management of topologies, duplication of information common to several application programs can be reduced. The API of the present invention provides a simple interface for an application developer to determine what information is presently managed by the API with respect to particular associations between managed objects. An application developer defines a particular set of attributes, useful to his/her management application, which uniquely defines the objects manipulated by the application. The API of the present invention detects that an object so defined by one application in fact refers to the same entity (also referred to herein as resource) as another object provided to the API topology management by the same or another application program. An application program thereby has a unique view of an entity represented by the object used by the application. The view of an object utilized by one application program is referred to herein as a resource aspect. The topology management API of the present invention can provide an application program any topological information from other managed objects which are recognized to represent the same entity (resource) as the managed object provided by the application program.

The API of the present invention also provides the ability to perform general topological queries of the entire enterprise-wide information base. General topological queries are queries that can provide information regarding managed objects and their managed topological associations. They can be generated as simple textual expressions yet may specify queries ranging from simple to very complex. These queries can involve objects and associations beyond the scope of information manipulated by any single application program. The query related API functions return subgraph object structures that contain the managed objects and their managed topological associations that matched the query.

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 API structures and methods of the present invention;

FIG. 2 depicts an object oriented analysis and design view of the API structures manipulated by the methods of the present invention;

FIG. 3 conceptually depicts the resource integration of the API structures and methods of the present invention as caused by management of a previously unmanaged object;

FIG. 4 conceptually depicts the resource integration of the API structures and methods of the present invention as caused by the unmanagement of a previously managed resource aspect;

FIG. 5 conceptually depicts the resource integration of the API structures and methods of the present invention caused by the addition of a resource name to an existing managed resource aspect;

FIG. 6 conceptually depicts the resource integration of the API structures and methods of the present invention caused by the removal of a resource name from an existing managed resource aspect;

FIG. 7 is a flowchart of the methods of the present invention which manipulate the structures of the present invention to provide general maintenance of topological information;

FIG. 8 is a flowchart of the methods of the present invention which operate to incorporate knowledge within the structures of the present invention of a newly managed object;

FIG. 9 is a flowchart of the methods of the present invention which operate to eliminate knowledge from the structures of the present invention of a previously managed object;

FIG. 10 depicts an object oriented analysis and design view of an exemplary IP network topology managed by the API structures and methods of the present invention;

FIG. 11 depicts an object oriented analysis and design view showing additional lower level details of an IP network topology managed by the API structures and methods of the present invention;

FIG. 12 shows a typical approach of the prior art wherein disparate application programs each manage particular enterprise topological information;

FIG. 13 shows various application programs utilizing the topological management service API of the present invention to manage all enterprise topologies using a common structure and related methods;

FIG. 14 depicts the hierarchy of exemplary inherited resource aspect type data constructs of the present invention;

FIG. 15 depicts graphical representations of general topology queries relating to topological associations in the topological stored information base exemplifying simple navigation paths;

FIG. 16 depicts graphical representations of general topology queries relating to topological associations in the topological stored information base exemplifying compound statements in a query;

FIG. 17 depicts graphical representations of general topology queries relating to topological associations in the topological stored information base exemplifying compound queries;

FIG. 18 depicts graphical representations of general topology queries relating to topological associations in the topological stored information base exemplifying repetition in queries;

FIG. 19 depicts graphical representations of general topology queries relating to topological associations in the topological stored information base exemplifying the returned information generated by a show indicator; and

FIG. 20 depicts a graphical design view of an exemplary IP network topology comprising objects managed by the API structures and methods of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention comprises an application program interface (API) which manages topologically associated objects according to rules which define one or more topologies. As used herein, "topological associations" refer to associations between objects which may be represented graphically. A collection of objects and the topological associations between them is referred to herein as a "topology." A system which manages such topologies is referred to herein as a "topological" management system. Topological management as used herein is also referred to as relationship management. In relationship management terminology, a topology is a set of managed relationships between managed objects, and topological information is a set of relationships between managed objects. Topological enterprise database refers equally to a relationship management database which contains topological information.

FIG. 12 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. In particular, typical applications which are used to manage topological information include human resources (H.R.) management applications 1200, asset management applications 1202, and network/computing management applications 1204. Each application has its own distinct application database associated therewith, namely, H.R. database 1206, asset database 1208, and network/computing database 1210, respectively.

Some information is common to all three management applications. For example, employee data in H.R. database 1206 shares some common information with the users data in asset database 1208 and with the users data in network/computing database 1210. Duplication of data in three databases creates problems in these prior designs. Problems, as discussed above, relate to one database being updated independently of another, unnecessary duplication of storage space, and difficulties in integrating one application with another as needs grow and evolve.

FIG. 13 depicts an overview of the enterprise management application designs made possible by the topology management service of the present invention. As in FIG. 12, FIG. 13 shows three separate management applications, namely H.R. management application 1300, asset management application 1302, and network/computing management application 1304. The three application programs 1300,1302, and 1304 are depicted above the dashed line in FIG. 13 to indicate that they are client application programs. However, unlike prior designs, all three applications utilize the common topology server 1314 of the present invention. Topology management server 1314 manages topological information (association information 1320) relating to the topological aspects of the objects manipulated by the three client application programs 1300, 1302, and 1304. All such topological information (association information 1320) is therefore managed according to a common set of rules through a common server program interface (topology server 1314). This permits each application client program to share topological information made known through other application client programs.

Other non-topological information may be managed by the application client programs through the use of dedicated server programs such as employee server 1306, asset server 1308, and network/computing server 1310. As depicted in FIG. 13, the server programs may in turn invoke the services of other common server programs such as people server 1312 to share common elements of information more effectively. People server program 1312 manages non-topological information relating to people in people information 1316. Asset server program 1308 manages asset information 1318 which is unique to its particular management task. Similarly, network/computing server program 1310 manages network/computing information 1322 which is unique to its application area.

FIG. 1 shows a block diagram of the computer hardware that contains the topology 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 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 topology management system of the present invention, to store the topological enterprise database, and to store the managed objects. A printer 116 can be used to provide a hard copy output of the topology information displayed by the system.

A main memory 110 within the system 100 contains the topology management system 120 of the present invention. An application program 126, developed by a user of the present invention communicates with the topological management system 120, which in turn communicates with an operating system 122 and storage management software 124 to perform the topological management services on behalf of client application programs. 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 topological enterprise database 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. For example, permanent storage of the information may reside on local or remote disk subsystems and a local memory cache may be used to improve performance. More generally, the information stored in the topological enterprise database may be stored in any memory device or subsystem having suitable capacity and performance characteristics. The term disk 114 as used herein is intended to describe all such suitable memory devices or subsystems.

FIG. 2 is an overview of the data constructs and relationships created and managed by the topological management methods of the present invention. FIG. 2 is an object oriented analysis view of the data constructs and relationships of the present invention. It is drawn and to be interpreted according to the FUSION object model. FUSION is an object oriented analysis and design tool produced by Hewlett Packard Company of Palo Alto, Calif. Readers unfamiliar with such object oriented design are directed to the published documentation for the Fusion Method in "Object-Oriented Development--the Fusion Method" (published by Prentice Hall ISBN 0-13-338823-9).

The data constructs are indicated by labelled boxes and the relationships between the data constructs are indicated by lines connecting the related boxes to a diamond shaped entity. The lines connecting data construct boxes in FIG. 2 are labelled to indicate the type of relationship between the related boxes. A label of "1" for example indicates that exactly one of the data constructs participates in the relationship, A label of "*" indicates zero or more data constructs participate in the associated relationship and a label of "+" indicates one of more data constructs. For example, a one-to-one relationship between two data constructs is indicated by a numeral "1" at each end of the lines connecting the data construct boxes to the diamond shaped relationship. A one-to-many relationship is indicated by a numeral "1" at the line connecting a first data construct box and a "*" or "+" character at the line connected to the other data construct box. A one-to-one relationship indicates that each data construct represented by the box at one end of the relationship is related to exactly one of the type of data constructs at the opposite end of the relationship. A one-to-many relationship indicates that each data construct represented by the box connected to the relationship with a line labelled "1" is related to zero or more of the data constructs at the other side of the relationship with a line labelled "*" (one or more if the line end is labelled "+").

DATA CONSTRUCTS

RESOURCES, RESOURCE ASPECTS, AND RESOURCE ASPECT TYPES:

Resource 200 is a data construct which represents the combined characteristics of all aspects of a "thing" of interest in the application of the methods of the present invention. A resource 200 is an instance of a thing, at the highest level of abstraction, to be managed by the present invention. For example, a person, a building, a network, or a computing node might be examples of abstract things to be managed by the topology management methods of the present invention. The level of abstraction useful to a particular application of the present invention is a matter of design choice and is frequently associated with the well known methods of Object Oriented Design and Analysis common to the software engineering arts.

A resource 200 is comprised of one or more resource aspects 202 (hereinafter referred to as RAs). An RA 202 is an object supplied by an application program using the topological management methods of the present invention. An RA 202 further comprises a topological component 206 which is related to zero or one non-topological components 208 as depicted in FIG. 2 by relation 210. The topological component 206 of an RA 202 contains the information relevant to the topological management service of the present invention, specifically resource names, the associated resource aspect type, and details relating to associations in which the RA 202 is participating. Details of these elements are discussed below. The non-topological component 208 of an RA 202 contains information unique to the application program which is using the object and is otherwise uninvolved in the topological management methods of the present invention.

A resource name (hereinafter referred to as RN) is a field which has a tag name and a presently assigned value. A resource 200 is uniquely defined by one or more resource names (stored within a resource aspect 202 as described below). Specifically, a resource 200 is uniquely identified by the transitive closure of the union of all resource names stored within all RAs 202 which are currently managed as aspects of the resource 200.

For example, in the following hypothetical set of data constructs:

Resource:Person1

RA:Employee

ResourceNames:

SSN:123456789

EMPNO:11221

RA:CreditUnionMember

ResourceNames:

SSN:123456789

ACCTNO:998761

Resource:Person2

RA:Employee

ResourceNames:

SSN:987654321

EMPNO:21212

RA:CreditUnionMember

ResourceNames:

SSN:987654321

ACCTNO:66884 resource Person1 is known by the transitive closure of all resource names, namely: SSN:123456789, EMPNO:11221, and ACCTNO:998761, while resource Person2 is known by the its unique resource names, namely SSN:987654321, EMPNO:21212, and ACCTNO:66884.

The RNs which uniquely define a resource 200 are supplied by the application programs using the methods of the present invention. An application program utilizing the present invention provides an RA 202 including one or more RNs identifying a specific resource 200, and requests that the object be managed by the topological management methods of the present invention. RNs not previously supplied in an object by another application program are thereby added to the collection of known characteristics (RNs) of the specified resource 200. Each RA 202 identifies the associated resource 200 by its particular subset of RN values. The resource 200 is therefore the union or integration point for all resource names known in all RA 202 subsets of the RNs.

The objects supplied to the topological management system are managed by associating each object with the resource 200 uniquely identified by the supplied RNs. If the supplied RNs do not identify an existing resource 200, a new resource 200 is automatically created. Therefore, each resource 200 is associated with one or more RAs 202. Each RA 202 associated with a resource 200 is said to represent one particular aspect of the resource 200.

Application programs which use the topology management methods of the present invention may each utilize different subsets of the resource names defining a resource 200. For example, one application program may be concerned with a "person" resource as an "employee" while another application may view the same person as a "club member." Similarly, one application may view a "network" resource as a "TCP/IP local area network" and concern itself with manipulation of RNs relating to that aspect of the "network" resource. Yet another application may be concerned with the "wide area network" aspect of the "network" resource RNs. Each subset of the RNs of a resource 200 is referred to as an "aspect" and is represented by at most one RA 202.

Each RA 202 is in a one-to-one relationship with a resource aspect type 212 (hereinafter referred to as RAT). A resource 200 may be represented by several aspects (several RAs may fully describe one resource from the perspective of several different application program aspects). Therefore, there is shown a many-to-many "classifies" relationship 220 between RAs 202 and RATs 212. Built-in rules (also referred to as invariants) within the present invention precludes a resource from being represented by more than one RA 202 classified by a particular RAT 212 (or a particular RAT 212 and a specialization of that type as discussed below).

The RAT 212 constrains the types of relations in which the related RA 202 may participate. A set of rules associated with the RAT 212 defines the constraints applied to the aspect of a resource 200 represented by an RA 202. The constraints include built-in rules which are predefined and allow for limited customization, and extensible rules which may be completely defined by the application programmer. Part of the configurable rules defined in the each RAT 212 is a list of previously defined, named roles through which the associated RA 202 may participate in associations (this is discussed in more detail below).

Consistent with the Object Oriented Design and Analysis which forms the basis for use of the present invention, RATs 212 are defined as a class or may be defined as a specialization of a previously defined RAT class. A specialization of a previously specified class inherits all properties of the previously defined class and specifies additional attributes and constraints. For example, "permanent employee" and "temporary employee" may be two resource aspect type specializations of an RAT 212 which specifies the constraints for the "employee" resource aspect type. In the sense that a specialization of an RAT 212 inherits all the RATs 212 properties, the newly defined specialization RAT 212 is in a "specializes" relation with the previously defined RAT 212 as indicated by the relation 214.

Exemplary of the built-in rules relating to resources is that each RA 202 represents one aspect of one "thing." This constraint is specified by stating that each RA 202 is associated with only one RAT 212 and no resource 200 can be represented by two RAs 202 classified by the same RAT 212 (or by two RAs where the RAT classifying one RA is a specialization of the RAT classifying the other RA). The constraints specified by each RAT 212 are discussed in more detail below.

Resources 200 are not explicitly managed by application programs utilizing the topological management methods of the present invention. Rather, the topological management methods create, modify, and destroy resources 200 based on the resource aspects 202 provided to the methods for topological management. In other words as objects are provided to the topological management services with a request that the object be managed, resources 200 are created, destroyed, or modified based on the resource names provided with the RA 202. Conversely, when a managed RA 202 is identified by an application program with a request that the object become unmanaged, related resources 200 are created, destroyed, or modified as appropriate to the remaining resource names known with respect to an affected resource 200. The methods of the present invention which create, destroy, and modify resources 200 are discussed below in further detail.

ASSOCIATIONS

Associations 204 define interrelationships between two RAs 200. For example, two "person" resources 200, each represented by an RA 202 having an "employee" resource aspect type 212, might participate in a "works for" association 204 to express enterprise personnel organization. The same two resources might also participate in a "works with" association for purposes of the same, or another, application program. Similarly, a "network" resource and a "computing node" resource might participate in a "connected to" association.

Associations 204 are created by an application program using the topological management methods of the present invention to reflect an association between two resource aspects 202. An application program invokes the topological management methods to create a new association. The application provides a list of RAs 202 and a definition of the "role" played by each provided RA in the new association. The use of "roles" in an association is discussed in detail below.

Application programs which use the topology management methods of the present invention may each utilize different interrelationships between resources 200. For example, one application program may be concerned with a "works for" or "works with" association between "person" resources 200 viewed from the "employee" aspect RAs 202 while another application may be concerned with "is the child of" or "is married to" associations between the same two "person" resources 200 viewed from the "family member" aspect RAs 202.

TOPOLOGY INVARIANTS--RULES ROLES, ENFORCERS, AND NOTIFICATION RECEIVERS

Built-In Invariants (rules):

The topological management service of the present invention includes built-in rules to reject certain inappropriate requests generated by a client application program. The methods of the present invention reject any request made by a client application program which would result in a resource 200 being represented by:

two or more RAs 202 classified by the same RAT 212, or

two or more RAs 202 where the RAT 212 classifying one RA is a specialization of another RAT.

Configurable Invariants (roles):

Other rules are configurable by the client application program, and are defined and stored with an RAT 212. The RAT 212 associated with each RA 202 defines a set of rules which enumerates the permitted association roles for that RAT 212. Specifically, the rules in each RAT 212 list the roles which are permitted for the related RA 202 in forming associations 204 with other RAs 202. By applying these rules, the methods of the present invention prevent the formation of invalid association 204 between resources 200 as represented by the RAs 202. As discussed above, an association 204 is created by a client application program providing two RAs 202 to be associated and the desired role for each specified RA. The desired association is only formed if the RAT 212 which relates to each provided RA includes a rule which permits the formation of the association with the specified roles used for the specified RAs 202.

In addition to specifying the permitted roles for forming associations, the rules defined and stored with an RAT 212 specify other attributes for permitted associations. Specifically, each rule specifies the RAT 212 which is to be used for the other RA 202 which forms the permitted association. In addition, the rule specifies the minimum and maximum cardinality of such associations which are permitted. A minimum cardinality indicates that an RA 202 classified by the RAT 212 defining the rules must participate in at least that number of such associations 204 with other permitted RAs 202. A maximum cardinality indicate that the RA 202 may not participate in more than that number of such associations 204.

Extensible Constraints (enforcers):

In addition to the built-in and the configurable invariants, a client application program may define application specific rules (enforcers) to verify the validity of other changes to the topologically managed enterprise database. Enforcers 216 are defined by the application program by providing a programmed function to be performed to verify the propriety of any changes to a particular resource. The enforcer 216 programmed function is invoked to verify any proposed changes to a resource related to the RAT 212 which defined the enforcer 216. The enforcer 216 function is provided with the resource 200 and the RAT 212 as inputs, evaluates the propriety of the proposed changes to the resource, and returns a value indicative of the propriety of the proposed change. The proposed changes are rejected by the topological management methods if any enforcer function return a value indicative of an improper change to the resource. Enforcers 216 provide the application program the maximum flexibility to verify the consistency and propriety of the resources in the topologically managed enterprise database.

Notification Receivers:

Notification receivers 226 are objects which are related 222 to an RAT 212 to define an interface for reception of a notification of a change of a particular RAT 212 in a managed topology. A notification receiver object is related to one or more predefined trigger conditions each of which is "triggered" when a particular predefined type of change is made to a related RAT 212 in the topology.

Notification receivers 226 are also related 224 to an RA 202 to define an interface for reception of a notification of a change of a particular RA 202 in a managed topology. A notification receiver object is related to one or more predefined trigger conditions each of which is "triggered" when a particular predefined type of change is made to a related RA 202 in the topology.

The notification receiver feature permits a first application program to be notified when a second application program changes the topology in a manner which may affect the first application program.

RESOURCE INTEGRATION

The topological management methods data constructs (described above) and the associated methods of the present invention permit different application programs to view and manipulate a common resource each using a different resource aspect. Each application's resource aspect is defined by an RAT 212 data construct and is embodied in a related RA 202 data construct which is classified by the RAT 212. Each resource aspect is capable of being manipulated independent of all other resource aspects of the same common resource.

The data constructs and associated methods of the present invention recognize when several resource aspects in fact refer to the same resource by the resource names (RN) given to the RA 202. This is accomplished by "representing" a resource 200 by each of the RAs 202 in a "resource name closure set." As used herein "representing" means that resources 200 are not referenced directly by client application programs, but rather indirectly through the RAs 202 which "represent" the resource. A "resource name closure set" is the largest set of resource aspects (RAs 202) such that each resource aspect in the set shares at least one resource name (RN) with at least one other resource aspect of the set. In other words it is the transitive closure of the intersection of resource names for resource aspects (RAs 202). The resource name closure set identifies a resource 200 as the set of resource aspects (RAs 202) representing the resource 200.

Any validated (by application of all invariants and enforcers) changes to the topological enterprise database may affect the resource integration. New resource names provided by a newly managed object provided to the topological management service of the present invention may alter the resource name closure set to thereby necessitate modifications to the resources 200 known to the topological management service.

FIG. 3 shows a specific graphical example of the operation of resource integration on an exemplary topology. The detailed operation of the methods used to manage a topology, and specifically resource integration of a managed topology, is discussed below. Topology 300 is a snapshot of a managed topology before the addition of a new object to be managed under the topology. RESOURCE1 302 and RESOURCE2 304 are two resources in the managed topology. In this exemplary topology both resources represent "person" resources. RESOURCE1 302 is "represented" by resource aspects (RAs) 306, 308, and 310 while RESOURCE2 304 is "represented" by resource aspect 314. The resource name closure set for RESOURCE1 302 is resource aspects 306, 308 and 310 because that is the largest set of RAs which all share at least one resource name (RN) with at least one other RA. Similarly, the resource name closure set for RESOURCE2 304 is the single RA 314. The topology management service of the present invention understands the total set of managed RAs (306, 308, 310, and 314) to represent two separate resources (persons), namely RESOURCE1 302 and RESOURCE2 304. Object 312 in topology 300 (before) has not yet been provided to the topology management service to be managed in the topology.

Topology 350 represents a snapshot of the same topology after the addition of object 312 to the set of topologically managed objects. In topology 350, object 312 has now been provided to the topology management service and thereby becomes a resource aspect 312. Because of the validated change to the managed topology, the resource name closure set is determined again by the topology management service for all managed resources. The newly managed RA 312 has a resource name shared by RA 310 and another resource name shared by RA 314. Therefore, the resource name closure set now includes all managed RAs in topology 350, namely 306, 308, 310, 312, and 314. RESOURCE1 302 and RESOURCE2 304 cease to exist as distinct resources and a new resource, RESOURCE3 316, is now represented by the entire set of RAs, namely 306, 308, 310, 312, and 314.

In FIG. 3, topology 350 is labelled as the result of adding object 312 to topology 300. The reverse operation can also be seen in FIG. 3 by simply reversing the "before" and "after" labels. In other words, if topology 350 were the initial condition of a managed topology, and the user requested that currently managed RA 312 be removed from the management services of the topology management service, then topology 300 would result. Specifically, when RA 312 is removed from topology 350, the resource name closure set determination reveals that there are now two, apparently, distinct resources where there was one. RESOURCE3 316 of topology 350 would be destroyed and RESOURCE1 302 and RESOURCE2 304 would be created in its place.

The topology management service of the present invention determines the resource name closure set after any change in the topology which may affect the relationship between resources and resource aspects. FIGS. 4-6 depict additional alterations made by the topology management service in response to other types of changes which affect the topology resource integration. In FIGS. 4-6, the resource aspects are shown only in abstraction with labels such as RA1-RA8. The specific contents of any resource aspect is not relevant to the types of operations which are depicted in FIGS. 4-6.

FIG. 4 depicts the above described reversal of the topology management function in FIG. 3. In FIG. 4, the initial state of topology 400 shows the resource name closure set representing RESOURCE1 402 to be RA1 406, RA2 408, RA3 410, and RA4 412 while the resource name closure set representing RESOURCE2 404 is RA5 414 and RA6 416. If RA3 410 is removed from the management service ("unmanaged"), then topology 450 results wherein RESOURCE1 402 is destroyed and two new resources, RESOURCE3 418 and RESOURCE4 420, are created in its stead. The unmanaging of RA3 410 breaks the sharing of at least one resource name between the previous members of the resource name closure set representing RESOURCE1 402. New RESOURCE3 418 is represented by RA1 406 and RA2 408 while new RESOURCE4 420 is represented by RA4 412. RESOURCE2 404 is unaffected by this change.

The resource name closure sets of resources in a topology may also be altered by changing the resource names associated with a particular resource aspect. If resource names are associated with, or disassociated with, managed resource aspects, the resource name closure set may also change. The resource names associated with a particular resource aspect are determined by the resource aspect type (RAT) which classifies the resource aspect (RA). FIG. 5 depicts the changes to a topology caused by addition of a resource name to a resource aspect. Topology 500 depicts an initial state of a managed topology in which there are two resources, RESOURCE1 502 and RESOURCE2 504. RESOURCE1 502 is represented by its resource name closure set RA1 506, RA2 508, RA3 510, and RA4 512. RESOURCE2 504 is represented by its resource name closure set RA5 514, RA6 516, and RA8 518. If a new resource name (RN) is added to RA8 518 and the new RN is shared with RA4 512, then topology 550 results from the topology management determination of resource name closure sets of all resources. RESOURCE1 502 and RESOURCE2 504 are destroyed and a new resource, RESOURCE3 520, is created in their place. RESOURCE3 520 is represented by the new resource name closure set which comprises all RAs known to the topology management service. The addition of the new RN to RA8 518 effectively joined to the two, previously distinct, resources by joining their respective resource name closure sets. It will be readily recognized that the same result may be produced by adding a new RN to RA4 512 which is shared by RA8 518, or similarly, with any pair of RAs, one of which is in a first closure set and the other in another closure set.

FIG. 6 depicts the reversal of the operations performed by the topology management service in FIG. 5. In FIG. 6 a resource name (RN) previously shared by two resource aspects is removed from one of the resource aspects to thereby split the common resource into two new resources. In an initial state, topology 600 is shown to be managing one resource, RESOURCE1 602, represented by all RAs, namely RA1 604, RA2, 606, RA3, 608, RA4 610, RA5, 614, RA6 616, and RA8 612. After removing a resource name from RA8 612, specifically the only resource name which was shared between RA8 612 and RA4 610, topology 650 results from the determination of new resource name closure sets. In topology 650, RESOURCE1 602 is destroyed and replaced by two new resources, RESOURCE2 618 and RESOURCE3 620. RESOURCE2 618 is represented by its resource name closure set comprising RA1 604, RA2 606, RA3 608, and RA4 610, while RESOURCE3 620 is represented by the closure set of RA5 614, RA6 616, and RA8 612. The deletion of an RN from RA8 612 effectively splits the resource by splitting the resource name closure sets. It will be readily recognized that the same result may be produced by removing an RN from RA4 610 which is shared by RA8 612, or similarly, with any pair of RAs in the same resource name closure set which share only the removed resource name.

It will be readily recognized that the data constructs described above may be represented and manipulated by any of several standard programming techniques.

EXEMPLARY APPLICATIONS

SIMPLE EXAMPLE

This example demonstrates how a developer can use the topology management service of the present invention to develop a solution to an application-specific problem.

The service department of a manufacturer manages all electrical devices used throughout the company. The department requires a system to assist them in managing their inventory of electrical devices.

Among the many functional requirements of the system is a requirement to keep track of the power outlets being used for electrical devices. The department manages both 110 V and 220 V electrical devices. Some power outlets are 220 V whereas others are 110 V. The department wants to ensure that 110 V electrical devices are not allocated to be plugged into 220 V power outlets and that 220 V devices are not allocated to be plugged into 110 V power outlets.

The application developer could choose to solve the problem of maintaining the associations between electrical devices and power outlets without the use of the topology management service. However, the developer would then need to implement code to:

capture semantic constraints on associations and ensure that the semantics are maintained

store and maintain association information

query associations.

Furthermore, by not using the topology management service, other applications may find it difficult to integrate with the new application. For example, the Information Technology department may wish to integrate with the electrical maintenance application to keep track of power connections for computers. The present invention provides the concept of resources so that the Information Technology department's view and the electrical maintenance department's view of the same power connection can be recognized as being different views of the same thing. One department can locate a connection using a topology query and then access the other department's data (as well as its own) that relates to this power connection.

Defining the "topology" is part of the Object Oriented Analysis and Design process of the particular problem. It consists of defining a set of resource aspect types and the inheritance relations between these types.

The application developer must choose the appropriate level of abstraction for his problem. For example, a serial connection between two computers may be modelled simply as a "connection" resource that has associations with two "computer" resources. Alternatively, the serial connection may be modelled as a "serial card" resource associated with a "cable" which is in turn associated with another "serial card."

One aspect of defining a "topology" is to define the resource aspect types to be used. Each resource aspect managed by a topology is classified by one resource aspect type. Resource aspect types constrain the associations in which a resource aspect of that type can participate. Resource aspect type rules are used to specify the configurable aspects of the semantics of a resource aspect type. Each resource aspect type rule specifies a role name, a minimum and maximum number of associations in which the resource aspect must participate in an association with that role, and the resource aspect type with which this resource aspect type can be associated. Table 1 shows the resource aspect type rules used for this example:

                  TABLE 1
    ______________________________________
    Resource aspect type (RAT) Rules
             Rules
    RAT        Role     Min    Max    Associated RAT
    ______________________________________
    Electrical.sub.-- Device
               Sink     0      1      Power.sub.-- Supply
    110 V.sub.-- Device
               Sink     0      1      Power.sub.-- Supply
               Sink     0      1      (inherited)
                                      110 V Power
    220 V.sub.-- Device
               Sink     0      1      Power.sub.-- Supply
               Sink     0      1      (inherited)
                                      220 V Power
    Power.sub.-- Outlet
               Source   0      1      Power.sub.-- Supply
    110 V.sub.-- Outlet
               Source   0      1      Power.sub.-- Supply
               Source   0      1      (inherited)
                                      110 V Power
    220 V.sub.-- Outlet
               Source   0      1      Power.sub.-- Supply
               Source   0      1      (inherted)
                                      220 V Power
    Power.sub.-- Supply
               Sink     1      1      Electrical.sub.-- Device
               Source   1      i      Power.sub.-- Outlet
    110 V.sub.-- Power
               Sink     1      1      Electrical.sub.-- Device
               Sink     1      1      (inherited)
               Source   1      1      110 V.sub.-- Device
               Source   1      1      Power.sub.-- Outlet
                                      (inherited)
                                      110 V.sub.-- Outlet
    220 V.sub.-- Power
               Sink     1      1      Electrical.sub.-- Device
               Sink     1      1      (inherited)
               Source   1      1      220 V.sub.-- Device
               Source   1      1      Power.sub.-- Outlet
                                      (inherited)
                                      220 V.sub.-- Outlet
    ______________________________________

                  TABLE 2
    ______________________________________
    Resource aspects
    Resource aspect    Resource aspect Type
    ______________________________________
    VDU                220 V.sub.-- Device
    Tape.sub.-- Unit   220 V.sub.-- Device
    Paper.sub.-- Shredder
                       110 V.sub.-- Device
    X.sub.-- Terminal  110 V.sub.-- Device
    PC                 110 V.sub.-- Device
    PO-110-1           110 V.sub.-- Outlet
    PO-110-2           110 V.sub.-- Outlet
    PO-110-3           110 V.sub.-- Outlet
    PO-220-1           220 V.sub.-- Outlet
    PO-220-2           220 V.sub.-- Outlet
    P1                 220 V.sub.-- Power
    P2                 220 V.sub.-- Power
    P3                 110 V.sub.-- Power
    P4                 110 V.sub.-- Power
    P5                 110 V.sub.-- Power
    ______________________________________

                  TABLE 3
    ______________________________________
    Valid associations
    Resource Aspect
                 Role     Resource Aspect
                                       Role
    ______________________________________
    P1           Source   PO-220-1     Source
    P1           Sink     VDU          Sink
    P2           Source   PO-220-2     Source
    P2           Sink     Tape.sub.-- Unit
                                       Sink
    P3           Source   PO-110-1     Source
    P3           Sink     Paper.sub.-- Shredder
                                       Sink
    P4           Source   PO-110-2     Source
    P4           Sink     X.sub.-- Terminal
                                       Sink
    P5           Source   PO-110-3     Source
    P5           Sink     PC           Sink
    ______________________________________

    ______________________________________
    logical.sub.-- node
               A logical.sub.-- node 2000 contains zero or more
               logical.sub.-- ifs 2004 (logical interfaces). A
               logical.sub.-- node 2000 is a member of zero or more
               logical.sub.-- segments 2018 by virtue of a single
               logical.sub.-- if 2004.
    logical.sub.-- if
               A logical.sub.-- if 2004 (logical interface) is contained
               by a single logical.sub.-- node 2000. A logical.sub.-- if 2004
               is
               connected to a single logical.sub.-- segment. A logical.sub.--
               if
               2004 implies that a logical.sub.-- node 2000 is a
               member of a logical.sub.-- segment 2018.
    logical.sub.-- segment
               A logical.sub.-- segment 2018 is connected to zero
               or more logical.sub.-- ifs 2004. A logical.sub.-- segment
               2018 is bounded by zero or more
               logical.sub.-- connectors 2006. A logical.sub.-- segment
               2018 may contain another logical.sub.-- network 2012 to
               define additional layers of detail of a
               logical.sub.-- network 2012, or may contain a
               physical.sub.-- network 2032 (which thereby ends the
               nesting definitions of logical.sub.-- networks).
    logical.sub.-- connector
               A logical.sub.-- connector 2006 is a specialization of a
               logical.sub.-- node 2000. A logical.sub.-- connector 2006
               bounds zero or more logical.sub.-- segments 2018.
    logical.sub.-- network
               A logical.sub.-- network 2012 contains zero or more
               logical.sub.-- segments 2018 and is contained by zero or
               more logical.sub.-- segments 2018. That is, a
               logical.sub.-- segment 2018 at a given protocol layer is
               implemented by a logical.sub.-- network 2012 at a lower
               protocol layer.
    ______________________________________

    ______________________________________
    logical.sub.-- network.sub.-- containment
                    2014 associates a logical.sub.-- network 2012
                    with its containing logical.sub.-- segment
                    2018.
    logical.sub.-- segment.sub.-- containment
                    2016 associates a logical.sub.-- network 2012
                    with its contained logical.sub.-- segments
                    2018.
    logical.sub.-- node.sub.-- containment
                    2002 associates a logical.sub.-- if 2004 with
                    its containing logical.sub.-- node 2000.
    logical.sub.-- interface.sub.-- connection
                    2010 associates a logical.sub.-- segment
                    2018 with its connected logical.sub.-- if 200.
    logical.sub.-- boundary
                    2008 associates a logical.sub.-- segment
                    2018 with its bounding
                    logical.sub.-- connectors 2006.
    ______________________________________

    ______________________________________
    media.sub.-- network
                 2038 this is the highest level of the low level
                 media elements contained by a
                 physical.sub.-- segment 2036.
    media.sub.-- terminator
                 2048 not all media technologies require
                 termination, but if they do, here it is.
    media.sub.-- cable
                 2042 a media cable is anything which
                 connects any two other media elements.
    media.sub.-- fitting
                 2044 this may be a barrel or tee connector in
                 thinLAN Ethernet, a media filter in Token
                 Ring, or anything else found between or at the
                 end of cables. Connectors which are an integral
                 part of the cable, like RJ-45 connectors at the
                 end of a twisted-pair cable, are usually
                 considered part of the cable and are not
                 modelled separately (although there is no
                 restriction saying they can't be).
    media.sub.-- connector
                 2046 this might be something as simple as a
                 telephone wire punch-down block for twisted-
                 pair, or as complex as a passive, unmanaged
                 Token Ring MAU.
    media.sub.-- containment
                 2040 is the resource aspect type used to
                 associate a media.sub.-- network 2038 with its
                 containing physical.sub.-- segment 2036.
    ______________________________________

                  TABLE 4
    ______________________________________
    Object Derivations for FIG. 11
    Resource Aspect Type
                        Specialization of:
    ______________________________________
    ip.sub.-- network   logical.sub.-- network
    ip.sub.-- node      logical.sub.-- node
    ip.sub.-- if        logical.sub.-- if
    ip.sub.-- router    logical.sub.-- connector
    ip.sub.-- subnet    logical.sub.-- segment
    link.sub.-- network logical.sub.-- network
    link.sub.-- node    logical.sub.-- node
    link.sub.-- if      logical.sub.-- if
    link.sub.-- bridge  logical.sub.-- connector
    link.sub.-- segment logical.sub.-- segment
    10baset.sub.-- network
                        physical.sub.-- network
    10baset.sub.-- node physical.sub.-- node
    10baset.sub.-- if   physical.sub.-- if
    10baset.sub.-- hub  physical.sub.-- connector
    10baset.sub.-- segment
                        physical.sub.-- segment
    tp.sub.-- network   media.sub.-- network
    RJ-45.sub.-- jack   media.sub.-- fitting
    tp.sub.-- cable     media.sub.-- cable
    tp.sub.-- block     media.sub.-- connector
    ______________________________________

    __________________________________________________________________________
    Resource-aspect
                  Rules
    Type (RAT)    Role    Min
                             Max
                                Associated RAT
    __________________________________________________________________________
    logical.sub.-- network
                  network 0  1  logical.sub.-- network.sub.-- containment
                  network 0  1  logical.sub.-- segment.sub.-- containment
    logical.sub.-- network.sub.-- containment
                  container
                          0  1  logical.sub.-- network
                  container
                          0  N  logical.sub.-- segment
    logical.sub.-- segment.sub.-- containment
                  container
                          0  1  logical.sub.-- segment
                  container
                          0  N  logical.sub.-- network
    logical.sub.-- node
                  logical.sub.-- device
                          0  1  logical.sub.-- node.sub.-- containment
    logical.sub.-- node.sub.-- containment
                  container
                          0  1  logical.sub.-- node
                  container
                          0  N  logical.sub.-- if
    logical.sub.-- if
                  interface
                          0  1  logical.sub.-- node.sub.-- containment
                  interface
                          0  1  logical.sub.-- interface.sub.-- connection
    logical.sub.-- interface.sub.-- connection
                  connector
                          0  1  logical.sub.-- if
                  connector
                          0  1  logical.sub.-- segment
    logical.sub.-- segment
                  segment 0  N  logical.sub.-- interface.sub.-- connection
                  segment 0  1  logical.sub.-- boundary
                  segment 0  1  logical.sub.-- network.sub.-- containment
                  segment 0  1  logical.sub.-- segment.sub.-- containment
                  segment 0  1  physical.sub.-- network
    logical.sub.-- boundary
                  bounds  0  N  logcal.sub.-- segment
                  bounds  0  N  logical.sub.-- connector (inherited)
    logical.sub.-- connector
                  connection device
                          0  1  logical.sub.-- boundary
    physical.sub.-- network
                  phy.sub.-- network
                          0  1  logical.sub.-- segment
                  phy.sub.-- network
                          0  1  physical.sub.-- segment.sub.-- containment
    physical.sub.-- segment.sub.-- containment
                  container
                          0  1  physical.sub.-- network
                  container
                          0  N  physical.sub.-- segment
    physical.sub.-- node
                  chasis  0  1  physical.sub.-- node.sub.-- containment
    physical.sub.-- node.sub.-- containment
                  container
                          0  N  physical.sub.-- if
                  container
                          0  1  physical.sub.-- node
    physical.sub.-- if
                  interface
                          0  1  physical.sub.-- node.sub.-- containment
                  interface
                          0  1  physical.sub.-- interface.sub.-- connection
    physical.sub.-- interface.sub.-- connection
                  connector
                          0  1  physical.sub.-- if
                  connector
                          0  1  physical.sub.-- segment
    physical.sub.-- segment
                  segment 0  N  physical.sub.-- interface.sub.-- connection
                  segment 0  1  physical.sub.-- boundary
                  segment 0  1  physical.sub.-- segment.sub.-- containment
                  segment 0  1  media.sub.-- containment
    physical.sub.-- boundary
                  bounds  0  N  physical.sub.-- segment
                  bounds  0  N  physical.sub.-- connector (inherted)
    physical.sub.-- connector
                  bounds  0  1  physical.sub.-- boundary
    media.sub.-- containment
                  attachment
                          0  1  physical.sub.-- segment
                  container
                          0  1  media.sub.-- network
    media.sub.-- network
                  media.sub.-- network
                          0  1  media.sub.-- containment
                  media.sub.-- container
                          0  N  media.sub.-- cable
    media.sub.-- terminator
                  termination
                          0  1  media.sub.-- cable
    media.sub.-- cable
                  physical wire
                          0  1  media.sub.-- terminator
                  physical wire
                          0  1  media.sub.-- fitting
                  physical wire
                          0  2  media.sub.-- connector
                  physical wire
                          0  1  media.sub.-- network
    media.sub.-- fitting
                  cable link
                          0  1  media cable
    media.sub.-- connector
                  connector
                          0  1  media.sub.-- cable
    __________________________________________________________________________

    ______________________________________
    FUNCTION TITLE -
                Descriptive name of the function.
    INTRODUCTION -
                Introductory commentary (if any) where
                necessary to describe the purpose of the function.
    INPUTS -    General description of parameters supplied by the
                calling application program.
    PROCESSING -
                Overview of the processing performed by the
                function.
    OUTPUT -    General description of the output produced by the
                operation of the function.
    ______________________________________