EP0750254B1 - Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten - Google Patents

Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten Download PDF

Info

Publication number
EP0750254B1
EP0750254B1 EP19960109347 EP96109347A EP0750254B1 EP 0750254 B1 EP0750254 B1 EP 0750254B1 EP 19960109347 EP19960109347 EP 19960109347 EP 96109347 A EP96109347 A EP 96109347A EP 0750254 B1 EP0750254 B1 EP 0750254B1
Authority
EP
European Patent Office
Prior art keywords
resource
logical
objects
physical
name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
EP19960109347
Other languages
English (en)
French (fr)
Other versions
EP0750254A1 (de
Inventor
Robert A. Potterveld
Thomas G. Bartz
Andrew Zander
Brian J. Atkins
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HP Inc
Original Assignee
Hewlett Packard Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Priority to DE1996621077 priority Critical patent/DE69621077T2/de
Publication of EP0750254A1 publication Critical patent/EP0750254A1/de
Priority to JP9150779A priority patent/JPH10116219A/ja
Application granted granted Critical
Publication of EP0750254B1 publication Critical patent/EP0750254B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Definitions

  • the present invention relates to the field of enterprise management systems and in particular to a computer based, object oriented, model of enterprise management which may be utilized to manage any objects which can be characterized by topological associations.
  • an enterprise may manage payroll functions through the management of objects such as payroll checks, employees, withholding accounts, retirement accounts, and the associations therebetween.
  • An employee is associated with one withholding account and one retirement account but with several payroll checks.
  • the management of an enterprise network may involve associations between several subnets, between a node and its neighbors, between a node and its users, or between a particular program and its users.
  • prior management information application programs which attempt to manage topological aspects of an enterprise can be characterized as managing the objects in isolation and the associations between the managed objects.
  • the rules that govern the associations between objects essentially define the topology.
  • the rules that define the associations between nodes and protocol layers in a Transmission Control Protocol/lnternet Protocol (TCP/IP) network define a TCP/IP topology.
  • TCP/IP Transmission Control Protocol/lnternet Protocol
  • Enterprise management applications which relate to TCP/IP network management therefore seek to enforce compliance with rules which define the TCP/IP topology.
  • there is no enterprise-wide standard for defining such topologies there is no enterprise-wide standard for defining such topologies. Instead, a variety of disparate solutions tend to evolve, each of which manages a particular topology within the enterprise.
  • the types of objects managed and the managed associations between those objects varies widely among these enterprise topology management systems. It is common practice in the art to utilize different computer based management tools for each of the several management tasks common within an enterprise. A tool which is well tuned for a particular use, a particular aspect of enterprise management, is often preferred to a general purpose tool which attempts to incorporate more features in a generalized manner. Due to this preference it is common to use a plurality of management tools, often produced by disparate vendors, each well tuned to a different management task. By way of example, a personnel management task may select one computing system well tuned to payroll generation. A different tool may be preferred for maintaining other personnel records and enterprise organizational matters relating to staffing (i.e. organization charts).
  • a first problem with the use of disparate applications programs is the increase in development effort to create the needed applications.
  • the various management applications are developed over a span of time by diverse development groups.
  • Each application tends to develop its own unique structures and methods for managing the topological associations between the managed objects.
  • This redundant development may increase the complexity and related costs for development of such topological management applications.
  • the variety of independently developed structures and methods for managing topological associations between managed objects tends to lead toward incompatible designs which may be difficult to integrate.
  • EP-A-0304071 discloses a data integration by object management.
  • An object based data processing system including an extensible set of object types and a corresponding set of object managers wherein each object manager is a program for operating with the data stored in a corresponding type of object.
  • the object managers in general support at least a standard set of operations. Any program can effect performance of these standard operations on objects of any type by making an invocation request.
  • object management services (which are available to all object managers) identifies and invokes an object manager that is suitable for performing the requested operation on the specified type of data.
  • a mechanism is provided for linking data from one object into another object.
  • An object catalog includes both information about objects and about links between objects.
  • Data interchange services are provided for communicating data between objects of different types, using a set of standard data interchange formats.
  • a matchmaker facility permits two processes that are to cooperate in a data interchange operation to identify each other and to identify data formats they have in common.
  • a facility is provided for managing shared data "resources”. Customized versions of resources can be created and co-exist with standard resources.
  • a resource retrieval function determines whether a customized or a standard resource is to be returned in response to each request for a resource.
  • Such improved systems would assist in reducing duplication of information stored within the topological management system in such a way that new management information applications could be more easily integrated with existing applications than is possible under known prior approaches.
  • the present invention solves the above identified problems and thereby advances the art by providing methods and related structures to manage topological associations between objects used in information management data processing applications.
  • the methods and structures of the present invention permit an application designer to create management information application programs to manage disparate aspects of topological information.
  • Topological rules defined by the application programs, govern the creation, deletion, and modification of these topological associations between objects. These topological rules are stored and enforced by the API to govern the manipulation by application programs of associations between managed objects. The API of the present invention thereby enforces consistent rules for the manipulation of topologies managed by the API on behalf of several application programs.
  • the API of the present invention provides a simple interface for an application developer to determine what information is presently managed by the API with respect to particular associations between managed objects.
  • An application developer defines a particular set of attributes, useful to his/her management application, which uniquely defines the objects manipulated by the application.
  • the API of the present invention detects that an object so defined by one application in fact refers to the same entity (also referred to herein as resource) as another object provided to the API topology management by the same or another application program.
  • An application program thereby has a unique view of an entity represented by the object used by the application.
  • the view of an object utilized by one application program is referred to herein as a resource aspect.
  • the topology management API of the present invention can provide an application program any topological information from other managed objects which are recognized to represent the same entity (resource) as the managed object provided by the application program.
  • the API of the present invention also provides the ability to perform general topological queries of the entire enterprise-wide information base.
  • General topological queries are queries that can provide information regarding managed objects and their managed topological associations. They can be generated as simple textual expressions yet may specify queries ranging from simple to very complex. These queries can involve objects and associations beyond the scope of information manipulated by any single application program.
  • the query related API functions return sub-graph object structures that contain the managed objects and their managed topological associations that matched the query.
  • the present invention comprises an application program interface (API) which manages topologically associated objects according to rules which define one or more topologies.
  • API application program interface
  • 'topological associations refer to associations between objects which may be represented graphically.
  • a collection of objects and the topological associations between them is referred to herein as a "topology.”
  • a system which manages such topologies is referred to herein as a "topological" management system.
  • Topological management as used herein is also referred to as relationship management In relationship management terminology, a topology is a set of managed relationships between managed objects and, topological information is a set of relationships between managed objects.
  • Topological enterprise database refers equally to a relationship management database which contains topological information.
  • FIG. 12 provides an overview of typical methods applied by prior designs for enterprise management
  • Each distinct enterprise management task is designed with a customized application program.
  • Each application program typically had its own database providing information and associated structure as appropriate to the specific application.
  • typical applications which are used to manage topological information include human resources (H.R.) management applications 1200, asset management applications 1202, and network/computing management applications 1204.
  • H.R. human resources
  • Each application has its own distinct application database associated therewith, namely, H.R. database 1206, asset database 1208, and network/computing database 1210, respectively.
  • H.R. database 1206 shares some common information with the users data in asset database 1208 and with the users data in network/computing database 1210.
  • Duplication of data in three databases creates problems in these prior designs. Problems, as discussed above, relate to one database being updated independently of another, unnecessary duplication of storage space, and difficulties in integrating one application with another as needs grow and evolve.
  • FIG. 13 depicts an overview of the enterprise management application designs made possible by the topology management service of the present invention.
  • FIG. 13 shows three separate management applications, namely H.R. management application 1300, asset management application 1302, and network/computing management application 1304.
  • the three application programs 1300, 1302, and 1304 are depicted above the dashed line in FIG. 13 to indicate that they are client application programs.
  • All three applications utilize the common topology server 1314 of the present invention.
  • Topology management server 1314 manages topological information (association information 1320) relating to the topological aspects of the objects manipulated by the three client application programs 1300, 1302, and 1304. All such topological information (association information 1320) is therefore managed according to a common set of rules through a common server program interface (topology server 1314). This permits each application client program to share topological information made known through other application client programs.
  • Non-topological information may be managed by the application client programs through the use of dedicated server programs such as employee server 1306, asset server 1308, and network/computing server 1310. As depicted in FIG. 13, the server programs may in turn invoke the services of other common server programs such as people server 1312 to share common elements of information more effectively.
  • People server program 1312 manages non-topological information relating to people in people information 1316.
  • Asset server program 1308 manages asset information 1318 which is unique to its particular management task.
  • network/computing server program 1310 manages network/computing information 1322 which is unique to its application area.
  • FIG. 1 shows a block diagram of the computer hardware that contains the topology management services system of the present invention.
  • a computer system 100 contains a processing element 102 which communicates to other elements within the computer system 100 over a system bus 104.
  • a keyboard 106 is used to input information from a user of the system, and a display 108 is used to output information to the user.
  • a network interface 112 is used to interface the system 100 to a network 118 to allow the computer system 100 to act as a node on a network and to thereby communicate with other nodes on the network.
  • a disk 114 is used to store the software of the topology management system of the present invention, to store the topological enterprise database, and to store the managed objects.
  • a printer 116 can be used to provide a hard copy output of the topology information displayed by the system.
  • a main memory 110 within the system 100 contains the topology management system 120 of the present invention.
  • An application program 126 developed by a user of the present invention communicates with the topological management system 120, which in turn communicates with an operating system 122 and storage management software 124 to perform the topological management services on behalf of client application programs.
  • the client application programs 126 may operate locally, within computer system 100 or may operate on other computer systems attached to, and communicating over, network 118. It will also be recognized by those of ordinary skill in the art that the information stored in the topological enterprise database may be stored locally on disk 114, or may be stored locally in main memory 110, or may be distributed over other computer systems accessible via network 118, or in any combination of storage devices.
  • permanent storage of the information may reside on local or remote disk subsystems and a local memory cache may be used to improve performance.
  • the information stored in the topological enterprise database may be stored in any memory device or subsystem having suitable capacity and performance characteristics.
  • the term disk 114 as used herein is intended to describe all such suitable memory devices or subsystems.
  • FIG. 2 is an overview of the data constructs and relationships created and managed by the topological management methods of the present invention.
  • FIG. 2 is an object oriented analysis view of the data constructs and relationships of the present invention. It is drawn and to be interpreted according to the FUSION object model.
  • FUSION is an object oriented analysis and design tool produced by Hewlett Packard Company of Palo Alto, California. Readers unfamiliar with such object oriented design are directed to the published documentation for the Fusion Method in "Object-Oriented Development - the Fusion Method” (published by Prentice Hall ISBN 0-13-338823-9).
  • the data constructs are indicated by labelled boxes and the relationships between the data constructs are indicated by lines connecting the related boxes to a diamond shaped entity.
  • the lines connecting data construct boxes in FIG. 2 are labelled to indicate the type of relationship between the related boxes.
  • a label of "1" indicates that exactly one of the data constructs participates in the relationship
  • a label of "*" indicates zero or more data constructs participate in the associated relationship
  • a label "+” indicates one of more data constructs.
  • a one-to-one relationship between two data constructs is indicated by a numeral "1" at each end of the lines connecting the data construct boxes to the diamond shaped relationship.
  • Resource 200 is a data construct which represents the combined characteristics of all aspects of a "thing" of interest in the application of the methods of the present invention.
  • a resource 200 is an instance of a thing, at the highest level of abstraction, to be managed by the present invention.
  • a person, a building, a network, or a computing node might be examples of abstract things to be managed by the topology management methods of the present invention.
  • the level of abstraction useful to a particular application of the present invention is a matter of design choice and is frequently associated with the well known methods of Object Oriented Design and Analysis common to the software engineering arts.
  • a resource 200 is comprised of one or more resource aspects 202 (hereinafter referred to as RAs).
  • An RA 202 is an object supplied by an application program using the topological management methods of the present invention.
  • An RA 202 further comprises a topological component 206 which is related to zero or one non-topological components 208 as depicted in FIG. 2 by relation 210.
  • the topological component 206 of an RA 202 contains the information relevant to the topological management service of the present invention, specifically resource names, the associated resource aspect type, and details relating to associations in which the RA 202 is participating. Details of these elements are discussed below.
  • the non-topological component 208 of an RA 202 contains information unique to the application program which is using the object and is otherwise uninvolved in the topological management methods of the present invention.
  • a resource name (hereinafter referred to as RN) is a field which has a tag name and a presently assigned value.
  • a resource 200 is uniquely defined by one or more resource names (stored within a resource aspect 202 as described below). Specifically, a resource 200 is uniquely identified by the transitive closure of the union of all resource names stored within all RAs 202 which are currently managed as aspects of the resource 200.
  • the RNs which uniquely define a resource 200 are supplied by the application programs using the methods of the present invention.
  • An application program utilizing the present invention provides an RA 202 including one or more RNs identifying a specific resource 200, and requests that the object be managed by the topological management methods of the present invention.
  • RNs not previously supplied in an object by another application program are thereby added to the collection of known characteristics (RNs) of the specified resource 200.
  • Each RA 202 identifies the associated resource 200 by its particular subset of RN values.
  • the resource 200 is therefore the union or integration point for all resource names known in all RA 202 subsets of the RNs.
  • the objects supplied to the topological management system are managed by associating each object with the resource 200 uniquely identified by the supplied RNs. If the supplied RNs do not identify an existing resource 200, a new resource 200 is automatically created. Therefore, each resource 200 is associated with one or more RAs 202. Each RA 202 associated with a resource 200 is said to represent one particular aspect of the resource 200.
  • Application programs which use the topology management methods of the present invention may each utilize different subsets of the resource names defining a resource 200.
  • one application program may be concerned with a "person” resource as an “employee” while another application may view the same person as a "club member.”
  • one application may view a "network” resource as a "TCP/IP local area network” and concern itself with manipulation of RNs relating to that aspect of the "network” resource.
  • Yet another application may be concerned with the "wide area network” aspect of the "network” resource RNs.
  • Each subset of the RNs of a resource 200 is referred to as an "aspect” and is represented by at most one RA 202.
  • Each RA 202 is in a one-to-one relationship with a resource aspect type 212 (hereinafter referred to as RAT).
  • a resource 200 may be represented by several aspects (several RAs may fully describe one resource from the perspective of several different application program aspects). Therefore, there is shown a many-to-many "classifies" relationship 220 between RAs 202 and RATs 212.
  • Built-in rules also referred to as invariants within the present invention preclude a resource from being represented by more than one RA 202 classified by a particular RAT 212 (or a particular RAT 212 and a specialization of that type as discussed below).
  • the RAT 212 constrains the types of relations in which the related RA 202 may participate.
  • a set of rules associated with the RAT 212 defines the constraints applied to the aspect of a resource 200 represented by an RA 202.
  • the constraints include built-in rules which are predefined and allow for limited customization, and extensible rules which may be completely defined by the application programmer.
  • Part of the configurable rules defined in the each RAT 212 is a list of previously defined, named roles through which the associated RA 202 may participate in associations (this is discussed in more detail below).
  • RATs 212 are defined as a class or may be defined as a specialization of a previously defined RAT class.
  • a specialization of a previously specified class inherits all properties of the previously defined class and specifies additional attributes and constraints.
  • "permanent employee” and "temporary employee” may be two resource aspect type specializations of an RAT 212 which specifies the constraints for the "employee” resource aspect type.
  • the newly defined specialization RAT 212 is in a "specializes" relation with the previously defined RAT 212 as indicated by the relation 214.
  • Resources 200 are not explicitly managed by application programs utilizing the topological management methods of the present invention. Rather, the topological management methods create, modify, and destroy resources 200 based on the resource aspects 202 provided to the methods for topological management. In other words as objects are provided to the topological management services with a request that the object be managed, resources 200 are created, destroyed, or modified based on the resource names provided with the RA 202. Conversely, when a managed RA 202 is identified by an application program with a request that the object become unmanaged, related resources 200 are created, destroyed, or modified as appropriate to the remaining resource names known with respect to an affected resource 200.
  • the methods of the present invention which create, destroy, and modify resources 200 are discussed below in further detail.
  • Associations 204 define interrelationships between two RAs 200.
  • two "person” resources 200 each represented by an RA 202 having an “employee” resource aspect type 212, might participate in a "works for" association 204 to express enterprise personnel organization.
  • the same two resources might also participate in a "works with” association for purposes of the same, or another, application program.
  • a "network” resource and a “computing node” resource might participate in a "connected to" association.
  • Associations 204 are created by an application program using the topological management methods of the present invention to reflect an association between two resource aspects 202.
  • An application program invokes the topological management methods to create a new association.
  • the application provides a list of RAs 202 and a definition of the "role” played by each provided RA in the new association. The use of "roles" in an association is discussed in detail below.
  • Application programs which use the topology management methods of the present invention may each utilize different interrelationships between resources 200.
  • one application program may be concerned with a "works for” or “works with” association between “person” resources 200 viewed from the "employee” aspect RAs 202 while another application may be concerned with "is the child of” or “is married to” associations between the same two "person” resources 200 viewed from the "family member” aspect RAs 202.
  • the topological management service of the present invention includes built-in rules to reject certain inappropriate requests generated by a client application program.
  • the methods of the present invention reject any request made by a client application program which would result in a resource 200 being represented by:
  • the RAT 212 associated with each RA 202 defines a set of rules which enumerates the permitted association roles for that RAT 212. Specifically, the rules in each RAT 212 list the roles which are permitted for the related RA 202 in forming associations 204 with other RAs 202. By applying these rules, the methods of the present invention prevent the formation of invalid associations 204 between resources 200 as represented by the RAs 202.
  • an association 204 is created by a client application program providing two RAs 202 to be associated and the desired role for each specified RA. The desired association is only formed if the RAT 212 which relates to each provided RA includes a rule which permits the formation of the association with the specified roles used for the specified RAs 202.
  • the clients application program may define application specific rules (enforcers) to verify the validity of other changes to the topologically managed enterprise database.
  • Enforcers 216 are defined by the application program by providing a programmed function to be performed to verify the propriety of any changes to a particular resource.
  • the enforcer 216 programmed function is invoked to verify any proposed changes to a resource related to the RAT 212 which defined the enforcer 216.
  • the enforcer 216 function is provided with the resource 200 and the RAT 212 as inputs, evaluates the propriety of the proposed changes to the resource, and returns a value indicative of the propriety of the proposed change.
  • the proposed changes are rejected by the topological management methods if any enforcer function return a value indicative of an improper change to the resource.
  • Enforcers 216 provide the application program the maximum flexibility to verify the consistency and propriety of the resources in the topologically managed enterprise database.
  • Notification receivers 226 are objects which are related 222 to an RAT 212 to define an interface for reception of a notification of a change of a particular RAT 212 in a managed topology.
  • a notification receiver object is related to one or more predefined trigger conditions each of which is "triggered" when a particular predefined type of change is made to a related RAT 212 in the topology.
  • Notification receivers 226 are also related 224 to an RA 202 to define an interface for reception of a notification of a change of a particular RA 202 in a managed topology.
  • a notification receiver object is related to one or more predefined trigger conditions each of which is "triggered" when a particular predefined type of change is made to a related RA 202 in the topology.
  • the data constructs and associated methods of the present invention recognize when several resource aspects in fact refer to the same resource by the resource names (RN) given to the RA 202. This is accomplished by "representing" a resource 200 by each of the RAs 202 in a "resource name closure set.” As used herein "representing" means that resources 200 are not referenced directly by client application programs, but rather indirectly through the RAs 202 which "represent” the resource.
  • a "resource name closure set” is the largest set of resource aspects (RAs 202) such that each resource aspect in the set shares at least one resource name (RN) with at least one other resource aspect of the set. In other words it is the transitive closure of the intersection of resource names for resource aspects (RAs 202).
  • the resource name closure set identifies a resource 200 as the set of resource aspects (RAs 202) representing the resource 200.
  • the resource name closure set for RESOURCE1 302 is resource aspects 306, 308 and 310 because that is the largest set of RAs which all share at least one resource name (RN) with at least one other RA.
  • the resource name closure set for RESOURCE2 304 is the single RA 314.
  • the topology management service of the present invention understands the total set of managed RAs (306, 308, 310, and 314) to represent two separate resources (persons), namely RESOURCE1 302 and RESOURCE2 304.
  • Object 312 in topology 300 (before) has not yet been provided to the topology management service to be managed in the topology.
  • Topology 350 represents a snapshot of the same topology after the addition of object 312 to the set of topologically managed objects.
  • object 312 has now been provided to the topology management service and thereby becomes a resource aspect 312.
  • the resource name closure set is determined again by the topology management service for all managed resources.
  • the newly managed RA 312 has a resource name shared by RA 310 and another resource name shared by RA 314. Therefore, the resource name closure set now includes all managed RAs in topology 350, namely 306, 308, 310, 312, and 314.
  • RESOURCE1 302 and RESOURCE2 304 cease to exist as distinct resources and a new resource, RESOURCES 316, is now represented by the entire set of RAs, namely 306, 308, 310, 312, and 314.
  • topology 350 is labelled as the result of adding object 312 to topology 300.
  • the reverse operation can also be seen in FIG. 3 by simply reversing the "before" and "after” labels.
  • topology 350 were the initial condition of a managed topology, and the user requested that currently managed RA 312 be removed from the management services of the topology management service, then topology 300 would result.
  • the resource name closure set determination reveals that there are now two, apparently, distinct resources where there was one.
  • RESOURCE3 316 of topology 350 would be destroyed and RESOURCE1 302 and RESOURCE2 304 would be created in its place.
  • the topology management service of the present invention determines the resource name closure set after any change in the topology which may affect the relationship between resources and resource aspects.
  • FIGS. 4-6 depict additional alterations made by the topology management service in response to other types of changes which affect the topology resource integration.
  • the resource aspects are shown only in abstraction with labels such as RA1-RA8. The specific content of any resource aspect is not relevant to the types of operations which are depicted in FIGS. 4-6.
  • FIG. 4 depicts the above described reversal of the topology management function in FIG. 3.
  • the initial state of topology 400 shows the resource name closure set representing RESOURCE1 402 to be RA1 406, RA2 408, RA3 410, and RA4 412 while the resource name closure set representing RESOURCE2 404 is RA5 414 and RA6 416. If RA3 410 is removed from the management service ("unmanaged"), then topology 450 results wherein RESOURCE1 402 is destroyed and two new resources, RESOURCE3 418 and RESOURCE4 420, are created in its stead.
  • RA3 410 breaks the sharing of at least one resource name between the previous members of the resource name closure set representing RESOURCE1 402.
  • New RESOURCE3 418 is represented by RA1 406 and RA2 408 while new RESOURCE4 420 is represented by RA4 412.
  • RESOURCE2 404 is unaffected by this change.
  • the resource name closure sets of resources in a topology may also be altered by changing the resource names associated with a particular resource aspect. If resource names are associated with, or disassociated with, managed resource aspects, the resource name closure set may also change.
  • the resource names associated with a particular resource aspect are determined by the resource aspect type (RAT) which classifies the resource aspect (RA).
  • FIG. 5 depicts the changes to a topology caused by addition of a resource name to a resource aspect Topology 500 depicts an initial state of a managed topology in which there are two resources, RESOURCE1 502 and RESOURCE2 504.
  • RESOURCE1 502 is represented by its resource name closure set RA1 506, RA2 508, RA3 510, and RA4 512.
  • RESOURCE2 504 is represented by its resource name closure set RA5 514, RA6 516, and RA8 518. If a new resource name (RN) is added to RA8 518 and the new RN is shared with RA4 512, then topology 550 results from the topology management determination of resource name closure sets of all resources. RESOURCE1 502 and RESOURCE2 504 are destroyed and a new resource, RESOURCE3 520, is created in their place. RESOURCE3 520 is represented by the new resource name closure set which comprises all RAs known to the topology management service. The addition of the new RN to RA8 518 effectively joined to the two, previously distinct, resources by joining their respective resource name closure sets.
  • RESOURCE1 602 is destroyed and replaced by two new resources, RESOURCE2 618 and RESOURCE3 620.
  • RESOURCE2 618 is represented by its resource name closure set comprising RA1 604, RA2 606, RA3 608, and RA4 610
  • RESOURCES 620 is represented by the closure set of RA5 614, RA6 616, and RA8 612.
  • the deletion of an RN from RA8 612 effectively splits the resource by splitting the resource name closure sets. It will be readily recognized that the same result may be produced by removing an RN from RA4 610 which is shared by RA8 612, or similarly, with any pair of RAs in the same resource name closure set which share only the removed resource name.
  • the service department of a manufacturer manages all electrical devices used throughout the company.
  • the department requires a system to assist them in managing their inventory of electrical devices.
  • the department manages both 110V and 220V electrical devices. Some power outlets are 220V whereas others are 110V. The department wants to ensure that 110V electrical devices are not allocated to be plugged into 220V power outlets and that 220V devices are not allocated to be plugged into 110V power outlets.
  • serial connection between two computers may be modelled simply as a "connection” resource that has associations with two "computer” resources.
  • the serial connection may be modelled as a "serial card” resource associated with a "cable” which is in turn associated with another "serial card.”
  • a resource aspect typed as a 110V_Device must participate in associations (on its Sink role) with resource aspects that are classified as both Power Supply and 110V_Power by resource aspect types (RATs). Both rules apply.
  • RATs resource aspect types
  • a resource aspect of type 110V_Power will comply with both rules because a resource aspect type 110V_Power is a specialization of the Power_Supply resource aspect type.
  • a resource aspect type of Power_Supply will not comply with both rules and so is invalid.
  • topology semantics the developer can now use topology to create, update, delete, and query associations between resource aspects.
  • table 2 specifies the resource aspects for the electrical devices: With the specified constraints, the developer can create the following associations:
  • the problem to be solved specifies that 110V_Devices are not able to form associations with 220V_Outlets and visa versa.
  • the resource aspect rules ensure that these restrictions are enforced in the enterprise topological database.
  • the cardinality constraints expressed for the 110V_Devices and 220V_Devices ensure that each device can only participate in one association with an appropriate Power_Supply resource aspect.
  • the cardinality constraints on the 110V_Outlets and 220V_Outlets ensure that each is associated with only one Power_Supply. This combination of rules ensures that only one device of the appropriate power rating will be plugged into each outlet of the same power rating.
  • the developer can pose queries on the topological stored information base. Only very simple queries can be demonstrated for this example. Some possible queries may include:
  • This example topology utilizes the topological management service of the present invention to manage a logical network.
  • This topological model is generalized enough that it may be used with appropriate specializations of the resource aspect types to manage the topology of, for example, a TCP/IP network, a Novell network, a Vines network, or most other commercially available network models.
  • This topology is composed of a "logical_network" which further comprises a collection of objects and associations between the objects.
  • the logical_network has a basic set of objects and associations common to most network topologies and can therefore be used to manage the topology of most commercially available networks.
  • any specific network implementation (an IP network for example), has network specific semantic rules which must be followed.
  • This logical_network topology model defines the basic network objects and associations without regard to specific network semantics.
  • FIG. 20 The objects managed by this exemplary application of the topology management service of the present invention are depicted graphically in FIG. 20 (as well as described in tables below).
  • a logical_network 2012 of FIG. 20 is an aggregation of the objects which participate in the network and any related associations. Not all objects shown must participate in a specific network implementation. That is, some network semantics may not make use of a given object or association.
  • the resource aspect types defined in this model are:
  • logical_segment 2018 contains a single logical_network 2012.
  • a logical_segment 2018 at one layer defines a logical_network 2012 at the layer below it.
  • An entire layer of a network "protocol stack" may be represented as a logical_segment 2018 within the layer above it.
  • the seven layer ISO and the TCP/IP layered models are exemplary of such layered protocol stacks.
  • a logical_network 2012 may be contained by multiple logical_segments 2018.
  • the containment, connection, and bounding associations described above are represented in the model as resource aspect types. These RATs are used to associate one element of the logical network with another.
  • ip_network 1050 of FIG. 10 For example, consider ip_network 1050 of FIG. 10.
  • ip_nodes 1000 and 1002 are each a specialization of the resource aspect type logical_node.
  • ip_if 1004 and 1006 are each a specialization of the resource aspect type logical_if
  • ip_router 1012 is a specialization of logical_connector
  • ip_subnet 1008 and 1010 is each a specialization of logical_segment.
  • the ip_subnet 1008 and 1010 (logical_segment) objects are supported by a complete logical_network at a lower layer (consisting of nodes, interfaces, segments, and possibly connectors).
  • the ip_subnet 1008 is said to contain this lower order network, namely ip_network 1052 and ip_subnet contains ip_network 1054.
  • the physical_network 2032 model of FIG. 20 is slightly different from the logical_network 2012. For the most part, it is a specialization of the logical_network 2012 model described above.
  • the physical_network 2032 topology objects are each largely inherited from the equivalent logical topology object.
  • Physical_segments 2036 are bounded by physical_connectors 2026 through physical_boundary objects 2028.
  • Physical_connectors 2026 are specializations of physical_nodes 2020 which contain physical_interfaces 2024 through physical_node_containment objects 2022.
  • Physical_segments 2036 are defined by physical_interfaces 2024 through physical_interface_containment objects 2030.
  • a physical_network 2032 is a subtype (subclass) of logical_network 2012, it can be contained by a logical_segment 2018. In most cases, the lowest level modeled in the Network Topology Service will be the physical_network 2032.
  • the lowest possible network topology layer is the media_network 2038 of FIG. 20.
  • This is basically a collection of hardware that forms the physical transmission medium. Though this layer model is rarely required for network management applications, it is described herein to demonstrate the interrelationship of diverse aspects of the same resources. In some cases, for example, the application developer may want to model this layer for inventory purposes.
  • Another potentially significant use of the media_network 2038 layer model includes verifying that an intended use of a media installation conforms to the requirements of the upper layer protocol. Media network layout might very well be the domain of some other agency within an enterprise, such as a site telecom or communication department, rather than a network management department.
  • the topology management services of the present invention permit the integration of all information relating to a managed topology so that a consistent view may be maintained from all aspects of the information.
  • the media_network 2038 layer objects are intended to be very flexible.
  • a media_cable 2042 might be a line of sight path from one infrared transceiver to another, or a packet radio frequency as well as conductive wiring.
  • FIG. 10 a single layer of an exemplary network was presented.
  • the example shown in FIG. 11 extends the example depicted in FIG. 10 by exploding the lower ip_networks, 1052 of FIG. 10 for example, using all the models described above (the logical, physical and media layers).
  • the several objects are shown with the following derivation in table 4:
  • the top level network is an ip_network 1160 comprising ip_nodes 1102 and 1104 which contain ip_ifs (interfaces) 1106 and 1108, respectively.
  • ip_node 1102 and 1104 is connected, through ip_ifs 1106 and 1108, respectively, to ip_router 1114 via ip_subnets 1110 and 1112, respectively.
  • Each ip_subnet 1110 and 1112 comprises a lower level logical_network.
  • Ip_subnet 1110 shows its lower level subnet exploded as link_network 1170.
  • link_network 1170 represents a logical_network layer of a typical ip_network which is using (for example) 802.3 protocols (Ethernet) for data exchange.
  • link_network 1170 comprises link_nodes 1116 and 1118 which contain link_ifs (interfaces) 1120 and 1122, respectively.
  • Each link_node 1116 and 1118 is connected, through link_ifs 1120 and 1122, respectively, to link_bridge 1128 via link_segments 1124 and 1126, respectively.
  • Each link_segment 1124 and 1126 comprises a lower level physical_network.
  • link_segment 1124 shows its lower level subnet exploded as 10baset_network 1180.
  • 10baset_network 1180 represents a physical_network layer of a typical link_network which is using twisted pair transmission devices to exchange data.
  • 10baset_network 1180 comprises 10baset_nodes 1130 and 1132 which contain 10baset_ifs (interfaces) 1134 and 1136, respectively.
  • Each 10baset_node 1130 and 1132 is connected, through 10baset_ifs 1134 and 1136, respectively, to 10baset_hub 1142 via 10baset_segments 1138 and 1140, respectively.
  • Each 10baset_segment 1138 and 1140 comprises a lower level media_network.
  • 10baset_segment 1138 shows its lower level subnet exploded as tp_network 1190.
  • Tp_network 1190 represents a media_network layer of a typical 10baset_network using RJ-45 twisted pair wiring medium to connect the physical entities of a network.
  • Tp_network 1190 comprises RJ-45_jacks 1144 and 1146. Each RJ-45_jack 1144 and 1146 is connected to tp_block 1152 via tp_cables 1148 and 1150, respectively.
  • the other ip_subnet 1112 would also contain a lower order logical_network, though not necessarily an 802.3 network.
  • the break down of lower order networks and their dependencies for this other ip_subnet 1112 would depend on the type of lower order networks it contains.
  • One of the two link_segments, namely 1124, depends on a 10baseT physical network. As above, only one of the link_segments is exploded, and the other link_segment, namely 1126, may or may not be a 10baseT physical network (it might be ThinLAN, or even ThickLAN). Finally, one of the 10baseT segments is shown to depend on a twisted-pair network, derived from media_network.
  • This example shows but one way the object models described above can model such a network topology.
  • the table below describes the resource aspect types and the associations formed between instances of those resource aspect types. These exemplary RATs and associations are usable to model various computing network topologies.
  • the present invention comprises the data constructs described above and related methods for manipulating the data constructs.
  • the methods of the present invention are invoked by application programs to manage topologies related to the application program.
  • An application program invokes the methods by calling an appropriate function within the API.
  • Resources 200 of FIG. 2 are managed indirectly through reference to the resource aspects 202 (RAs) which comprise the resource, to the resource aspect types 212 (RATs), and associations 204. Functions described below directly manipulate these data constructs. Indirect side effects of these manipulations alter the definition of resources (200) in a topology.
  • RAs resource aspects 202
  • RATs resource aspect types 212
  • associations 204 Functions described below directly manipulate these data constructs. Indirect side effects of these manipulations alter the definition of resources (200) in a topology.
  • Each function of the API of the present invention is described below in a common format which discloses the operation of each API function. Most functions discussed below operate according to the generalized flowcharts shown in FIG. 7.
  • the flowcharts of FIG. 7 depict the operations of "add”, “delete”, “update”, and “query” relating to an entity to be explicitly manipulated by the related API function.
  • entity stands for the data construct being explicitly manipulated by the API function.
  • Element 712 operates to prepare all necessary changes to the permanent storage of the API information base stored on disk 114 of FIG. 1. Processing continues with element 740 to commit all previously prepared modifications to the permanent storage of the information base on disk 114 of FIG. 1. The preparation and commitment of the modifications is separated into two elements to permit logging and reversal of changes to the permanently stored information base. All changes prepared for a particular addition, deletion, or update to the permanently stored information base are committed to storage as a single transaction so as to simplify the processing required to "undo" or reverse a particular update.
  • Element 724 operates as does element 712 discussed above to prepare the requested changes to the permanent information base on disk 115 of FIG. 1. Processing then continues with element 740 and 742, as discussed above, to commit the requested changes to the permanent storage, to notify any notification receivers, and to re-evaluate the resource integration of the affected topologies in the permanent storage on disk 114.
  • the flowcharts of FIG. 7 also depict the processing of a typical query request of the API topology management service.
  • the calling application program identifies a data construct for which information is requested, and identifies the type of information required.
  • the processing of the query function returns a failure status to the calling program if the identified data construct is not located or returns a successful status plus the requested information if the identified data construct is located.
  • Processing of a query function begins at element 728.
  • Element 730 and 732 combine to locate the data construct identified by the calling program. If the identified data construct is not located in the permanent information base stored on disk 114 of FIG. 1, then processing continues with element 738 to return a "not found" status to the calling program.
  • element 734 retrieves the requested information from the permanent information store on disk 114 and prepares the information as appropriate for return to the calling program.
  • Element 736 then operates to return a successful status indication to the calling program and returns the requested information as appropriate.
  • FIG. 7 The flowcharts of FIG. 7 are intended only as general guidelines to aid in the understanding of the processing of several of the API functions listed and discussed below. Each API function discussed below includes a detailed description of its processing as applied to the data constructs discussed above.
  • the flowchart of FIG. 8 represents the processing which re-evaluates resource integration following the provision of an object to be managed by the topology management service API.
  • Processing in FIG. 8 begins at element 800 when an object is provided to the API to be managed under the topological management service of the present invention.
  • Element 800 is operable to determine whether the newly managed object specifies resource names (RNs) which identify an already known resource. If not, then processing continue with element 802 to create a new resource uniquely identified by the resource names supplied in the newly managed object. The new resource is said to be represented by the newly managed object. Processing of the method is then complete and element 812 returns control to the caller of the resource integration function.
  • RNs resource names
  • processing of element 804 determines whether it identifies one resource or multiple resources. If only one resource is identified by the newly managed objects, processing continues with element 806 wherein any resource names specified by the newly managed objects which were not previously known in the identified resource are added to the resource. In this manner, resources are said to grow by the possible addition of resource names which further identify the resource. Processing of the method is then complete and element 812 returns control to the caller of the resource integration function.
  • Elements 808 and 810 operate to combine the identified resources into a new resource which is identified by the union of resource names of all objects representing the plurality of identified resources.
  • the new resource is represented by the union of all objects (resource aspects - RAs) which previously represented the plurality of identified resources.
  • the originally identified plurality of resources are then destroyed by operation of element 810 having been replaced by the new resource. Processing of the method is then complete and element 812 returns control to the caller of the resource integration function.
  • element 904 determines whether removal of the specified object changes the closure set of the identified resource. In other words, do the remaining objects which represent the resource still share at least one resource name (RN) with at least one other object which also represents the identified resource? If the resource name closure set is not changed, other than the removal of the specified object, then processing continues with element 910 to remove the resource names from the resource which are unique to the object specified to be removed. In this manner the resource is said to shrink by removal of resource names which previously were used to uniquely identify the resource. Processing then continues with element 912, comple processing of the method, and to return control to the calling function.
  • RN resource name
  • element 904 determines that the resource name closure set of the resource has changed, then processing continues with element 906 and 908 to split the identified resource into multiple new resources.
  • Each new resource is represented by a resource name closure set of resource aspects (RAs) which previously were in the resource name closure set of the identified resource.
  • Element 908 then continues processing by deleting the originally identified resource from the topology management service API permanent store on disk 114 of FIG. 1. The originally identified resource is no longer represented by any objects managed by the topology management service API. Processing then continues with element 912, to comple processing of the method, and to return control to the calling function.
  • RAs resource aspects
  • FIG. 7 Graphical examples of the operation of the resource integration methods of FIG. 8 and FIG. 9 are discussed above with respect to FIGS. 3-6.
  • similar resource integration methods are utilized in conjunction with other methods (such as those generally described by the flowcharts of FIG. 7).
  • the methods of FIG. 7 may, for example, change the set of resource names associate with a managed object, either adding or deleting resource names. Changes in the resource names stored in a managed object necessitate invocation of resource integration methods similar to those of FIGS. 8 and 9 without actually adding or removing an object from the topology management service API.
  • Such modifications to the methods of FIGS. 8 and 9 will be readily apparent to those of ordinary skill in the computing arts.
  • This section describes the functions for managing resource aspect types (RATs).
  • the functions include:
  • Resource aspect types are named and can be specializations of one or more existing resource aspect types.
  • the function rejects a request to delete a resource aspect type if:
  • the developer can define rules for a resource aspect type. These specify the number and type of associations that a resource aspect of a given type must participate in. As one or more resource aspects represent a resource, one or more resource aspect rules describe the associations that a resource can participate in. A resource aspect whose resource aspect type is a specialization of a more general type must be a valid example of both the specialized type and the more general type. Resource aspect rules specified for the specialized resource aspect type therefore cannot overwrite rules specified for the more general type, instead they must be applied in addition to the more general rules.
  • Each resource aspect rule includes a resource role.
  • T resource aspect type
  • say T' resource aspect type
  • both rules apply to instances of type T'.
  • Resource aspect rules express configurable invariants of a resource aspect type. They specify:
  • this example demonstrates the use of specialization in resource aspect type definitions. Also assume there is a resource aspect type X' that is a specialization of X with the following resource aspect rules:
  • a topology enforcer is an object that supports an interface that implements a validity checker.
  • the validity checker returns true or false when given a resource aspect of the specified type (including sub-type) to check.
  • the API enforcers allow the developer to specify constraints that can't be expressed using the resource aspect rules. For example, assume a developer has defined resource aspect types "computer”, “modem” and “provides dial-up services”. Assume that a resource of type "provides dial-up services" must have one association with a "computer” and one with a “modem”. These constraints are expressible using resource aspect rules.
  • the function rejects a request to define the API enforcers for a resource aspect type and generates an error if:
  • a resource aspect is valid according to an enforcer if the enforcer returns a true result when called by the API. If the enforcer returns an error, then the function returns that error, together with the resource aspect that would have become invalid, to the user that requested the topology change, and rejects the change. If no valid response from an enforcer is received by the function, then the function informs the user that requested the topology change, and rejects the change.
  • the function rejects a request to define topology change notification receivers for a resource aspect type and generates an error if:
  • a topology notification receiver is an object that supports an interface that receives a notification of a change in the API.
  • the function rejects a request to register topology change notification receivers for a resource aspect and generates an error if:
  • a topology notification receiver is an object that supports an interface that receives a notification of a change in the API.
  • the function rejects a request to de-register topology change notification receivers for a resource aspect and generates an error if:
  • the function indicates whether or not the resource aspect type name is known. If known, the function supplies the resource aspect type that corresponds to the resource aspect type name.
  • This query returns the details of a resource aspect type.
  • the function generates an error if the resource aspect type does not exist. If not rejected, the function supplies the following data about the resource aspect type:
  • This query returns true if resource aspect type (A) is an ancestor of resource aspect type (B). This query is used for determining if B 'is-a' A.
  • a request to determine if resource aspect type B inherits from resource aspect type A specifying:
  • the function returns True if resource aspect type B is a descendent of resource aspect type A in the resource aspect type inheritance hierarchy.
  • the function returns False if resource aspect type B is not a descendent of resource aspect type A.
  • a resource is the model that the API produces of the combined characteristics of a thing of interest
  • a resource aspect is the model of a set of those characteristics that relate to a particular "aspect" of the thing.
  • resource aspects model the thing from the viewpoint of one application program whereas a resource models the combination of all such viewpoints.
  • Each resource aspect is said to represent the resource that it models a view of.
  • a resource aspect is the fundamental unit in the topology management API that
  • the "manage a resource aspect” function is the means by which an object is related to a resource aspect type to thereby become a resource aspect available to the API.
  • the object provided to the API may contain other non-topological aspects which are not managed by the API other than to be stored with the object as it is managed within the API as a resource aspect.
  • the API topology management service maintains the additional state that is acquired by the resource aspect. This state is contained within the "topological component" of the resource aspect, links are maintained between the "topological components" and the "non-topological components.
  • Resource aspects may be named by resource names. Resource names are one method used by the API service to indicate when two or more resource aspects represent the same resource. As a result of adding and removing resource names from resource aspects, resources may cease to exist and new resources may be created. If direct references to resources were held by applications, these references would become "stale" as a result. For this reason resources are only referenced indirectly (outside of the API service itself) via the resource aspects that represent them. Therefore there can be no stale references to resources that no longer exist.
  • a request to manage a resource aspect by the API service is a request to manage a resource aspect by the API service.
  • the function rejects a request to manage a resource aspect and generates an error if any of the following are true:
  • the function updates the topological stored information base and returns the resource that the specified resource aspect represents.
  • the function determines the resource, that is represented by the resource aspect specified in the input request, by processing that is functionally equivalent to the following:
  • a request to unmanage a resource aspect by the API service If the resource is only represented by the single resource aspect being unmanaged then the resource will cease to exist. If the resource is represented by other resource aspect as well then either:
  • the function rejects a request to unmanage a resource aspect and generates an error if any of the following are true:
  • FIG. 5 illustrates the change that would result by adding a new resource name to resource aspect RA8 518.
  • the new name is shared by RA4 512.
  • RESOURCE1 and RESOURCE2 merge to form RESOURCE3, RESOURCE1 and RESOURCE2 cease to exist.
  • FIG. 6 illustrates the change that would result by removing a resource name from resource aspect RA8 612.
  • the name was only shared by RA4 610.
  • RESOURCE1 splits to form RESOURCE2 and RESOURCE3, RESOURCE1 ceases to exist.
  • the function rejects a request to remove a resource name from a resource aspect and generates an error if any of the following are true:
  • This API is used to change the resource aspect type of an existing resource aspect.
  • the function rejects a request to combine two resource aspects and generates an error if any of the following are true:
  • This operation is functionally equivalent to removing from each resource aspect the API generated resource name used to ensure that the two resource aspects represented the same resource.
  • the resource that the two resource aspects represented will split into two resources, unless the resource aspects are also part of the same resource name closure group.
  • the function rejects a request to unconstrain two resource aspects from having to represent the same resource and generates an error if any of the following are true:
  • the queries specified in this section apply to data about a resource (i.e. the aggregated view as defined through resource aspects).
  • the resource that is being queried is identified by specifying any one of the resource aspects that represent it.
  • the query result may be filtered so that it only contains information pertaining to a limited set of the resource aspects that represent the resource.
  • the filter is specified by:
  • the function rejects this request if any of the following occur:
  • the queries specified in this section apply to a particular resource aspect. Other resource aspects representing the resource are not involved.
  • the output from the query will be the resource names and the resource aspect type of the resource aspect
  • the function rejects this request if any of the following occur:
  • the queries specified in this section apply to all resource aspects.
  • the output from the query will be the resources which are identified by the resource names.
  • the function outputs the resources that have any name in the input resource name list.
  • a request to query a resource aspect for explicitly combined resource aspects specifying:
  • the function rejects the request if
  • Associations are established between resources. Specifically they are established between particular resource aspects.
  • the function rejects a request to establish an association and generates an error if any of the following are true:
  • the function allows an association to be removed if no other resource will be affected.
  • the function rejects a request to delete an association and generates an error if any of the following are true:
  • This section specifies the queries provided for examining individual associations. It does not include general queries about the associations between resources nor resource attribute based queries. These types of queries are described in "General topology query” below.
  • the function generates an error if the resource aspect does not exist. If not rejected, the function supplies for the resource aspect the following data for each association that this resource aspect participates in:
  • the support for general topology queries consists of a Topology Query (TQ) API defined below.
  • TQ Topology Query
  • the TQ API provides a programming interface for the expression of general topology queries.
  • a topology query language may be implemented utilizing the topology query API to simplify ad-hoc inquiry of the topology management service API.
  • the topological stored information base can be viewed as a graph of associated resources.
  • a topology graph is a set of nodes and a set of edges connecting the nodes. Nodes are resources, and edges simply indicate the existence of an association between the two resources.
  • a meta-resource is a template for matching resources in topology.
  • a meta-resource can be:
  • a meta-resource can optionally also express a propositional expression on resource attribute values.
  • the propositional expression can be formed from one or more value assertions linked using the logical connectives AND, OR and NOT.
  • meta-resources logical connectives and their associations form a tree.
  • branches can only occur at the AND and OR logical connectives. Therefore meta-resource nodes have at most two associations with other meta-resource nodes:
  • An association in the query tree means that an association in the topological stored information base must be traversed.
  • a meta-resource can optionally specify a resource role for the associations it is involved in. If specified these resource roles limit the resources that match the meta-resource to those that take the specified role in the corresponding association.
  • the specification for a resource role may include an index.
  • a meta-resource can also specify a filter.
  • a filter is a user defined method which is applied to all resources that match the meta-resource.
  • a filter is a boolean expression that returns true or false. If a filter is specified the filter must return true for the resource to be considered as a match.
  • Resource aspect types are organized into inheritance type hierarchies. A resource aspect is matched against a resource aspect type if:
  • Simple navigation paths can be combined, using logical connectives, to pose more advanced queries on the topology graph structure.
  • the logical AND, OR and NOT connectives are used to produce compound propositional expressions on topology. Evaluation of the connectives is in accordance with the rules of logic. These are:
  • topology queries using the logical connectives depicted graphically in FIG. 16 may be described as follows:
  • Queries Ex1 and Ex2 contains two complex navigation paths rooted at E1, whereas query Ex3 contains a single navigation path rooted at E1.
  • Query Ex4 shows an example of nested logical connectives, with a total of three complex navigation paths that are rooted at E1.
  • the logical connective can be used to express compound queries on topology.
  • a compound query combines the result of two or more queries to produce a single result.
  • the logical AND and OR connectives are used to express compound queries. Examples of compound queries are depicted in FIG. 17 and may be described as follows:
  • a simple navigation path or a part of a simple navigation path can be repeated a number of times as part of the query.
  • a repetition statement is bounded by a lower limit.
  • An optional upper limit may also be specified. These limits indicate the minimum and maximum number of times the repetition can occur in a topology path.
  • An example of specifying repetition in a query is depicted graphically in FIG. 18 and may be described as follows:
  • the query user will want to express a constraint that any resource is to only match one meta-resource in the query. This will be taken as the default. This default can be overridden so that the user can alternatively specify the following resource matching constraints. These constraints are specified for any pair of meta-resources:
  • the result construction rules specify the number of sub-graphs to be returned from a query.
  • a query can only return sub-graphs if the boolean result of the query was true.
  • the show indicator rules are used to modify the sub-graph(s) returned by the query. Show indicator rules can be applied to each meta-resource specified in the query.
  • a show indicator rule can specify the following for a meta-resource:
  • the topology query service allows user tags to be specified on the meta-resources of the query.
  • User tags are semantically irrelevant to the query evaluation process.
  • the tags provide a means of identifying topology resources that matched a meta-resource in the query.
  • Each sub-graph returned in the result of a query will copy all user tags from the meta-resources to their corresponding matched topology resource. If the result construction rule of the query specifies the 'graph' option, and a topology resource in the query result represents more than one meta-resource, the resource will copy all user tags from each meta-resource it matched.
  • a request to query the topology graph structure specifying:
  • the API considers the propositional expression of the query to be valid if:
  • the API considers as a topology sub-graph:
  • the API returns the resources and their associations that matched the query in the form of topology sub-graphs.
  • the API outputs sub-graphs according to the following result construction rules:

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Claims (21)

  1. Ein computerbasiertes Verfahren zum Verwalten topologischer Zuordnungen (204) unter Objekten (202), das folgende Schritte aufweist:
    a) Speichern einer Anzahl von Objekten (202) in einer Informationsbasis (110, 114), wobei jedes der Anzahl von Objekten (202) eine Anzahl von Ressourcennamen (206) besitzt; und
    b) Bestimmen eines oder mehrerer Ressourcenname-Abschlußsätze, die die Anzahl von Objekten (202), die in der Informationsbasis (110, 114) gespeichert sind, einschließen, wobei jeder des einen oder der mehreren Ressourcenname-Abschlußsätze einen größten Teilsatz der Anzahl von Objekten (202), die in der Informationsbasis (110, 114) gespeichert sind, aufweist, derart, daß jedes Objekt (202) des größten Teilsatzes einen Ressourcennamen (206) mit mindestens einem weiteren Objekt des größten Teilsatzes gemeinsam verwendet, wobei die Objekte (202) jedes Ressourcenname-Abschlußsatzes eine Ressource (200) definieren und die Ressourcennamen (206) der Objekte (202) die Ressource (200) eindeutig identifizieren.
  2. Ein computerbasiertes Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist:
    a) Empfangen einer Anforderung, ein neues Objekt zu verwalten, wobei das neue Objekt eine Anzahl von Ressourcennamen besitzt; und
    b) Bestimmen (800), ob das neue Objekt einen oder mehrere Ressourcennamen besitzt, die eine oder mehrere bekannte Ressourcen eindeutig identifizieren; und
    i) falls nicht, Definieren (802) einer neuen Ressource durch einen Ressourcenname-Abschlußsatz, der das neue Objekt aufweist, wobei die neue Ressource durch die Anzahl von Ressourcennamen, die das neue Objekt besitzt, eindeutig identifiziert wird;
    ii) falls dem so ist und nur eine bekannte Ressource identifiziert wird, Hinzufügen (806) des neuen Objekts zu dem Ressourcenname-Abschlußsatz der einen bekannten Ressource, wobei die bekannte Ressource nun durch die Anzahl von Ressourcennamen, die das neue Objekt und jedes der Objekte in dem Ressourcenname-Abschlußsatz der identifizierten bekannten Ressource besitzen, eindeutig identifiziert wird; und
    iii) falls dem so ist und mehr als eine bekannte Ressource identifiziert wird,
    A) Definieren (808) einer neuen Ressource durch einen Ressourcenname-Abschlußsatz, der das neue Objekt und jedes der Objekte in den Ressourcenname-Abschlußsätzen der identifizierten bekannten Ressourcen aufweist, wobei die neue Ressource durch die Anzahl von Ressourcennamen, die das neue Objekt und jedes der Objekte in den Ressourcenname-Abschlußsätzen der identifizierten bekannten Ressourcen besitzen, eindeutig identifiziert wird; und
    B) Löschen (810) der Ressourcenname-Abschlußsätze der identifizierten bekannten Ressourcen.
  3. Ein computerbasiertes Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist:
    a) Empfangen einer Anforderung, eines der Anzahl von Objekten, die in der Informationsbasis gespeichert sind, nicht mehr zu verwalten; und
    b) Bestimmen (900), ob der existierende Ressourcenname-Abschlußsatz, zu dem das nicht mehr zu verwaltende Objekt gehört, zusätzliche Objekte aufweist; und
    i) falls nicht, Bewilligen der Anforderung zum Nicht-Mehr-Verwalten, und Löschen (902) des existierenden Ressourcenname-Abschlußsatzes;
    ii) falls dem so ist und jedes der zusätzlichen Objekte einen Ressourcennamen mit mindestens einem weiteren der zusätzlichen Objekte gemeinsam verwendet, Bewilligen (910) der Anforderung zum Nicht-Mehr-Verwalten; und
    iii) falls dem so ist und eines oder mehrere der zusätzlichen Objekte einen Ressourcennamen nicht mit mindestens einem weiteren der zusätzlichen Objekte gemeinsam verwendet,
    A) Bewilligen der Anforderung zum Nicht-Mehr-Verwalten;
    B) Bestimmen (906) einer Mehrzahl von neuen Ressourcenname-Abschlußsätzen, die die zusätzlichen Objekte einschließen; und
    C) Löschen (908) des existierenden Ressourcenname-Abschlußsatzes.
  4. Ein computerbasiertes Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist:
    a) Empfangen (700) einer Anforderung, einen Ressourcennamen zu einem gegebenen der Anzahl von Objekten (202), die in der Informationsbasis (110, 114) gespeichert sind, hinzuzufügen;
    b) Hinzufügen des Ressourcennamens (200) zu dem gegebenen Objekt (202); und
    c) Bestimmen, ob der hinzugefügte Ressourcenname zusätzlich zu einer ersten Ressource, die durch den Ressourcenname-Abschlußsatz, zu dem das gegebene Objekt gehört, definiert ist, eine oder mehr Ressourcen identifiziert, und falls dem so ist,
    i) Definieren einer neuen Ressource durch einen Ressourcenname-Abschlußsatz, der jedes der Objekte in den Ressourcenname-Abschlußsätzen jedes des ersten und des einen bzw. der mehreren zusätzlichen Ressourcenname-Abschlußsätze aufweist; und
    ii) Löschen der Ressourcenname-Abschlußsätze jedes des ersten und des einen bzw. der mehreren zusätzlichen Ressourcenname-Abschlußsätze.
  5. Ein computerbasiertes Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist:
    a) Empfangen (714) einer Anforderung, einen Ressourcennamen von einem gegebenen der Anzahl von Objekten, die in der Informationsbasis gespeichert sind, zu entfernen;
    b) Entfernen des Ressourcennamens von dem gegebenen Objekt;
    c) Bestimmen eines oder mehrerer neuer Ressourcenname-Abschlußsätze, die die Anzahl von Objekten in dem existierenden Ressourcenname-Abschlußsatz, zu dem das gegebene Objekt gehört, einschließen; und
    d) Löschen des existierenden Ressourcenname-Abschlußsatzes.
  6. Ein computerbasiertes Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist:
    a) Empfangen einer Anforderung, mindestens zwei Ressourcen ausdrücklich zu kombinieren;
    b) Erzeugen eines eindeutigen Ressourcennamens;
    c) Hinzufügen des eindeutigen Ressourcennamens zu einem Objekt in den Ressourcenname-Abschlußsätzen jeder der mindestens zwei Ressourcen;
    d) Definieren einer neuen Ressource durch einen Ressourcenname-Abschlußsatz, der jedes der Objekte in den Ressourcenname-Abschlußsätzen der mindestens zwei Ressourcen aufweist, wobei die neue Ressource durch die Anzahl von Ressourcennamen, die jedes der Objekte in den Ressourcenname-Abschlußsätzen der mindestens zwei Ressourcen besitzt, eindeutig identifiziert wird; und
    e) Löschen der Ressourcenname-Abschlußsätze der mindestens zwei Ressourcen.
  7. Ein computerbasiertes Verfahren gemäß Anspruch 1, das ferner den Schritt eines Speicherns einer Anzahl von Ressourcenaspekttypen (212) in einem Ressourcenaspekttypspeicher aufweist, bei dem:
    a) ein Ressourcenaspekttyp (212) eine Anzahl von Regeln aufweist, die erlaubte Zuordnungen für Objektinstanzen des Ressourcenaspekttyps definieren; und
    b) jedes der Anzahl von Objekten (202), die in der Informationsbasis gespeichert sind, eine Instanz eines der Ressourcenaspekttypen ist.
  8. Ein computerbasiertes Verfahren gemäß Anspruch 7, bei dem die Anzahl von Ressourcenaspekttypen (212) ihrem Wesen nach hierarchisch sind und ein gegebener Ressourcenaspekttyp, der eine Spezialisierung mindestens eines weiteren Ressourcenaspekttyps ist:, zusätzlich zu der Anzahl von Regeln des gegebenen Ressourcenaspekttyps die Anzahl von Regeln des mindestens einen weiteren Ressourcenaspekttyps erbt.
  9. Ein computerbasiertes Verfahren gemäß Anspruch 7, bei dem die Anzahl von Regeln für einen gegebenen Ressourcenaspekttyp eine Anzahl von konfigurierbaren Regeln aufweist, wobei jede konfigurierbare Regel folgende Merkmale aufweist:
    a) eine Rolle;
    b) eine minimale und eine maximale Anzahl von Zuordnungen, an denen eine Objektinstanz des gegebenen Ressourcenaspekttyps beteiligt sein muß; und
    c) einen Ressourcenaspekttyp, der einen Objekttyp angibt, mit dem eine Zuordnung gemäß der konfigurierbaren Regel durchgeführt werden muß.
  10. Ein computerbasiertes Verfahren gemäß Anspruch 7, das ferner folgende Schritte aufweist:
    a) Konfigurieren einer Anzahl von Durchsetzungseinrichtungsobjekten (216), von denen sich jedes auf einen Ressourcenaspekttyp (212) bezieht; und
    b) wenn eine Anforderung, die Informationsbasis zu ändern, empfangen wird und die Anforderung eine Auslösebedingung eines beliebigen Durchsetzungseinrichtungsobjekts erfüllt, Sicherstellen, daß die Änderung der Informationsbasis den Einschränkungen der erfüllten Auslösebedingungen entspricht.
  11. Ein computerbasiertes Verfahren gemäß Anspruch 8, das ferner folgende Schritte aufweist:
    a) Konfigurieren einer Anzahl von Durchsetzungseinrichtungsobjekten (216), von denen jedes mindestens eine Auslösebedingung, die mindestens einer Einschränkung zugeordnet ist, aufweist, und von denen sich jedes auf einen Ressourcenaspekttyp (212) bezieht; und
    b) wenn eine Anforderung, die Informationsbasis zu ändern, empfangen wird und die Anforderung eine Auslösebedingung eines beliebigen Durchsetzungseinrichtungsobjekts erfüllt, Sicherstellen, daß die Änderung der Informationsbasis den Einschränkungen der erfüllten Auslösebedingungen entspricht;
    wobei die Auslösebedingungen eines Durchsetzungseinrichtungsobjekts, das sich auf einen gegebenen Ressourcenaspekttyp bezieht, durch Ressourcenaspekttypen geerbt werden, die Spezialisierungen des gegebenen Ressourcenaspekttyps sind.
  12. Ein computerbasiertes Verfahren gemäß Anspruch 7, das ferner folgende Schritte aufweist:
    a) Konfigurieren einer Anzahl von Benachrichtigungsempfängerobjekten (226), von denen jedes mindestens eine Auslösebedingung aufweist und von denen sich jedes auf einen Ressourcenaspekttyp (212) bezieht; und
    b) wenn eine Anforderung, die Informationsbasis zu ändern, empfangen wird und die Anforderung eine Auslösebedingung eines beliebigen Benachrichtigungsempfängerobjekts erfüllt, Protokollieren der Änderung der Informationsbasis bei dem Benachrichtigungsempfängerobjekt, das die erfüllte Auslösebedingung aufweist.
  13. Ein computerbasiertes Verfahren gemäß Anspruch 8, das ferner folgende Schritte aufweist:
    a) Konfigurieren einer Anzahl von Benachrichtigungsempfängerobjekten (226), von denen jedes mindestens eine Auslösebedingung aufweist und von denen sich jedes auf einen Ressourcenaspekttyp (212) bezieht; und
    b) wenn eine Anforderung, die Informationsbasis zu ändern, empfangen wird und die Anforderung eine Auslösebedingung eines beliebigen Benachrichtigungsempfängerobjekts erfüllt, Protokollieren der Änderung der Informationsbasis bei dem Benachrichtigungsempfängerobjekt, das die erfüllte Auslösebedingung aufweist;
    wobei die Auslösebedingungen eines Benachrichtigungsempfängerobjekts, das sich auf einen gegebenen Ressourcenaspekttyp bezieht, durch Ressourcenaspekttypen geerbt werden, die Spezialisierungen des gegebenen Ressourcenaspekttyps sind.
  14. Ein computerbasiertes Verfahren gemäß Anspruch 7, das ferner folgende Schritte aufweist:
    a) Konfigurieren einer Anzahl von Benachrichtigungsempfängerobjekten (226), von denen jedes mindestens eine Auslösebedingung aufweist und von denen sich jedes auf ein Objekt (202) bezieht, das in der Informationsbasis gespeichert ist; und
    b) wenn eine Anforderung, die Informationsbasis zu ändern, empfangen wird und die Anforderung eine Auslösebedingung eines beliebigen Benachrichtigungsempfängerobjekts erfüllt, Protokollieren der Änderung der Informationsbasis bei dem Benachrichtigungsempfängerobjekt, das die erfüllte Auslösebedingung aufweist.
  15. Ein computerbasiertes Verfahren gemäß Anspruch 8, das ferner folgende Schritte aufweist:
    a) Konfigurieren einer Anzahl von Benachrichtigungsempfängerobjekten (226), von denen jedes mindestens eine Auslösebedingung aufweist und von denen sich jedes auf ein Objekt (202) bezieht, das in der Informationsbasis gespeichert ist; und
    b) wenn eine Anforderung, die Informationsbasis zu ändern, empfangen wird und die Anforderung eine Auslösebedingung eines beliebigen Benachrichtigungsempfängerobjekts erfüllt, Protokollieren der Änderung der Informationsbasis bei dem Benachrichtigungsempfängerobjekt, das die erfüllte Auslösebedingung aufweist;
    wobei die Auslösebedingungen eines Benachrichtigungsempfängerobjekts, das sich auf einen gegebenen Ressourcenaspekttyp bezieht, durch Ressourcenaspekttypen geerbt werden, die Spezialisierungen des gegebenen Ressourcenaspekttyps sind.
  16. Ein computerbasiertes Verfahren gemäß Anspruch 7, bei dem:
    a) die Anzahl von Regeln für einen gegebenen Ressourcenaspekttyp Regeln aufweist, die folgende Merkmale aufweisen:
    i) eine Rolle;
    ii) eine minimale und eine maximale Anzahl von Zuordnungen, an denen eine Objektinstanz des gegebenen Ressourcenaspekttyps beteiligt sein muß; und
    iii) einen Ressourcenaspekttyp, der einen Objekttyp, mit dem eine Zuordnung gemäß der konfigurierbaren Regel durchgeführt werden muß, angibt; und
    b) die Ressourcenaspekttypen und Regeln jene in der folgenden Tabelle aufweisen: Ressourcenaspekttyp Regeln Rolle Min Max zugeordneter Ressourcenaspekttyp logisches_Netz Netz 0 1 logisches_Netz_Einschluß Netz 0 1 logisches_Segment_Einschluß logisches_Netz_Einschluß Behältnis 0 1 logisches_Netz Behältnis 0 N logisches_Segment logisches_Segment_Einschluß Behältnis 0 1 logisches_Segment Behältnis 0 N logisches_Netz logischer_Knoten logische_Vorrichtung 0 1 logischer_Knoten_Einschluß logischer_Knoten_Einschluß Behältnis 0 1 logischer_Knoten Behältnis 0 N logisches_falls logisches_falls Schnittstelle 0 1 logischer_Knoten_Einschluß Schnittstelle 0 1 logische_Schnittstelle_Verbindung logische_Schnittstelle_-Verbindung Verbinder 0 1 logisches_falls Verbinder 0 1 logisches_Segment logisches_Segment Segment 0 N logische_Schnittstelle_Verbindung Segment 0 1 logische_Grenze Segment 0 1 logisches_Netz_Einschluß Segment 0 1 logisches_Segment_Einschluß logische_Grenze Schranken 0 N logisches_Segment Schranken 0 N logischer_Anschluß (geerbt) logischer_Verbinder Verbindungsvorrichtung 0 1 logische_Grenze
  17. Ein computerbasiertes Verfahren gemäß Anspruch 16, bei dem der Ressourcenaspekttyp logisches_Segment ferner die Regel in der folgenden Tabelle aufweist: Ressourcenaspekttyp Regeln Rolle Min Max Zugeordneter Ressourcenaspekttyp logisches_Segment Segment 0 1 physisches_Netz
  18. Ein computerbasiertes Verfahren gemäß Anspruch 17, bei dem die Ressourcenaspekttypen und Regeln ferner jene in der folgenden Tabelle aufweisen: Ressourcenaspekttyp Regeln Rolle Min Max Zugeordneter Ressourcenaspekttyp physisches_Netz phy_Netz 0 1 logisches_Segment phy_Netz 0 1 physisches_Segment_Einschluß physisches_Segment_- Behältnis 0 1 physisches_Netz Einschluß Behältnis 0 N physisches_Segment physischer_Knoten Chassis 0 1 physischer_Knoten_Einschluß physischer_Knoten_- Behältnis 0 N physisches_falls Einschluß Behältnis 0 1 physischer_Knoten physisches_falls Schnittstelle 0 1 physischer_Knoten_Einschluß Schnittstelle 0 1 physische_Schnittstelle_Verbindung physische_Schnitt- Verbinder 0 1 physisches_falls stelle_-Verbindung Verbinder 0 1 physisches_Segment physisches_Segment Segment 0 N physische_Schnittstelle_Verbindung Segment 0 1 physische_Grenze Segment 0 1 physisches_Segment_Einschluß physische_Grenze Schranken 0 N physisches_Segment Schranken 0 N physischer_Verbinder (ererbt) physischer_Verbinder Schranken 0 1 physische_Grenze
  19. Ein computerbasiertes Verfahren gemäß Anspruch 18, bei dem der Ressourcenaspekttyp logisches_Segment ferner die Regel in der folgenden Tabelle aufweist: Ressourcenaspekttyp Regeln Rolle Min Max Zugeordneter Ressourcenaspekttyp physisches_Segment Segment 0 1 Medien_Einschluß
  20. Ein computerbasiertes Verfahren gemäß Anspruch 19, bei dem die Ressourcenaspekttypen und Regeln ferner jene in der folgenden Tabelle aufweisen: Ressourcenaspekttyp Regeln Rolle Min Max Zugeordneter Ressourcenaspekttyp Medien_Einschluß Zusatz 0 1 physisches_Segment Behältnis 0 1 Medien_Netz Medien_Netz Medien_Netz 0 1 Medien_Einschluß Medien_-Behältnis 0 N Medien_Kabel Medien_Abschlußeinheit Abschluß 0 1 Medien_Kabel Medien_Kabel Physischer_Draht 0 1 Medien_Abschlußeinheit Physischer_Draht 0 1 Medien_Anschlußstück Physischer_Draht 0 2 Medien_Verbinder Physischer_Draht 0 1 Medien_Netz Medien_Anschlußstück Kabel-Verbindung 0 1 Medien_Kabel Medien_Verbinder Verbinder 0 1 Medien_Kabel
  21. Ein System zum Verwalten topologischer Zuordnungen (204) unter einer Anzahl von Objekten (202), die in einer Informationsbasis (110, 114) gespeichert sind, wobei jedes der Anzahl von Objekten eine Anzahl von Ressourcennamen (206) besitzt, das folgende Merkmale aufweist:
    a) einen Ressourcenaspekttypspeicher, der Ressourcenaspekttypen aufweist, wobei jeder Ressourcenaspekttyp eine Anzahl von Regeln aufweist, die erlaubte Zuordnungen für Objektinstanzen des Ressourcenaspekttyps definieren, wobei jedes der Anzahl von Objekten (202), die in der Informationsbasis (110, 114) gespeichert sind, eine Instanz eines der Ressourcenaspekttypen ist; und
    b) einen Computercode zum Bestimmen eines oder mehrerer Ressourcenname-Abschlußsätze, die die Anzahl von Objekten (202), die in der Informationsbasis (110, 114) gespeichert sind, einschließen, wobei jeder des einen oder der mehreren Ressourcenname-Abschlußsätze einen größten Teilsatz der Anzahl von Objekten (202), die in der Informationsbasis (110, 114) gespeichert sind, aufweist, derart, daß jedes Objekt des größten Teilsatzes einen Ressourcennamen mit mindestens einem weiteren Objekt des größten Teilsatzes gemeinsam verwendet, wobei die Objekte jedes Ressourcenname-Abschlußsatzes eine Ressource (200) definieren und die Ressourcennamen (206) der Objekte (202) die Ressource (200) eindeutig identifizieren.
EP19960109347 1995-06-22 1996-06-11 Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten Expired - Lifetime EP0750254B1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE1996621077 DE69621077T2 (de) 1996-06-11 1996-06-11 Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten
JP9150779A JPH10116219A (ja) 1996-06-11 1997-06-09 オブジェクト間のトポロジー的結合の管理方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US493767 1983-05-12
US49376795A 1995-06-22 1995-06-22

Publications (2)

Publication Number Publication Date
EP0750254A1 EP0750254A1 (de) 1996-12-27
EP0750254B1 true EP0750254B1 (de) 2002-05-08

Family

ID=23961626

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19960109347 Expired - Lifetime EP0750254B1 (de) 1995-06-22 1996-06-11 Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten

Country Status (1)

Country Link
EP (1) EP0750254B1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9396214B2 (en) 2006-01-23 2016-07-19 Microsoft Technology Licensing, Llc User interface for viewing clusters of images

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7836050B2 (en) 2006-01-25 2010-11-16 Microsoft Corporation Ranking content based on relevance and quality
US7870564B2 (en) 2006-02-16 2011-01-11 Microsoft Corporation Object-based computer system management

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU607795B2 (en) * 1987-08-21 1991-03-14 Eastman Kodak Company Data integration by object management

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9396214B2 (en) 2006-01-23 2016-07-19 Microsoft Technology Licensing, Llc User interface for viewing clusters of images

Also Published As

Publication number Publication date
EP0750254A1 (de) 1996-12-27

Similar Documents

Publication Publication Date Title
US5878431A (en) Method and apparatus for providing topology based enterprise management services
US5787437A (en) Method and apparatus for shared management information via a common repository
US7822785B2 (en) Methods and apparatus for composite configuration item management in configuration management database
US20070208764A1 (en) Universal information platform
US20030177139A1 (en) Dynamically generated schema representing multiple hierarchies of inter-object relationships
US20080091491A1 (en) Method and/or system for flexible data handling
JP2002543743A (ja) 電気通信ネットワーク・リソース取り扱い装置および方法
CA2510835A1 (en) Schema server object model
KR100529661B1 (ko) 오브젝트 통합 관리 시스템
US6484160B1 (en) Process for optimizing accesses to a database
CA2673422A1 (en) Software for facet classification and information management
Silvescu et al. Graph databases
MXPA05006260A (es) Sistemas y metodos para extensiones y herencia para unidades de informacion manejables a traves de un sistema de interfaz de sistemas de componentes fisicos de computacion y programas y sistemas de programacion.
US7702647B2 (en) Method and structure for unstructured domain-independent object-oriented information middleware
EP0750254B1 (de) Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten
US20040098294A1 (en) Adaptable resource model
EP0750253B1 (de) Verfahren und Gerät zum Teilen von Verwaltungsinformationen über einen gemeinsamen Speicher
Egyhazy et al. Interoperability architecture using RM-ODP
Jodłowiec Complex relationships modeling in association-oriented database metamodel
WO2000042529A1 (en) A system for composing applications based on explicit semantic models, event driven autonomous agents, and resource proxies
DE69621077T2 (de) Verfahren und Gerät, um auf Topologie basierte Verwaltungsdienste für Firmen anzubieten
Heberling et al. Visual Modelling and Managing the Software Architecture Landscape in a large Enterprise by an Extension of the UML
Kudelas Adapting Service Interfaces when Business Processes Evolve
Mansour et al. Industrial systems communications: design and integration
Jarke The design of a database for multiperson decision support

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB SE

17P Request for examination filed

Effective date: 19970627

17Q First examination report despatched

Effective date: 20000228

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: HEWLETT-PACKARD COMPANY, A DELAWARE CORPORATION

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

REG Reference to a national code

Ref country code: GB

Ref legal event code: IF02

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB SE

REF Corresponds to:

Ref document number: 69621077

Country of ref document: DE

Date of ref document: 20020613

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20030211

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: SE

Payment date: 20070627

Year of fee payment: 12

EUG Se: european patent has lapsed
PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20080612

REG Reference to a national code

Ref country code: GB

Ref legal event code: 732E

Free format text: REGISTERED BETWEEN 20120329 AND 20120404

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20150521

Year of fee payment: 20

Ref country code: GB

Payment date: 20150527

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20150526

Year of fee payment: 20

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 69621077

Country of ref document: DE

Representative=s name: SCHOPPE, ZIMMERMANN, STOECKELER, ZINKLER, SCHE, DE

Ref country code: DE

Ref legal event code: R081

Ref document number: 69621077

Country of ref document: DE

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOU, US

Free format text: FORMER OWNER: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., HOUSTON, TEX., US

REG Reference to a national code

Ref country code: DE

Ref legal event code: R071

Ref document number: 69621077

Country of ref document: DE

REG Reference to a national code

Ref country code: GB

Ref legal event code: PE20

Expiry date: 20160610

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20160610

REG Reference to a national code

Ref country code: GB

Ref legal event code: 732E

Free format text: REGISTERED BETWEEN 20160825 AND 20160831

REG Reference to a national code

Ref country code: FR

Ref legal event code: TP

Owner name: HEWLETT PACKARD ENTREPRISE DEVELOPMENT LP, US

Effective date: 20160819