Platform independent computer network manager6788315Abstract A client-server network management system includes: a plurality of managed computer network elements, a managed element server that executes on a first computer; and at least one managed element server client that typically executes on a second computer. The managed element server and managed element server client are computer processes that execute from memory of their respective computers. The client-server network management system is really two applications in one: a visual element manager builder and a manager. The manager provides the run-time environment in which element managers are executed to monitor and manage computer network behavior such as network throughput, collision rate, and number of duplicate IP packets, to name a few. The manager portion of managed element server is independent of any graphic user interface. The logic and structure of the manager of managed element server is cleanly separated from the graphic user interfaces. The visual element manager builder is a visual development environment in which device vendors or network managers may create standardized element management applications, called element managers. A user can build an element manager without writing any computer code. In addition, a user can edit an element manager without writing any computer code. A graphic user interface of this invention, that is displayed by the client, includes a visual image of a computer network element being managed. As a user looks at the visual display in the graphic user interface, the user is provided the same visual information as if the user where physically present at the location of the managed computer network element. Thus, at a glance, a user can obtain considerable information about the status of the computer network element as represented by the visual display. Claims We claim: Description BACKGROUND OF THE INVENTION
TABLE 1
Standard PDU's
GetRequest Issued by the management station to the agent to
retrieve information from the MIB
GetResponse Issued by the agent after receiving a GetRequest-PDU,
GetNextRequest-PDU, or SetRequest-PDU to send
MIB object values or responses to the
management station
GetNextRequest Issued by the management station to traverse the
agent's MIB tree by moving sequentially from one
object value(instance) to the next
without knowing the precise name of the object
SetRequest Issued by the management station to modify and store
information within the agent's MIB
Trap An asynchronous (unsolicited) message
issued by the agent to the
management station to report a significant event.
By using these operators, a SNMP manager application can communicate with managed nodes to identify the nodes, and to determine statistical information, such as network traffic flow through a given computer network, for the network. SNMP trap events allow the SNMP agent to initiate communication with management applications when a significant (serious) network event takes place. The significant trap events are defined in RFC 1157. By default, all SNMP agents generate Trap-PDUs for the events shown in TABLE 2.
TABLE 2
Events Resulting in Traps
Cold Start An agent initialization or re-initialization which
may affect the values of objects has occurred
Warm Start An agent re-initialization which does not affect
the value of any object has occurred
Link Down The agent has discovered a failure in one of the
communication links of its configuration
Link Up A communications link in the agent's
configuration has just become activated
Authentication The agent has received a protocol message that
Failure was not properly authenticated with the correct
community name (this trap may be suppressed
upon request)
Neighbor Loss The agent has discovered that a neighbor is down
Enterprise The agent has experienced a vendor-specific
event
In contrast to trap events, polling events are proactive requests made by management station 110 to elicit information from the agent. A common network management technique called "trap directed polling" is for the management station to wait for a trap event and then poll for more information regarding that event. This method minimizes the impact on managed elements and network bandwidth. However, since traps are sent unreliably, some degree of polling is still required as a backup precaution. Access to an agent is controlled by a community name. Every agent is configured to recognize one or more community names, and to provide the appropriate level of access to SNMP managers based on the community name that the managers include in their messages. The community relationship between agents and managers defined by the community name is used to administer the MIB and to provide the agent information on where to send a trap. There are three levels of access to MIB objects: read-only(object value can be read but not modified), read-write (object value can be read or modified), and write-only (object value can be modified but not read). The level of access which the agent allows for its MIB objects is determined by comparing the community name provided in the SNMP message with that defined by the agent. If the two names match, access is given. A separate community name is defined for read and write accesses. The most common community names are public (access given to all management stations) and private (no access allowed). Community names are not considered passwords because community names cannot make any guarantees regarding the command (message) with respect to its origin, its integrity, its delivery, or its privacy. More information regarding community names is contained in RFC 1157. While SNMP was designed to simplify network management, this has not be the case. To make SNMP successful, every device vendor must provide tools to monitor and troubleshoot their devices, or alternatively get some other company that supplies a management system to include support for their particular device. In general, the communication of vendor specific MIB objects among heterogeneous elements is problematic. The challenge is clear. How can a group of network managers efficiently manage a constantly changing and growing network which is composed of a wide array of heterogeneous elements, that are produced by different vendors, and that support many different platform types? Any solution must be simple, flexible, robust, secure, collaborative, and most importantly has to work. SUMMARY OF THE INVENTION A managed element server of this invention is a comprehensive open, standards-based network management solution for computer networks having a computer network management capability. The managed element server of this invention efficiently manages a constantly changing and growing heterogeneous computer network. The solution of this invention, as described more completely below, is flexible, robust, secure, collaborative, and most importantly works. The client-server network management system of this invention includes: a plurality of managed computer network elements, sometimes called managed elements; a managed element server that executes on a first computer; and at least one managed element server client that typically executes on a second computer. The managed element server and managed element server client are computer processes that execute from memory of their respective computers. The managed element server and managed element server client are platform independent computer processes and can be executed on any computer platform that supports the platform independent computer language in which the server and client are written. This is particularly advantageous because it is unnecessary to write a different version of the client and server for each of the different computing platforms typically found on a heterogeneous computer network. The client-server network management system provides a new capability for creating a managed element template, called an element manager, for a management-enabled computer network element, such as a bridge, a workstation, or perhaps, a computer software application that is executing a computer system connected to the network. A user can build an element manager without writing any computer code. In addition, a user can edit an element manager without writing any computer code. Moreover, since the computer processes are platform independent, the user does not need to be working on a particular type of computer platform to build an element manager. The user utilizes an intuitive graphical user interface (GUI) not only to builder element managers, but also to utilize the managed element server of this invention in managing computer network elements. The graphic user interface of this invention, that is displayed by the client, includes a visual image of a computer network element being managed. The visual image includes a representation of the components of the computer network element, which include for example active components such as ports; a set of LEDs, and action buttons that are typically used to change the state of the computer network element. The user can select one of the components by clicking on a representation of the component in a navigation tree that is displayed in a navigation area of the graphic user interface, or alternatively by clicking on the component in the visual image. The user can configure an element manager for the managed computer element represented by the display in graphic user interface so that a managed component, called a hotspot, has either a colored outline about component or the component itself has a color. The color of the outline or the color of the component itself gives the user a visual representation of the status, e.g., state of the component. Thus, as a user looks at the visual display in the graphic user interface, the user is provided the same visual information as if the user where physically present at the location of the managed computer network element. Thus, at a glance, a user can obtain considerable information about the status of the computer network element as represented by the visual display. An alarms button in the graphic user interface flashes when the managed computer network element experiences an event that is associated with a alarm. This notifies the user that action may be required in management of the computer network element. The user can determine why the alarms button was activated by reviewing an alarm log that is presented in the graphic user interface upon the user activating the alarms button. Using the client graphic user interface, the user can initiate action that corrects a problem that generated the alarm, or alternatively, configure the server to automatically correct such problems. Also, the user can change the management configuration for the managed computer network element by redefining rules that are used in event management to monitor and control the operation of the managed computer network element. Through the graphic user interface, the user can configure the server to periodically send user-defined polling event requests. The managed computer network element replies with the requested information to the server. Depending on the configuration of the server, predefined actions may be executed in response to polling events. The event management also supports trap-directed polling. Thus, any user can manage the computer network from a computer connected to the network without being physically present at the location of each managed computer network element. Further, the user does this by using any computer that can be connected to the network independent of the processor or operating system on the computer, and without writing any computer code. Hence, the intuitive client GUI of this invention makes client-server network management system easy to use and hides its complexity. The GUI presentation is separated from the application logic in the server and this reduces hardware requirements, provides scalability and extensibility, and increases the flexibility of the client-server network management system. The client-server network management system of this invention is really two applications in one: a visual element manager builder and a manager. The visual element manager builder is a visual development environment in which device vendors or network managers may create standardized element management applications, called element managers. The manager provides the run-time environment in which the element managers are executed to monitor and manage computer network behavior such as network throughput, collision rate, and number of duplicate IP packets, to name a few. No programming is required and the separation between the visual element manager and the manager is seamless and transparent to the user. According to the principles of this invention, one of a plurality of element managers is associated with each managed computer network element in the computer network. Herein, a management-enabled computer network element is any element in a computer network that can be managed using a computer network management protocol. A management-enabled computer network element can be any hardware or software on the computer network that implements the network management protocol by having a network management agent and a network management information database, or a similar process. The manager of this invention includes a discovery engine that automatically interrogates each host in the computer network to determine whether the host is running a network management agent. Upon detection of a management-enabled computer network element, the discovery engine attempts to associate one of the plurality of element managers with the computer network element. If the discovery engine is able to associate the computer network element with one with one of the plurality of element managers, the discovery engine calls a process that uses the element manager to create a managed element object, and creates a poll server and an event engine for the managed computer network element. Upon completion of the discovery of management-enabled computer network elements, each management-enabled computer network element either has a managed element object and an associated poll server and an event engine, or is assigned a predefined element manager name, if no association could be made. A poll server in the manager of this invention creates a thread for each polling event (request) specified in poll events of the managed element object. When the poll server receives a response to a polling event, the data in the response is passed to the event engine for evaluation. The managed server element allows polling events which are used to solicit the information from a computer network element, or any of its components. The event engine in the manager of this invention, in one embodiment, is an event rule engine. The event engine process all polling events, and all trap events for the managed computer network element associated with the managed element object. The event engine uses event rules to determine the action that should be taken in response to each polling event, and each trap event. Each rule has a rule condition, and a rule action. The event engine evaluates the rule condition using the data from the polling event or trap event, and if the rule condition is true, performs the action or actions specified by the rule action. The combination of the event engine and the event rules is a sophisticated state machine and rules engine which allows pro-active management of a managed computer network element. Each active component of a managed computer network element has states, which are defined within the managed element object. These states are used in event rules to accurately manage a device, by triggering alarms based on sequence of events rather than simple threshold conditions, or by taking some other prescribed action. In response to the result of a poll of the managed computer network element, the event engine determines the current state of the element component for the poll event. Next the event engine loops through all the rules in event rules for the polling event to determine whether there is a rule that can be applied for the current state. If there is such a rule, the event engine uses the information returned in the result of the poll to evaluate the rule. If the rule is true, and any persistence condition is satisfied, the action specified in the rule is executed. The action specified in the rule can be one or more of: executing a system command, logging an event to the alarm log, and changing the state of the element component from the current state. In response to a trap event from the managed computer network element, a trap server passes data in the trap to the event engine which in turn determines the current state of the element component that generated the trap. Next the event engine loops through all the rules in event rules for the trap event to determine whether there is a rule that can be applied. If there is such a rule, the event engine evaluates the rule using data sent in the trap. If the rule is true, and any persistence condition is satisfied, the action specified in the rule is executed. If there is no rule for the trap in the event rules, the event engine logs the trap into the alarm log for the computer network element. After an alarm factory in the manager of this invention loads an existing alarm log for each managed element object. The user can view the alarms for all managed computer network elements, for a group of managed computer network elements, for a specific computer network element, or, for a component of a specific computer network element. When an alarm is received, button Alarms on the client GUI changes state, e.g., blinks, and if the alarm is associated with a particular component, the appearance of the component may be changed in response to the alarm. The trap server, in the manager of this invention, receives all traps from other hosts on the computer network. If a received trap is from one of the managed elements, the trap server copies the data in the trap to a buffer, and notifies the event engine for the managed element that generated the trap. The event engine processes the trap data as described above. Notice that the manager portion of managed element server described above is independent of any graphic user interface. The logic and structure of the manager of managed element server is cleanly separated from the graphic user interfaces The managed element server also interacts with managed element server clients. In one embodiment, the managed element server client is implemented as a JAVA applet and is running inside a World-Wide Web Browser or a JAVA Applet Viewer. The JAVA applet is downloaded from the managed element server. The JAVA applet includes information that allows a user a) to monitor the operation of each of the managed computer network elements, b) to edit the event management for the managed computer network elements by reconfiguring the event management model in the element manager object for the network element, and c) in one embodiment, to use a visual element manager builder that permits both building and editing of element managers. The element manager of this invention is a template that is used by the manager in the server of this invention to manage a computer network element. The element manager includes basic information data that defines core properties of a computer network element, and event management information that is used in managing the computer network element. A method for building an element manager for a computer network element includes entering data characterizing the element manager through a graphical user interface of a client computer process. The client computer process uses a visual element manager builder server process to build the element manager using the data. The element manager is stored in a memory on a computer that executes the server process for the client computer process. The basic information includes a storage location of a file that contains a visual representation of the computer network element; identification of attributes that characterize operation of components of the computer network element; association of a component of the computer network element with one hotspot in a plurality of hotspots; association of attributes that characterize operation of the component with the one hotspot. All of this basic information is entered using element manager build panels in the client graphic user interface. The element manager build panels include a plurality of wizard panels. In one embodiment, a wizard panel is identified by a plurality of edit command buttons. The event management information includes: states for a component of the computer network element; polling events for the component; a requisite component state or states for each polling event; a rule for each polling event when the component is in the requisite component state; and trap events for the component. All of this event management information is entered using element manager build panels in the client graphic user interface. The element manager build panels include a plurality of wizard panels. Hence, in this embodiment, the element manager builder tool is downloaded from the computer server process and executed as a client process wherein the element manager builder tool presents a user with a plurality of panels in a graphic user interface to build the element manager. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is an illustration of a portion of a prior art heterogeneous computer network that is managed using SNMP. FIG. 2 is a sample MIB tree as defined by SNMP. FIG. 3A is an illustration of a portion of a heterogeneous computer network that includes the client-server network management application of this invention. FIG. 3B is an illustration of one embodiment of the client grahpical user interface of this invention. FIG. 4 is a more detailed diagram of the managed element server of this invention. FIGS. 5A and 5B are a process flow diagram for the managed element server of this invention. FIG. 5C is an example of a state diagram that could be implemented in one embodiment of this invention. FIGS. 6A and 6B are specific examples of the client graphic user interface of this invention. FIG. 6C is an example of the navigation tree that is displayed in the navigation of the client graphical user interface of this invention. FIG. 7 is a high level illustration of the client-server computer network management system of this invention. FIG. 8 is a block diagram that illustrates the components of an element manager stored in a memory, according to the principles of this invention. FIG. 9A is an illustration of one embodiment of an element manager list panel and associated command buttons that are displayed in the work area and command button area of the client graphical user interface of this invention. FIG. 9B is an illustration of one embodiment of an element manager description wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 9C is an example of a background image that is displayed in the element image area of the client graphical user interface of this invention. FIG. 9D is an illustration of the complete client graphical user interface of this invention that is utilized by the visual element manager builder. FIG. 10 is a process flow diagram for building the basic information in an element manager according to the principles of this invention. FIG. 11 is an illustration of one embodiment of a MIB file selection wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 12A is an illustration of one embodiment of a hotspot definition wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 12B is an illustration of a toolbar that is displayed in the header of the GUI of this invention, when the hotspot definition panel also is displayed in the GUI. FIG. 13 is a process flow diagram of the operations associated with creating a hotspot in an element manager using the visual element manager builder of this invention. FIG. 14A is an illustration of one embodiment of a button hotspot property definition wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 14B is an illustration of one embodiment of an embedded graph hotspot property definition wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 15 is an illustration of one embodiment of a hotspot MIB variable selection wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 16 is an illustration of one embodiment of a define attributes of hotspot variable wizard panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 17 is an about edit panel for an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 18A is a state definition list panel for an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 18B is a state definition panel for an active component hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 18C is a state definition panel for a LED hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 19A is a polling event list panel for an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 19B is a polling event definition panel for a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 19C is a requisite state selection panel for a polling event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 20 is a trap event list panel for an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 21 is a polling event definition panel for a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 22 is a trap event rules list panel for an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 23 is a rule definition panel for a trap event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 24 is a trap rule condition definition panel for a trap event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 25 is a trap rule action definition panel for a trap event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 26 is a trap rule alarm log information panel for a trap event rule for a trap event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 27 is an auto-discovery panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 28 is a block diagram of a computer network that is used to demonstrate the various embodiments of the auto-discovery process of this invention. FIG. 29 is a managed element group definition panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 30 is an element manager to physical computer network element association panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 31 is an example of an alarm log history panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 32 is an example of an alarm filter panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 33 is an example of a hotspot status panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 34 is an embedded graph hotspot definition panel and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 35A illustrates highlighting variables in a hotspot status panel that are used to generate a regular graph upon activating the graph value command button of the client graphical user interface of this invention. FIG. 35B illustrates the regular graph that is generated in response to the selections illustrated in FIG. 35A. FIG. 36 illustrates the client graphic user interface for the MIB browser of this invention. FIG. 37A is an illustration of one embodiment of an element manager list tabbed edit panel and associated command buttons that are displayed in the work area and command button area of the client graphical user interface of this invention. FIG. 37B is an illustration of one embodiment of a MIB file selection tabbed edit panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37C is an illustration of one embodiment of a hotspot definition tabbed edit panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37D is an illustration of one embodiment of a hotspot MIB variable selection tabbed edit panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37E is an illustration of one embodiment of a define attributes of hotspot variable tabbed edit panel and associated command buttons that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37F is a state definition list edit panel for an element manager hotspot and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37G is a polling event definition tabbed edit panel for a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37H is a poll event rules list edit panel for an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37I is a rule definition tabbed edit panel for a polling event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37J is a polling event rule condition definition tabbed edit panel for a polling event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37K is a trap rule action definition tabbed edit panel for a polling event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37L is a polling event rule alarm log information tabbed edit panel for a polling event rule for a polling event associated with a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 37M is a trap event definition edit panel for a hotspot of an element manager and associated command buttons, that are displayed in the work area and command button area, respectively, of the client graphical user interface of this invention. FIG. 38 is an illustration of the server object model and containment hierarchy of one embodiment of this invention. FIG. 39 is an illustration of the server RMI object class hierarchy in one embodiment of this invention. FIG. 40 is an illustration of the server non-RMI object class hierarchy in one embodiment of this invention. FIG. 41 is a polling object diagram according to the principles of this invention. FIG. 42 is a process flow diagram for one embodiment of the auto-discovery process of this invention. FIG. 43A to 43C are more detailed process flow diagrams of selected operations in FIG. 42. FIG. 44 is a diagram of the discovery notification structure of this invention. In the Figures, objects with the same reference numeral are the same object. Also, the first numeral of a reference number for FIGS. 1 to 9 and the first two numerals of a reference number for FIGS. 10 and greater indicate the figure in which the element first appeared. DETAILED DESCRIPTION OF THE INVENTION According to the principles of this invention, a managed element server 314 (FIG. 3A) was developed as a comprehensive open, standards-based network management solution for computer networks having a computer network management capability, such as SNMP. Managed element server 314 of this invention efficiently manages a constantly changing and growing computer network 300 which is composed of a wide array of heterogeneous elements, e.g., operating system server 310, which in one embodiment is a Microsoft WINDOWS NT server, workstation 320, which could be for example a DEC, Sun Microsystems, or Silicon Graphics workstation, bridge 330, router 340, and printer 350, that are produced by different vendors, and that support many different platform types. (WINDOWS NT is a registered U.S. trademark of Microsoft Corp. of Redmond, Wash.) The solution of this invention, as described more completely below, is flexible, robust, secure, collaborative, and most importantly works. Client-server network management system 375 includes a plurality of managed elements, a managed element server 314 that executes on a first computer 310 and at least one managed element client 391 that executes on a second computer 390. Managed element server 314 and managed element client 391 are computer processes that execute from memory of their respective computers. Moreover, prior to loading for execution managed element server 391 and managed element client 391 are stored typically on a non-volatile medium. Managed element server 314 and managed element client 391 are platform independent computer processes and can be executed on any computer platform that supports the platform independent computer language in which server 314 and client 391 are written. This is particularly advantageous because it is unnecessary to write a different version of the client 391 and server 314 for each of the different computing platforms found on heterogeneous computer network 300. In one embodiment, client 391 and server 314 are written in the JAVA programming language, and are able to take advantage of the languages' inherent simplicity, flexibility, robustness, security, and other object-oriented technology strengths, as described more completely below. (JAVA is a trademark of Sun Microsystems, Inc.) Client-server network management system 375 provides a new capability for creating a managed element template, called an element manager, for a management-enabled computer network element, such as bridge 331, or workstation 320. Computer 310 has a plurality of element mangers 315 stored on a memory of computer 310. A user can build an element manager without writing a computer program as was required in the prior art. Moreover, since the computer processes are platform independent, the user does not need to be working on a particular type of computer platform to build an element manager. The user utilizes an intuitive graphical user interface (GUI) not only to builder element managers, but also to utilize server 314 in managing computer network elements. FIG. 3B is an example of graphic user interface 376 of this invention. Graphic user interface 376 includes a visual image 377 of the computer network element being managed, which in this example is a computer network hub. Visual image 377 includes a representation of the components of the computer network element, which in this embodiment includes: ports 1 to 16 that are active components; LEDs 1 to 16, a POWER LED, a set of status LEDs, that are each an LED component; and an input button 378 that is an active button. The user can select one of the components by clicking on the component in a navigation tree 305, or alternatively by clicking on the component in visual image 377. As explained more completely below, navigation tree 305 is a hierarchical representation of the information on server 314 that can be accessed by the user through client 391. An outline 379 is drawn around the selected component, port 1, in visual display 377, and status information about port 1 is displayed on a panel 374 in graphic user interface 376. In this embodiment, port 1 is named a_hotspot Graphic user interface 376 also includes a severity legend bar 311 that allows the user to visually determine the state of the managed computer element by associating the color of the managed computer element with the corresponding color in severity level bar 311. Thus, according to the principles of this invention the color of port 1 is used to communicate to the user the status of the port. As explained more completely below, the user can configure an element manager for the managed computer element represented by the display in graphic user interface 376 so that port 1 has an outline about the port 1, or port 1 itself has a color. The color of the outline or the color of the port itself gives the user a visual representation of the status, e.g., state of the port. The element manager can also be configured to represent the state of each of the other ports by the color of the port in visual display 377. Similarly, each of the LEDs is assigned a plurality of colors and blink rates. Thus, as a user looks at the visual display in graphic user interface 376, the user is provided the same visual information as if the user where physically present at the location of the managed computer network element. Thus, at a glance, a user can obtain considerable information about the status of the computer network element as represented by visual display 377. Button Alarms 312B in persistent buttons 312 flashes when the managed computer network element experiences an event that is associated with a alarm. This notifies the user that action may be required in management of computer network 300. The user can determine why button Alarms 312B was activated by reviewing an alarm log that is explained more completely below. Using graphic user interface 376, the user can initiate action that corrects a problem that generated the alarm, or alternatively, configure server 314 to automatically correct the problem. Also, the user can change the management configuration for the managed computer network element by redefining rules that are used in event management to monitor and control the operation of the managed computer network element. Through graphic user interface 376. the user can configure server 314 to periodically send user-defined polling event requests. The managed computer network element replies with the requested information to server 314. Depending on the configuration of server 314, actions may also be executed in response to polling events. The event management also supports trap-directed polling. Thus, any user can manage the computer network from a computer connected to the network without being physically present at the location of each managed computer network element. Further, the user does this by using any computer that can be connected to the network independent of the processor or operating system on the computer, and without writing any computer code. Hence, the intuitive GUI of this invention makes client-server network management system 375 easy to use and hides its complexity. As explained more completely below, the separation of the GUI presentation from the application logic reduces hardware requirements, provides scalability and extensibility, and increases the flexibility of client-server network management system 375. The distributed client-server architecture also promotes coordinated collaboration in that many users can confidently work together simultaneously on shared information which is guaranteed to be consistent for all users. Lastly, a built-in security policy which takes advantage of the security provided by the operating system ensures a controlled environment which prevents unauthorized access and is capable of maintaining accountability. Client-server network management system 375 is really two applications in one: a visual element manager builder and a manager. As explained more completely below, the visual element manager builder is a visual development environment in which device vendors or network managers may create standardized element management applications, called element managers. The manager provides the run-time environment in which the element managers may be executed to monitor and manage computer network behavior such as network throughput, collision rate, and number of duplicate IP packets, to name a few. No programming is required and the separation between the visual element manager and the manager is seamless and transparent to the user. According to the principles of this invention, one of a plurality of element managers 315 is associated with each managed computer network element in computer network 300, e.g., an element manager is associated with each of managed computer network elements 310 to 350. Herein, a management-enabled computer network element is any element in a computer network that can be managed using a computer network management protocol, such as SNMP. A management-enabled computer network element can be any hardware or software on computer network 300 that implements the network management protocol by having a network management agent and a network management information database, or a similar process. Hence, in FIG. 3, workstation 320, bridge 330, router 340, and printer 350 include network management agent 321 and network management database 322, network management agent 331 and network management database 332, network management agent 341 and network management database 342, and network management agent 351 and network management database 352, respectively. Each of network management agents 321, 331, 341, and 351 communicates over network 300 using predefined commands, such as those defined above in TABLE 1, and a predefined protocol, e.g., SNMP. Also, each of the network management agents stores information characterizing the operation of the network element in the network management information database, according to a defined standard, that is associated with the network management agent. The operation of the agents and the storage of data by an agent is the same as in the prior art. Upon initiation of execution of managed element server 314 or reset of managed element server 314, processing transfers from start/reset 501(FIG. 5) to create server operation 502. In operation 502, managed element server 314 is loaded from disk storage for execution on OS server 310, and processing transfers to initialize user parameters operation 503. In initialize user parameters operation 503, managed element server 314 accesses a file stored on computer 310, that contains, for example, the name for managed element server 314, a storage location for alarm log files, and a maximum number of entries in each alarm log file, and processes the data in that file. Operation 503 transfers to list managed elements operation 504. In managed elements operation 504, managed element server 314 first determines whether there are any entries in a startup file stored on computer 310 in additional managed elements check 505. The startup file contains a list of managed computer network elements on network 300 and an address on the network of each managed computer network element. If there is an unprocessed entry in the startup file, check 505 transfers processing to managed element specified check operation 506 and otherwise to create visual element manager builder operation 510. In managed element specified check 506, managed element server 314 compares the current entry in the startup file with a list of managed computer network elements. If the current entry is in the list of managed computer network elements, check 506 transfers to check 505 and otherwise to specify managed element operation 507. Managed element server 314 adds the current entry in the startup file to the list of managed elements in specify managed elements operation 507. Operation 507 also returns processing to additional managed elements check operation 505. When all the entries in the startup file have been processed, check operation 505 deletes any managed elements that are in the list of managed elements, but are not listed in the startup file and transfers to create visual element manager builder operation 510. Managed element server 314 creates a number of objects that utilized by managed element server 314. Specially, in operations 510 to 514, managed element server 314 creates a visual element manager builder 406, a manager 404, a trap server 403, a database browser 405, and a network management application programming interface, respectively. Each of these is described more completely below. After manager 404 is created, manager 515 creates alarm factory 402 in create alarm factory operation 515. As explained more completely below alarm factory 402 manages alarms generated in response to events that occur in the managed computer network elements. Manager 404 also creates a discovery engine 401 in operation 516. Discovery engine 401, in discover management-enabled elements operation 517, automatically interrogates each host in network 300 to determine whether the host is running a network management agent in response to initiation of an auto-discovery process by a user through client process 391. Upon detection of a management-enabled computer network element such as workstation 320, discovery engine 401 attempts to associate one of the plurality of element managers 315 with workstation 320 by comparing the system object identification of the discovered computer network element with information stored in a map file. The stored information associates system object identifications with element managers. If discovery engine 401 is able to associate workstation 320 with one with one of the plurality of element managers 315, e.g., element manager 1, discovery engine 401 calls a process that uses element manger 1 to create managed element object 416. Poll server 417, and event engine 418 are also created for managed element object 416. If discovery engine 401 is unable to associate the management-enabled computer network element with an element manager, a poll server and event engine are not created for the management-enabled computer network element, and a predefined element manager name, e.g., EMNotFound, is assigned to the management-enabled computer network element. Upon completion of discover management enabled elements operation 517, each management-enabled computer network element either has a managed element object and an associated poll server and an event engine, or is assigned the predefined element manager name. Thus, a plurality of managed element objects 415 are created and each managed element object has its own poll server and event engine. Poll server 417 creates a thread for each polling event (request) specified in poll events of managed element object 416. Poll server 417 also performs single network management operations. When poll server 417 receives a response to polling event, the data in the response is passed to event engine 418 for evaluation. Poll server 427 performs similar operations for managed element object 426. A poll event in a managed element object contains information on a set of attributes that need to be polled, a default polling interval, a current polling interval that is being used, and a set of flags that are used to determine if polling is turned on or off for the event, and if the polling results are to be logged. The poll event also contains a list of states and an associated polling interval for each state. A poll event is processed by the poll server only when the managed element component associated with the poll event is in one of the listed states. The primary purpose of states is to classify the status of a component. States may also serve as transition points between changes in modes of operation of a component. In contrast to the trap-based approach to computer network management, with a polling-based approach, the network picture is constructed based on information which managed element server 314 explicitly requests. This is advantageous in that managed element server 314 has full control and is able to get a full picture of the network status. However, this method also has its shortcomings, the biggest one being timeliness. If managed element server 314 requests information too frequently, network bandwidth is used up. If managed element server 314 waits too long between requests, response to critical events may be too late. Another disadvantage is that in either situation, the requests introduce additional traffic onto the network. Managed server element 314 allows polling events which are used to solicit the information from a computer network element, or any of its components. As just explained, the frequency of the polling request is set initially set by the individual that builds the element manager for the computer network element. However, if the polling request frequency adversely affects the computer network performance, the polling frequency for the managed element object can be modified to achieve optimal performance vs. polling frequency. A trap-directed polling approach to network management was popularized in an attempt to take advantage of the strengths of the two other techniques while mitigating their weaknesses. With this approach, when an extraordinary event occurs, a single trap event is sent to managed element server 314, which in response to the trap, polls the managed computer network element for more information regarding that event. This method has turned out to be very effective, keeping the effect on managed computer network elements, and on computer network bandwidth down while supporting timeliness. Since traps are not reliably sent, low frequency polling is still necessary. Managed element server 314 supports trap-directed polling allowing association of polling events with states. In other words, the polling request takes place when the computer network element/component is in a specified state. The rules are defined such that this state is only entered when a particular trap event occurs. This state-dependent polling feature helps to reduce polling traffic. Event engine 418, in this embodiment, is an event rule engine. Event engine 418 process all polling events, and all trap events for the managed computer network element associated with managed element object 416. Event engine 418 uses event rules 412 to determine the action that should be taken in response to each polling event, and each trap event. The combination of event engine 418 and event rules 412 is a sophisticated state machine and rules engine which allows pro-active management of a managed computer network element. Each active component of a managed computer network element has a state, which is defined within the managed element object. For example, a port of a hub might have normal, warning and alarm states. These states are in event rules 412 to accurately manage a device, by triggering alarms based on sequence of events rather than simple threshold conditions. For example, an administrator of network 300 may decide that an alarm should be triggered on a port only if a threshold condition is passed continuously for one minute, i.e., a persistence condition is satisfied. With client 391, the administrator can set up a set of rules within event rules 412 which say that the first time the threshold is passed, the port is put in the warning state and the polling rate is increased. If the port remains over the threshold for the rest of the minute, the port is put in the alarm state and an alarm is triggered. Event rules 412 also allow a network administrator to execute scripted actions when a rule is triggered. In the example above, the administrator might want the port switched off or reset if the error occurs, and using an appropriate rule can save the administrator from having to perform the action. Using rules like this can dramatically reduce the time and complexity of managing a computer network, such as computer network 300. In response to the result of a poll of the managed computer network element, event engine 418 determines the current state of the element component for the poll event. Next event engine 418 loops through all the rules in event rules 412 for the polling event to determine whether there is a rule that can be applied for the current state. If there is such a rule, event engine 418 uses the information returned in the result of the poll to evaluate the rule. If the rule is true, and any persistence condition is satisfied, the action specified in the rule is executed. The action specified in the rule can be one or more of: executing a system command, logging an event to alarm log 419, and changing the state of the element component for the current state. In response to a trap event from the managed computer network element, event engine 418 determines the current state of the element component that generated the trap. Next event engine 418 loops through all the rules in event rules 412 for the trap event to determine whether there is a rule that can be applied. If there is such a rule, event engine 418 evaluates the rule using data sent in the trap. If the rule is true, and any persistence condition is satisfied, the action specified in the rule is executed. The action specified in the rule can be one or more of: executing a system command, logging an event to alarm log 419, forwarding the trap event to a host, and changing the state of the element component for the current state. If there is no rule for the trap in event rules 412, event engine 418 logs the trap into alarm log 419. In one embodiment, event engine 418 can be thought of as a finite state machine that has three user-defined parameters: the managed element component states, events which trigger rule evaluation, and rules which specify what state transition or other action to perform when a given event condition is satisfied. States identify the current status of the managed element component, sometimes simply referred to as component. Events are polling or trap events which a component may experience. Rules are if-then type statements whose condition (if-part) is evaluated each time the corresponding event takes place and whose action (then-part) is executed if the condition is satisfied. FIG. 5C depicts the relationship between the three parameters. States s1, s2, s3, and s4 are the states that the component can possibly have. Polling events p1, p2, and p3 are user defined. Polling event p1 is performed in either states s1 or s2. Polling event p2 is performed only if the component is in state s3, and polling event p3 is performed only if the component is in state s4. Here, a polling event is performed by polling the component. The user can specify, using client 391, different polling intervals for polling event p1 in states s1 and s2. Polling event rules p1r1, p1r2, and p1r3 are user-configured rules for polling event p1. Polling event rule p1r1 is picked to evaluate the polling result of polling event p1 when the component is in state s1, i.e., polling event rule p1r1 has a requisite state of state s1. Polling event rules p1r2 and p1r3 are used to evaluate the polling result when the component is in state s2. If the condition of polling event rule p1r2 is evaluated true, the component transitions from state s2 to state s3. Hence, since polling event rule p1r3 is evaluated only when the component is in state s2, polling event rule p1r3 is not evaluated. Polling event rules p2r1 and p3r1 are rules defined for polling events p2 and p3 respectively. It is also possible to define more than one polling event for one particular state. For each polling event defined, there are associated rules for that state. So depending on the polling interval and polling result, different rules can be applied. As explained more completely below, event rule engine 418 works in a similar same way for trap events except traps can appear when the component is in any state. After alarm factory 515 is created, alarm factory 515 loads an existing alarm log for each managed element object, e.g., alarm logs 419 and 429. Alarm factory 515 also passes handles to the element alarms in each managed element object, e.g., element alarms 413 and 423. Element alarms 413 and 423 contain the alarms for the managed element. Each alarm has a unique identification. A user can view the alarm logs through client 391. The user can view the alarms for all managed computer network elements, for a group of managed computer network elements, for a specific computer network element, or, for a component of a specific computer network element. When an alarm is received, button Alarms 312B on client GUI 376 is activated, and if the alarm is associated with a particular component, the appearance of the component may be changed in response to the alarm. Trap server 403 receives all traps from other hosts on network 300. If a received trap is from one of the managed elements, e.g., element 320, represented by the plurality of managed element objects 415, Trap server 403 copies the data in the trap to a buffer, and notifies the event engine, e.g., event engine 418 for the managed element that generated the trap. Event engine 418 processes the trap data as described above. As explained more completely, a user can specify the rules for each trap event and each polling event. Through definition of the polling and trap events and the set of rules, an accurate picture of extraordinary element behavior can be constructed automatically, and advance problem analysis can be performed automatically. According to the principles of this invention, a filtering mechanism allows definition of which traps managed element server 314 should acknowledge. All other traps are ignored. Notice that the portion of managed element server 314 described above is independent of any graphic user interface. The logic and structure of manager 404 of managed element server 314 is cleanly separated from the graphic user interfaces described more completely below. Further, in one embodiment, the portion of managed element server 314 preferably is written in a computer language, such as the JAVA computer language that is platform independent. Consequently, managed element server 314 can be executed on any platform that is JAVA enabled independent from the type of platform. This greatly simplifies the generation of the managed element server 314, because it is unnecessary to port managed element server 314 to each type of computer platform that could be conceivably found on computer network 300. Managed element server 314 also interacts with managed element clients such as managed element server client 391 on portable personal computer 390, managed element server client 361 on personal computer 360, and managed element server client 371 on workstation 370. Multiple managed element clients can connect to managed element server 314, and can view and manipulate the plurality of managed element-objects 415. Each of managed element server clients 361, 371 and 391 provides a graphic user-interface 375. In one embodiment, the managed element server client is implemented as a JAVA applet and is running inside a World-Wide Web Browser or a JAVA Applet Viewer. The JAVA applet is downloaded from managed element server 314. The JAVA applet includes the structures described more completely below. Briefly, the applet includes information that allows a user a) to monitor the operation of each of the managed computer network elements, b) to edit the event management for the managed computer network elements by reconfiguring the event management model in the element manager object for the network element, and c) in one embodiment, to build and edit element managers using a visual element manager builder 406. To run a managed element server client, sometimes simply called a client, a user must have a valid user name and password on managed element server 314. In this embodiment, clients 361, 371, and 391 communicate with managed element server 314 through JAVA remote method invocations (JAVA RMI). Clients 361, 371, and 391 send requests and receive synchronous responses by invoking remote methods on managed element server 314, and server 314 sends asynchronous notifications to clients 361, 371, and 391 by invoking remote methods on clients 361, 371, 391. The operation of RMI is known to those of skill in the art and so is not described in detail herein. In this embodiment, the client processes are computer platform independent. This means that the client process can be executed independent of the particular processor and operating system in the computer on which the client is executed. In general, it is desirable to have most of the client process platform independent, because this minimizes any platform specific code that must be written to support execution of the client process on a particular computer platform. This also facilitates downloading the client process from server 314. FIGS. 6A and 6B illustrate other specific instances of the client graphic user interface 600A and 600B, respectively. The various areas 601 to 604 are the same in both instances, but the information displayed in a particular area is determined by the managed computer network element selected as well as the specific information concerning the managed computer network element of interest. In general, header area 601 displays a NetPrism logo 610, persistent buttons 312 and context-sensitive information. When the computer network element displayed in element image area 602 is managed by managed element server 314, i.e., has a managed element object in server 314, header area 601 also contains a severity legend 311. Severity legend 311 shows the current state of the managed element, if only the managed element has been selected. The primary purpose of severity legend 311 is to visually identify the current level of criticality associated with the managed element or one of its components. In this embodiment, there are six severity levels supplied by managed element server 314. Each severity level has a name, description, priority, color, and blinking speed. The last two attributes specify how a component appears when the component enters a state with the associated severity level. In this embodiment, the severity level attributes cannot be edited. This restriction prevents conflicts between different vendors since severity levels apply to all managed computer network elements. TABLE 3 lists one embodiment of the severity levels and the attributes of each level. The definitions in TABLE 3 are illustrative only and are not intended to limit the invention to the particular definitions presented. In view of this disclosure, those of skill in the art can define severity levels that are used in a particular management situation.
TABLE 3
SEVERITY LEVEL DEFINITIONS
PRI-
REF. OR- BLINK
NO. NAME ITY COLOR SPEED DESCRIPTION
311A FatalErr 1 Red Fast Complete loss of
functionality
311B Critical 2 Orange Fast Severe problem
experienced
311C Warning 3 Yellow Slow Potential problem
311D Normal 4 Green None Operations as expected
311E Unknown 5 Gray None Operational performance
unknown
311F Disabled 6 Blue None Administratively disabled
Persistent buttons 312 includes a logout button 312A, an alarms button 312B, a MIB browser button 312C, and a help button 312D. Persistent buttons 312 are constantly displayed in header area 601. The user activates, i.e., clicks on, logout button 312A to logout from managed element server 314. When a user logs out, all element managers, managed elements, and their attributes are saved. In addition, managed element server 314 continues to monitor the managed elements, i.e. event processing and rule evaluation continues. This ensures that the next time the user logs on and initiates a client process, component status and alarm history are current. When the user activates button Alarms 312B, an alarm history log of all managed computer network elements in network 300 is displayed in work area 603. The selection of particular alarms is described more completely below. In this embodiment, the network management protocol is SNMP, and so network management data are MIBs. Recall as described above, SNMP-capable computer network elements may be detected by discovery engine 401, but discovery engine 401 may be unable to associate an element manager with a computer network element. In such a case, a user may activate button MIB Browser 312C to manage the element. Upon clicking on button MIB Browser 312C, a MIB browser, e.g., general database browser 405, is launched. The MIB browser uses another graphical user interface that is described more completely below. The MIB browser allows the user to view a MIB Tree and to get and set MIB variables assuming that the permissions allow the user to perform such operations. The MIB browser is also useful for determining instance numbers for MIB variables. Hence, if no element manager exists for a SNMP-capable computer network element, the current invention still permits the user to manually perform some basic network configuration with the MIB browser. To access on-line help, the user activates button Help 312D. In one embodiment, on-line help is available in Adobe PDF format and in stand-alone HyperText Mark-up Language (HTML) format. Element image area 602 is an area which is reserved to display a computer network element image which is an image chosen to represent the selected managed computer network element. As explained more completely below, components of a computer network element that are used in management of the computer network element are called hotspots. During management of the computer network element, the appearance of the hotspot provides element status information, e.g., the color of the hotspot is changed to show the state, severity level, of the component. In FIG. 6B, CPU Usage 633, and Cache Memory 634 are embedded graph hotspots. Thus, status information 633 and 634, in the form of graphs, is provided in element image area 602. Navigation tree area 604, in this embodiment, displays a navigation tree 305 that is an object-oriented hierarchical representation of objects which represent (i) element managers and their attributes and (ii) managed elements and their attributes. Two alternative embodiments of managed element server 314 are possible. A first embodiment includes visual element manager builder 406, and a second embodiment does not include visual element manager builder 406. If visual element manager builder 406 is not included in server 314, element manager folder 641 is not displayed in navigation tree 305. Root 640 of navigation tree 305 represents managed element server 314, and its name may be configured in a configuration file, that is described more completely below. Each distinct element attribute is represented by a separate node in tree 305. Attributes are either properties of the real physical computer network element or protocols indicating how the computer network element will be/may be managed. As explained more completely below, attributes may be accessed and modified through navigation tree 305. Similar attributes are grouped together in folders, and some folders may also be attributes in themselves. The hierarchical structure of tree 305 parallels the "is an attribute of" relationships of the real element. FIG. 6C is an illustration of a standard navigation tree 305. Folders, e.g., folders 641 and 642, are containers for other folders or attributes. A user expands or collapses a folder by clicking on the plus sign, or minus sign associated with the folder. In FIG. 6C, the user clicked on the plus sign(not shown) for element manager folder 641 and so folder 641 was expanded to obtain the structure shown. Managed element server 314 distinguishes between two types of folders, those which are created by server 314 and serve solely as containers, and those which serve as both a container AND an attribute. The former type is visually identifiable by the presence of a folder outline in its icon and is referred to as a specialized folder, e.g., folders 660 to 661. Specialized folders contain objects of the same type. The latter type does not have a folder outline in its icon and is simply referred to as a standard folder, e.g., standard folders 650, 651, 652. These folders represent a single object, but the single object may contain many different types of objects. Clicking on any folder displays the contents of the folder in work area 603. Double-clicking on a standard folder opens the folder and displays a panel containing the parameters of its attributes in work area 603. Double-clicking on a specialized folder just toggles the folder between open and closed. Thus, in navigation tree 605, element mangers, managed elements, specific hotspot attributes, specific states, specific polling events, specific traps and specific rules are each represented by a non-folder icon. While the collection of element manager, the collection of managed elements, the collection of hotspot attributes, the collection of hotspot states, the collection of hotspot polling events, the collection of hotspot trap events, and the collections of rules are each represented by a folder icon that contains the collection. Attributes, as used here, are similar to files in graphical file systems in that they contain information pertaining to the named attribute which can be displayed by double-clicking on the attribute node. Managed element server 314 supports the following computer network element attribute types: (i) element hotspots representing (a) components, e.g., ports, LEDs, jacks, meters, connectors, switches, etc., (b) action buttons, and (c) embedded graphs; (ii) MIB variables associated with the element hotspots and the variable' static attributes, e.g., type, access, etc.; (iii) states which visually identify the criticality of an element hotspot's current condition; (iv) polling and trap events associated with the element hotspot; and (v) rules associated with events which cause a element hotspot state change or other action to take place when a specified criteria is satisfied. Clicking on a pure attribute node of navigation tree 305 has no effect. Double-clicking on the node displays a panel containing the parameters of the attribute in work area 603. If the selected folder or attribute is associated with a computer network element, an image representing the physical computer network element is displayed in element image area 602. Work area 603 is equivalent to a dialog box of a world-wide-web browser. In other words, this is the primary area that the user utilizes to enter any information. All information related to a node is displayed in this area in logical units called panels. Whenever a folder type, standard or special, in navigation tree 305 is selected, a panel containing a list of the items in the folder is displayed in work area 603. Whenever a user double-clicks on a node of navigation tree 305 which has associated attributes, a panel containing the parameters of the attribute is displayed in work area 603. In this example, graphic user interface 600A (FIG. 6A) is displayed by client 391 on portable PC 390. The user is checking the status of the number of hits on server 380, that in this embodiment is a Netscape Enterprise server Pop-up graph 631 shows the number of page hits the site is receiving. Table 632 shows more detailed information about the server processes. Graphic user interface 600B (FIG. 6B) also is displayed by client 391 on portable PC 390. The user is checking the status of CPU and memory usage of WINDOWS NT workstation, e.g., workstation 320. Graphs 633 and 634 in area 602 show CPU and memory utilization, respectively. Table 635 contains detailed information about the memory installed on the workstation. Element managers make configuration of management-enabled computer network elements simple. Since managed element server 314 includes a visual element manger builder 406, any computer network element manufacturer can easily build an element manager that results in optimal management of the computer network element. Alternatively, an administrator can build an element manager for a computer network element remotely through client 391 by selecting components in for element manger, and defining characteristics of those components in their associated attribute tables. As explained more completely below, in one embodiment, there are four possible types of managed element components, an active component, a LED component, an embedded graph component, and an action button. The attribute table contains descriptions of each attribute of the component, saving the user from having to understand the complexities for the managed computer element's MIB. The attribute table also contains management information, for example, whether the MIB is being polled, and what the current value is. For more advanced configurations, full access to GET and SET variables in the managed computer network element's MIB tree is allowed. As described above the client-server network management system of this invention features a three tiered client-server architecture 700. Architecture 700 includes a plurality of clients 702, managed element server 314, and managed elements 701. In the embodiment, where server 314 is implemented using a platform independent language such as the JAVA programming language, the JAVA RMI is used for communications between clients in plurality of clients 702 and server 314. Also, as indicated above, in this embodiment, network 300 uses TCP/IP and the network management protocol is SNMP. This embodiment is used through the remainder of the disclosure. However, the utilization of a particular programming language, network protocol, and network management protocol is illustrative only and is not intended to limit the invention to this particular embodiment. In view of this language, those of skill in the art can implement the invention in a wide variety of ways. Managed element server 314 is a GUI-less component that manages a domain of SNMP devices, i.e., a plurality of managed elements 701. Each managed computer network element, sometimes called a managed element, s represented by a managed element object. Managed element objects are persistent and kept in a server database 705 on a non-volatile storage system 710. Server database 705 is implemented using JAVA serialization. As described above, multiple clients can connect to managed element server 314 and view and manipulate managed element objects. As indicated above, server 314 is written in the JAVA programming language, with only a small portion of the native code written in the C programming language. In one embodiment, server 314 is running on a WINDOWS NT, Version 4.0 platform. In another embodiment, server 314 runs on a Sun SOLARIS platform. In this embodiment of architecture 700, a HTTP server 714 is required to provide an initial bootstrap HTML page to the World-Wide-Web browser that supports client 391. Once this page is loaded, the JAVA applet embedded in the page communicates directly with server 714. After the initial page is loaded, HTTP server 714 is only used to download JAVA classes and image files to client 391. Managed elements 701 are SNMP-enabled devices which are managed by server 314. Typical managed elements 701 include hubs, routers, switches, bridges, and work stations. In general, a managed element can be any hardware of software entity that implements SNMP protocol, e.g., printers, applications, etc. The system requirements for running managed element server 314 in one embodiment are: Microsoft WINDOWS Environment Server 314 Pentium 166 MHz, Pentium Pro 200 recommended 32 MB RAM minimum, 64 MB recommended Hard disk with at least 100 MB free hard disk space WINDOWS NT 4.0 Operating System JDK 1.1.3 or higher runtime environment Any HTTP web server Client 391 Pentium 166 MHz or higher PC 32 MB RAM minimum 800.times.600 or higher resolution monitor WINDOWS 95 or NT 4.0 JDK 1.1.3 or higher Appletviewer Sun SOLARIS Environment Server 314 Sparc 5 or higher workstation 32 MB RAM minimum Hard disk with at least 200 MB free hard disk space SOLARIS 2.5 Operating System JDK 1.1.3 or higher runtime environment Any HTTP web server Client 391 Sparc 5 or higher workstation 32 MB RAM minimum SOLARIS 2.5 Operating System JDK 1.1.3 or higher Appletviewer Element Managers Element manager 800 (FIG. 8), which is representative of each element manager in the plurality of element managers 315, typically is stored in a memory 890 of computer 310. As explained above, when element manager 800 is associated with a specific computer network element, element manager 800 is used in generating a managed element object that in turn executes on manager 404 (FIG. 4) of managed element server 314. Hence, effectively, element manger 800 is executed on manager 404. Element manager 800 (FIG. 8) is a standardized, cross-vendor structure that can be built using visual element manager builder 406(FIG. 4), as described more completely below, to support any computer network element that can be managed using the network management protocol. Element manager 800 is an abstract representation of the managed computer network element that when executed on manager 404 of managed element server 314 manages and monitors the managed computer network element associated with element manager 800. The information stored in element manager 800 is divided into two categories, basic information 801 and event management information 802. Basic information 801 includes (i) visual display information 810 that is used to provide a user with a visual display of the managed computer network element in element image area 602, (ii) hotspots of the managed computer network element, and (iii) attributes of each hot spot. Visual display information 810 includes a combination of components representing the features of the managed computer network element that may be used in management of network 300. In this embodiment, the components include: (i) active components, such as ports, jacks, meters, or connectors; (ii) indicator components, such as LEDs: (iii) command buttons such as off/on switches, or reset switches; and (iv) embedded graphs for the managed computer network element. As explained above, the components of the computer network element, that are actually utilized in the management of the element, are referred to as hotspots. Typically, there is one hotspot per component, but if necessary, more than one hotspot can be defined for a component. The important aspect is that a hotspot is defined for each characteristic of the managed element that is used in computer network management. Attributes, that define and characterize each hotspot, are also stored as a part of element manager 800. A user can click on components in the computer network element image to see attributes which can be monitored. For example, when managing a hub, element manager contains a picture of the front panel of the hub that is displayed in element area 602. Clicking on a port on the hub shows attributes of that port which can be monitored, for example, the number of packet collisions. Event management information 802 of element manager 800 includes an event management model for the managed element. As explained more completely below, one feature of this invention provides the user with a series of GUI panels, called a wizard, to define the operations that are performed by the event management model. Based upon the information that is provided by the user, an event management model is constructed and stored as a part of element manager 800. Briefly, using this invention, the user builds an event management model that proactively and automatically detects over time specified network conditions and takes automated actions in response thereto. In one embodiment, as described above, the event management model is a set of rules associated with a managed computer network element which causes specified actions to take place when a specified criterion is satisfied. A rule is evaluated upon occurrence of a predefined polling event or trap event for the managed computer network element. A typical criterion is testing whether a network management variable value has exceeded some threshold value. The specified actions can include, for example changing a component's state, executing a server operating system command, forwarding a trap to another host, and/or logging pertinent information. The severity associated with a element component's state is visually highlighted in the visual display of the managed element, and a visual cue notifies the user whenever information is logged. By carefully defining the polling and trap events and the set of rules, an accurate picture is constructed of extraordinary element behavior and advanced problem analysis is automatically performed to aid in common network management strategies including configuration management, fault management, and performance management. In this embodiment, as described above, the management model can be thought of as a finite state machine. The management model has three user-defined parameters: the component states, events which trigger rule evaluation; and rules which specify what state transition or other action to perform when a given rule condition is satisfied. The component states identify the status of the component. Events are polling or trap events which a component may experience. Rules, in this embodiment, are if-then type statements whose condition (if-part) is evaluated each time the corresponding event takes. Building an Element Manager In one embodiment, managed element server 314 includes a visual element manager builder 406. Visual element manager builder 406 is a standardized visual environment which gives the user the ability to easily build an element manager which, as described above, provides an abstract model of a real physical computer network element and management information for that element. In this embodiment, the managed computer network elements are limited to SNMP-capable host systems such as workstations and terminal servers, router systems, and media devices such as printers, hubs, bridges, and repeaters. Components may include jacks, ports, meters, switches, connectors, LEDs, etc., to name a few. Visual element management builder 406 runs on any platform on network 300 which supports a World-Wide-Web browser that in turn supports JAVA Development Kit (JDK), Version 1.1.1 or higher of Sun Microsystems. Preferably, either an applet viewer or Sun Microsystems' HOTJAVA browser are used. (HOTJAVA is a trademark of Sun Microsystems, Inc. of Palo Alto, Calif.) However, any World-Wide Web browser that reliably supports JDK Version 1.1.1 or higher may be used. Visual element management builder 406 gives the user the ability to build element managers with characteristics such as: an image to represent the physical computer network element; logical component hotspots of the element, e.g., the device itself, ports, LEDs, used to monitor MIB variables; action button hotspots used to set MIB variable value(s) when the button is pressed; embedded graph hotspots used to display the value of MIB variable(s) over time; rule-based event management models for any hotspotted component; alarm conditions, alarm logging text, and alarm representation attributes; and a wizard mode which guides the user through any multi-step process such as building a basic element manager. The user does not need any ability to write computer code, but rather only the ability to answer the questions presented by builder 406. Once an element manager is created using visual element management builder 406, a user can test and verify the element manager's accuracy using managed element server 314. After the element manager has been fully tested, a device manufacturer can distribute managed element server 314 and the element manager along with the device to customers of the device manufacturer. The customers can use server 314 and the element manager to monitor/manage the device, or to customize and further refine the network management strategy built into the element manger. Visual element management builder 406, which is implemented via a client process and server 314, is unique in its feature set, and unique in that is employed through a World-Wide-Web browser as a JAVA applet. As such, visual element management builder 406 inevitably has a different look than the every-day word processing and spreadsheet-type applications which are known so well. Visual element management builder 406 preserves as much behavior of common well-known applications as possible. However, visual element management builder 406 also introduces a new look which is described more completely below. In this embodiment, the GUI layout for visual element management builder 406 is similar to the GUI layout displayed in FIGS. 6A and 6B. Recall that element managers include information that falls into two categories. Basic information 801 defines the core properties of the computer network element, including image 810 representing the computer network element, hotspots 811 of the computer network element, and MIB variables 812 associated with each hotspot. Event management information 802 defines how the computer network element is dynamically managed, and is defined by a rule-based event management model of the computer network element. The process of building an element manager is a two step process. In the first step, as described more completely below, basic information 801, i.e., a core description of the computer network element is built by having the user sequentially answer questions about the computer network element. In the second step, the user again answers questions to build event management information 802. Visual element management builder 406 makes creating an element manager easy by using wizard panels, which guide a user through a set of steps required to build the element manager. Initially, the user invokes visual element management builder 406. To do this the user must first log onto managed element server 314 via a client process as described above. The client communicates with server 314 using JAVA RMI (FIG. 7). After logging in the user is presented with a GUI that is similar to those in FIGS. 3B, 6A and 6B. Any time after logging in, the user clicks on element managers folder 641 in navigation tree 305 (FIG. 6C) to initiate building of an element manager. See FIGS. 6A, 6B, and 6C. In response to the user selecting element managers folder 641, element managers folder 641 is highlighted in navigation tree 305. In addition, a panel, such as panel 900 (FIG. 9A) is displayed in work area 603. (Herein, the terms highlight and select both refer to the action of clicking the left-most computer mouse button, but highlight indicates that after the action of clicking, the item clicked on is highlighted) Title 901, "Element Managers List" indicates to the user the type of information displayed in panel 900. A name and description 902 of each object at the next hierarchical level within element managers folder 641 is listed in panel 900. A set of command buttons 903 are also displayed. Using panel 900 and in particular command buttons 903, the user can add an element manager, edit an existing element manager, copy an element manager, remove an element manager, or export an element manager. Thus, to build a new element manager, the user activates button Add 903A. Typically, to activate a command button, or a button in general, the user clicks on the button, or when the button has a frame around it, as button Add 903A does, the user can simply press the enter key on the user's keyboard. Upon activating button Add 903A, wizard panel 910 (FIG. 9B) is presented in work area 603. A wizard panel is visually characterized by a plurality of command buttons 904. The plurality of command buttons 904 is presented on each wizard panel. The plurality of command buttons are a plurality of edit command buttons. Button <<Back 904A is disabled on the first panel of a wizard sequence. Button Next>> 904B is disabled on the last panel of the wizard sequence. Button Exit 904C changes to a button Finish 904E on the last panel of the wizard sequence. Activating button Exit 904C saves incomplete work and exits visual element management builder 406. Activating button Cancel 904D exits visual element management builder 406 without saving incomplete work. Title 911, "Describe the Element Manager" indicates to the user what information is to be entered via panel 910. Panel 910 ask for three pieces of information: an element manager name 912; a description of the element manager 913; and a background image 914. The user enters a name for the new element manager in element manager name text field 918. Typically, the name should be the same as the name of the physical computer network element. The name appears in navigation tree 305 after the element manager has been created. The name may contain spaces if the computer operating system supports spaces in file names. The name is case sensitive if the computer operating system is case sensitive. (The computer operating system is the computer operating system on the computer on which managed element server 314 runs.) The name must be unique and care must be taken to choose a specific enough name to minimize the chance of a name clash with an element manager created by another vendor. Entry of a description of the element manager in description text field 917 is optional. The description is displayed in the element mangers list that is displayed in work area 603. See FIG. 9A. Background image 914 is the visual display image that is presented in element image area 602. Initially, the default background image <None> is displayed in field 915. The user selects an appropriate background image for the computer network element by activating button 916. Activation of button 916 displays a drop-down list (not shown) that lists each of the image files stored in a first predefined directory on a non-volatile storage system of computer 310, e.g., a directory with a path netprism.backslash.users.backslash.images. In one embodiment, only GIF and JPEG image file formats are supported. An example of a background image 960 for a Fujitsu hub is presented in FIG. 9C. If the image of the computer network element is not important, a dummy blank image can be used. The background image need not be elaborate so long as the image depicts the location and markings of each component that is used in computer network management. Viewing the background image is easier if the dimensions of the image are small enough to fit in element image area 602 without scrolling. FIG. 9D is an example of the GUI after the information has been entered in fields of panel 910. The information in header area 601 and element image area 602 is displayed in each subsequent panel of visual element management builder 406, and so only the information that changes is described below. After the user has completed describe new element manager operation 1001(FIG. 10) by completing panel 910, the user activates button Next>> 904B to proceed to next wizard panel 1110 (FIG. 11) and to select MIB definition files operation 1003 (FIG. 10). Again wizard panel 1110 (FIG. 11) is displayed in work area 603, as is each of the wizard panels, and so this aspect of the invention is not pointed out again in the following description. Title 1111, "Select the MIB Files to Use With the Manager," tells the users the action that is to be completed with panel 1110. Panel 1111 has two list boxes 1114 and 1117. Each of list boxes 1114 and 1117 has a heading, headings 1112 and 1113, respectively, that describes the information displayed in the respective list box. In selectable MIB files list box 1114, a list of MIB files 1112 is displayed. The MIB files in the list are those stored in a second predefined directory on non-volatile storage system of computer 310, e.g., a directory with a path netprism.backslash.users.backslash.mib. All MIB-II and MIB-I definition files are supported and must be placed in the second predefined directory prior to starting to build the new element manager. MIB definition files can be obtained from the vendor of the computer network element. The user highlights the MIB definition file(s) in the MIB Files list which contain MIB variables that the user wants to associate with the computer network element or any of the components of the computer network element. After the user highlights one or more MIB files, button Move>> 1115 is enabled. The user activates button Move>> 1115 to copy the names of highlighted file or files to manager MIB files list box 1117. This places a pointer to the files in the new element manager. Upon completion of selection MIB definition files operation 1003, the user activates button Next>> 904B to proceed to the next wizard panel 1210 (FIG. 12A) and specify hotspots operation 1004. Wizard panel 1210, a hotspot definition panel, is part of a GUI that has the background image in element image area 602 and hotspot definition panel 1210 in work area 603. In addition, a hotspot editor 1250 (FIG. 12B) is displayed in header area 601 of the GUI. The user defines a hotspot in define hotspot operation 1301 by clicking and dragging the mouse in the element image to draw an outline around a component. This operation is not illustrated in the drawings, because the operation is similar to those commonly performed in computer drawing programs, and so an illustration is not required for one of skill to understand what is required to define a hotspot. As explained above, there are four types of hotspots, i.e., active component, LED indicator, button, and embedded graph hotspots. Active component hotspots are used to visually identify a logical component of the network computer element and the current state of the logical component when the computer network element is managed. Similarly, LED indicator hotspots are used to visually identify an LED and its current state when the computer network element is managed. Button hotspots are used to set a MIB variable with a single button action during computer network element management, and graph hotspots are used to graph a MIB variable value over time during computer network element management. Each hotspot may have any number of MIB variables associated with the hot spot. To associate MIB variables with the computer network element itself, a symbolic component outline (hotspot) is drawn to represent the computer network element. For example, the symbolic component outline used to define this hotspot could be drawn to surround the computer network element's logo image or be placed in some other meaningful area which will not be confused with a real component of the computer network element. Hotspot outlines should not be contained within one another or else it may not be possible to differentiate between the resulting hotspots. The hotspot can be moved and/or resized using standard moving and resizing methods with the mouse. Alternatively, precise pixel values can be entered in geometry field 1215. Specifically, the x and y coordinates and the height and width of the component can be entered. A hotspot can be removed by selecting the hotspot and clicking scissors icon 1251 in toolbar 1250. After define hotspot operation 1301(FIG. 13) is completed, i.e., the outline is drawn, the user uses toolbar icons 1251 to 1258 in toolbar 1250 to change the visual characteristics, e.g., color, shape, line thickness, and fill of the outline, as desired in define hotspot visual appearance operation 1302. TABLE 4 defines the operation of each icon in toolbar 1250.
TABLE 4
Hotspot Editor Toolbar Icon Function Definition
Icon
Reference No. Function
1251 Cut
1252 Copy
1253 Paste
1254 Square Outline
1255 Circular Outline
1256 Outline Line Thickness
1257 Fill
1258 Outline Color
When a computer network element is being managed, hotspots for components which experience an exceptional event are displayed with the visual characteristics specified here. The only visual characteristic which does not carry over is the color of the outline, since the color is dependent on the severity of the event. See Table 3 above. The visual appearance of graph and button hotspots is unaffected during computer network management. In addition to geometry field 1215, panel 1210 contains a name text field 1212, a description text field 1213, and a type field 1214. Each of fields 1212 to 1214 is labeled for easy identification by the user. In name operation 1303, the user enters a name for the hotspot in name text field 1212. Preferably, the name entered is the same as the name of the physical component which the hotspot represents or some other meaningful name so that a user of the element manager can immediately associate the name with the correct component in element image area 602. The hotspot name must be unique for the computer network element. The user enters a description of the hotspot in description text field 1213 to complete description operation 1304. The user selects the hotspot type in specify type operation 1305. Specifically, the user activates button 1216 and a drop-down list is displayed of the permissible hotspot types, which, as described above, are active component, LED indicator, button, and graph. The user selects one of the four types and that type appears in type field 1214. After name operation 1303 and specify type operation 1304 both are completed, checks 1306 and 1307 are made to determine whether a button hotspot, or a graph hotspot was specified. If a button hotspot was specified, a wizard hotspot properties panel 1400 (FIG. 14A) is displayed in work area 603. If a graph hotspot was specified, a wizard hotspot properties panel (FIG. 14B) is displayed in work area 603. If neither a button hotspot nor a graph hotspot was specified, processing fall through checks 1306 and 1307 to additional hotspot check 1308 that is described below. In wizard hotspot properties panel 1400, the name of the selected button hotspot appears in hotspot field 1410. The user can change the selected hotspot by activating pull down menu button 1411 which in turn results in the display of a menu of the name of each button and graph hotspot that has been previously defined. This allows the user to edit information that was previously entered as well as provide information for the button currently selected. In label operation 1320, the users enters in button label text field 1412, a label as it is to appear on the button. In style operation 1321, the user selects one of a normal and a transparent style for the button hotspot by activating drop-down list button 1414 and then selecting one of the two styles from the menu. A normal style specifies that the button should appear as a standard button. A transparent style specifies that the button should appear as an outline only. Typically, the transparent style is used when the underlying image of the hotspot is already the image of a button. In this embodiment style operation 1321 transfers to additional hotspots check 1308. In wizard hotspot properties panel 1450, the name of the selected graph hotspot appears in hotspot field 1410. Again, the user can change the selected hotspot by activating pull down menu button 1411 which in turn results in the display of a menu of the name of each button and graph hotspot that has been previously defined. This allows the user to edit information that was previously entered as well as provide information for the graph currently selected. In title operation 1330, the users enters a title as it is to appear on the graph in graph title text field 1452. In style operation 1321, the user selects one of a 2-D graph and a 3-D graph by activating drop-down list button 1452 and then selecting one of the two styles from the menu. During computer network element management, 2-D graphs appear flat, and 3-D graphs have shadow markings which make them appear 3-D. The user checks show legend check box 1453 in legend operation 1332 to have a legend for the graph appear automatically when the graph is displayed. The legend can take up a significant amount of storage space. If only a single MIB variable is graphed, preferably the MIB variable is identified in the graph title and the legend is not turned on. If the graph uses more than one MIB variable, the legend is preferred. In time span displayed field 1454, the user enters a time window that specifies how many seconds to display at any given instance in the graph. As new values of the MIB variable are received via polling, the time window slides in time so that the most recently received values are displayed. Similarly in polling field 1455, the user enters the polling interval in seconds for updating the values of the MIB variable(s) displayed in the graph. Entry of the time window completes time window operation 1333, and entry of the polling interval completes operation 1334, and so processing transfers to additional hotspot check 1308. If the user has entered all the hotspots for the computer network element, the user presses button NEXT>> 904B to proceed to hot spot MIB variables wizard panel and so processing transfer from check 1308 to associate MIB variables with hotspot operation 1005. Conversely, if there are additional hotspots for the computer network element, the user returns to define hotspot operation 1301 and outlines another hotspot and then repeats operations 1301 to 1307, 1320, 1321 and 1330 to 1334, as appropriate. Instead of drawing a new outline in define hotspot 1301, a user can copy an existing hotspot outline. When a hotspot outline is copied, visual characteristics as well as the other information associated with the existing hotspot outline is copied. The name of the copy is the original name with an index number appended to the end of the original name. The index number starts at one, or the next highest number if the name already ends in a number, and increments by one each time the copy is pasted. The sequence of operations illustrated in FIG. 13 is illustrative only and is not intended to limit the invention to the particular sequence of operations shown. The importance aspect is to specify the hotspot by having the user input the information described in the sequence of operation. For example, check 1308 could be positioned after specify type operation 1305. In this embodiment, all of the hotspots would be defined and then one of the button or graph hotspots selected. In this case, checks 1306 and 1307 would be performed for each button hotspot and graph hotspot after all the hotspots were defined. In associate MIB variables with hotspot operation 1005, select the variables with the hotspot wizard panel 1500 is used. Title 1501, Select the Variable(s) with Each Hotspot, identifies panel 1500 for the user. The user selects a hotspot by activating pull down menu button 1502 which in turn results in the display of a menu of the names of hotspots previously defined. The user selects one of the hotspots and the name of that hotspot is displayed in hotspot field 1503. Similarly, the user selects a MIB file by activating pull down menu button 1504 which in turn results in the display of a menu of the MIB files, i.e., folders, previously selected for use with this element manager. The folders are a virtual representation of SNMP MIB branch objects. The user selects the MIB file which contains a variable or variables associated with the selected hotspot. The MIB file is displayed in selectable variables list box 1506. The user then opens the folder or folders in selectable variables list box 1506 until the desired MIB variable(s) is/are visible. When a user highlights one of the MIB variables in selectable variables list box 1506, button ADD>> 1507 is enabled. When the user clicks on button ADD>> 1507, the highlighted MIB variable is copied to hotspot variables list box 1509 as a selected MIB variable. Both single-valued MIBs and aggregate-valued MIBs, such as tables, with any access mode may be selected for active component and LED hotspots. For graph hotspots, only single-valued MIB variables which have read access may be selected. For button hotspots, only single-valued MIB variables which have write access may be selected. The selection of files and variables can be repeated for a selected hotspot until all the MIB variables are displayed in hotspot variables list boxes 1509. After all of the MIB variables needed to manage the hotspot are selected, the user selects another hotspot and repeats the process described above for panel 1500. When all the hotspots are processed, the user presses button NEXT>> 904B and proceeds from associate MIB variables with hotspots operation 1005 (FIG. 10) to hotspot variables' attributes wizard panel 1600 in modify MIB variable attributes operation 1006. As with the other wizard panels, hotspot variables' attributes wizard panel 1600 has a title 1601, Enter the Attributes of Each Hotspot's Variable, that identifies panel 1600 to the user. The currently selected hotspot is shown in hotspot field 1603. To change the currently selected hotspot, the user can activate drop-down list button 1602 and select another hotspot from those listed in the drop-down list. The MIB variables selected in operation 1005 for the currently selected hotspot are listed in attribute list box 1604. Attribute list box 1604 displays a table having six columns: Attribute, MIB variable, Instance, Access Mode, Type, and Description. The user can modify the data in the cells in the Attribute and Description columns of the table. By default, in a particular row of the table, the Attribute name is the same as the MIB variable name. The Attribute name can be changed to a more meaningful name. The Attribute name must be unique for the hotspot. The description in the Description column is that which was provided for the MIB variable in the MIB definition file. The other cells in the table, with the exception of those in those in the Instance column, are read-only and represent attributes of the MIB variable as defined in the MIB definition file. These attributes include Access Mode and Type. Attribute Access Mode specifies whether the MIB variable is read-only, read-write, write-only, or not-accessible. SNMP set operations are not allowed for read-only variables. The access mode is not applicable for aggregate variables such as tables since each variable in the table may have a different access mode. Other factors such as the community name may also affect access. Attribute Type specifies the MIB variable type, e.g., integer, string, etc. | ||||||