JPH10116219A - Managing method for topological combination between objects - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage topological combination between objects to be used by generating a data structure showing the relation between core objects of a resource name closure set. SOLUTION: In the topological management method, data structure, and a method combined with it common resources are accessed and processed application programs which use mutually different resource aspects processes. The resource aspect type(RAT) 212 of the resource aspect(RA) of each application is defined by the data structure and executed by a relation RA 202 data structure assorted by the RAT 212. This data structure and method combined with it recognize the point of time when the same resource is actually referred to with the resource name(RN) that several resource aspects are given to the RA 202. This is achieved by representing the resource 200 by respective RAs 202 in a resource name closure set.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an enterprise management system, and more particularly, to an enterprise management of an object-oriented model by a computer which can be used for managing an object having a feature of topological connection. .

[0002]

BACKGROUND OF THE INVENTION Management systems utilized in business or other enterprises often employ computer systems to automate aspects of enterprise management. Enterprise management, as used herein, relates to the management of all objects used by an enterprise (i.e., a business entity) and the topological connections between those objects. Also,
As used herein, "topological assoc
"iations)" means a connection or relationship between a plurality of objects. These connections or relationships are often expressed visually. A set of objects and the topological connections between them is referred to herein as a “topology”.
(topology) ". Systems that manage such topologies are referred to herein as "topological" management systems. Typical examples of such topological enterprise management computer systems are personnel management systems, asset management systems, network / computing management systems, communication management systems, and business office management systems. Large enterprises can use computers and computers to help manage these and other aspects.
It is common practice to use the system.

For example, an enterprise may manage wage operations through the management of objects such as paychecks, employees, withholding books, retirement books, and the connections between them. One employee is combined with one withholding account and one retirement account, but for paychecks, several records are combined. Or, as another example, managing an enterprise network involves coupling between several subnets, between a node and its neighbors, between a node and its users, or between a particular program and its users. Maybe.

[0004] Prior art management information application programs that generally attempt to manage the topological aspects of an enterprise are characterized by managing objects and connections between objects individually. The rules governing the connections between objects basically define the topology. For example, the rules that define the coupling between nodes and protocol layers in a Transmission Control Protocol / Internet Protocol (or TCP / IP) network define a TCP / IP topology. Therefore, the enterprise management application related to TCP / IP network management is TCP / IP
Pursue enforcement of the rules that define the topology.
In any known prior art management application, there is no enterprise-scale standard that defines such a topology, but rather various individual solutions, each managing a particular topology within the enterprise. And the situation tends to multiply.

[0005] The types of managed objects and the managed connections between those objects vary widely from one enterprise topology management system to another. Taking advantage of disparate computer management tools for each of several internal management tasks common to enterprises,
This is a general method in the related art. Tools that are well tuned for specific uses and aspects of enterprise management are often required to be general purpose tools that incorporate more functionality in a more generalized form. Due to such requirements, it is common to use a plurality of management tools, each created by a different vendor and optimized for different management tasks. For example, the HR management task may be to select the appropriate accounting system for payroll calculations, while maintaining a different, different organizational entity to maintain other HR records and staffing (such as organization charts). Tools may be required.

A first problem with the use of heterogeneous application programs is the increased development effort to create the required application. Often, various management applications are developed by various development groups over a period of time. Each application tends to develop its own structures and methods to manage the topological coupling between managed objects. Such redundant development increases the complexity and associated costs of developing such a topological management application. In addition, various independently developed structures and methods for managing topological coupling between managed objects tend to result in incompatible designs that are difficult to integrate.

A second problem with the use of heterogeneous systems for different management tasks that exploits common elements of information lies in the necessary duplication of stored information. Because each of the typical heterogeneous management tasks uses its own format and structure for information storage, it is common for similar information to be duplicated in the information storage of some management applications. For example, one management application may need information about an employee in connection with payroll, while another application may need information about the same employee to use for travel planning. Both management applications will need access to common information, such as company email numbers and extensions. Two disparate management applications may each store this common information for use in various tasks (such as paying wages and travel itineraries).

[0008] Such redundant storage of common information results in increased demands on the total storage capacity of the enterprise. More seriously, if such common information is modified (eg, when an employee moves to a new corporate email number location), the information is updated in one application but not in another. May not be updated in some applications. The potential inconsistency of such information managed by enterprise management applications creates problems for information managers. Each heterogeneous management application must be responsible for updating its own stored version of all common elements of information.

To avoid the information duplication problem as described above, Enterprise will initially attempt to integrate all possible enterprise information management subsystems early in the design phase. With such a scheme, it would be possible to build an integrated enterprise-wide information storage base that could avoid unnecessary duplication of stored data. Regardless of the planning accuracy applied to the initial design of the unified management information storage base, it is clear that a new management information application will need to be created after implementation.
Such new applications will require significant redesign of the initially integrated information base.
This requires a great deal of effort to redesign the information storage base. Design change efforts often require the human resources of a centralized management information technology group to coordinate the necessary changes to maintain the desired information integration.
Such centralized integrated control and human redesign interference conflict with the ongoing trend of decentralized data processing resources within the enterprise.

[0010]

In view of the above points,
Clearly, a need exists for an improved topological information management system that automates the maintenance of topological connections between objects. That is, to reduce duplication of information stored in a topological management system while maintaining a form that allows new applications to be integrated with existing applications more easily than known prior art approaches. There is a demand for a system that can do this.

[0011]

SUMMARY OF THE INVENTION The present invention solves the above-identified problems by providing a method and associated structure for managing topological connections between objects used in an information management data processing application. And develop the technology in this field. The methods and structures of the present invention allow application designers to create management information application programs that manage topological information of disparate aspects (ie, aspects or aspects).

The present invention provides an application program interface (hereinafter abbreviated to API for Application Program Interface) that is utilized by an application programmer to create a topological information management application. The API of the present invention allows the creation, deletion, and modification of connections between objects provided by application programs. The above connections represent (ie, imply) the topological connections between related objects provided by the application program. Objects that are recognized by the API through the creation of a connection are referred to herein as "managed objects."

[0013] Topological rules defined by application programs control the creation, deletion and modification of topological connections between objects. These topological rules are stored and enforced by the API to control the handling of bindings between managed objects by application programs. AP of the present invention
I enforces consistent rules on the handling of topologies managed by the API on behalf of some application programs.

Since the API provides a common structure and method for managing the topology, the duplication of information common to some application programs is reduced. The API of the present invention provides a simple interface for application developers to determine what information about a particular binding between managed objects is currently managed by the API. The application developer defines a specific set of attributes that can be used in the management application and uniquely define the objects handled by the application. An object actually defined as such by one application refers to the same entity (an entity is another name for a resource) as another object provided by the same or another application for API topology management. Is detected by the API of the present invention. This allows the application program to:
It has its own view of the entity represented by the object used by the application. One
The perspective of objects used by two application programs is referred to herein as a resource aspect (as
pect, face).

The topology management API of the present invention has a certain
One application program is provided with topological information of other managed objects that are identified as representing 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 information base across the enterprise. A general topological query is a query that can provide information about managed objects and their managed topological combinations, specifying queries that are simple textual but simple to complex Generated so that you can. These queries can handle objects and bindings beyond the information handled by a single application program. Inquiry related A
The PI function returns to the queryer a subgraph object structure that contains the managed objects that match the query and their managed topological connections.

As a means of solving the above problems, the present invention provides a method for managing the topological connection between a plurality of objects each having at least one resource name to identify one resource by using a computer. Including.
The method includes providing a storage device for storing and retrieving information, receiving a request to manage an object, and generating a data structure in the storage device in response to receiving the request to manage an object. Performing the step of: associating the object with the resource identified by the at least one resource name of the object, representing the resource by the object; determining a resource name closure set of a plurality of objects, each representing a shared resource. And generating a data structure indicating a relationship between objects in the resource name closure set in the storage device in response to the determination of the resource name closure set.

Further, the method of the present invention includes the steps of receiving a request to add a specified resource name to a specified object, and responsive to receiving the request to add a specified resource name. Updating a data structure indicating a resource name owned by the specified object by adding the resource name to the resource name owned by the specified object; Re-determining a resource name closure set of a plurality of objects representing a shared resource; and a data structure in the storage device indicating a relationship between each object in the resource name closure set in response to the re-determination of the resource name closure set. Is updated.

[0018]

DETAILED DESCRIPTION OF THE INVENTION The present invention includes an application program interface (or API) that manages topologically linked objects according to rules defining one or more topologies. The “topological connection” in this specification means a connection between objects that can be represented in a graph. The collection of objects and the topological connections between them are referred to herein as "topology." Systems that manage such topologies are referred to herein as "topological" management systems. What is topological management?
It is also called relationship management. Using the terminology of relationship management, a topology is a set of managed relationships between managed objects, and topological information is a relationship between managed objects. Topological enterprise database also means a relational management database that contains topological information.

FIG. 12 outlines a typical method applied to enterprise management by prior art designs. Each of the enterprise management tasks is designed using a custom application program. Each application program typically has its own database that provides information and associated structures suitable for the particular application. In particular, typical applications used to manage topological information include a human resources (HR) management application 1200,
Includes an asset management application 1202 and a network / computing management application 1204. Each application has its own unique application database associated with the application, eg, a human resources (HR) database 1206;
It has an asset management database 1208 and a network / computing management database 1210.

Some information is common to all three management applications. For example, HR database 1
The employee data at 206 is stored in the asset database 12
Some common information is shared with the user data at 08 and the user data at the network / computing database 1210. The duplication of data in the three databases raises such prior art design problems. As discussed above, the issues are related to the updating of separate databases, unnecessary duplication of storage space, and the difficulty of integrating multiple applications as they grow and evolve.

FIG. 13 outlines an enterprise management application design enabled by the topology management service of the present invention. Like FIG. 12, FIG.
Human resources (HR) management application 1300, asset management application 1302 and network /
3 illustrates three separate management applications, a computing management application 1304. These three
Application programs 1300, 1302
And 1304 are placed above the dotted lines in FIG. 13 to indicate that they are client application programs. However, unlike prior art designs, all three of these applications utilize the common topology server 1314 of the present invention.
The topology management server 1314 manages topological information (connection information 1320) and manages topological aspects (aspects) of objects processed by the three client application programs 1300, 1302, and 1304. Therefore, all such topological information (combination information 1320)
Are managed according to a common set of rules via a common server program interface (topology server 1314). Thus, each application client program shares the obtained topological information with other application client programs.

Other non-topological information is provided to application servers through the use of dedicated server programs such as employee servers 1306, asset servers 1308, and network / computing servers 1310.
It can also be managed by a client program. In this case, as shown in FIG. 13, the server program can then call another common server program, such as a personnel server 1312, to efficiently share the common elements of information. Personnel server
The program 1312 manages non-topological information on personnel in the personnel information 1316. The asset server program 1308 manages asset information 1318 that is unique for that particular management task. Similarly, network /
The computing server program 1310
Manage network / computing information 1322 that is unique to the application.

FIG. 1 is a block diagram of computer hardware including the topology management service system of the present invention. In FIG. 1, a computer system 1
00 includes a processing element 102 that communicates with other internal elements in the computer system 100 via 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. Network interface 11
2 is used to connect the system 100 to the network 118, allowing the computer system 100 to act as one node on the network, thereby communicating with other nodes on the network. Disk 114 is used to store the software of the topology management system of the present invention, store a topological enterprise database, and store managed objects. Printer 116 can be used to provide a hard copy output of the topology information displayed by the system.

The main memory 11 inside the system 100
0 includes the topology management system 120 of the present invention.
Applications developed by users of the present invention
The program 126 executes the topological management system 120
Management system 120 then communicates with operating system 122 and storage management software 124
To perform topological management services for client application programs. Client application program 126
It may operate locally in the computer system 100, or may operate on another connected computer system and communicate via a network. As will also be appreciated by those skilled in the art, information stored in the topological enterprise database may be stored locally on disk 114 or locally in main memory 110. Alternatively, it may be distributed to another computer system accessible via a network, or may be stored in a form in which various storage devices are combined. For example, permanent storage of information may be on a local or remote disk subsystem, and the local memory
A cache can also be used to improve processing performance. More generally, the information stored in the topological enterprise database may be stored on any storage device or subsystem having appropriate capacity and processing performance characteristics. The term disk 114, as used herein, should be construed as representing any such suitable storage device or storage subsystem.

FIG. 2 is an overview of the data structures and relationships created and managed by the topological management method of the present invention. FIG. 2 shows the data structure and relation of the present invention from the viewpoint of object-oriented analysis. FIG.
Is drawn according to the FUSION object model and should be interpreted accordingly. F
USION is an object-oriented analysis and design tool developed by Hewlett-Packard. If you are unfamiliar with such object-oriented design, please refer to Prentice Hall Publishing Company, ISBN 0-13-338823-9) "Obje
See the FUSION method described in "ct-Oriented Development-the Fusion Method".

In FIG. 2, the data structures are indicated by numbered boxes, and the relationship between the data structures is indicated by the lines connecting the relevant boxes to diamond-shaped entities. In FIG. 2, the lines connecting the data structure boxes are numbered to indicate the type of relationship between related boxes.
For example, the sign "1" indicates that exactly one data structure is involved in the relationship. The sign "*" indicates that zero or more data structures are involved in the association,
A "+" sign indicates that one or more data structures are involved. For example, one between two data structures
The one-to-one relationship is indicated by the symbol "1" at both ends of the line connecting the data structure boxes in a diamond-shaped relationship. A one-to-many relationship is indicated by a "1" on the line connecting the first data structure box and a "*" or "+" on the line connecting another data structure box on the opposite side. A one-to-one relationship indicates that each of the data structures represented by boxes at one end of the relationship is exactly related to one of the types of data structures on the other side of the relationship. A one-to-many relationship is one in which each of the data structures represented by the boxes connected to the relationship having the line labeled "1" has zero or more (or line ends) opposite the relationship having the line labeled "*". If "+" is one or more)
Related to the data structure of

Data Structure Resources, Resource Aspects and Resource Aspect Types In FIG. 2, a resource 200 is a combination of all aspects of one "thing" that is relevant to the application of the method of the present invention. It is a data structure showing characteristics. Resource 200 is an instant of matter, at the highest level of abstraction, to be managed by the present invention. For example, people, buildings, networks or computing nodes are examples of abstractions managed by the topology management methods of the present invention. A useful level of abstraction for certain applications of the invention is a matter of design choice, often related to known methods of object-oriented design analysis that are common to software engineering arts.

The resource 200 includes one or a plurality of resource aspects (hereinafter, may be abbreviated as RA with an abbreviation of Resource Aspect) 202. RA20
2 is one object supplied by the application program using the topological management method of the present invention. RA 202 is related in FIG.
(relation) 210 further includes a topological component 206 associated with zero or one non-topological component 208. R
The topological component 206 of A 202 includes information related to the topological management service of the present invention, namely, resource name, associated resource aspect type, and RA.
202 includes details regarding the bindings involved. Details of these elements will be described later. The non-topological component 208 of RA 202 is unique to the application program using the object,
It contains information that is not otherwise included in the topological management method of the present invention.

The resource name (hereinafter sometimes abbreviated to RN by taking the initials of Resource Name) is a field having a tag name and a currently assigned value. Resources 200
It is uniquely defined by one or more resource names (stored in resource aspect 202 as described below). Specifically, the resource 200 is the resource 20
It is uniquely identified by a transitive closure that merges all resource names stored in all currently managed RAs 202 as an aspect of zero.

Table 1 below shows an example of a hypothetical set of data structures.

[0031]

[Table 1]

In the example of the data structure shown in Table 1 above, the resource
Person1 is all resource names, SSN: 123456789, EMPN
Recognized by the transitive closure of O: 11221 and ACCTNO: 998761. Resource Person2, on the other hand, is recognized by its unique resource name: SSN: 987654321, EMPNO: 21212 and ACCTNO: 66884.

The RN that uniquely defines the resource 200 is
Supplied by an application program utilizing the method of the present invention. An application program utilizing the present invention identifies a particular resource 200
Providing an RA 202 containing one or more RNs requests that the object be managed by the topological management method of the present invention. RNs not already provided in the object by another application program are added to the set of known properties of the specified resource 200 (ie, the set of RNs). Each RA 202 identifies the combined resource 200 by a particular subset of RN values. Therefore, resource 200
Is the merging or integration point for all resource names known in all RA 202 subsets of the RN.

The objects provided to the topological management system associate each object with a resource 200 uniquely identified by the provided RN.
Managed by letting If the supplied RN does not correspond to any existing resource 200, a new resource 2
00 is created automatically. Therefore, each resource 200
Combines with one or more RAs 202. Each of the RAs 202 that couple to the resource 200 may be said to represent one particular aspect of the resource 200.

Each application program that uses the topology management method of the present invention may utilize a different subset of the resource names that define resource 200. For example, one application program may be interested in "people" resources as "employees", while another application may see the same "people" as "club members". Similarly, one application may view a "network" resource as a "TCP / IP local area network" and may be interested in handling RNs with respect to the aspect of a "network" resource. However, another application is the "network" resource R
You may be interested in N aspects of a "wide area network." Each subset of RNs for resource 200 is:
It is called an aspect and is represented by one RA 202.

Each RA 202 is a resource aspect type
There is a one-to-one relationship with 212 (which may be abbreviated as RAT hereinafter, taking the initials of resource aspect type). Since the resource 200 may be represented by several aspects (some RAs may completely describe one resource in terms of several different application program aspects), the RAs 202 and R
Although a many-to-many "classifies" relationship 220 is shown between the ATs 212, the built-in rules (also referred to as invariants) within the scope of the present invention are that one resource must be a particular RAT 212 (or So specific RA
T212 and special types of that type).

[0037] The RAT 212 constrains the type of relationship in which the associated RA 202 participates. The set of rules bound to RAT 212 defines the constraints that apply to the aspects of resource 200 represented by RA 202. Constraints include pre-defined built-in rules that can be modified and fully defined by the application programmer to extend the rules. Each RA
The configurable rule part defined in T212 is a list of roles that have already been defined and given names. Through this role list, the RA 202 participates in binding (the details of this will be described later).

To be consistent with the object-oriented design / analysis underlying the use of the present invention, RAT 212
It may be defined as a single class or as a specialization of an already defined RAT class. The already specified class special type inherits all the attributes of the previously defined class, and specifies additional properties and constraints. For example, "permanent employee"
And "employee" are the "employee" resource aspect
It can be considered a special type of two resource aspect types of RAT 212 that specify constraints on the type. The newly defined special type RAT 212 is different from the previously defined RAT 212 in the sense that the special type of the RAT 212 inherits all the attributes of the RAT 212.
And a “specialization” relationship indicated by a relationship 214.

That each RA 202 represents one aspect of one "thing" is one example of a built-in rule associated with a resource. The constraint is that each RA 202:
Combined with only one RAT 212, any resources 20
0 are also two RAs classified by the same RAT 212.
202 (or two RATs where the RAT that categorizes one RA is a special type of RAT that categorizes the other RA
It is specified by stating that it cannot be represented by A). Details of the constraint specified by each RAT 212 will be described later.

Resources 200 are not explicitly managed by application programs that utilize the topological management methods of the present invention. Rather, a topological management method creates, modifies, and deletes resources 200 based on the resource aspects passed to the topological management method. In other words, each time an object is provided to the topological management service according to the object management request, the resource 200 is created, deleted, or modified based on the resource name provided in the RA 202. Conversely, if the application program specifies a managed RA 202 with a request to unmanage the object, the associated resource name is adjusted to match the remaining resource name known for the affected resource 200. Resource 200 to be created, deleted, or modified. Details of the methods of the present invention for creating, deleting, and modifying resources 200 are described below.

ASSOCIATIONS binding 204 defines the interaction between two RAs 200. For example, two "person" resources 200, each represented by an RA 202 having a resource aspect type 212 of "employee", may sometimes be "work for" to represent an enterprise HR organization. (w
oroks for) ". The same two resources are combined 204 called "woroks for" for the same or another application program.
May be involved. Similarly, "network" and "computing node" resources may participate in a "connection" coupling.

The binding 204 is created by an application program that uses the topological management methods of the present invention and reflects the binding between the two resource aspects 202. The application program invokes a topological management method to create a new binding. The application creates a list of RAs 202 and a definition of the "roles" played by each RA in the new binding. "Role" in binding
The details of the use will be described later.

Each of the application programs that use the topology management method of the present invention
Different correlations between 0 can be used. For example, an application program may “works for” or “work with” between “human” resources 200 as viewed from the “employee” aspect RA 202.
swith), while another application program might be interested in a "family member"
The same two “people (perso) viewed from the aspect RA202
n) "is the child o" between resources 200
f) "or" is married to "union.

Topology Invariants Rules, Roles, Enforcement Functions, and Notification Receiving Mechanisms Built-in Invariants
Includes built-in rules that reject certain inappropriate requests generated by application programs. The method of the present invention rejects a client application program request that results in the resource 200 being represented by an RA, for example: * Multiple RA20s categorized by the same RAT212
2, or * The request is rejected for multiple RAs 202 where the RAT 212 classifying one RA is a special type of another RAT.

Configurable invariants (roles) and other rules are configurable by the client application program and are defined and stored using the RAT 212. RAT21 binding to each RA202
2 defines a set of rules that list the allowed binding roles for that RAT 212. Specifically, each RAT
The rule at 212 is a connection 204 with another RA 202
Are listed for the associated RA 202 in forming the. By applying these rules, the method of the present invention prevents the formation of invalid bonds 204 between resources 200 when represented by RA 202. As mentioned above, the binding 204 is created by a client application program that provides the two RAs 202 to be combined and the required role for each RA. The desired binding is formed only if the RAT 212 associated with each designated RA includes a role that allows the formation of a binding with the designated role used for the designated RA 202.

In addition to specifying the roles allowed to form a bond, the rules defined and stored using RAT 212 specify other attributes for the permitted bonds. Specifically, each rule defines the RA to be used for other RAs 202 that form an acceptable combination.
Specify T212. In addition, the rules specify the minimum and maximum cardinality of such bonds allowed. The minimum radix indicates that the RA 202 categorized by the RAT 212 that defines the rule has at least the radix or more of the number of bonds involved in a bond 204 with another allowed RA 202. The maximum radix indicates that the number of such bonds 204 involving RA does not exceed that radix.

Extending Constraints (Enforcing Functions) In addition to embedding and configurable invariants, client application programs can define topologically managed enterprise applications by defining application-specific rules (enforcing functions). Other changes to the database can be checked for validity. The enforcement function 216 is defined by an application program by creating a program function that is executed to check the validity of a change to a particular resource. The enforcement function's program function is invoked to check for any changes specified for the resource associated with the RAT 212 that defined the enforcement function 216. The function of the enforcement function 216 has as input the resource 200 and the RAT 21
Use 2 to evaluate the attribute of the specified change to the resource and return a value indicating the attribute of the specified change to the function. If the enforcement function 216 function returns a value indicating an improper change to the resource, the specified change is rejected by the topological management method. The enforcement function 216 provides maximum flexibility in checking the integrity and attributes of resources in the topologically managed enterprise database.

Notification Receiving Function The notification receiving function 226 is related to the RAT 212 (222).
Object that defines the interface for receiving notification of a change in a particular RAT 212 in the managed topology. The notification receiver object indicates that a change of a certain predefined type
Associated with one or more defined trigger conditions that are each triggered when executed against the AT 212.

The notification receiving function 226 also
(224), and defines an interface for receiving notification of a change to a specific RA 202 in the managed topology. The notification acknowledgment object is associated with one or more defined trigger conditions, each of which is triggered when a particular defined type of change is performed on the relationship RA 202 in the topology. The notification acknowledgment function enables the first application program to be notified when the second application program changes the topology in a manner that may affect the first application program. .

Resource Integration The topological management method data structure of the present invention and its associated methods allow different application programs, each using a different resource aspect, to access and process the shared resource. The resource aspect of each application is defined by a RAT 212 data structure and is implemented in a relational RA 202 data structure categorized by the RAT 212.
Each resource aspect can be processed independently of all other resource aspects of the same shared resource.

The data structure of the present invention and the methods bound to it have several resource aspects
Recognize the point in time when the same resource is actually referred to by the resource name (RN) given to. This is the "resource name closure set
(resource name closure set) by "representing" the resource 200 by each of the RAs 202. "Represent" means that the resource 200 is not referenced directly by the client application program, but is indirectly referenced through the RA 202 that "represents" the resource. A “resource name closure set” is a resource aspect (ie, RA20) in which each resource aspect in the set is configured to share at least one resource name (RN) with at least one other resource surface.
This is the maximum set of 2). In other words, it is a transitive closure of the common part of the resource name for the resource aspect (RA 202). The resource closure set contains a resource aspect (RA
The resource 200 is identified as a set of 202).

Any change to the topological enterprise database that has been validated (by application of all invariants and enforcement functions) can affect resource consolidation. The new resource name provided by the new managed object input to the topological management service of the present invention changes the resource name closure set, thereby changing changes to the resource 200 known to the topological management service. Can be requested.

FIG. 3 illustrates a specific example of the operation of resource consolidation on a typical topology. The detailed operation of the methods used to manage the topology, especially the resource integration of the managed topology, is described below. The topology 300 is the (prior) of the managed topology prior to the addition of new objects to be managed under the topology.
This is a snapshot. RESOURCE1 (Resource 1)
302 and RESOURCE2 (resource 2) 304 are two resources in the managed topology. In this exemplary topology, both resources represent "person" resources. RESOURCE1 (302) is "represented" by resource aspects (RA) 306, 308 and 310, while RESOURCE2 (304) is "represented" by resource aspect 314. RESOURCE
The resource name closure sets for 1 (302) are resource aspects 306, 308 and 310. This is because it is the largest set of RAs that share at least one resource name (RN) with at least one other RA. Similarly, the resource name closure set for RESOURCE2 (304) is a single 314. The topology management service of the present invention provides a complete set of managed RAs (30
6, 308, 310 and 314) have two separate resources (people): RESOURCE1 (302) and R
Recognize that it represents ESOURCE2 (304). The object 312 of the (advanced) topology 300 has not yet been presented to the topology management service to be managed in the topology.

Topology 350 is a (post-mortem) snapshot of the same topology after object 312 has been added to the set of objects managed under the topology. In the topology 350, the object 312 has already been presented to the topology management service, and is a resource aspect 312. As a valid change to the managed topology, the resource name closure set is again determined by the topology management service for all managed resources. Newly managed RA3
12 is a resource name shared by RA 310 and RA 3
14 have another resource name shared by them. Thus, the resource name closure set now contains all RAs managed in topology 350, ie, 306, 308, 31
0, 312 and 314. RESOURCE1
(302) and RESOURCE2 (304) have ceased to exist as independent resources, and now a new resource R
ESOURCE3 (316) is represented by the full set of RAs, 306, 308, 310, 312 and 314.

In FIG. 3, topology 350 is the result of adding object 312 to topology 300. In FIG. 3, the operation in the opposite direction can be observed by simply reversing “before” and “after”. In other words, the topology 350 is an initial condition of the managed topology, and the user is not allowed to manage the currently managed RA3.
If it is requested to delete 12 from the management service of the topology management service, the topology 300 is the result. In particular, when the RA 312 is deleted from the topology 350, the mechanism for resource name closure determination reveals that the number of resource names that was one is now two. RESOURCE3 (316) of topology 350 is discarded and RESOURCE1 (302) and RESOURCE1 are deleted.
E2 (304) is created at that location.

The topology management service of the present invention determines a resource name closure set after a topological change that may affect the relationship between resources and resource aspects.
4-6 illustrate yet other changes made by the topology management service in response to other types of changes affecting topology resource consolidation. In FIGS. 4 to 6, resource aspects are abstractly indicated by codes such as RA1 to RA8. The specific content of the resource aspect is not important in understanding the type of operation shown in FIGS.

FIG. 4 illustrates the reverse topology management function shown in FIG. In FIG. 4, the initial state of the topology 400 is such that the resource closure sets representing RESOURCE1 (402) are RA1 (406), RA2 (408), and RA3 (41).
0) and RA4 (412), while RESOURCE
It indicates that the resource closure sets representing E2 (404) are RA5 (414) and RA6 (416). RA3 (410)
Is removed from the management service ("unmanaged"),
The result is topology 450, RESOURCE1
(402) is discarded, and instead two new resources R
ESOURCE3 (418) and RESOURCE4
(420) is created. Release of management of RA3 (410)
Discard sharing of at least one resource name among the previous members of the resource name closure set representing RESOURCE1 (402). The new RESOURCE3 (418) is RA1 (4
06) and RA2 (408), while the new RESOURCE4 (420) is represented by RA4 (412). RESOURCE2 (404) is not affected by this change.

The resource name closure set of resources in the topology can also be changed by changing the resource name associated with a particular resource aspect. If a resource name is combined or unbound with a managed resource aspect, the resource name closure set may also change. The resource name associated with a particular resource aspect is a resource aspect type (RAT) that categorizes the resource aspect (RA).
Is determined by FIG. 5 illustrates the topology change that occurs due to the addition of a resource name to the resource aspect. The topology 500 has two resources RESOURCE
1 (502) and RESOURCE2 (504) indicate the initial state of the managed topology. RESOURCE
CE1 (502) transmits its resource name closure set RA1 (50).
6), RA2 (508), RA3 (510) and RA4 (5
12). RESOURCE2 (504)
Are the resource name closure sets RA5 (514), RA6 (5
16) and RA8 (518). If a new resource name (RN) is added to RA8 (518) and the new RN is shared with RA4 (512), the topology 550 is configured by the topology management decision of the resource name closure set of all resources. RESOURCE1
(502) and RESOURCE2 (504) are discarded and a new resource RESOURCE3 (5
20) is created. RESOURCE3 (520)
All RAs known to the topology management service
Is represented by a new resource name closure set containing The addition of a new RN to RA8 (518) has effectively combined two separate resources by combining their respective resource name closure sets. The same result is obtained by adding a new RN to RA4 (512) shared by RA8 (518), and similarly, any one in the first closure set and the other in another closure set. It will be readily appreciated that the same result is obtained for the RA pair.

FIG. 6 shows the reverse operation of FIG. 5 performed by the topology management service. In FIG.
The resource name (R
N) is deleted from one of the objects, thereby dividing the shared resource into two new resources. Initially, as shown, the topology 600
Are all RAs, RA1 (604), RA2
(606), RA3 (608), RA4 (610), RA5
(614), one resource RESOURCE1 (602) represented by RA6 (616) and RA8 (612). After deleting the resource name from RA8 (612), specifically, the only resource name shared between RA8 (612) and RA4 (610), topology 650 is determined by the determination of the new resource name closure set. Generated. In topology 650, RESOURCE1 (602) is discarded and replaced with two new resources RESOURCE2 (618) and RESOURCE3 (620). R
ESOURCE2 (618) is RA1 (604), RA2
(606), represented by a resource name closure set consisting of RA3 (608) and RA4 (610), while RESOU
RCE3 (620) is RA5 (614), RA6 (616)
And RA8 (612). Deleting the RN from RA8 (612) effectively split the resources by splitting the resource name closure set. RA4 shared by RA8 (612)
The same result is obtained by removing one RN from (610), and similarly for any RA pair in the same resource name closure set sharing only the resource name to be deleted. It will be easily recognized.

It will be readily appreciated that the data structures described above can be represented and processed by any of several standard programming techniques.

Typical Application Simple Example This example illustrates how a developer can use the topology management service of the present invention to answer an application specific problem. A manufacturer's service department manages all electrical equipment used throughout the company. The department needs a system to help manage the inventory of electrical equipment.

[0062] Among many system functional requirements is the need to keep track of the power outlet used for the electrical device. The department manages both 110V and 220V electrical equipment. Outlet is also 11V 220V
Some are OV. The department has 22 units of 11 OV electrical equipment
It is necessary to make sure that it is assigned not to be plugged into a 0V outlet and that 220V electrical devices are assigned not to be plugged into a 110V outlet. Application developers could also solve the problem of maintaining the association (ie, coupling) between electrical devices and outlets without using topology management services. However, in that case, developers need to create program code for the following items. * Understand semantic (semantic) constraints on joins and ensure that their semantics are maintained. * Store and maintain join information. * Inquire joins. In addition, if you do not use the topology management service,
It will be difficult to integrate other applications with new applications. For example, an information technology department may want to integrate with electrical maintenance applications to keep track of power connection information about computers. With the concept of resources provided by the present invention, it is possible to recognize the information technology department's perspective and the electric maintenance department's perspective on the same power connection as different perspectives on the same matter. Using the topology query of the present invention, one department can locate one power connection and then access data of other departments (including its own) associated with this power connection. .

Defining a "topology" is part of the process of performing object-oriented analysis and design for a particular problem. It consists of defining a set of resource aspect types and defining inheritance relationships between those types.

The application developer must choose an appropriate level of abstraction for his problem.
For example, a serial connection between two computers may be modeled as a "connection" resource with a connection to two "computer" resources. Alternatively, the series connection may be modeled as a "series card" resource associated with a "cable" associated with another "series card".

One aspect that defines the “topology” is
It is to define the resource aspect type to be used. Each of the resource aspects managed by the topology is categorized by one resource aspect type. A resource aspect type constrains the bindings in which that type of resource aspect can be involved. Resource aspect type rules are used to specify configurable aspects of the resource aspect type semantics. Each of the resource aspect type rules specifies a role name, a minimum and maximum number of bindings. in this case,
Resource aspects must be involved in binding to that role.

Table 2 below shows the resource aspect type rules used for this example. In Table 2 and the following description, Device refers to the device as Power_Out
let or simply let the outlet, Pow
er_Supply is a power supply, Electrical_
Device represents an electric device, and Power represents electric power.

[0067]

[Table 2] Resource Aspect Type (RAT) Rule Rule RAT Role Minimum Maximum Connected RAT Use Electrical_Device 0 1 Power_Supply Use 110V_Device 0 1 Use Power_Supply 0 1 (inherited) Use 110V_Power 220V_Device 0 1 Use Power_Supply 0 1 ( 220V_Power Power_Outlet supply 0 1 Power_Supply 110V_Outlet supply 0 1 Power_Supply supply 0 1 (inherited) 110V_Power 220V_Outlet supply 0 1 Power_Supply supply 0 1 (inherited) 220V_Power Power_Supply use 1 1 Electrical_Device supply 1 1 Power_Outlet 110V_Power use 1 Electrical_Device Use 1 1 (Inherited) Supply 1 1 110V_Device Supply 1 1 Power_Outlet (Inherited) 110V_Outlet 220V_Power Use 1 1 Electrical_Device Use 1 1 (Inherited) Supply 1 1 220V_Device Supply 1 1 Power_Outlet (Inherited) 220V_Outlet

Table 2 above shows how the rules specified for a more generalized type apply to that type of specialization. For example, a resource aspect of the type 110V_Device is (depending on its role of "power usage"), Power_Supply and 110V_Power by a resource aspect type (RAT).
Must participate in binding to resource aspects categorized as r. Both rules apply. 11O
A resource aspect of type V_Power will match both rules, since it is a special type of the Power_Supply resource aspect type. However, the resource aspect type Power_Supply does not match both rules and is therefore invalid.

According to the defined topology semantics, developers can use the topology to create, update, delete and query connections between resource aspects. Table 3 below specifies resource aspects for electrical devices.

[0070]

[Table 3] Resource aspect Resource aspect type VDU 220V_Device Tape_Unit (magnetic tape unit) 220V_Device Paper_Shredder (paper cutting machine) 110V_Device X_Terminal (X terminal device) 110V_Device PC 110v_Device PO-110-1 110V_Outlet PO-110-2 110V_Outlet PO-110 -3 110V_Outlet PO-110-4 220V_Outlet PO-110-5 220V_Outlet P1 220V_Power P2 220V_Power P3 110V_Power P4 110V_Power P5 110V_Power

According to the specified constraints, the developer can create the following connection.

[0072]

[Table 4] Effective combined resource aspect role Resource aspect role P1 supply PO-220-1 supply P1 use VDU use P2 supply PO-220-2 supply P2 use Tape_Unit use P3 supply PO-110-1 supply P3 use Paper_Shredder use P4 Supply PO-110-2 Supply P4 Use X_Terminal Use P5 Supply PO-1130-3 Supply P5 Use PC Use

The problem to be solved is 110V_Dev
ice specifies that it cannot form a bond with 220V_Outlet and vice versa. The resource aspect rules ensure that such constraints are enforced in the enterprise topological database. 11OV_Device and 22OV_De
The radix constraint expressed in terms of the device ensures that each device can participate in only one binding with the appropriate Power_Supply resource aspect. Similarly, 11OV_Outlet and 22OV_
The radix constraints expressed for Outlet ensure that each can have a connection with only one Power_Supply. Such a combination of rules ensures that only one device with the appropriate power rating is plugged into each outlet with the same power rating.

The developer can issue a query request to the topological stored information base. Here is a simple query for this example. The following can be included in the query: * Which outlet should the 220V device be connected to? * Is the document shredder plugged into outlet PO-220-1? * What is the device plugged into outlet PO-110-3? Network Topology Service Example Logical Network Layer Topology Model This topology example utilizes a topological management service of the present invention to manage a logical network. For managing topologies such as TCP / IP networks, Novell networks, Vines networks or most other commercially available network models so that they can be used for appropriate specialization of resource aspect types. , This topological model is well generalized. This topology is composed of "logical_network (meaning a logical network)" including a set of objects and a connection between the objects. logical_net
The work has a common set of objects and connections of most network topologies, and can therefore be used to manage the topology of most commercially available networks. In addition (for example, IP
For a particular network (such as a network), network-specific semantic rules that must be adhered to are introduced. Logical_n in this example
The network topology model defines only basic objects and connections without considering any particular network semantics.

FIG. 20 shows objects managed by the application example of the topology management service of the present invention. Logical_network in FIG. 20
2012 is the total set of objects involved in the network and related connections. Not all objects shown are involved in a particular network implementation. That is, some network semantics do not utilize a given object or combination. The resource aspect types defined in this model are as follows: * logical_node: logical_node
e (logical node) 2000 has zero or more than one lo
digital_if2004 (logical interface). logical_node2000 is a single l
Zero or more logical_segments (logical segments) depending on the physical_if 2004
It is a member of 2018. * Logical_if: logical_if200
4 are contained in a single logical_node2000. logicai_if2004 is one logi.
digital_segment. logic
al_if2004 is logical_node200
0 means a member of logical_segment 2018. * Logical_segment: logical_
segment2O18 is zero or more than one log
ical_if2004. logical
_Segment 2018 is zero or more than one lo
physical_connector (logical connector) 20
06. logical_segme
nt2018 is logical_network20
Another logical defining 12 additional layers of detail
Physical_network (which may complete the nesting definition of logical_network).
2032 in some cases. * Logical_connector: logica
l_connector2006 is logical_
This is a special type of node2000. logical_c
connector2006 is zero or more log
Restrict ical_segment 2018. * Logical_network: logical_
network2012 is zero or one or more log
, including zero, one or more logical_segment 2018. That is, logical_segment 2018 for a given protocol layer is:
Logical in lower protocol layers
_Network2012.

Logical_segment2018
The relationship between and logical_network 2012 will be further described. One logical_segment2
018 is a single logical_network 201
It should be noted that 2 is included. In this sense,
Logical_segment2018 of a certain layer
Is the logical_network of the lower layer
k2012 is defined. In this way, a layered model of most network products can be represented by the topological structure of the present invention. Network "Protocol
The overall layer of the "stack" is the log in the layer above it
ical_segment 2018.
The ISO7 and TCP / IP layer models are:
It is a typical example of such a layered protocol stack. However, one logical_network
rk2012 has multiple logical_segments
Note that it may be included by 2018. Other logica (possibly reflecting other protocols implemented in the same protocol layer)
l_network 2012 also has the same lower lo
digital_network 2012, and therefore
It can also include a given radix. For example, TCP / IP
In network communication (for example, FTP or TELN
Some TCP protocol applications (such as ET) will make use of the same underlying TCP layer (the TCP layer then uses the IP layer, which also uses the lower link layer). ).

The inclusions, connections and restrictive bindings described above are represented in the model as resource aspect types as follows: Using these RATs, certain elements of the logical network are combined with other elements. * Logical_network_containinm
ent (including logical network) 2014: logical
logi that contains al_network2012
bind to cal_segment2018. * Logical_segment_containinm
ent (including logical segment) 2016: logica
l_network2012 contains its contained logi
bind to cal_segment2018. * Logical_node_containment
(Including logical node) 2002: logical_if2
Logical_node 200 that contains 004
Bind to 0. * Logical_interface_connect
Tion (logical interface connection) 2010: lo
The physical_segment 2018 is bound to its contained logical_if 200. * Logical_boundary (logical limit) 20
08: logical_connectors 200 that restricts logical_segment 2018
To 6.

Using this model, it is possible to construct a network representation for a given protocol layer. One logical_segment2
018 and other logical_network20
Twelve protocols, each using one of the protocols
It is possible to build multiple networks representing layers and associate higher layers with lower layers on which they depend.

As an example, ip_network in FIG.
Consider (IP network) 1050. In this example, ip_nodes (IP nodes) 1000 and 10
02 is the resource aspect type logical
A special type of al_node. Similarly, ip_nod
e1004 and e1006 are special types of the resource aspect type logical_if, respectively.
_Router (IP route setting) 1012 is logi
A special type of cal_connector, ip_s
ubnet (IP subnet) 1008 and 1010
Are special types of logical_segment, respectively. ip_subnets 1008 and 1010
(Logical_segment) object is the complete logical_n in the lower layer (consisting of nodes, interfaces and attachments)
Supported by Ework. ip_subn
et1008 includes this lower network. That is, ip_network 1052 and ip_sub
net includes ip_network 1054. A more complete example showing multiple layers and their relationships is shown below.

The physical network layer topology
A physical_network (physical network) 2032 in the model diagram 20 is a logical_network.
slightly different from k2012. It is, for the most part, the l
This is a special type of the technical_network2012 model. The physical_network 2032 topology object is mostly a logical topology
Inherited from object. physical_se
gments (physical segment) 2036 is phys
physical_connect through an ical_boundary (physical restriction) object 2028
r (physical connector) 2026 is restricted. physic
a_connector2026 is physical
_Node_containment (including physical node) object 2022
interface (physical interface) 2024
Physical_node (physical node) 20 including
24 special types. physical_segmen
ts2036 is physical_interfac
physic_i via e_containment (including physical interface) object 2030
interface 2024. phy
local_segment2036 is physic
phy by an al_segment_containment object 2034
local_network 2032. Next, physical_segment 2036 is m
media_network via media_containment object 2040
(Media network) 2038. logical
The major difference from the _network model is the physi
cal_segment 2036 is media_co
m via the object of the element 2040
media_network2038 only, so that logical_segment 2018 and
Terminates the recursive process implied by the relationship of the physical_network 2012. In all other respects, the physical topology model and the objects within it are derived from the logical topology model. In particular, physical_network2
032 is a subtype (or subclass) of logical_network 2012,
logical_segment 2018. In most cases, the lowest level modeled in the network topology service will be physical_network 2032.

The media network layer topology
The lowest possible network topology layer is the media_network (media network) 2038 of FIG. This is basically a set of hardware that forms the physical transmission medium. This layer model is rarely needed for network management applications, but is described here to illustrate the interrelationship of various aspects of the same resource. In some cases, for example, an application developer may want to model this layer for inventory purposes. Another important potential use of the media_network 2038 layer model includes verifying that the intended use of the media installation meets the requirements of the higher layer. Often, the media network deployment is not the network administration department, but rather the area of another organization within the enterprise, such as the office communications department. However, the topology management service of the present invention allows for the integration of all information related to a managed topology such that a consistent view is maintained for all aspects of the information.

The media_network 2038 layer object is intended to be very flexible. media_table (media cable) 2
Reference numeral 042 may be a line on a visible path between the infrared transceivers, or may be a conductive wiring or packet radio. * Media_network2038: physic
The highest level in the low level media element included by al_segment 2036. * Media_terminator (media terminator) 2
048: Not all technologies require a terminator, but only if necessary. * Media_table 2042: Connects any two different media elements. * Media_fitting (medium compatible) 2044:
It can be a thin LAN Ethernet shaft or tee connection, a token ring media filter, or a cable termination or between cables.
Connection terminals, which are components of a cable such as an RJ-4-55 connector at the end of a twisted pair, are usually considered part of the cable and are not modeled separately. * Media_connector 2046: may be as simple as a telephone line with a flat twisted pair or as complex as a passive unmanaged token ring MAU. * Media_containment2040: me
phy containing dia_network2038
The resource aspect type used to bind to local_segment 2036.

Example of a Network Multi-Layer Topology In FIG. 10, a typical network of a single layer is described. In the example shown in FIG. 11, the network of FIG. 10 is expanded by extending the low-level ip_networks (IP network) 1052 of FIG. 10 using, for example, all the models described above (logical, physical and media layers). Be extended. Some objects in the example shown in FIG. 11 are shown using the derivations in Table 5 below.

[0084]

Table 5 Source of object derived resource aspect type specialization for Fig. 11 media_network RJ-45_jack media_fitting tp_cable media_cable tp_block media_connector

As in the case of FIG. 10, in FIG.
The top level network is ip_no, which includes ip_if (interface) 1106 and 1108, respectively.
i consisting of de (IP nodes) 1102 and 1104
p_network 1160. Each ip_node
1102 and 1104 are respectively ip_if (IP
Interface) 1106 and 1108,
Ip_subnet (IP subnet) 111
It is connected to ip_router (IP route setting) 1114 via 0 and 1112. Each ip_subnet1
110 and 1112 are lower level logic
al_network. ip_subnet11
Reference numeral 10 denotes a low-level subnet that is extended as a link_network (link network).

The link_network 1170 is a typical ip_network that uses the 802.3 protocol (Ethernet) for data exchange (for example).
Represents the physical_network layer. Those skilled in the art will recognize that similar structures can be utilized to represent other physical layer models (such as token rings). link_network 1170 is li
li including nk_if 1120 and 1122, respectively
nk_node 1116 and 1118. Each link_node 1116 and 1118 is
By link_if 1120 and 1122 respectively, link_segment 1124 and 1 respectively
It is connected to a link_bridge 1128 via 126. Each link_segmen
t1124 and 1126 are lower level physics
al_network. link_segmen
t1124 is 10base_network (10
baseT network) 1180, showing a lower level subnet extended.

10baset_network 1180
Is a typical link_network physical_net using twisted pair transmission equipment for data exchange
Represents a work layer. 10baset_network
k1180 is a 10ba that includes 10base_if (interfaces) 1134 and 1136, respectively.
set_node 1130 and 1132. 10base_nodes 1130 and 113 respectively
2 is 10basset_segments1 by 10basset_if1134 and 1136, respectively.
10base_hub via 138 and 1140
(10baseT hub) 1142. 10 each
basset_segment 1138 and 1140
Includes a lower level media_network. 10baset_segment 1138 is tp
Show that lower level subnet extended as _network1190.

The tp_network (TP network) 1190 is a typical 10 ba using RJ-45 twisted pair to connect the physical components of the network.
media_network of set_network
Represents a layer. tp_network 1190 is RJ
-45_jack (RJ-45 jack) 1144 and 1146. Each RJ-45_jack 1144 and 1146 is a tp_cable (TP cable) 1
148 and 1150 via tp_block (T
P block) 1152.

The other ip_subnets 1112 will also include lower-level logical_networks, although not necessarily 802.3 networks.
Decomposition of lower level networks and other ip_
Their dependencies on subnet 1112 depend on the type of lower-level network it contains. One of the two link_segments, 1124
Depends on a 10baseT physical network. As described above, only one of the link_segments is extended, and the other link_segments (ie, 1126) may or may not be a 10baseT physical network (it may be a ThinLAN, and in some cases even a ThickLAN). is there). Finally, one of the 10baseT segments is m
It is shown as depending on a twisted pair network derived from the media_network. Similarly, the other segments may or may not be the same type of media (in fact, other logical_segments at the 802.3 level are ThinLA
Other segments are not of the same type if they rely on N or ThickLAN physical networks). t
In p_network, for illustrative purposes, the RJ-45 jack on the interface card is connected to the connection terminal, the TP cable itself, and the media_con.
Select an example to model as a flat block as a vector.

This example shows the only way that the object model described above can model such a network topology. Table 6 below describes the resource aspect types and the bindings formed between instances of those resource aspect types. These typical RATs and connections are useful for modeling various computing network topologies.

[0091]

[Table 6] RAT role * Minimum / Maximum RAT logical_network 1 0 1 logical_network_containment 1 0 1 logical_segment_containment logical_network_containment 2 0 1 logical_netwwork 2 0 N logical_segment logical_segment \ containment 2 0 1 logical_segment 2 0 N logical_network logical_node 3contain logical_node_containment logical_node 2 0 N logical_if logical_if 4 0 1 logical_node_containment 4 0 1 logical_if_connection logical_if_connection 5 0 1 logical_if 5 0 1 logical_segment logical_segment 6 0 N logical_if_connection 6 0 1 logical_boundary 6 0 1 logical_network_containment 6 0 1 logical_segment_containment 6 01 physical_network 0 N logical_connector (inherited) logical_connector 8 0 1 logical_boundary physical_network 9 0 1 logical_segment 9 0 1 physical_segment_containment phy_segment_containment 2 0 1 physical_network 2 0 N physical_segment physical_node 10 0 1 physical_node_containment physical_no de_containment 2 0 N physical_if 2 0 1 physical_node physical_if 4 0 1 physical_node_containment 4 0 1 physical_if_connection physical_if_connection 2 0 1 physical_if 2 0 1 physical_segment physical_segment 6 0 N physical_if_connection 6 0 1 physical_boundary 6 0 1 physical_segment_containment 6 0 1 media_containment 7 physical_containment 0 0 N physical_connector (inherited) physical_connector 7 0 1 physical_boundary media_containment 11 0 1 physical_segment 2 0 1 media_network media_network 12 0 1 media_containment 13 0 N media_cable media_terminator 14 0 1 media_cable media_cable 15 0 1 media_terminator 15 0 1 media_fitting 15 0 2 media_connector 15 1 media_network media_fitting 16 0 1 media_cable media_connector 2 0 1 media_cable Note (*): Role 1 is network, 2 is included, 3 is logical device, 4 is interface, 5 is connector, 6 is segment, 7 Is restriction, 8 is connection device, 9 is physical network 10 represents each chassis 11 is supplied with, 12 medium network, 1 3 medium include, 14 terminator, 15 physical wire, and 16 a cable link.

Topology Management Method API Functions: Overview The present invention includes the data structures described above and associated methods for processing the data structures. The method of the present invention is invoked by an application program to manage the topology associated with the application program. The application program invokes the method by calling the appropriate function within the API.

The resource 200 shown in FIG.
2 (RA), resource aspect type 212 (RAT)
And indirectly through the reference to the join 204.
The functions described below work directly with these data structures. As a side effect of such processing, the definition of the resource (200) in the topology can be changed.

Each function of the API of the present invention is described below in a common format that clarifies the operation of each API function. Most functions operate according to the general flowchart shown in FIG. The flow diagram of FIG. 7 illustrates the operations "add,""delete,""update," and "query" for entities that are to be explicitly processed by the associated API function. FIG.
In the terminology used in, an entity refers to a data structure that is explicitly handled by an API function.

The “add entity” operation of FIG. Blocks 702 and 704
Check the parameters given as input to the function. Block 702 represents the processing of the method of the present invention to check the parameters passed to a particular API "Add Entity" function. If the parameter indicates an unexpected inconsistent request or value, processing moves to block 744, which terminates processing of the function and returns an error indication to the calling application program.

If the parameters are valid, the process proceeds to block 706 where it is checked whether the entity to be added is known to the topology management service API. If the entity to be added is known to the system, processing proceeds to block 744, which terminates the processing of the function and returns an error indication to the calling application program. If the entity to be added is not known to the API system, processing proceeds to block 708, where the addition of the entity is checked against all topology rules known to the topology service API. At block 710,
If it is determined that adding the entity violates a known topology rule, processing moves to block 744 where processing of the function is terminated and an error indication is returned to the calling application program. If it is determined that adding the entity does not violate any rules known to the topology management service API, processing proceeds to block 712.

Block 712 corresponds to disk 114 in FIG.
Prepare all necessary changes to the permanent storage portion of the API information base stored at Processing is block 7
40, and the A stored in the disk 114 of FIG.
Commit all prepared change requests to the permanent storage portion of the PI information base (ie, commit the changes).
The preparation and commit of changes is two to allow for history tracking and reverse operation of changes to the permanent storage information base.
Operation. All prepared changes to specific additions, deletions or updates to the permanently stored information base are submitted as a single transaction, thus "undoing" the specific update (ie, undoing the update operation).
Is required, the processing is simplified.

Further, block 740 operates to activate a notification receiving mechanism (described above) that is coupled to a trigger condition that is activated by a prepared change to the information base. Block 740 is also responsible for evaluating the modified topology and coordinating resource consolidation for committed changes. Details of the method applied to resource integration will be described later.

The entity addition processing operation is a block 74.
In step 2, a success status is returned to the application program that has started the entity addition API function, and the processing ends.
Typically, a "handle" is returned to the caller upon successful completion of the add entity operation. Handles are future APIs that delete or update data structures.
Used by the calling application program to identify the created data structure in preparation for a function call.

The "delete entity" and "update entity" operations are handled in the same way as in the case of addition, as shown in FIG. An entity delete function is invoked by an application program to delete a previously stored and identified data structure, while an entity update modifies or supplements previously recorded information about the identified data structure. The data structure to be deleted or modified is passed as a parameter to the delete entity or update entity API function by the calling application program.

The entity delete API function is block 7
From 14, the entity update API function returns to block 72
Starts with 6. As shown in the flow chart of FIG. 7, both functions proceed along a common path. Block 716
Locates the data structure identified by the calling application program to be deleted or updated.

If the entity to be located is not found in the permanent information base of the disk of FIG. 1, processing proceeds to block 746, which terminates the processing of the function and returns an error indication to the calling application program. Blocks 720 and 72 if the location of the identified entity is determined in the permanent information base of the disc of FIG.
2 determines whether the requested deletion or modification matches all the rules of the affected topology. Details on the rules and related enforcement functions are described above.
If the requested deletion or change does not match the rules of the affected topology, processing proceeds to block 746 and
Terminates processing of the function and returns an error indication to the calling application program.

If the requested deletion or change is acceptable under the defined rules of the topology, processing proceeds to block 724. Block 724 prepares all necessary changes to the permanent storage portion of disk 114 of FIG. 1, similar to block 712 described above. Processing then continues to blocks 740 and 742, which commit the change request to the permanent storage portion, notify the notification acceptor, and re-evaluate the affected topology resource consolidation in permanent storage on disk 114, as described above. I do.

The flowchart of FIG. 7 also illustrates the processing of a typical query request of the API topology management service. In a query request, the calling application program identifies the data structure for the requested information and identifies the type of information requested. The processing of the query function returns a failure status to the calling program if the identified data is not found, or returns a success status and the requested information if the identified data is found.

The processing of the query function begins at block 728. Blocks 730 and 732 locate the data structure identified by the calling program. The data structure identified is the disk 114 of FIG.
If the above permanent information base is not found, processing returns a "noto found" status information to the calling application program at block 738.

If the identified data structure is found, processing proceeds to block 734 where the requested information is retrieved from the permanent information base on disk 114 of FIG. 1 and the information is appropriately formatted for return to the calling program. Block 7
36 returns a success status indicator and the requested information to the calling program.

The flowchart of FIG. 7 is intended only as a general guideline in understanding the processing of some of the API functions listed and described below. A detailed description of the processing applied to the above data structure is included in each of the API functions described below.

API Function: Resource Integration As described in connection with the processing of block 740 of FIG. 7, whenever a change is made to the information base representing the topology managed by the present invention, a re-evaluation of the resource integration is required. Done. Several API functions directly affect the resource integration features of the present invention. For example, an API that supplies objects to a topology service for topological management
API to delete functions or objects from management
Functions can directly affect the resource integration of the affected topology.

When an object is initially provided to the topology management service API, resource integration is evaluated to determine whether the addition of a new object to the topology requires the integration of already existing individual resources. You. The flowchart of FIG. 8 illustrates the process by which resource integration is re-evaluated following entry of an object to be managed by the topology management service API.

When an object is passed to the API to be managed under the topological management service of the present invention, the process of FIG. Block 800 determines whether the newly managed object specifies a resource name (RN) that identifies a known resource. If not, processing proceeds to block 802, where a new resource is created for the newly managed object uniquely identified by the given resource name. New resources will be represented by newly managed objects. Processing of the method ends here, and block 812 returns control to the caller of the resource integration function.

If so, the process proceeds to block 804, since the newly managed object specifies an existing resource, and the object identifies a single resource or identifies multiple resources. It is determined whether or not. If only one resource is identified by the newly managed object, processing proceeds to block 806, where the resource name specified by the newly managed object and not present in the identified resource is entered. Added to the resource. In this manner, a resource grows with the addition of a resource name that further identifies the resource. Processing of the method ends here, and block 812 returns control to the caller of the resource integration function.

If the newly managed object specifies more than one resource, processing proceeds to blocks 808 and 8
Proceed to 10 to integrate the specified existing resources into the specified new resource by integrating the resource names of all objects representing the identified resources. The new resource is a collection of all objects (i.e., resource aspect R) that previously represented the specified resources.
It is represented by the integration of A). The specified previous resources are discarded and replaced with new resources. Processing of the method ends here, and block 812 returns control to the caller of the resource integration function.

When an object is deleted from the topology management service API, resource consolidation is evaluated to determine if deleting the object would cause a decomposition of a previously consolidated resource. The flowchart of FIG. 9 illustrates the process of re-evaluating resource integration when an object is deleted from the topology management service API.

The process of FIG. 9 begins at block 900 when an object is deleted from the topology management service API of the present invention. The object to be deleted includes a resource name (RN) that helps identify the particular resource. It is determined whether the identified resource is represented by another object currently managed under the topology management service API of the present invention. If the resource is no longer represented by any object under the API, processing proceeds to block 902 and destroys the resource by deleting it from the information base stored on disk 114. Because it is not represented by any object under the management service,
The resource is no longer under the control of the API topology management service. The processing of the method ends here, and block 91
2 returns control to the calling function.

If the identified resource is represented by one or more objects currently managed under the topology management service API of the present invention, processing proceeds to block 904 where the specified object is deleted. Is required to change the closure set of the identified resource. In other words, the remaining objects representing the resource have at least one resource name (RN)
Is shared with at least one other object representing the identified resource. If there is no change in the resource name closure set other than the deletion of the specified object, processing proceeds to block 910 where the resource name unique to the object specified to be deleted is deleted from the resource. In this way, the resource is reduced by deleting the resource name previously used to uniquely identify the resource. Processing of the method ends here, and block 912 returns control to the calling function.

If it is determined at block 904 that the resource's resource name closure set has changed, processing proceeds to blocks 906 and 908, where the identified resource is split into a plurality of new resources. Each new resource is represented by a Resource Aspect (RA) resource name closure set that was previously in the resource name closure set of the specified resource. Processing proceeds to block 908 where the topology management service A permanently stored on disk 114 of FIG.
The identified resource is deleted from the PI. The initially identified resource is no longer represented by any object managed by the topology management service API. Processing of the method ends here, and block 912 returns control to the calling function.

The operation example of the resource integration method of FIGS. 8 and 9 described above is performed with reference to FIGS. 3 to 6 (as generally described by the flowchart of FIG. 7). It should be noted that similar resource integration methods can be leveraged in conjunction with other methods. For example, the method of FIG. 7 may add or delete resource names and change the resource name set associated with the managed object. In this case, it is necessary to activate a resource integration method similar to that shown in FIGS. 8 and 9 without actually adding or deleting the topology management service API by changing the resource name stored in the managed object. Is done. Such modifications to the methods of FIGS. 8 and 9 will be readily apparent to those skilled in the art.

API Function: Detailed Description The following description describes the topology management service API of the present invention.
Provides details of the operation of each of the API functions available to an application programmer using. The format of each description is as follows. Function title-descriptive name of the function. Introduction-Comments if you need to describe the purpose of the function. Input-a general description of the parameters passed by the calling program. Processing-An overview of the processing performed by the function. Output-A general description of the output produced by the operation of the function.

Management of Resource Aspect Types This section describes functions for managing resource aspect types (RATs). The functions include: * Add new resource aspect type. This may be a special type of one or more existing resource aspect types. * Deletion of existing resource aspect types.

Add New Resource Aspect Type Introduction The resource aspect type has a name and may be a special type of one or more existing resource aspect types. In a request to add an input resource aspect type, specify: * Name of the resource aspect type * A list of more general resource aspect types for specialization (optional). The function rejects the request to add a resource aspect type and generates an error if: * If the resource aspect type name is already known to the API * If a more general resource aspect type is specified in the request but it does not exist in the system Allow the request to add a resource aspect type Then
The function updates the resource aspect type storage and returns the resource aspect type. Output * updated resource aspect type storage area * resource aspect type * error.

Resource Aspect Type Deletion An input resource aspect type deletion request specifies: * Resource aspect type. Processing The function rejects the resource aspect type deletion request in the following cases. * If the resource aspect type does not exist * If an instance of the resource aspect type exists and the resource aspect is managed by a topology service * If the resource aspect type is another valid resource aspect type If it is a general type. Upon accepting the resource aspect type deletion request, the function deletes the resource aspect type from the resource aspect type storage. If the resource aspect type delete request is rejected, the function generates an error. Output * updated resource aspect type storage * error.

A resource resource related to a resource aspect type
Defining Pect Type Rules Introduction Developers can define rules for resource aspect types. These rules specify the number and type of bindings that a given type of resource aspect must participate in. Where one or more resource aspects represent a resource, one or more resource aspect rules describe the associations that the resource can participate in. A resource aspect whose resource aspect type is a special type of the more general type must be a valid case of both the special type type and the more general type. Therefore,
Resource aspect rules specified for specialized resource aspect types cannot override rules specified for more general types, but rather must be implemented in addition to more general rules. .
Every resource aspect type has a list of valid resource roles. For example: * "Power Connection" resource aspect type is "Generator"
It may have a resource role and a "consumer" resource role. * The "Computer" resource aspect type may have a "Power Consumer" resource role and an "Expansion Card" resource role. * The "ownership" resource aspect type may have an "owner" resource role and an "owner" resource role. Each resource aspect rule contains one resource role. One resource aspect type (T) with the same resource role
And when used in both rules of another resource aspect type (T '), if T' is a special type of T, then both rules apply to instances of type T '. In the request that defines the resource aspect rules for the input resource aspect type, specify: * Resource Aspect Type * List of resource aspect rules, each consisting of {Resource Role, Resource Aspect Type, Minimum Radix, Maximum Radix, Error} tuples. Output * updated resource aspect type storage * error.

Resource Aspect Rule Operation Introduction The resource aspect rule describes the configurable invariants of the resource aspect type. The following are the specified items. * Resource roles applied to the resource aspect type * The number of bindings that resources of that resource aspect type must participate in * Details of the effect of the special type of the type resource aspect type on the resource aspect rules. The API supports the concept of resource aspect type specialization through a way that allows developers to specify configurable topology invariants using resource aspect rules. In this context, the specialization of a resource aspect type means that the particular resource aspect must be a valid representation of all generic types of that type, not just that resource aspect type. This is so that when developers recognize the inheritance relationships between resource aspect types used to model that particular problem area, the invariants naturally reflect those inheritance relationships. It means that the API allows it to be represented. The API does this by doing
A resource aspect rule definition that applies to a particular resource aspect type is considered to define only additional rules for that resource aspect type. The definition of rules for all general types of the resource aspect type need not be repeated.

For example, assume that there is a resource aspect type X with the following resource aspect type rules. * X supports resource role A according to rule R (where R represents resource aspect type and radix restriction) * X supports resource role B according to rule S * X supports resource role C according to rule T . Further assume that resource aspect type X does not inherit from any other resource aspect type. Type X resources can only participate in binding as follows. * All connections are one of resource roles A, B or C
Must be accompanied by two resources. * The combination when the resource is in resource role A must obey rule R. * The combination when the resource is in resource role B must obey rule S. * The resource is resource role C. In this case, following the previous example, this example illustrates the use of special types in resource aspect type definitions. Furthermore, assume that there is a resource aspect type X 'that is a special type of X with the following resource aspect type rules: * X' supports resource role B according to rule U * X ' * Supports role C * X 'supports resource role D according to rule W Resources of type X' can only participate in binding as follows. * All bindings must be accompanied by one of the resource roles A, B, C or D * If the resource is in resource role A, the binding must follow rule R * Resource is a resource role The combination when in B is the rule S and T
* If the resource is in resource role C, the binding is rules T and V
* When the resource is in resource role D, the binding must follow rule W.

Input * Resource Aspect Type Storage * Resource R. A resource R is valid if all resource aspects representing the processing resource R are valid according to the following requirements. A resource aspect of resource aspect type T is valid according to the resource aspect rules if all of the following are true: * The resource aspect only has a binding if there is a resource aspect in the resource role specified for the resource aspect type T or for a more generalized resource aspect type. The resource is a resource aspect type T
Has a resource aspect type that conforms to all of the appropriate resource role special types and the general type of T. * The resource aspect is changed to all of the appropriate resource role special types and the general type of T Included in the number of bindings for each compliant resource role. If a request made to the function is rejected as a result of a resource aspect rule, an error associated with the resource aspect rule is returned, and the associated resource aspect (invalid) is also returned. Output * Error * Resource aspect related to the error.

Implementation Mechanism for Resource Aspect Type
The introduction topology implementation mechanism is an object that supports an interface that performs a validity check function. Validity features are specified to be tested (including subtypes)
Returns true or false given the type resource aspect. The API enforcement mechanism allows a developer to specify constraints that cannot be expressed using resource aspect rules. For example, assume that a developer has defined resource aspect types of "computer", "modem" and "provide dialing service". Assume that a resource of the "Dial Call Serving" type must have one connection with "Computer" and one connection with "Modem". Such constraints are:
It can be expressed using resource aspect rules. Any combination between "computer" and "dial service" and between "modem" and "dial service" cannot be formed unless the transmission rates for "computer" and "modem" are the same. Let us consider the constraint here. This constraint cannot be expressed using resource aspects, and therefore requires an enforcement mechanism.

The API enforcer constrains all resource aspects of a specified resource aspect type (and its special types). A trigger condition is associated with each API enforcement mechanism. The trigger condition specifies a condition under which the API activates the execution mechanism. Trigger conditions include changes to topological and non-topological characteristics. The trigger condition must be a "local" change. "Local" means resource aspect
This means that the API enforcement mechanism for type (T) is invoked only for changes to resources with resource aspect type T, and only for changes to resources that are directly coupled to resources with resource aspect type T. I do.

Input An API implementation mechanism definition request for one resource aspect type specifies: * Resource Aspect Type (T) * List of API Enforcers each having one or more of the following associated trigger conditions: 1) A binding is formed that includes Resource Aspect Type T. 2) Resource Aspect Type T 3) a (non-topological) state has occurred in resource aspect type T 4) a resource aspect that was of type T up to that point changes the resource aspect type 5) a resource of type T A bond containing the resource represented by the aspect is formed. 6) A bond containing the resource represented by the type T resource aspect is deleted. 7) The resource aspect representing the resource represented by the type T resource aspect is ( A non-topological) state has occurred. 8) A resource aspect that further represents the resource represented by the type T resource aspect Change the aspect type. 9) Conditions 1) to 8) above except that a change to the combination of the resource aspects of type T occurs. 10) For the combination of the resource aspects representing the resource represented by the resource aspect of the type T. Conditions 1) to 8) above except that the change has occurred. Processing The function rejects a request to define an API enforcement mechanism for a resource aspect type if: * If the resource aspect type is not known to the API * AP defined for the resource aspect type
When the I implementation mechanism already exists * When an invalid trigger condition is specified. Upon accepting a request to define an API enforcement mechanism for a resource aspect type, the function updates the resource aspect type storage. Output * updated resource aspect type storage * error.

API Enforcer Operation Inputs * Resource R of Resource Aspect Type T * List of API Enforcers. Processing Whenever a request corresponding to a trigger condition for that API enforcer is to modify the topology information storage base, the function returns all API enforcers and resource aspects for resource aspect type T.
Invoke the “validation verification” method with argument R for all API enforcers for type T general types. If the enforcer returns a true result when invoked by the API, the resource is valid according to the enforcer.
If the enforcer returns an error, the function returns the error returned by the resource aspect type enforcer, along with the invalid resource aspect, to the user who requested the topology change and withdraws the change. If it does not receive a valid response from the enforcement function, it notifies the user who requested the topology change and withdraws the change. Output * Error * Resource aspect related to the error.

Change Notification for Resource Aspect Type
Receiving Mechanism Definition Introduction The topology notification receiving mechanism is an object that supports an interface that receives notification of a change in the API. A request for the definition of a change notification receiving mechanism for an input resource aspect type, which specifies: * Resource Aspect Type (T) * Hosts acting as filters (optional) * List of notification receivers each having one or more of the following associated trigger conditions: 1) A bond is formed that includes Resource Aspect Type T 2) The binding containing the resource aspect type T is deleted 3) The (non-topological) state has occurred in the resource aspect type T 4) The resource aspect that was of type T up to that point is the resource aspect Changing the type 5) A bond containing the resource represented by the type T resource aspect is formed 6) The binding containing the resource represented by the type T resource aspect is deleted 7) By the type T resource aspect (Non-topological) state has occurred in the resource aspect that represents the represented resource. The resource aspect further representing the resource to be changed changes the resource aspect type. 9) The above conditions 1) to 8) except that a change to the combination of the type T resource aspect occurs. Conditions 1) to 8) above except that a change to the combination of resource aspects representing the resources to be performed has occurred. Processing The function rejects the request defining the topology change notification receiving mechanism for the resource aspect type and generates an error if: * If the resource aspect type is not known to the API * if a notification receiving mechanism that defines the resource aspect type already exists * if an invalid trigger condition is specified. When the request for defining the policy change notification receiving mechanism is received,
The function updates the resource aspect type storage. Output * updated resource aspect type storage * error.

Registration of Change Notification Related to Resource Aspect The introduction topology notification receiving mechanism is an object that supports an interface for receiving notification of a change in the API. A request to register a change notification for an input resource aspect type, specifying: * Resource Aspects (RA) * List of notification receivers each having one or more of the following associated trigger conditions: 1) A bond containing resource aspect RA is formed 2) A bond containing resource aspect RA is deleted 3) A (non-topological) state has occurred in the resource aspect RA 4) The resource aspect RA changes the resource aspect type 5) A connection is formed that includes the resource represented by the resource aspect RA 6) The resource aspect The binding containing the resource represented by the RA is deleted. 7) A (non-topological) state has occurred in the resource aspect representing the resource represented by the resource aspect RA. 8) The resource represented by the resource aspect RA is further represented. Resource aspect changes resource aspect type 9) A change to the combination of resource aspect RA occurs 10) The conditions of the above 1) to 8) except that a change to the combination of the resource aspects representing the resource represented by the resource aspect RA has occurred. Processing The function rejects the request to register a topology change notification receiver for the resource aspect type and generates an error if: * If the resource aspect is not known to the API * if a notification receiver defining the resource aspect type already exists * if an invalid trigger condition is specified. Upon receipt of the registration request of the mechanism for receiving notification of
The function updates the API storage information base. Output * Updated API storage information base * Error.

Registration of Change Notification Mechanism for Resource Aspect
Recording release introduced topology notification receiving mechanism is an object that supports the interface to receive notification of changes in the API. A request to unregister a change notification for an input resource aspect type, specifying: * Resource Aspects (RA) * List of notification receivers to be deregistered. Processing The function rejects the request to deregister the topology change notification receiver for the resource aspect type and generates an error if: * If the resource aspect is not known to the API * if a notification receiver defining the resource aspect type already exists * if an invalid trigger condition is specified. The function updates the API storage information base when the deregistration request of the policy change notification receiving mechanism is received. Output * Updated API storage information base * Error.

Topology notification processing input * Resource aspect RA of resource aspect type T * List of topology change notification receiving mechanisms. Processing whenever a change corresponding to the trigger condition is performed on the topology information base about the receipt mechanism, The function is defined for the general type of resource aspect RA, and resource aspect type T or resource aspect type T For all topology change notification receiving mechanisms that are registered for all that are running, invoke the "notify received" method with the argument RA. If the topology change notification receiving mechanism is defined using an optional host filter, the function invokes the receiving method only if a change occurs for the specified host. The output receiving mechanism is notified.

Resource Aspect Type Query Introduction This query returns the data that the API binds to the resource aspect type. Queries are applied to individual resource aspect types or resource aspect type namespaces. In a request to find the resource aspect type by input name,
Specify: * Resource aspect type name. The processing function indicates whether the resource aspect type name is known. If known, the function returns the resource aspect type corresponding to the resource aspect type name. Output * Whether the resource aspect type name is known * Resource aspect type.

Resource Aspect Type Content Query Introduction This query returns the details of a resource aspect type. In the request to determine the details of the input resource aspect type, specify: * Resource aspect type. If the processing resource aspect type does not exist, the function generates an error. Otherwise, the function provides the following data for the specified resource aspect type: * Name of the resource aspect type * List of more general resource aspect types (direct parents) * List of user-supplied topology enforcement mechanisms for the resource aspect type * List of user-supplied topology notification receiving mechanisms for the resource aspect type * A list of user provided resource aspect rules for the resource aspect type. Output * Name of the resource aspect type * List of more general resource aspect types * List of user-supplied topology enforcer objects * List of user-provided topology notification receiver objects * List of resource aspect rules * Error.

Resource Aspect Type Inheritance Query Introduction This query returns true if resource aspect type (A) is an ancestor of resource aspect type (B). This query is used to determine if it is B'is a'A (ie, A is B). The request to determine whether the input resource aspect type B inherits type A specifies the following: * Resource aspect type A * Resource aspect type B If processing resource aspect type B is a descendant of resource aspect type A in the resource aspect type inheritance hierarchy, the function returns true. If a descendant of the resource aspect type B is resource aspect type A, either the true or false output * Boolean format function returns false.

A model generated by the resource management API from the combined characteristics of the processing target is one resource. A resource aspect is a model of a set of properties for a particular "aspect" of the matter. Typically, the resource aspect (s) is one
One resource models things from the perspective of one application program, while one resource models the combination of all such perspectives. Each resource aspect represents a resource from the viewpoint of modeling. The resource aspect is a basic unit of the topology management API that performs the following. * Has its topological properties managed by the API * Supports transaction and locking functions * Supports protection functions * Supports naming

The "resource aspect management" function is a means of associating one object with one resource aspect type, thereby making the resource aspect available to the API. Objects entered into the API may include other non-topological aspects that are not managed by the API, except that the objects entered into the API are stored with the objects managed in the API as resource aspects. When a resource aspect is managed, the API topology management service maintains the additional state obtained by the resource aspect. This state is included in the "topological component" of the resource aspect,
A link between "topological components" and "non-topological components" is maintained. Resource aspects can be named by resource name. The resource name is one method used by the API service to indicate when one or more resource aspects represent the same resource. As a result of adding and deleting a resource name to a resource aspect, the resource stops existing and a new resource is created.
If direct references to resources are held by the application, those references can result in "staleness." Thus, a resource is always referenced indirectly (from outside the API service itself) via a resource aspect that represents the resource. Thus, there can be no stale references to resources that no longer exist.

Resource Aspect Management Introduction This is a request for resource aspect management by the API service. In the resource aspect management request by the input API, the following is specified. * Object * Resource aspect type * List of resource names (optional). If the process following is true, The function rejects the resource aspect management request, and generates an error. * There is no resource aspect. If the request is granted, the function updates the topology storage information base and returns the resource represented by the specified resource aspect. The function determines the resource represented by the resource aspect specified in the input request by performing a process that is functionally equivalent to the following. * Create a new anonymous resource represented only by the input resource aspect * Add each resource name of the input request to that resource aspect as described in the "Add New Resource Name to Resource Aspect" function below (This may combine existing resources). Output * Updated topology storage information base * Resources * Error.

Resource Aspect Management Release Introduction This is a request to release the resource aspect management by the API service. If the resource is represented by only one resource aspect being unmanaged, the resource stops existing. If the resource is also represented by other resource aspects, the resource loses the properties represented by the resource aspect and "shrinks" or the resource is split into two new resources and the original resource exists. Disappears. As described above, FIG. 4 illustrates the API RA3 (4
Indicates the change caused by the request to release the management of 10).
In this case, RESOURCE1 (402) is split and two new resources (RESOURCE3 and RESOURCE3)
SOURCE 4 is formed. If the request is R3 instead of RA3
If the management of A4 is cancelled, the result is that RESOURCE1 is simply reduced. It is an input resource aspect management cancellation request and specifies the following: * Resource aspect. If one of the processing below is true, the function number reject the resource aspect management release request to generate an error. * The input does not specify a valid resource aspect * The resource aspect is not included in any bindings managed by the API service * The "opology invariant" requirement described above is not met. If the request is granted, the function disassociates this resource aspect with all resource names. The resource aspect is no longer a resource aspect and does not represent any resources. Output * Updated topological storage information base * Error.

Add Resource Name to Resource Aspect Introduction This function processes a request to add a name to the list of resource names by which the resource aspect is recognized. If the new resource name entered also identifies another existing resource, the two existing resources are combined into one new resource. As mentioned above, FIG. 5 illustrates the changes that result from the addition of a new resource name to resource aspect RA8 (518). In this case, the new name is shared by RA4 (512). RESOURCE1 and RESOURCE
RCE2 merges to form RESOURCE3, and RESOURCE1 and RESOURCE2 no longer exist. In the request to add a resource name to the input resource aspect, specify the following. * Resource aspect * Resource name. If one of the processing below is true, The function generates an error reject resource name addition request to the resource aspect. * The resource aspect does not exist. * The requirement of the above "topology invariant" is not satisfied. If allowed, the function binds the resource name to the resource aspect. As a result, the two resources merge to form a new resource. Output updated topological storage information base.

Delete Resource Name from Resource Aspect Introduction This function handles a request to delete a name from the list of resource names identifying the resource aspect. If the resource name to be deleted identifies another existing resource aspect,
The existing resource may be split (whether or not to split depends on the new resource name closure set). As described above, FIG. 6 illustrates the changes that occur as a result of deleting a resource name from resource aspect RA8 (612). In this case, the name was shared only by RA4 (610). RE
SOURCE1 is RESOURCE2 and RESOURCE
It is divided into RCE3 and RESOURCE1 no longer exists. Specify the following in the request to delete the input resource name from the resource aspect. * Resource aspect * Resource name. If one of the processing below is true, the function number reject the resource name deletion request from the resource aspect to produce an error. * The resource aspect does not exist. * The resource aspect is not combined with the resource name. * The above-mentioned requirement of "topology invariant" is not satisfied. If allowed, the function breaks the association of the resource name with the resource aspect. As a result, the resource may be split to form two new resources. Output * Updated topology storage information base * Error.

Resource aspect type of resource aspect
Introduction of the update This API is used to change the resource aspect type of an existing resource aspect. Specify the following in the update request of the resource aspect type of the input resource aspect. * New resource aspect type * Resource aspect. If one of the processing following is true, the function number to reject the request to change the resource aspect type of resource aspect to produce an error. * The resource aspect type does not exist * The resource aspect is invalid * The above "topology invariant" requirement is not satisfied. If allowed, the function changes the resource aspect type of the resource aspect. All resource aspects hold all bindings managed by the API service they had prior to the update request. Output * Updated topology storage information base * Error.

Explicit Combining Two Resource Aspects Introduction This API describes a process that requires that two resource aspects be explicitly combined. This operation is functionally equivalent to generating a unique resource name (not shared by other resource aspects) and adding the generated name for each of the two resource aspects to the name list. As a result, two resources are merged into one resource unless both resource aspects already represent the same resource. In the request to combine the two resource aspects, specify the following: * Two resource aspects. The function rejects the request to combine the two resource aspects and generates an error if any of the following are true: * Either resource aspect does not exist. * The above requirement of "topology invariant" is not satisfied. If allowed, the function ensures that two resource aspects always represent the same resource. Output * Updated topological storage information base.

Release of Explicit Binding of Two Resource Aspects Introduction This API describes the process of releasing two resource aspects from the need to represent the same resource. This operation is functionally equivalent to removing the API-generated resource name from each resource aspect that was used to ensure that the two resource aspects represent the same resource. As a result of this operation, the resource represented by the two resource aspects is split into two resources unless the resource aspect is part of the same resource name closure set. Input A request to release two resource aspects from the need to represent the same resource, specifying: * Two resource aspects. If one of the processing below is true, the function number, reject the request to release the two resource aspects from the need to represent the same resources to generate an error. * Either resource aspect does not exist. * The above requirement of "topology invariant" is not satisfied. If allowed, the function removes the constraint that the resource aspect always represents the same resource. Output * Updated topology storage information base * Error.

Resource Queries Introduction This section specifies the queries that are created to look up the relationship between the resource aspect (s) and the resource they represent. This does not include queries regarding the coupling between resources or queries based on resource characteristics. Such types of queries are described below under "General Topology Queries". The following types of queries are supported: * Query individual resources * Query individual resource aspects * Query the entire resource namespace to identify individual resources or resource aspects.

Inquiry Introduction to Individual Resource Data The queries specified in this section apply to data about resources (ie, the overall picture defined through resource aspects). The queried resource is identified by specifying one of the resource aspects that represents the resource. The query results are filtered to narrow down only information relevant to a limited set of resource aspects that represent the resource. Filters are specified by: * Resource aspect type (in this case, the result is limited to those supported by that type of resource aspect) * Resource name (in this case, the result is only supported by the resource aspect with that name) . The output of the query result is the resource name, resource aspect type and resource aspect supported by the specified resource, depending on the filter. Input * Resource * Resource Aspect Type (optional) * Name (optional). The function rejects the request if any of the following occurs: * The resource is not a valid resource * The resource aspect type has been entered but does not exist. * A resource name has been entered but does not exist. When a resource aspect type is input, the function limits the output data to those supported by the resource aspect of the input resource aspect type. When a resource name is entered, the function limits the output data to those supported by the resource aspect with the input resource name. The function outputs the following data. * Resource resource aspect type * Resource resource aspect * Resource resource name Output * List of resource aspect types * List of resource aspects * List of resource names.

Inquiry Introduction to Individual Resource Aspect Data The queries specified in this section apply to a particular resource aspect. It does not include other resource aspects that represent resources. The output of the query result is the resource name and resource aspect type of the resource aspect. Input resource aspect. The function rejects this request if: * The resource aspect is not valid If the resource aspect is valid, the function outputs the following data. * Resource aspect type of resource aspect * Resource name of resource aspect Output * Error * Resource aspect type * List of resource names.

Resource Namespace Query Introduction The queries specified in this section apply to all resource aspects. The output of the query is the resource identified by the resource name. List of input resource names. With any name in the process input resource name list to output a resource with the same name. Output * list of resources.

The explicitly combined resource aspect
Query input Query for explicitly combined resource aspects, specifying: * Resource aspect. The function if treatment following occurs rejects the request. * There is no resource aspect. If the request is accepted, the function returns a list of other resource aspects explicitly combined with this resource aspect, or identifies that there are no other resource aspects explicitly combined with this resource aspect Returns information. Output * List of resource aspects explicitly combined with a given resource aspect * Identification information that no explicitly combined resource aspect exists.

Creating a Binding Management Binding An introductory binding is established between the resource (s). Specifically, a binding is established between specific resource aspect (s). A request to establish a connection between input resources, specifying: * Two {resource aspect, resource role} pair. If one of the processing below is true, The function generates an error rejects the binding establishment request. * Either resource aspect does not exist * Resource aspect does not support the specified resource role * The above "topology invariant" requirement is not met. Upon accepting the request, the function stores the association. If the resource role has a radix greater than one, the function assigns a unique index to each resource role so that it can be identified. Output * updated resource storage * error.

Binding Removal Introduction This function allows a binding to be deleted if no other resources are affected. Specify the following in the connection deletion request between input resources. * Two {Resource Aspect, Resource Role} pairs (optionally includes an index for Resource Role). If one of the processing below is true, The function generates an error rejects the binding deletion request. * Either resource aspect does not exist * Resource aspect does not support the specified resource role * The above "topology invariant" requirement is not met. Upon accepting the request, the function removes the association. Output * Updated topology storage information base * Error.

Introduction to Join Queries This section specifies the queries prepared to look up individual joins. Queries in this theory do not include general queries on bindings between resources or queries based on resource characteristics. Such a query is described below under “General Topology Query”.

Query Input for Bindings for Resource Aspects * If there is no request processing resource aspect that lists all of the bindings for the specified resource aspect, the function will generate an error. If not rejected, the function provides, for the resource aspect, the following data for each binding in which the resource aspect participates. * Resource roles and indices for this resource aspect * Resource roles and indices and resource aspects for the combined resource aspect. For each output binding: * Resource role and index for this resource aspect * Resource role and index for the resource aspect being combined, and resource aspect * Error.

General Topology Query Introduction General topology query support is supported by the Topology Query (Topology Query API) defined in the “Topology Query API” described below.
Query may be abbreviated as TQ hereinafter). The TQ-API provides a programming interface for expressing general topology queries. Topology query AP to simplify ad hoc queries of topology management service API
Those skilled in the art will recognize that I can implement a topology query language. The API of the present invention supports general topology queries for all defined resource sets. Each query specifies one or more "meta-resources" that are matched against known resources. Meta-resources are essentially templates for matching resources. A navigation query is expressed as a navigation path that must be matched to a path through the topology storage information base. Navigation paths can be combined with logical operators that form compound propositional expressions about the topology. Further, a repeat statement can be placed on the navigation path or a portion of the navigation path to indicate the repetition (optional) of resources in the topology path.

The result of the topology query has two parts. The first part is a Boolean value that indicates whether the propositional expression presented by the query is true or false. This part of the result is always returned. The second part of the result is a subgraph that matches the navigation path specified by the query. The composition and existence of this part of the result depends on: * Result construction rules * Display rules.

Topology Storage Information Base The topology storage information base can be displayed as a graph of the combined resources. The topology graph is
A set of nodes and a set of connecting lines connecting those nodes. A node is a resource, and a connecting line simply indicates the existence of a connection between two resources.

Meta-Resource Template A meta-resource is a template for matching resources in the topology. A meta-resource is: * a specific resource in the topology * an "unspecified" resource in the topology * a resource aspect type * a propositional representation of the resource aspect type. The propositional expression is a logical connective AND, OR and N
It can be formed using OT. For example, one meta-resource is (Type A AND Type B) ANDNOT
Specify type C. Meta-resources can also optionally express propositions about resource property values. A propositional expression can be formed from a representation of one or more linked values using the logical connectors AND, OR and NOT. For example, one meta-resource specifies (attribute A = 25 AND attribute B <50) AND NOT attribute C = “string”.

The meta-resources, logical connectors and their connections form a tree. In this tree, the branches are A
It occurs only at the ND and OR logical connectors. Thus, a meta-resource node has at most two connections with other meta-resource nodes: * at most one predecessor connection and * at most one successor connection. Joins in the query tree mean that joins in the topological stored information base must be followed.

A meta-resource can optionally specify a resource role for the binding to which it is related. If specified, these resource roles constrain the resource that matches the meta-resource to the resource playing the specified role in the corresponding association. The specification for the resource role is
May contain an index. Meta-resources can also specify filters. Filters are user-defined methods that apply to all resources that match a meta-resource. A filter is a Boolean expression that returns true or false. If specified, the filter returns true for resources considered to be matched.

The Type Matching Resource Aspect Type is organized in an inherited type hierarchy. A resource aspect matches a resource aspect type if: * Having the same resource aspect type as specified, or * Having a resource aspect type that is a special type of the specified type. For example, if the meta resource specifies the resource aspect type RT3 (1406) in the tree of FIG.
Resource aspect type RT3 (1406), RT6 (1
All resources with 412), RT7 (1414) and RT9 (1416) match meta-resources. Resource aspect type root node 1400, RT1 (1402), R
T2 (1404), RT4 (1408) and RT5 (14
10) does not match the meta-resource.

Navigation Path A simple navigation path includes one or more meta-resources. A simple navigation path is considered a proposition about a topology that returns either true or false.
Each of the topology queries must consist of at least one simple navigation path. A simple navigation path is a "prescription" that matches a path through the topology storage information base. A path in the topology matches a simple navigation path if each of the resources in the topology path matches the corresponding meta-resource in the navigation path. A simple navigation path consists of a root (or root) meta-resource and a leaf.
Has (leaf) meta resources. The resource matching starts from the root meta resource and sequentially proceeds to the leaf meta resource. Some paths in the topology correspond to simple navigation paths. Some examples of simple topology queries using a simple navigation path are shown in FIG. 15, which are as follows: Example 1 (Ex1): Resource E1 is resource E1 through resource R1 if resource E2 is coupled to resource E3 through resource R2.
Is it combined with 2? Example 2 (Ex2): ET1 combined with resource of resource aspect type matching ET2 via resource matching RT1
There a resource of the resource aspect type that matches In both query examples, a resource match begins at the root node meta-resource of the simple navigation path, E1 in Example 1 and ET1 in Example 2. Example 1 is
It finds at most one matching path in the topology because it specifies a particular resource in every meta-resource. Example 2 finds some paths in the topology that match the root root meta-resource, since it specifies the resource aspect type (s) in every meta-resource. Query is at least 1 in the topology
The query returns true if two matching paths can be found.

The compound statement logical connective can be used to combine simple navigation paths to make further queries on the topology graph structure. Logical AND, OR and NO
A T-connector is used to create a compound propositional representation of the topology. The evaluation of the connector follows the rules of logic. The connectors are as follows. Logical NOT: negation of a true result is false, while negation of a false result is true. Logical AND: if both component results are true,
The combination of the two results is true. Logical OR: The separation of two results is true if at least one of the component results is true.

By adding navigation paths that form more complex navigation paths, logical connectors extend simple and complex navigation paths at their leaf nodes. Complex navigation paths are paths in the query tree. If the root node of the navigation path is any node in the query tree,
A navigation path is one path in the query tree. Some examples of topology queries using the logical connector shown in FIG. 16 are as follows. Example 1 (Ex1): Resource E2 binds to resource E3 via resource R2, and resource E2 is also resource E4 via resource R3.
If so, is resource E1 linked to resource E2 via resource R1? Example 2 (Ex2): If resource E2 is coupled to resource E3 via resource R2, or if resource E2 is coupled to resource E4 via resource R3, resource E1 is a resource via resource R1. Is it linked to E2? Example 3 (Ex3): Resource E2 is resource E via any resource
If not, is resource E1 linked to resource E2 via resource R1? Example 4 (Ex4): Resource E2 binds to resource E3 via resource R2, and resource E2 is also resource E4 via resource R3.
And if resource E3 is coupled to resource E5 via resource R4, or if resource E3 is coupled to resource E6 via resource R5.
Is connected to resource E2 via resource R1? These examples show that queries that can be presented to the API are complex to describe in natural language without ambiguity. All four queries start a resource match from the root root meta-resource (E1). Query example 1 and example 2 include two complex navigation paths with a root node at E1, while query example 3 includes a single simple navigation path with a root node at E1. Query Example 4 shows an example of a nested logical connector that includes all three complex navigation paths with a root node at E1. * Example 1 is true only if there is at least one path through the topology from E1 to E2 (via R1) and E3 from E2 (via R2) and E4 (via R3). Back. * Example 2 has at least one path through the topology from E1 to E2 (via R1) and E2 from E2 (via R2) or E3 (via R3) Returns true only if. * Example 3 shows that there is at least one path through the topology from E1 to E2 (via R1) and
Returns true only if there is no path through the topology from 2 to E3 (via unspecified resources). * Example 4 is from E1 to E2 (via R1) and E2 to E3 (via R2) and E4 (via R3), and E3 to (via R4) ) E
Return true only if there is at least one path through the topology, either to 5 or to E6 (via R5).

A compound query logical connector can be used to represent a compound query on a topology. A compound query combines the results of at least two queries to produce one result.
Logical AND and OR connectors are used to represent compound queries. An example of the compound query shown in FIG. 17 is as follows. Example 1 (Ex1): Is resource E1 bound to resource E2 via resource R1, and (AND), and is resource E3 bound to resource E4 via resource R2? Example 2 (Ex2): Resource E1 is coupled to resource E2 via resource R1, or (OR), resource E3 is coupled to resource E4 via resource R2, and (AND), resource E5 is not Is it linked to resource E6 via a specific resource? Iterative simple navigation paths or parts of simple navigation paths can be repeated multiple times as part of a query. The iteration statement is bounded by a lower bound. You can optionally specify an upper limit. These limits indicate the minimum and maximum number of times that iterations can occur on the topology path. An example of the query iteration shown in FIG. 18 is as follows. * Assuming that the content is transitive, is resource E2 contained within resource E1? That is, E1 contains X and X is Y
If E1 contains Y? This example also shows how the resource roles specified for each of the meta-resources are used per binding. In this example, the resource aspect type "contain" is used. This type is
Supports two roles: "container" and "container". Other resources also support these roles.

Resource Match Constraint Typically, the querying user wants to express a constraint that any resource should match only one meta-resource in a query. This will be the default (default). This default can be overridden so that the user can alternatively specify a resource match constraint such as: These constraints can be specified for any pair of meta-resources. Equals: A resource that matches the meta-resource specified in the query must also match another specified meta-resource. Don't care: A resource that matches the meta-resource specified in the query. May or may not match another specified meta-resource.

[0167] There are two parts to the query results query results. * Boolean value indicating whether the propositional expression presented by the query is true or false. This part of the result is always returned. * A subgraph that matches the navigation route specified by the query. This part is optional and depends on a combination of result construction rules and display rules.

Result Building Rule The result building rule specifies the number of subgraphs to be returned from the query. A query can return a subgraph only if the Boolean result of the query is true. There are four result construction rules: No results (none): This rule specifies that the query does not return any subgraphs as a result. Only boolean values are returned. Any: Returns any one subgraph. The query returns one successful match result made on the topology. List: returns one or many subgraphs. The query returns all successful matching results made on the topology. Graph: returns one subgraph. The query combines all successful match results made on the topology and removes all duplicate resources. A query can specify only one result construction rule at a time.

Display Rules Display rules are used to modify the subgraph returned by a query. The display rules can be applied for each meta-resource specified in the query. Display rules can specify the following for meta-resources: ON: Resources that match the meta-resources are shown in the results. Off: Resources matching the meta-resource are not shown in the results. If the result-building rule specifies a graph option and the resource in the query result represents more than one meta-resource, there is at least one resource that matches the resource, and if the display rule specifies ON, the resource Is shown. The default display rule is "on", except for meta-resources modified by the logical NOT operator. Such meta-resources will never be displayed in the subgraph results because it cannot display what should not be present. An example of the display rule use query shown in FIG. 19 is as follows. * Example 1 (Ex1): Displays the result of any of the resources E1 that are bound to a resource of type ET1 via an unspecified resource (in this case, a resource of type ET1 is bound to resource E3 via resource R1) doing). The display rules of R1 and E3 are off. * Example 2 (Ex2): Display all the results of resource E1 that are bound to a resource of type ET1 via an unspecified resource (in this case a resource of type ET1 is bound to resource E3 via any resource) Not). The result of inquiry example 1 is that the resource of type ET1
1, the path from resource E1 to a resource of type ET1 is indicated. Resources R1 and E3 are not included in the result because their display rules are "off". The result of query example 2 displays the entire path from resource E1 to any resource of type ET1, assuming that resources of type ET1 are not bound to E3 via any resources. If a logical NOT is specified, the display rule is implicitly set to “off” for all meta-resources following the logical NOT.

The user tag topology query service allows a user tag to be specified in the meta-resource of the query. The user tag is
It is semantically unrelated to the referral evaluation process. Tags provide a means to identify topological resources that match meta-resources in a query. Each of the subgraphs returned to the caller as a result of the query copies all user tags from the meta-resources to their corresponding matching topology resources. If the query result construction rule specifies the "graph" option, the query result topology resource represents multiple meta resources, and the resource copies all user tags from each of the meta resources it matched. .

In the input topology graph structure query request, the following is specified. * At least one meta-resource that specifies matching criteria for topology resources and optionally specifies a filter • At least one navigation path that includes one or more meta-resources • Multiple navigation paths Symbols (options) for iteratively combining to modify compound propositions (options)-Iterative configuration (options)-Resource matching constraints (options) * Result construction rules * Display rules for meta resources (options) * User tags for meta resources (option).

The processing API evaluates the propositional representation of the query against the topology graph structure. The API returns true if the propositional expression is valid, and returns false if the propositional expression is invalid.

The API returns (and may not return) the topology subgraph according to the result construction rules supplied to the query and the result display rules specified for individual meta-resources.

Definition of Valid Propositional Expressions The API considers a query's propositional expression to be valid in the following cases: * If the logical evaluation of the navigation path that places its root at the root node of the query tree returns true. The API considers the navigation route to be true if there is a topology route that matches the navigation route. The API considers a navigation path that does not include a logical NOT connector to be a topological path if all of the following are true: * All resources in the topology path match the corresponding meta-resources of the navigation path (i.e., the first resource of the topology path matches the first meta-resource of the navigation path, and so on. Matches). * Every resource in the topology path has a binding (managed by the API service) with the neighboring resources in the topology path. * All logical conditions represented in the navigation path are fulfilled.

The API considers a topology path to be consistent with a navigation path that includes a logical NOT connector if all of the following are true: * All resources in the topology path match the corresponding meta-resources in the navigation path for that part of the navigation query that processes the first NOT connector in the navigation path (i.e., the first resource in the topology path is in the navigation path) The first meta-resource matches, and the second corresponds correspondingly as the second). * Every resource in the topology path has a binding (managed by the API service) with neighboring resources in the topology path. * All logical conditions represented in the navigation path are fulfilled.

The API considers a resource to be a meta-resource if all of the following that apply to the meta-resource are true: * A meta-resource specifies a particular resource, which is a particular resource. * The meta-resource specifies an "any" resource. * A meta-resource specifies a resource aspect type and the resource is a specified resource aspect type or is a special type of a specified resource aspect type. * The meta-resource specifies a resource aspect type proposition,
The resource aspect type of the resource evaluates whether the proposition is true. * A meta-resource specifies the resource role for the predecessor binding, and the last traversal along the matching topology path has been formed for the resource in the specified role. * A meta-resource specifies the resource role for the subsequent binding, and the next traversal along the matching topology path has been formed for the resource in the specified role. * The meta-resource specifies the filter, which evaluates the resource as an argument and returns true. * There is no resource matching constraint specified for the meta-resource and the resource does not match any other meta-resource. * The "equal (e)" specified between a meta resource and another meta resource
quals) constraint existed and the resource matched both meta-resources. * There was a "do'nt care" constraint specified between meta resource (A) and another meta resource (B), and the resource was consistent with both A and B. * The meta-resource specifies the proposition of the resource aspect attribute value,
The resource aspect attribute value of the resource evaluates the true of the proposition.

The API considers the logical condition in a query to be satisfied only if: * Logical AND: child and navigation path match. * Logical OR: At least one child navigation path matches. * Logical NOT: No route in the API matches the child navigation route.

Definition of Topology Subgraph The API regards the following items as topology subgraphs. * A topology route that matches the navigation route with the root node at the root node of the query tree. * A connection between resources in the topology path, expressed as two {resource aspects, resource roles (including index)} tuples.

Define Subgraph Output The API returns the resources that matched the query and their connections in the form of a topology subgraph. The API outputs a subgraph according to the following result construction rules. * None: The API does not include any subgraphs in the query results. * Any: The API includes one subgraph in the query result. The subgraph is randomly selected. * List: The API returns each subgraph individually. The order of the subgraphs is chosen randomly. * Graph: the API combines all subgraphs, removing duplicates, and returns the resulting subgraph. The API supports display rules for meta-resources for non-replaced navigation paths. The default value of the display rule is “ON”. The API modifies the topology subgraph according to the display rules as follows. * If the meta-resource specifies a display rule "on", the resources of the matched topology are shown in the subgraph. * If the meta-resource specifies the display rule "off", the resources of the matched topology are not shown in the subgraph. * If the result construction rule for the query specifies the "Graph" option and the resources in the subgraph represent multiple meta-resources in the query, the display rule "On"
If there is at least one meta-rule specifying, only that resource is displayed. The API supports user specified tags for each meta-resource being queried. The API modifies the topology subgraph according to the user tag as follows. * If the meta-resource specifies a user tag, the user tag is attached to the resources in the matching topology. * If the result construction rule for the query specifies the "Graph" option, and the resource in the subgraph represents more than one meta-resource in the query, the resource will have all associated user tags.

Output * True or false Boolean result. This part of the query result is always output. * Subgraph (optional). This part of the query result
Depends on result construction rules and display rules.

The method and structure of the topology management service for managing the topological connection between objects have been described above. It is to be understood that the particular embodiments described herein are for illustrative purposes, and should not be construed as limiting the invention to this particular embodiment. It is also clear from the description herein that those skilled in the art can make numerous uses and modifications of the specific embodiments described above without departing from the inventive concept. For example, the data structures described above may be implemented in the form of various known software data structures. Specifically, the representation of a resource by a resource name closure set may be implemented as a linked list data structure, a bit-mapped field indicating set inclusion, or a number of known computer software data structures. It is possible. Further, the methods described above can be modified to handle various data structures representing a topology storage information base. Alternatively, equivalent structures and processes can be used in place of the various structures and processes described above. Accordingly, the present invention should be considered to encompass the novel features and combinations of these features and configurations of the above-described methods and configurations, respectively.

The present invention includes the following embodiments as examples. (1) A method of managing a topological connection between a plurality of objects each having at least one resource name to identify one resource by using a computer,
Preparing a storage device for storing and retrieving information; receiving a request to manage the object; and generating a data structure in the storage device in response to receiving the request to manage the object. ,
Representing the resource by the object by associating the object with a resource identified by the at least one resource name of the object; and determining a resource name closure set of a plurality of objects each representing a shared resource. And generating, in the storage device, a data structure indicating a relationship between objects in the resource name closure set in response to the determination of the resource name closure set. (2) receiving a request to add a specified resource name to a specified object; and, in response to receiving the request to add the specified resource name, changing the specified resource name to the specified object. Updating a data structure indicating a resource name owned by the specified object by adding to a resource name owned by the object; and responding to the update, a plurality of objects each representing a shared resource. Re-determining a resource name closure set; and, in response to the re-determination of the resource name closure set, updating a data structure in the storage device indicating a relationship between objects in the resource name closure set. The method according to the above (1), further comprising: (3) receiving a request to delete a specified resource name from a specified object; and, in response to receiving the request to delete the specified resource name, changing the specified resource name to the specified resource. Updating a data structure indicating a resource name owned by the specified object by deleting from the resource name owned by the object; and responding to the update, a plurality of objects each representing a shared resource. Re-determining a resource name closure set; and, in response to the re-determination of the resource name closure set, updating a data structure in the storage device indicating a relationship between objects in the resource name closure set. The method according to the above (1), further comprising:

(4) receiving a request to constrain at least two specified objects to represent a shared resource; generating a unique resource name in response to receiving the restriction request; In response to receiving the constraint request, by adding the unique resource name to a resource name owned by each of the at least two specified objects, by each of the at least two specified objects. Updating a data structure indicating a owned resource name; re-determining resource name closure sets of a plurality of objects each representing a shared resource in response to the updating; and re-determining the resource name closure set Update the data structure in the storage device indicating the relationship between the objects in the resource name closure set Further comprising the a step, the (1)
The method described in. (5) receiving a request to unconstrain at least two specified objects that are already constrained to represent a shared resource; and in response to receiving the unconstrained request, the at least two specified objects. Updating a data structure indicating a resource name owned by each of said at least two specified objects by removing said unique resource name from a resource name owned by each of said created objects; Re-determining a resource name closure set of a plurality of objects each representing a shared resource in response to the updating; Updating the data structure in the storage device indicating the relationship.
The method described in.

(6) If the object is a network
The method according to (1), wherein the resource of the topology is represented. (7) the object is coupled to a logical network object representing the network and sub-network resources in the network topology by one of the logical network objects by an "included" connection, and the coupled logical network・
A logical node object representing an end point of information exchanged on the object, connected to one of the logical network objects by an "included" connection, and connected to one of the logical node objects by a "included" connection A logical interface node object representing a means for linking the combined logical node object to another object, and zero or more than one of the logical network objects coupled by an "included" connection With the above logical network object by a "containment" join,
One of the above logical interface node objects
A logical segment object that is connected by a "contained" connection and represents a means for transferring information between the connected logical interface node object and another object, and one of the logical network objects A logical concatenation object coupled by at least one of the logical segment objects and coupled by a "restricted" coupling and representing a means for concatenating one of the logical segment objects; The method according to the above (6).

(8) One of the logical segment objects is connected to one of the logical segment objects by an "included" connection, and is a physical network object representing a network and a sub-network resource in the network topology. A physical node object coupled to one of said physical network objects by a "contained" connection and representing an endpoint of information exchanged on the combined physical network object; and a physical node object of said physical network object. A physical interface that is coupled to one of the physical node objects by a "contained" connection, and is coupled to the one of the physical node objects by a "contained" connection, and represents a means for connecting the combined physical node object to other objects. And a physical interface object coupled to one of the physical network objects by a "contained" connection, and coupled to one of the physical interface node objects by a "coupled" connection. A physical segment object representing a means of transferring information between the physical segment object and one of the physical network objects by a "contained" connection, and a "restricted" connection with at least one of the physical segment objects And a physical connector object representing means for connecting at least one of the physical segment objects, and zero or more than one of the physical network objects connected by an "included" connection A chassis coupled to the physical connection object by an "inclusive" connection, coupled to zero or more physical node objects by an "inclusive" connection, and may include zero or more nodes and coupling means. The method according to (7), further comprising: representing a physical container object.

(9) A media network in which one of the physical segment objects is coupled to one of the physical segment objects by an "included" connection and represents an electronic interconnection of one of the physical segment objects. Object and said media network object by a "contained"connection;
And zero or more media cable objects representing interconnected signal paths that effectuate the exchange of data, coupled to the media network object by an "included" connection, and to at least one of the media cable objects and Zero or more media terminator objects coupled by a "coupled" connection and representing a signal termination device; and at least one of the media cable objects coupled by a "included" coupling to the media network object. Zero or one or more media adaptation objects coupled by a "coupled" connection and representing adaptation means for connecting one or more of the at least one media cable object; "Joined by a bond Linked by at least one "object linking" binding body cable object, and,
The method of claim 8, further comprising: zero or one or more media connector objects representing a signal concatenation / conversion device.

(10) A computer for managing topological connections between a plurality of objects stored in a storage device for use by an application program.
A system for associating at least one resource name adapted to identify a resource with each of the objects, and receiving a request to manage one of the objects from the application program. And storing the data structure representing the resource by the object by associating the object with a resource identified by the at least one resource name of the object in response to receiving the request to manage the object. Means for generating in the device; means for determining a resource name closure set of a plurality of objects each representing a shared resource; and, in response to the determination of the resource name closure set, a relationship between each object in the resource name closure set. Means for generating the data structure shown in the storage device. Temu. (11) means for receiving, from the application program, a request to add the specified resource name to the specified object; and, in response to receiving the request to add the specified resource name, changing the specified resource name. Means for updating a data structure indicating resource names owned by the specified object by appending to resource names owned by the specified object; and Means for redetermining the resource name closure set of the plurality of objects to be represented, and responsive to the redetermination of the resource name closure set, updating a data structure in the storage device indicating a relationship between the objects in the resource name closure set. Means, further comprising: (12) means for receiving, from the application program, a request to delete the specified resource name from the specified object; and responding to the receipt of the request to delete the specified resource name, the specified resource name Means for updating a data structure indicating a resource name owned by the specified object by removing from the resource name owned by the specified object; and in response to the update, Means for re-determining a resource name closure set of a plurality of objects representing a plurality of objects, and in response to the re-determination of the resource name closure set, updating a data structure in the storage device indicating a relationship between objects in the resource name closure set. The system according to (11), further comprising:

(13) At least 2 to represent shared resources
Means for receiving, from the application program, a request to constrain the two specified objects; means for generating a unique resource name in response to the receipt of the constraint request; and responding to the receipt of the constraint request, By adding the unique resource name to the resource name owned by each of the at least two specified objects, a data structure indicating the resource names owned by each of the at least two specified objects is created. Means for updating; means for re-determining a resource name closure set of a plurality of objects each representing a shared resource in response to the update; and means for re-determining the resource name closure set in response to the re-determination of the resource name closure set. (1) means for updating a data structure in the storage device indicating the relationship between the objects in (1). The system according to). (14) means for receiving from the application program a request to unconstrain at least two specified objects which are already constrained to represent a shared resource; and in response to receiving the unconstrained request, By removing the unique resource name from the resource names owned by each of the at least two specified objects, a data structure indicating the resource names owned by each of the at least two specified objects is created. Means for updating; means for re-determining resource name closure sets of a plurality of objects each representing a shared resource in response to the updating; and means for re-determining the resource name closure set in response to the re-determination of resource name closure sets. Means for updating a data structure in the storage device indicating a relationship between the objects in the storage device. The system according to (13).

(15) The system according to (10), wherein said object represents a resource of a network topology. (16) the object is coupled to a logical network object representing the network and sub-network resources in the network topology by one of the logical network objects by an "included" connection, and the connected logical network A logical node object representing the end point of the information exchanged on the object, coupled to one of the logical network objects by a "contained" connection, and to one of the logical node objects by a "contained" connection A logical interface node object that is coupled and represents a means of coupling the coupled logical node object to other objects, and is coupled to one of the logical network objects by an "included" coupling A logical interface node object coupled to one or more of the logical interface node objects by a "contained" connection with zero or one or more of the logical network objects; A logical segment object representing a means for transferring information between other objects;
A logical concatenated object coupled to one of the logical segment objects by a "contained" connection, at least coupled to one of the logical segment objects by a "restricted" connection, and representing means for connecting one of the logical segment objects The system according to the above (15), comprising:

(17) One of the logical segment objects is connected to one of the logical segment objects by an "included" connection, and a physical network object representing a network and a sub-network resource in the network topology. A physical node object coupled to one of said physical network objects by a "contained" connection and representing an endpoint of information exchanged on the combined physical network object; and a physical node object of said physical network object. A physical interface coupled to one of the physical node objects by a "contained" connection, and coupled to the one of the physical node objects by a "contained" connection, and representing a means for connecting the combined physical node object to other objects. And a physical interface object coupled to one of the physical network objects by a "contained" connection, and coupled to one of the physical interface node objects by a "coupled" connection. A physical segment object representing a means of transferring information between the physical segment object and one of the physical network objects by a "contained" connection, and a "restricted" connection with at least one of the physical segment objects And a physical connector object representing a means for connecting at least one of the physical segment objects, and zero or more than one coupled to one of the physical network objects by an "included" connection A chassis coupled to the physical connection object by an "inclusive" connection, coupled to zero or more of the physical node objects by an "inclusive" connection, and may include zero or more nodes and coupling means. The system of claim 16, further comprising: a physical container object to represent.

(18) A media network in which one of the physical segment objects is coupled to one of the physical segment objects by an "included" connection and represents an electronic interconnection of one of the physical segment objects. An object, zero or more media cable objects coupled by said media network object by an "included" connection and representing an interconnect signal path for effecting the exchange of data; and said media network object. "Included"
Zero or one or more media terminator objects coupled by a coupling and coupled to at least one of the media cable objects by a "coupled" coupling and representing a signal termination device; Zero or more than one or more of the media cable objects coupled by at least one of the media cable objects and coupled by a "coupled" coupling to represent one or more of the adaptation means for connecting one or more of the at least one media cable object. A media adaptation object, coupled to the physical media network object by a "included" connection, coupled to at least one of the media cable objects by a "coupled"connection;
And zero or more media connector objects representing signal concatenation / conversion devices.
The system according to 7).

[0192]

By implementing the topology management service of the present invention, it is possible to share common information between different applications without individually storing common information, and to update information in a consistent manner. As a result, the present invention has the effects of reducing the information storage capacity of the entire enterprise and ensuring data consistency.

[Brief description of the drawings]

FIG. 1 is a block diagram of a general purpose data processing system that can implement the API structures and methods of the present invention.

FIG. 2 illustrates an object-oriented analysis and design of an API structure handled by the method of the present invention.

FIG. 3 is a block diagram conceptually showing resource integration of an API structure and a method of the present invention caused by managing an unmanaged object.

FIG. 4 is a block diagram conceptually showing resource integration of an API structure and a method of the present invention caused by deleting management of a managed object.

FIG. 5 is a block diagram conceptually illustrating resource integration of an API structure and a method of the present invention which is generated by adding a resource name to a currently managed resource aspect.

FIG. 6 is a block diagram conceptually illustrating resource integration of an API structure and a method of the present invention generated by deleting a resource name from a currently managed resource aspect.

FIG. 7 is a flow diagram of the method of the present invention for processing the structure of the present invention to perform general maintenance of topological information.

FIG. 8 is a flow chart of a method of the present invention for performing the operation of incorporating knowledge into the structure of a newly managed object.

FIG. 9 is a flowchart of a method of the present invention for performing an operation of deleting knowledge from the structure of an object that is already managed.

FIG. 10 illustrates an object oriented analysis and design of an example IP network topology managed by the API structures and methods of the present invention.

FIG. 11 illustrates a more detailed object oriented analysis and design of the IP network topology managed by the API structures and methods of the present invention.

FIG. 12 is a block diagram illustrating a typical prior art approach in which each heterogeneous application program manages specific enterprise topological information.

FIG. 13 is a block diagram illustrating various application programs that utilize the Topological Management Services API of the present invention to manage all enterprise topologies using a common structure and related methods.

FIG. 14 is a block diagram illustrating a hierarchical data structure in which resource aspect types are inherited in accordance with the present invention.

FIG. 15 is a block diagram that graphically represents a general topology query for topological connections in a stored topological information base using a simple navigation path as an example.

FIG. 16 is a block diagram showing a general topology query regarding a topological combination in a stored topological information base as a graph by taking a compound query as an example.

FIG. 17 is a block diagram illustrating a general topology query regarding a topological connection in a stored topological information base as a graph using a composite query as an example.

FIG. 18 is a block diagram graphically representing a general topology query for topological connections in a stored topological information base, using query iteration as an example.

FIG. 19 is a block diagram that graphically illustrates, by way of example, information generated and returned according to a labeling rule for a general topology query regarding topological coupling in a stored topological information base.

FIG. 20 is a block diagram that graphically illustrates a typical IP network topology design including objects managed by the API structure and methods of the present invention.

[Explanation of symbols]

REFERENCE SIGNS LIST 100 computer system 102 processing element 110 main memory 112 network interface 114 disk 118 network 120 topology management system 122 operating system 124 storage management software 126 application program 200 resources 202 resource aspect (RA) 204 coupling 210, 214, 220 , 222, 224 relationship 206 topological component 208 non-topological component 212 resource aspect type (RAT) 216 enforcement function 222 notification receiving function 300, 350, 400, 450, 500, 550, 6
00,650 Topology 1050,1160 IP Network 1170 Link Network 1180 10baseT Network 1190 TP Network 1314 Topology Server 1320 Binding Information 1400 Root Node of Resource Aspect

Continued on the front page (72) Inventor Andrew Zander Australia 4069 Plaguer Street, Chapel Hill, Queensland 23 (72) Inventor Brian Jay Atkins, United States 80525 Edinburgh, Fort Collins, Colorado 2918

Claims (1)

[Claims] A method for managing, by using a computer, a topological connection between a plurality of objects each having at least one resource name to identify one resource, the storage for information storage and retrieval. Preparing the device; receiving a request to manage the object; generating a data structure in the storage device in response to receiving the request to manage the object; and the at least one resource of the object Representing the resource by the object by associating the object with a resource identified by a name; determining a resource name closure set of a plurality of objects each representing a shared resource; In response to the decision, each object in the above resource name closure set Method comprising the steps of a data structure illustrating the relationship between-objects generating in the storage device.