Method and apparatus for sharing objects and object state between processes

Abstract

A method and apparatus for integrating management agents and EM frameworks is provided. For a representative embodiment, the present invention includes an open enterprise management gateway or OEM gateway. The OEM gateway is a software process that functions as an intermediary between one or more management agents and one or more EM frameworks. The OEM gateway includes a set of APIs that allow management agents to export object hierarchies to EM frameworks. The EM frameworks create interactive displays using the exported object hierarchies. The interactive displays allow users to invoke command interfaces for the displayed objects. When command interfaces are invoked, the EM frameworks invoke a callback request API within the OEM server. The OEM server then directs callback processing to an API exported by the appropriate management agent.

Claims

What is claimed is:

1. A gateway for integrating management agents and EM frameworks, the apparatus comprising:

a first interface for receiving objects exported by one or more management agents, each object corresponding to an entity managed by the exporting management agent;

an first subsystem configured to select objects within the objects received by the first interface;

a second interface for forwarding the selected objects to one or more EM frameworks;

a third interface for receiving callback requests from the EM frameworks, each callback request associated with an exported object;

a second subsystem for selecting a destination management agent for each callback request; and

a fourth interface for forwarding each callback request to the destination management agent selected for the callback request.

2. A gateway as recited in claim 1 wherein each exported object has an associated state, and wherein the first subsystem is configured to select, where more than one management agent exports the same object, the object having the state with the highest priority.

3. A gateway as recited in claim 1 wherein the second subsystem is configured to determine if a callback request is specifically associated with a particular object and to select the management agent that exported the particular object as the destination management agent for that callback request.

4. A gateway as recited in claim 1 wherein the second subsystem is configured to determine if a callback request is generically associated with an object class and to select the management agent that exported the object class as the destination management agent for that callback request.

5. A gateway as recited in claim 1 wherein the first interface is configured to receive command interfaces exported by one or more management agents, each command interface corresponding to one or more exported objects and wherein the fourth interface is configured to forward the exported command interfaces to the EM frameworks.

6. A gateway as recited in claim 5 wherein the exported command interfaces are popup menus.

7. A method for integrating management agents and EM frameworks, the method comprising the steps, performed by a computer system, of:

receiving objects exported by one or more management agents, each object corresponding to an entity managed by the exporting management agent;

selecting objects within the objects received by the first interface;

forwarding the selected objects to one or more EM frameworks;

receiving callback requests from the EM frameworks, each callback request associated with an exported object;

selecting a destination management agent for each callback request; and

forwarding each callback request to the destination management agent selected for the callback request.

8. A method as recited in claim 7 wherein each exported object has an associated state, and wherein the step of selecting objects within the objects received by the first interface is configured to select, where more than one management agent exports the same object, the object having the state with the highest priority.

9. A method as recited in claim 7 further comprising the steps of:

determining if a callback request is specifically associated with a particular object; and

selecting the management agent that exported the particular object as the destination management agent for that callback request.

10. A method as recited in claim 7 further comprising the steps of:

determining if a callback request is generically associated with an object class; and

selecting the management agent that exported the object class as the destination management agent for that callback request.

11. A method as recited in claim 7 further comprising the steps of:

receiving command interfaces exported by one or more management agents, each command interface corresponding to one or more exported objects; and

forwarding the exported command interfaces to the EM frameworks.

12. A method as recited in claim 11 wherein the exported command interfaces are popup menus.

13. A computer program product comprising:

a computer usable medium having computer readable code embodied therein for providing a gateway for integrating management agents and EM frameworks, the computer program product comprising:

first computer readable program code devices configured to cause a computer system to receive objects exported by one or more management agents, each object corresponding to an entity managed by the exporting management agent;

second computer readable program code devices configured to cause a computer system to select objects within the objects received by the first interface;

third computer readable program code devices configured to cause a computer system to forward the selected objects to one or more EM frameworks;

fourth computer readable program code devices configured to cause a computer system to receive callback requests from the EM frameworks, each callback request associated with an exported object;

fifth computer readable program code devices configured to cause a computer system to select a destination management agent for each callback request; and

sixth computer readable program code devices configured to cause a computer system to forward each callback request to the destination management agent selected for the callback request.

14. A computer program product as recited in claim 13 wherein each exported object has an associated state, and wherein the first computer readable program code devices are configured to select, where more than one management agent exports the same object, the object having the state with the highest priority.

15. A computer program product as recited in claim 13 wherein the fifth computer readable program code devices are configured to determine if a callback request is specifically associated with a particular object and to select the management agent that exported the particular object as the destination management agent for that callback request.

16. A computer program product as recited in claim 13 wherein the second computer readable program code devices are configured to determine if a callback request is generically associated with an object class and to select the management agent that exported the object class as the destination management agent for that callback request.

17. A computer program product as recited in claim 13 wherein the first computer readable program code devices are configured to receive command interfaces exported by one or more management agents, each command interface corresponding to one or more exported objects and wherein the fourth interface is configured to forward the exported command interfaces to the EM frameworks.

18. A computer program product as recited in claim 17 wherein the exported command interfaces are popup menus.

Description

FIELD OF THE INVENTION

The present invention relates generally to object oriented programming methodologies. More specifically, the present invention includes a method and apparatus that provides object oriented interfaces between enterprise management frameworks and management agents that interact with enterprise management frameworks.

BACKGROUND OF THE INVENTION

The growth in size and complexity of computer networks has made network management an increasingly difficult task. As a result, a number of software applications have been developed to automate management of computer systems and networks. These applications are referred to in this document as management agents. Management agents are designed to allow the state of entities, such as computer systems, disks and processes, to be remotely monitored and managed. Many management agents perform these functions on a network wide basis. This allows large numbers of entities within a network to be centrally analyzed and managed.

Most management agents have been developed to manage specific entity types. As a result, a single computer network may include several different management agents. For example, a representative network may use a first management agent to manage disks and a second management agent to manage software applications. This complicates the network management task by forcing network operators to learn and use the features of several different management agents.

Enterprise management frameworks (also known as EM frameworks) are software applications that have been developed to simplify the use of different management agents. To accomplish this end, EM frameworks attempt to provide a single, unified interface to different management agents. An effective method for providing this type of interface is to treat entities, such as computer systems, disks and processes, as objects. The objects within a computer network may then be grouped into a hierarchy. The object hierarchy provides a structure that may be visually navigated. Objects within the hierarchy can be manipulated to manage their associated entities.

The unified interface provided by EM frameworks greatly simplifies the task of network management. As a result, it is generally desirable to extend EM frameworks to provide this interface for a wide range of management agents. Unfortunately, providing this type of cross-compatibility between EM frameworks and management agents can be complex. This complexity results, partially, because each management agent and each EM framework will typically have its own programming interface. Integrating an EM framework with a group of management agents means adapting the programming interfaces of the framework and each agent. This work may have to be redone if a new EM framework or agent is used or if an updated programming interface is provided for an existing EM framework or agent. Effectively, when traditional methods are used, EM frameworks and management agents form part of a closed architecture. These architectures are expensive to implement, expensive to maintain, and expensive to adapt or upgrade.

Integrating multiple management agents with EM frameworks may also result in complex runtime problems. As an example, consider the case where two management agents both report status for a particular entity. A question arises as to how an EM framework will proceed if the two management agents do not agree on the status of the entity. Furthermore, where multiple management agents are used, it may be difficult for the EM framework to determine which management agent should process a given user command.

Integrating multiple management agents with EM frameworks also tends to increase the number of objects that must be managed. In large networks, this may increase the number of managed objects to the point that an EM framework would provide unacceptable performance or require unacceptable initialization periods.

Based on the preceding discussion, it may be appreciated that there is a need for systems that facilitate the integration of management agents and EM frameworks. It is important for systems of this type to be inexpensive to implement, inexpensive to maintain, and inexpensive to adapt or upgrade. These systems need to correctly report entity status and correctly direct user commands. These systems also need to scale to large network environments without suffering unacceptable performance degradation.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for integrating management agents and EM frameworks. For a representative embodiment, the present invention includes an open enterprise management gateway or OEM gateway. The OEM gateway is a software process that functions as an intermediary between one or more management agents and one or more EM frameworks. The OEM gateway includes an OEM server and a series of EM adapters. Each EM adapter provides an interface between the OEM gateway and a particular type of EM framework.

There are two interfaces between the OEM server and a given management agent. The first of these interfaces, known as the OEM request interface, is exported by the OEM server and used by the management agent. The second, known as the client callback interface, is exported by the management agent and used by the OEM server. Both of these interfaces are constructed to conform to predefined application programming interfaces (APIs). Adapting a particular management agent to work with the OEM gateway requires configuring the management agent to use the OEM request interface and to export a client callback interface.

There are two interfaces between the OEM server and a given EM adapter agent. The first of these interfaces, known as the adapter request interface, is exported by the EM adapter and used by the OEM server. The second, known as the OEM callback interface, is exported by the OEM server and used by the EM adapter. Both of these interfaces are constructed to conform to predefined application programming interfaces (APIs). Adapting a particular EM adapter to work with the OEM gateway requires configuring the EM adapter to provide an adapter request interface and to use the OEM callback interface.

Once configured, an EM framework or management agent may be used in combination with any EM framework or management agent that has been adapted to use the OEM gateway. Effectively, the APIs of the OEM gateway provide an open architecture for EM framework/management agent interaction. The open architecture simplifies the task of adding new or changed EM frameworks or management agents.

During operation, a group of one or more management agents uses the OEM gateway to interact with a group of one or more EM frameworks. Management agents use the OEM request interface to add objects to the EM frameworks. Each object corresponds to an entity, such as a computer system, disk or process. The EM frameworks display, using their own native interfaces, the objects added by the management agents. When appropriate, the management agents use the OEM request interface to define and associate command interfaces, such as popup menus, with the objects within the EM frameworks.

Users trigger the command interfaces associated with the objects in an EM framework to interact with the underlying entities. In response, the EM framework uses the OEM callback interfaces to invoke callback procedures within the appropriate management agents. The callback procedures perform the steps required to effectuate the operation requested by the user.

The OEM gateway provides arbitration between different EM frameworks and different management agents. As an example, if two or more management agents report different status information for a single object, the OEM gateway determines which information should be forwarded to the EM frameworks. Arbitration also allows the OEM gateway to correctly direct callback processing to the correct management agents.

The OEM gateway maintains an internal depth variable. The depth variable is user-configurable and describes the preferred depth for the hierarchy of objects created by the management agents. Management agents may access the depth variable to determine the preferred depth for their object hierarchies. This decreases the probability that management agents will add objects in numbers that exceed the performance capabilities of the EM frameworks.

Advantages of the invention will be set forth, in part, in the description that follows and, in part, will be understood by those skilled in the art from the description herein. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims and equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, that are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and, together with the description, serve to explain the principles of the invention.

FIG. 1 is a block diagram of a computer network or cluster shown as an exemplary environment for an embodiment of the present invention.

FIG. 2 is a block diagram of an exemplary computer system as used in the computer network of FIG. 1.

FIG. 3 is a block diagram of an embodiment of the OEM gateway of the present invention, shown with a representative set of management agents and EM frameworks.

FIG. 4 is a block diagram of an object hierarchy as used by an embodiment of the present invention.

FIG. 5 is a block diagram showing internal components of an embodiment of the OEM gateway of the present invention, shown with a representative management agent and EM framework.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

ENVIRONMENT

In FIG. 1, a computer network 100 is shown as a representative environment for the present invention. Structurally, computer network 100 includes Ma series of nodes, of which nodes 102a through 102d are representative. Nodes 102 are intended to be representative of a wide range of computer system types including personal computers, workstations and mainframes. Although four nodes 102 are shown, computer network 100 may include any positive number of nodes 102. Nodes 102 may operate under distinct operating system types.

Nodes 102 are interconnected via computer network 104. Network 104 is intended to be representative of any number of different network types. As shown in FIG. 2, each node 102 includes a processor, or processors 202, and a memory, or memories 204. An input device 206 and an output device 208 are connected to processor 202 and memory 204. Input device 206 and output device 208 represent a wide range of varying I/O devices such as disk drives, keyboards, modems, network adapters, printers and displays. Each node 102 also includes a disk drive 210 of any suitable disk drive type (equivalently, disk drive 210 may be any non-volatile storage system such as "flash" memory).

OPEN ENTERPRISE MANAGEMENT GATEWAY

The present invention provides a method and apparatus for integrating management agents and EM frameworks. For a representative embodiment, the present invention includes an open enterprise management gateway (OEM) of the type designated 300 in FIG. 3. OEM gateway 300 is a software process that functions as an intermediary between one or more management agents 302 and one or more EM frameworks 304. OEM gateway 300 is partitioned into an OEM server 306 and a series of EM adapters of which EM adapters 308a through 308c are representative. OEM server 306 communicates with management agents 302 and performs processing that is independent of the particular EM frameworks 304 being used. Each EM adapter 308 provides an interface between OEM server 306 and a respective EM framework 304. Unlike OEM server 306, EM adapters 308 are EM framework specific. This means that EM adapters 308 perform processing that is dependent on their particular EM framework 304.

Management agents 302 use OEM gateway 300 to export data to EM frameworks. The exported data describes the entities that the management agents 302 manage. Preferably, this data is exported in the form of a hierarchy of objects. A representative object hierarchy of this type is designated 400 in FIG. 4. Object hierarchy 400 includes a series of objects 402a through 402h. Each object 402 represents an entity, such as a computer system, disk or process. Each object 402 has a name. For example, object 402a has the name "San Francisco." Object 402h has the name "two." Objects 402 are arranged into hierarchical levels. The hierarchical arrangement means that each object 402 has a pathname. The pathname of an object 402 corresponds to the location of the object 402 in the object hierarchy 400. In the case of object 402h, for example, the pathname is ".backslash.San Francisco.backslash.Disk.".

Objects 402 within object hierarchy 400 may have associated states. A state is a numeric value. States are typically used to described the operational status of objects 402. As an example, numeric states corresponding to "normal", "marginal" or "bad" may be assigned to describe the operational status of DISK objects 402f, 402g, and 402h. Different objects 402 and different types of objects 402 may have different states.

Objects 402 within object hierarchy 400 may have associated command interfaces. As an example, a representative command interface 404 is associated with CPU object 402d. In this example, command interface 404 is a popup menu that acts on the associated object 402. In the case of representative command interface 404, the command interface includes two options: "restart" and "halt." Different objects 402 and different types of objects 402 may have different command interfaces 404. Command interfaces 404 may be associated with specific objects 402. Command interfaces 404 may also be defined to apply to a specified object 402 and all of its descendent objects 402. Finally, command interfaces 404 may be defined generically. Generically defined command interfaces 404 apply to a class of objects 402 that share a common name. As an example, it may be assumed that a command interface 404 has been defined for a class of objects 402 having the name "DISK." In this case, the command interface would apply to object 402c and its descendants (objects 402f, 402g and 402h). The same command interface 404 would apply to all other similar objects 402 in object hierarchy 400. Thus, if objects 402 for a second system, such as ".backslash.Chicago" where included in object hierarchy, the example command interface 404 would apply to disk objects 402 included for that system. It should be noted that there is an order of precedence between command interfaces 404. Thus, a command interface 404 defined specifically for an object 402 takes precedence over a command interface 404 defined for one of the ancestors of the object 402 or a class that includes the object 402.

As previously described, management agents 302 use OEM gateway 300 to export data, in the form of object hierarchies 400, to OEM gateway 300. OEM gateway 300 forwards the exported object hierarchies 400 to EM frameworks 304. EM frameworks 304 use the exported object hierarchies 400 to create interfaces to the entities managed by the exporting management agents 302. These interfaces typically take the form of a navigable hierarchy that bears some resemblance to object hierarchy 400 as shown in FIG. 4. Examples of these navigable hierarchies include the MICROSOFT EXPLORER-style interface provided by the OBJECT INTEGRATION LAYER (OIL) of TANDEM COMPUTERS INC. Displays using Java, HTML or other web-based technologies are also suitable. In other cases, still other display formats will be used.

EM frameworks 304 may use the state information associated with objects 402 to modify their displays. As an example, EM frameworks 304 may color objects 402 according to their states to indicate "normal", "marginal" or "bad" operational conditions. EM frameworks 304 also preferably provide some type of interface that allows users to view and select the options included in command interfaces 404. Typically, but not necessarily, this interface will provide command interfaces that interact with a mouse or other pointing device. Other interfaces may be used, however, without departing from the present invention.

EM frameworks 304 respond to user selection of options within command interfaces 404 by notifying OEM gateway 300. OEM gateway 300, in turn, passes these notifications on to management agents 302. Management agents 302 invoke callback objects to perform the steps required by the command interface options selected by the users of EM frameworks 304.

The use of OEM gateway 300 to export object hierarchies 400 and to direct callback processing is better appreciated by reference to FIG. 5. In FIG. 5, a representative management agent 302, OEM server 306, EM adapter 308 and EM framework 304 are shown. Representative management agent 302 includes an entity reporting module 502 and a command processing module 504. Entity reporting module 502 represents the portion of management agent 302 that is configured to use OEM gateway 300 to export object hierarchy 400 to EM frameworks 304. Command processing module 504 represents the portion of management agent 302 that responds to commands sent by EM frameworks 304 and OEM gateway 300. Representative EM framework 304 includes an object display module 506 and an interactive input module 508. Object display module 506 represents the portion of EM framework 304 that is configured to receive and display object hierarchy 400 from EM adapter 308. Interactive input module 508 represents the portion of EM framework 304 that is configured to receive interactive input from a user and perform appropriate callbacks using EM adapter 308.

To perform its role as an intermediary, OEM server 306 maintains a series of tables. These tables include an object table 510, a popup table 512, an adapter table 514 and a client table 516. Object table 510 includes a series of data structures that describe the objects 402 that have been exported by management agents 302. Each of these data structures is an instance of an ObjectInfo class. OEM server 306 constructs ObjectInfo instances on a permanagement agent 302 basis. Thus, if two management agents 302 export the same object 402, OEM server 306 will construct two separate instances of the ObjectInfo class. It should be noted that OEM server 306 constructs instances of the ObjectInfo class only for objects 402 that have actually been exported by management agents 302. OEM server 306 does not construct instances of the ObjectInfo class for objects 402 that are implied by the pathname of an exported object 402. Thus, where a management agent 302 exports objects .backslash.W.backslash.X.backslash.Y and .backslash.W.backslash.X.backslash.Z, OEM server 306 creates ObjectInfo instances for Y and Z but not for W or X. Instances of the ObjectInfo class include the following elements:

              Element Name         Data Type
              Path                 Character String
              ObjectName           Character String
              ClientName           Character String
              CallbackObject       OLE Callback Object
              State                Integer
              Context              Character String

          Element Name             Data Type
          Path                     Character String
          ObjectName               Character String
          ObjectInfoList           List of ObjectInfo objects
          ObjectNodeList           List of ObjectNode objects
          Parent                   ObjectNode object
          PropagatedOwner          ObjectNode object
          PropagatedState          Integer
          PropagatedClient         Character String
          PropagatedContext        String
          PropagatedClient         OLE Callback Object

            Element Name             Data Type
            ClientName               Character String
            ObjectName               Character String
            MenuCaption              Character String
            CallbackCommand          Character String
            CallbackObject           OLE Callback Object
            AppEXEName               Character String
            CallbackClassName        Character String
            CallbackType             Character String

          Element Name                 Data Type
          AdapterName                  Character String
          ClassName                    Character String
          AdapterInterfaceObject       OLE Object
          OEMCallbackObject            OLE Callback Object
          State                        Integer
          Priority                     Integer

            Element Name             Data Type
            ClientName               Character String
            DefaultCallbackObject    OLE Callback Object
            AppEXEName               Character String
            CallbackClassName        Character String
            RequestInstanceID        Integer

• Inventors
  Miller, Michael R.; O'Brien, Collin P.; Boucher, Sylvain; Tremblay, Chantal;
• Assignee
  Compaq Computers Incorporated (Houston, TX)
• Published
  Oct-9-2001
• Current US Classes:
  704/223
  719/316
• Application #
  132945
• International Classes
  G06F 015/173
• Field of Search
  709/202 709/223 709/224 709/315 709/316 709/317
• Examiner
  Dinh; Dung C.
• Agent
  Fenwick & West LLP
• US Patent References:
  5367635
  5452433
  5611050
  5751962
  5781736
  5790789
  5822585
  5832224
  5933601
  5983016
  6049828
  6052722
  6061721
  6067559
  6101500