WO2000067144A1

WO2000067144A1 - Method and apparatus for defining management knowledge in a machine interpretable format and interpreting those descriptions

Info

Publication number: WO2000067144A1
Application number: PCT/US2000/010400
Authority: WO
Inventors: Thomas Soares; John Korondy; Ashwani Dhawan
Original assignee: Manage.Com
Priority date: 1999-05-04
Filing date: 2000-04-18
Publication date: 2000-11-09
Also published as: AU4358800A

Abstract

Parser/compiler (201) is responsible for reading various definition files expressed in a particular format and converting the information contained in a file into a single, object-based internal representation. Database (202) stores the objects produced by parser/compiler (201). Engine (210) takes control panel objects with all their associated wires, managed objects and control objects and causes them to run. Data collector (203) is responsible for collecting data from a network environment on a periodic basis or on demand. Scheduler (204) receives requests to execute jobs. Data listener (205) is responsible for receiving data sent by external sources. Peer manager server (206) receives events from engine (210) and forwards them to peer manager clients (207). Peer manager clients (207) typically handles interaction with user interface (UI).

Description

METHOD AND APPARATUS FOR DEFINING MANAGEMENT KNOWLEDGE IN A MACHINE INTERPRETABLE FORMAT AND INTERPRET ING THOSE DESCRIPTIONS

FIELD OF THE INVENTION

The present invention relates to the field of managing networked elements; more particularly, the present invention relates to modeling management knowledge, representing the management knowledge in a machine interpretable format, and converting the management knowledge into an internal representation for use.

BACKGROUND OF THE INVENTION

Hardware devices (e.g. routers, printers, workstations, etc.) and software

programs (e.g. database servers, web servers, etc.), which will be collectively referred to

herein as managed elements, require continual attention to ensure that they're

functioning properly. The tasks that need to be performed to ensure proper operation

of managed elements include, but are not limited to: configuration, control (e.g.,

starting and stopping), monitoring and analysis of real-time changes in the element's

state to detect performance problems, diagnosing the cause of problems, determining

what control and /or configuration actions need to be performed to repair problems,

and security monitoring (e.g., detecting whether a managed element is properly

secured and /or whether a violation of the security control on the element has

occurred). Control includes any action that changes the state of the

device /application /service, either directly or indirectly. For example, this also includes

changing thresholds, deleting files, or increasing available virtual memory. In order for users of a managed element to perform all of the necessary

management tasks, someone (typically the manufacturer of the managed element) must

supply information that explains how to do those tasks. This is referred to as

management knowledge. The party supplying management information will be

generically referred to herein as the managed element manufacturer (or simply

manufacturer), even though it may be someone other that the actual party that

physically manufactured the device.

The information, hereafter referred to as management knowledge, supplied by

the managed element manufacturer may include: descriptive information, access

mechanisms, interpretive knowledge, procedures, and management expertise.

Management expertise is also referred to herein as condition-action knowledge.

Descriptive information includes definitions of attributes of the element that describe its

state, that operations that can be performed in the element to change its state, and those

events, if any, that it can signal. Access mechanisms describe how to access the element,

including reading its attributes, performing operations on the element, and receiving

event notifications. Interpretive knowledge is knowledge needed to derive meaningful

or important information that is either not directly available from an

attribute /method /event, or requires examining the changes in values of the

attribute /methods /events over time. For example, taking the average of several

attribute values over time in order to derive the current status of a device is interpretive

knowledge. Interpretive knowledge is necessary when the raw, un-interpreted data

provided by attributes /methods /events does not provide all the needed information to

enable performance of the management tasks. Procedures describe the specific sequence of operations that need to be executed to perform individual management

tasks. For example, the sequence of operations may consist of operations necessary to

make a directory controlled by a web server read-only. Management expertise includes

knowledge that describes how, when, and under what circumstances to perform

procedures in order to ensure proper functioning of the managed element based on the

current state of the element.

Manufacturers often supply the management knowledge in a printed manual. In

such a case, the user of the managed element must read the manual, learn all of the

descriptive, access, interpretive, procedural, and management expertise contained in it,

and then manually perform management tasks as needed. This is an expensive and

time consuming process for the user.

There have been a number of prior art solutions to overcome the process of

learning the management knowledge and then manually performing management

tasks. For example, some vendors write a custom software program specifically for the

managed element, such as, for example, CiscoWorks is produced by Cisco Inc., of Santa

Clara, California, manages a range of Cisco routers. However, writing a custom

software program is expensive and resource intensive, and difficult to maintain. The

custom software program also forces the user to learn to use another application,

which, with the number of managed elements, can be very time consuming and difficult

for the user. Furthermore, the management knowledge embedded in them is not

accessible to any other management application. Also, the management knowledge is

encoded in binary format that is not easily accessible to the user without reengineering

the application and then interpreting what the source code is doing. The custom software program also forces the user to learn to use another application, which, with

the number of managed elements, can be very time consuming and difficult for the

user.

A similar approach to overcome the dependence on a manual is to write code

and /or data to add support to an existing, extendable management application. For

example, it's possible to write code modules to allow Unicenter of Computer Associates

of Islandia, New York, or OpenNue of Hewlett Packard of Palo Alto, California, to

manage the application. However, writing code to add support to an existing

management application is not portable, as the code only works with that specific

application. Therefore, the manufacturer must either do a considerable amount of work

to support all available platforms, and to maintain the code as those platforms evolve,

or they are forced to leave some users without a management mechanism.

Still another approach uses logic embedded in custom applications and "plug-

ins" for existing management applications. This logic is generally expressed in machine

instructions that are not easy for an end user to interpret. Thus, while the

application /plug-in may allow the user to configure an element, or tell the user when

the element is not performing correctly, it is not always easy for the user to understand

how /why that is the case.

Another approach is to use portable management description mechanisms, such

as Common Information Model (CIM), Simple Network Management Protocol (SNMP)

Management Information Base (MIBs), and Desktop Management Initiative (DMI)

Manage Object Format (MOFs). However, existing portable management information

modeling mechanisms allow only descriptive information to include some combination of the attributes, methods, and events supported by a managed element. The

descriptive information also includes the interpretive, procedural, and condition-action

knowledge.

Thus, what is needed is a way to manage elements without having the user rely

on manuals to learn how to manage these elements so that it is easy for the user to

understand, is portable and allows the descriptive information to include attributes,

methods and events supported by the managed element.

SUMMARY OF THE INVENTION

A method and apparatus for managing elements in a networked environment. In one embodiment, a method comprises receiving management knowledge for managed elements in a machine interpretable format to create a description for each of the managed elements, interpreting the descriptions to create an internal representation for each of the managed elements, and managing the managed elements based on the internal representation.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.

Figure 1 illustrates one process for converting management knowledge into machine interpretable format. Figure 2 illustrates one way is to simply pass all objects in the database or to

apply a set of rules that determines which objects get passed.

Figure 3 is a flow diagram of one embodiment of the process performed by an application.

Figure 4 is a flow diagram of one embodiment of a process for automatically filling in control panel references. DETAILED DESCRIPTION OF THE PRESENT INVENTION

The following specification includes copyrighted material. Applicant retains all rights in the copyrighted material included herein, but expressly allows for its copying for the purpose of copying the patent and its application.

A method and apparatus for managing elements is described. An element refers to an entity connected to the network that needs management, and may include actual physical devices, software applications running on devices, services running on devices, and/or arbitrary groups of devices, applications, and services, etc. In the following description, numerous details are set forth, such as types of elements, etc. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention can be practiced without these specific details. In other instances, well- known structures and devices are shown in block diagram form in order to avoid obscuring the present invention. 7 Some portions of the detailed descriptions which follow are presented in terms

of algorithms and symbolic representations of operations on data bits within a

computer memory. These algorithmic descriptions and representations are the means

used by those skilled in the data processing arts to most effectively convey the

substance of their work to others skilled in the art. An algorithm is here, and generally,

conceived to be a self-consistent sequence of steps leading to a desired result. The steps

are those requiring physical manipulations of physical quantities. Usually, though not

necessarily, these quantities take the form of electrical or magnetic signals capable of

being stored, transferred, combined, compared, and otherwise manipulated. It has

proven convenient at times, principally for reasons of common usage, to refer to these

signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be

associated with the appropriate physical quantities and are merely convenient labels

applied to these quantities. Unless specifically stated otherwise as apparent from the

following discussions, it is appreciated that throughout the present invention,

discussions utilizing terms such as "processing" or "computing" or "calculating" or

"determining" or "displaying" or the like, refer to the action and processes of a computer

system, or similar electronic computing device, that manipulates and transforms data

represented as physical (electronic) quantities within the computer system's registers

and memories into other data similarly represented as physical quantities within the

computer system memories or registers or other such information storage, transmission

or display devices. 8 The present invention also relates to apparatus for performing the operations

herein. This apparatus may be specially constructed for the required purposes, or it

may comprise a general purpose computer selectively activated or reconfigured by a

computer program stored in the computer. Such a computer program may be stored in

a computer readable storage medium, such as, but is not limited to, any type of disk

including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only

memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or

optical cards, or any type of media suitable for storing electronic instructions, and each

coupled to a computer system bus.

The algorithms and displays presented herein are not inherently related to any

particular computer or other apparatus, nor are they inherently related to any

particular processing device (e.g., processor, control processing unit, etc.) that may

execute instructions to perform a portion or all of each algorithm and display. Various

general purpose systems may be used with programs in accordance with the teachings

herein, or it may prove convenient to construct more specialized apparatus to perform

the required method steps. The required structure for a variety of these systems will

appear from the description below. In addition, the present invention is not described

with reference to any particular programming language. It will be appreciated that a

variety of programming languages may be used to implement the teachings of the

invention as described herein.

Overview

A mechanism to simplify the task of managing many managed elements is described. A managed element may comprise a single device, an abstract system (e.g., a messaging system a cluster of server machines, or a group of several web servers that support a web site), software applications, and services provided by those applications.

In one embodiment, the mechanism includes at least two elements: (1) a description mechanism that allows defining management knowledge in a machine interpretable format, and (2) an application for interpreting the descriptions created using the description mechanism. Both of these are described in more detail below.

Generally, in this approach, the manufacturer or other person(s), reduces the management knowledge to a machine interpretable format using the descriptive mechanism to model the management knowledge. The model is then represented in a chosen machine readable format. The data in the machine readable format can then be passed into the application, which converts it into an internal representation and uses it as described below.

In one embodiment, the description mechanism and the application provide the following characteristics and benefits. Users don't need to learn all of the knowledge required to fully manage the device/application/service/etc. The knowledge required to manage the device /application /service /etc. can be interpreted by a machine, so the user doesn't have to do everything manually. The mechanism to manage the device/application/service/etc. is portable, so that it can be used by many different management systems and the user isn't forced to use a particular system from a particular vendor; additionally, the user is able to use a single management system, instead of having to use several separate systems (which is inconvenient and requires learning to use additional applications). It includes the knowledge needed to manage a device, including interpretive, procedural, and condition-action knowledge. Without information, the user would have to acquire the remaining knowledge and do the remaining tasks manually. The management knowledge is readily understandable to a user, so that the user can know how the management system is operating, and be able to modify or extend it. It is easy for the manufacturer to create the means for managing the device, in a way that is not expensive, time consuming, and /or requires a large amount of specialized expertise. It is easy for an arbitrary management application to create a user interface that is readily understandable by a user, and allows the user to use the management knowledge embedded in the system (e.g., the user is able to view the interpreted information, cause the procedures to be executed, view the current state of the device /application /service /etc., and examine the condition-action rules).

The Description Mechanism

The description mechanism defines the process used to reduce management

knowledge to a machine interpretable format. In one embodiment, the description

mechanism is independent of the actual file format in which the description is

represented. In one embodiment, to reduce the management knowledge to a machine

readable format, a binary or text-based file format may be chosen, along with a specific

mechanism for reading and validating the file. For example, in one embodiment, the

XML file format is used, with Document Type Definition (DTDs) to specify what a

"valid" format is, and a validating XML parser to verify the validity of a file.

In one embodiment, a mechanism for supplying management knowledge in a machine interpretable format has the following features: portability, completeness, supports automation, simplicity and low cost, and is readily understandable by an end user. Portability refers to the characteristic that the information can be interpreted by more than one management application. If the information can only be interpreted by a single application, then it is useless to any user that does not own or use that application. For completeness, the mechanism allows for describing descriptive, access, interpretative procedural, condition-action, and management expertise information. If the mechanism only supports some of these, then the user is likely to perform some manual work. However, in alternative embodiments, the mechanism only supports one or more of these. The mechanism supports automation because it represents the descriptive, access, procedural, interpretive, and condition-action knowledge in a format that is machine interpretable. The mechanism is simplistic and low cost by allowing the information to be described with a minimum amount of effort, both in terms of time and money, and should be easy and inexpensive to maintain and extend.

The mechanism is readily understandable by the end user in that the management information captured by the mechanism is in a format that is easy for the end user to interpret, so the end user can understand the information that the mechanism encodes, in order to extend it, modify it, or simply know what it is doing.

Therefore, the machine interpretable mechanism describes management knowledge and has the properties of portability, completeness, simplicity, and support for automation, along with a management system that interprets those descriptions. Note that in alternative embodiments, the mechanism for describing the management knowledge in a machine interpretable format need not have all of these properties and may only have a subset of these properties.

In one embodiment, the elements of the description mechanism are specifications for defining and describing: managed elements, controls, "wires", and managed element and control groupings (e.g., "control panels").

Managed Elements & Managed Element Definitions

For each managed element for which the manufacturer (or other party) desires to

reduce management knowledge to a machine interpretable format, the manufacturer

creates a managed element definition, one exemplary embodiment of which is

described in more detail in the section entitled "Pseudo-Grammar for Managed Element

Definitions" given below. In one embodiment, a managed element definition defines a set of attributes, methods, and events that characterize or describe the device,

application, service, etc. A managed element is a specific instance of a managed element

definition that corresponds to a particular device/application/service/etc. For

example, "Apache web servers" defines a category, or class, of web servers. The

Apache web server running on port 80 of IP address 123.45.1.1 is a specific instance of

the Apache web server category. A manufacturer that wants to make a management

solution for Apache web servers would need to create a managed element definition for

Apache web servers; this definition would define the attributes, methods, and events

that are needed to describe the state of Apache web servers. The managed element that

corresponds to the Apache web server running on port 80 of IP address 123.45.1.1

adheres to the managed element definition for Apache web servers (i.e., it supports all

of the attributes, methods, and events defined in the definition), and has values for the

attributes that reflect the state of that particular web server. Additionally, the managed

element could be used to invoke methods that change the state of the particular web

server, and receive events sent by the web server.

Attributes of a managed element definition describe the state information of

relevant to the device, application, service, etc. Each managed element is an instance of

a particular managed element definition, representing a particular instance of the

device /application /service /etc. class, and has values assigned to each of its attributes;

these values reflect the current state of the particular device /application /service /etc.

that the managed element represents. The attribute values can be static or dynamic.

Methods are operations invoked on a managed element to cause the device,

application, server, etc., that the managed element represents to change state and /or perform an action that has "side-effects" that change the state of the networked

environment.

Events are periodic occurrences that are caused by some combination of the state

of the device, application, service, etc., and the state of the networked environment. In

one embodiment, events are detected by registering with an instance of the managed

element. Events can also be received by executing an arbitrary piece of code to receive

notifications. In one embodiment, the managed element that corresponds to the device,

application, service, etc., receives notification of those detected events for which

registration has been performed. In an alternative embodiment, no formal registration

is needed.

Controls & Control Definitions

Controls are objects that are defined to have zero or more attributes, methods,

and events. Controls are defined using a control definition, an exemplary embodiment

of which is described in the section entitled "Pseudo-Grammar for Control Definitions".

Attributes of a control are values that define the current state of the control and can be

changed. In one embodiment, the attributes of a control can be changed either by

external callers or internally by control logic. Methods are actions that can be invoked

on the control to change its state and /or the state of the networked environment.

Events may be aperiodic occurrences that are triggered by some condition of the state of

the control.

Examples of controls include button, simple gauge, on /off switch, status

indicator light, alphanumeric display, and dial: Button

The Button control is a simple push-button, equivalent to a mouse button or a key on the keyboard.

Event Name Parameters Description button_pushed None This event is raised when the PUSH action of the Button control is invoked

Action Name Arguments Description push None This action causes the button to be " pushed". Typically this is called in response to input from the Button's UI peer, or as the result of an event from somewhere else in the Control Panel. A BUTTON_PUSHED event will be raised, and the scπpt (if any) in the PUSH_H.ANDLER attribute will be executed (note that these happen concurrently)

Attribute Name Data Type Description push_handler Scπpt This scπpt is executed by the PUSH action of this control. If

NULL, no scπpt will be executed (but the BUTTON_PUSHED event will still be raised label String This contains text to use as the label for the button (the UI component can decide how to display it) description String This contains longer text (possibly several sentences or a short paragraph) that gives more detail about the control. This will typically be displayed only in special circumstances (i.e. in a large tool tip or in a separate help window — still to be determined)

Simple Gauge

The Simple Gauge control is a simple indicator that displays a value that typically falls somewhere in a predefined range.

Attribute Name Data Type Description current_value Number This is the value that is currently displayed in the gauge mιnιmum_value Number This is the "minimum value" of the gauge. Note that the current value may be less than this value. The minimum value is mainly used for display purposes and to determine when events need to be raised maxιmum_value Number This is the "maximum value" of the gauge. Note that the current value may be greater than this value. The maximum value is mainly used for display purposes and to determine when events need to be raised. label Stπns This contains text to use as the label for the gauge (the UI component can decide how to display it) descπption String This contains longer text tpossibly several sentences or a short paragraph) that gives more detail about the control This will typically be displayed only in special circumstances link Stπng Contains text (similar, but not identical, to a URL) that can be used to link to a new control panel or web page Typically this will be used when the user double clicks on the gauge to link the user's browser to a different location.

Event Name Parameters Description value_changed current value : Number This event is raised anytime the current value of the gauge changes The argument contains the new current value of the gauge

Moved Below Minimum Current_Value . Number This event is raised when the current value ot the gauge is updated to a value below the minimum, and the previous current value was above the minimum (i.e. the value has crossed the minimum) The Current_Value parameter contains the current value of the gauge

Moved_ Above Minimum Current_Value : Number This event is raised when the cuπent value of the gauge is updated to a value above the minimum, and the previous current value was below the minimum (i.e. the value has crossed the minimum). The Current Value parameter contains the current value of the gauge

Moved_Above Maximum Current_Value : Number This event is raised when the current value of the gauge is updated to a value above the maximum, and the previous cuπent value was below the maximum (i.e. the value has crossed above the maximum). The Current_Value parameter contains the current value of the gauge

Moved_Below Maximum Curτent_Value : Number This event is raised when the cuπent value of the gauge is updated to a value below the maximum, and the previous current value was above the maximum (i.e. the value has crossed below the maximum). The Current_Value parameter contains the current value of the gauge

Above_Maxιmum Cuπent_Value : Number This event is sent every time the current value of the gauge is updated to a value above the maximum This event will be sent in addition to a Moved_Above_Maxιmum event when applicable

Below_Mmimum Curτent_Value : Number This event is sent every time the current value of the gauge is updated to a value below the minimum This event will be sent in addition to a Moved_Below_Mιnιmum event when applicable

On/ Off Switch A two position switch can be toggled between two different positions (typically ON and OFF, but that doesn't have to be the case) which are internally referred to as the TRUE position and the FALSE position.

Event Name Parameters Description posιtιon_true <none> This event is raised whenever the position of the switch is changed to the TRUE position This event will be raised in addition to the Posιtιon_Changed event posιtιon_false <none> This event is raised whenever the position of the switch is changed to the FALSE position. This event will be raised in addition to the Posιtιon_Changed event

Action Name Arguments Description toggle <none> Flips the switch position, 1 e if the switch is in the TRUE position it will be moved to the FALSE position and vice versa This has the identical effect of reading the current_posιtιon attπbute and then setting it to the opposite, and is provided mainly as a convenience. Returns the new cuπent position of the switch

Attribute Name Data Type Description true abel Stπng The text associated with the TRUE position of the switch falsejabel Stπng The text associated with the FALSE position of the switch current position Boolean The current position of the switch. Starts off FALSE by default. label Stπng This contains text to use as the label for the switch (the UI component can decide how to display it) descπption Stπng This contains longer text (possibly several sentences or a short paragraph) that gives more detail about the control This will typically be displayed only in special circumstances

Status Indicator Light

In one embodiment, status indicator light is a four color light used to represent status information. The four colors that it displays may be: Blue (unknown status), Green (okay status), Yellow (warning status), and Red (critical status). An Enumeration data type is used to indicate & set the status of the light. Event Name Parameters Description status_changed current_status . Integer Raised every time the status light changes colors status_red Raised when the light changes color from a color other than red to red status_yellow Raised when the light changes color from a color other than yellow to yellow

Status_green Raised when the light changes color from a color other than green to green status_blue Raised when the light changes color from a color other than blue to blue

Action Name Arguments Description

Attribute Name Data Type Description current_status Integer The current status indicated by this light. Blue = 0, Green = 1 , Yellow = 2, and Red = 3. Iniuahzed to status Blue (0) label Stπng This contains text to use as the label for the indicator (the UI component can decide how to display it) description Stπng This contains longer text (possibly several sentences or a short paragraph) that gives more detail about the control. link Stπng Contains text (similar, but not identical, to a URL) that can be used to link to a new control panel or web page

Alphanumeric Display

In one embodiment, the alphanumeric display displays a single line of text.

Event Name Parameters Description text_changed text : Stπng This event is raised whenever the text attπbute is changed. The new value of the text is passed as an event parameter

Action Name Arguments Description

Attribute Name Data Type Description text Stπng The text that is currently being displayed label Stπng This contains text to use as the label for the alphanumeric dιspla> (the UI component can decide how to display it) descnption Stπng This contains longer text (possibly several sentences or a short paragraph) that gives more detail about the control link Stπng Contains text (similar, but not identical, to a URL) that can be used to link to a new control panel or web page 18

Dial

In one embodiment, dial is a type of knob that can be set to any value between a minimum and maximum value. It is equivalent to a volume control on a stereo.

Event Name Parameters Description posιtιon_changed position ^• Number This event is raised when the dial is rotated to a new position

Action Name Arguments Description

Attribute Name Data Type Description position Number The current position of the dial. Can be any value in the range between the minimum and maximum values, inclusive mimmum_value Number The minimum position to which the dial may be moved maximum value Number The maximum value to which the dial may be moved. label Stπng This contains text to use as the label for the dial. descπption Stπng This contains longer text (possibly several sentences or a short paragraph) that gives more detail about the control. link Stπng Contains text (similar, but not identical, to a URL) that can be used to link to a new control panel or web page

Wires & Wire Definitions

Wires define "connections" between the attributes, methods, and events of

managed elements and controls. In one embodiment, wires are defined to have one or

more input connections, one output connection, and a function block that processes the

inputs and sends the result to the output. In an alternative embodiment, wires may

have more than one output and connection and one or more functional blocks.

A wire definition specifies the input connections, output connection, and

function block of a specific instance of wire. In one embodiment, wires are defined

within the context of a managed element and control group. One exemplary embodiment of the information associated with each wire definition is described below

in the "Pseudo-Grammar for a Management Definition File".

Managed Element & Control Groupings

Managed element and control groupings are a collection of managed element

descriptions and control descriptions (where a description is defined to represent an

instance of a managed element /control) along with one or more wires "connecting"

them together. A managed element description can also refer to any managed element

that belongs to a class of elements defined by a particular managed element definition.

For example, a managed element description could represent "the apache web server at

123,45.1.1" or it could represent "any Apache web server". If it is the latter case, then

the grouping can be duplicated for any individual apache web server (so if there are 10

apache web servers, 10 different instances of the grouping could be created, each of

which applies to a single web server).

A Conversion Process

One process for converting management knowledge into machine interpretable

format is described in Figure 1 and in conjunction with an example. This process may

be performed manually or automatically. If automatically, the process is performed by

processing logic that may comprise hardware, software, or a combination of both.

Referring to Figure 1, the manufacturer identifies the element to be managed

(processing block 101). For example, assume that one desires to manage a Windows NT

computer system, particularly the virtual memory (VM) subsystem, to ensure that the Windows NT computer system has adequate VM and is not experiencing performance

degradation (e.g., thrashing) due to lack of VM.

After identifying an element to be managed, the manufacturer defines the

relevant descriptive information needed to build a management solution (processing

block 102). In order to manage VM usage and VM-related performance issues, the

following pieces of information are needed: size of the swap file; current CPU

utilization; total Virtual Memory; current amount of free Virtual Memory; context

switches per second; amount of free space on the root hard drive; the domain and host

name of the Windows NT computer; and the ID of the Windows Management

Instrumentation (WMI) object that corresponds to the root hard disk.

Additionally, the following actions need to be executed: increase the size of the

swap file; and delete unnecessary files on the root hard drive.

Also, notifications of the following occurrences need to be received: low Virtual

Memory notification (sent when VM is beginning to run out).

Next, the manufacturer lists the information for the managed element definition

(processing block 103). The listing eventually defines a managed element that has

attributes, methods, and events. In one embodiment, the name of the manage element

class that is being defined is chosen first. After the name is chosen, the attributes,

methods, and events of the managed element are defined.

Since the element in the example for which a management solution is being

created is a Windows NT Workstation, the chosen name for the element is

WinNTWorkstation . TtUSOO/10400

21 Once the name is chosen, the attributes, methods, and events of

WinNTVJorkstation are defined. The "pieces of information" listed created by the

manufacturer is processing block 102 are made into attributes, the "actions" are made

into methods, and the "occurrences" are made into events. For all attributes whose

values change on a continual basis to reflect the status of the actual Windows NT

workstation, a data source that allows collection of their current values is defined.

Similarly, for methods and events that require communication with the Windows NT

workstation, a mechanism by which the communication happens is defined. For

example, to define the mechanism used to invoke the growSwapFile method, the

manufacturer defines that the WMI method changeSwapFileSize is supposed to be

invoked.

If the values of the attribute need to be collected, then (for this example) either

SNMP or Windows NT Performance counters may be used to collect the values. For

invoking methods, SNMP SET operations and /or Windows Management

Instrumentation (WMI) methods may be used. For receiving notifications of events,

SNMP Traps are used.

The tables below summarize one example of attributes, methods, and events that

will be used to make constitute a managed element definition.

Attribute Name Data Type Data Source Description swapFileSize 64-bit unsigned SNMP OID 1.2.3.4.5 The cuπent size of the swap file, in integer bytes cpuUtihzation Float SNMP OID 1.2.3.4.7 The current percentage of CPU utilization, between 0.0 and 100 0 totalVM 64-bit unsigned SNMP OID 1.2.3.4.8 The total amount of Virtual Memory integer on the Win NT system, including both used and free V!vl, in bytes availableVM 64-bit unsigned NT Performance Counter The cuπent amount of free VM, in integer "Memory\ Available bytes" bytes contexts witches 32-bit unsigned NT Performance Counter The number of thread context integer "Thread\ Context Switches/ sec" switches over the last second rootDπveFreeSpace 64-bit unsigned NT Performance Counter Current amount of free space on the integer "Dιsk(0)\ Free Space" root hard dπve (i.e. the one that holds the swap file), in bvtes domamName Stπng <cnone> The name of the Windows NT domain that the workstation is pan of. This is a static value hostName Stπng <none> The host name of the Windows NT computer. This is a static value wmiRootDisklD Stπng <none> The ID stπng of the WMI object that corresponds to the Windows NT workstation's root hard disk This is a static value snmpIPAddress Stπng <none> The IP address of the workstation's SNMP agent This is a static value commumtyStπng Stπng <none> The community stπng of the workstation's SNMP agent This is a static value

Method Name Arguments Return Invoker Description Value growSwapFile Amount Void WMI Method Grows the size of the swap file

(unsigned 64-bit changes wapFιleSιze(ιnt6 by the specified amount, in integer) 4 delta) bytes freeDiskSpace <none> Void SNMP SET OID Frees disk space on the root

1.2.3.4.37 dπve by deleting all files in the "temp" and "cache" directoπes & emptying the trash can

Event Name Event Parameters Event Source Description lowVM percentFree (32-bit SNMP TRAP OID 1.2.3.4.78 This event is raised the first time the float) free virtual memory on the system drops below 20%. The percent free parameter contains the percentage of free VM at the time the event was raised

After listing information for the managed element definition, the manufacturer

creates the managed element definition (processing block 104). One embodiment of the

"managed_element.dtd" document type definition (DTD) file defines the valid format

for the XML definition file, and is essentially equivalent to a grammar that defines a

valid syntax for managed element definitions.

In the example, it is assumed that the XML format is used to put the definition

into a machine readable file. Using the DTD as a guide, a "winntworksation.xml" file is

created, which is a valid XML file that defines the new class of managed element named "WinNTWorkstation". Note that the XML file merely defines a new class of managed

element; it does not create any instances of that class. Instances of the

"WinNTWorkstation" managed element class exist only inside of a management

application. Management applications create instances of the class by either

discovering Windows NT workstations and create instances for them, or by reading the

instance data directly from the workstation.

Once the managed element definition is actually created, the manufacturer

captures the management knowledge (processing logic 105). This knowledge is that

which is required to manage the element, given the data in its definition and may

include interpretive, procedural, and condition-action knowledge. First the knowledge

required to interpret the raw data provided in the managed element's definition is

processed.

For the example, there are two things that need to be detected by interpreting the

data: the CPU thrashing (i.e., the CPU is rapidly changing thread contexts due to page

swapping); and the swap file size is too small.

Neither of these pieces of information comes directly from an attribute, method,

or event of the managed object. Instead the logic is denned in order to derive them.

For this example (an in one embodiment), the required logic is expressed by the

following IF..THEN rules:

IF (cpuUtilization is less than 20% AND contextSwitches > 20) THEN (the CPU is

thrashing) IF (available VM is less than 15% of totalVM) THEN (the swap file size is too small)

Note that these rules essentially specify a Boolean indicator that is true whenever the

condition of the IF..THEN rule is satisfied and false otherwise.

Once the knowledge needed to interpret the raw data has been defined, the

procedural knowledge needed to manage the element may be defined. For the

example, only a single procedure is needed: how to increase the size of the swap file.

In one embodiment, this procedure is a two step process, consisting of first freeing disk

space on the root drive, if necessary, and then actually increasing the size of the swap

file. For simplicity, assume that each time the swap file is grown, its size by 10% is

increased. An exemplary version of the full process for increasing the size of the swap

file expressed in pseudo-code is as follows:

1. LET x = current swap file size * 0.10

2. IF root drive free space < x THEN free space on root drive

3. Grow swap file size by x bytes

Note that invoking this process requires no arguments.

Having defined the procedural knowledge that is needed to manage the element,

the knowledge of when to perform the procedure (e.g., condition-action rules) is also

captured. In one embodiment, for the example, only a single, simple condition-action

rule is used: WHEN (swap file size is too small) DO (increase the size of the swap file)

In the example, it is assumed that this condition-action rule is always in effect; however,

of rules, such as condition-action rules, may not always be in effect.

With the management knowledge captured, the manufacturer represents the

management knowledge using the description mechanism (processing block X06). The

description mechanism allows the manufacturer to define controls and wires that can be

"connected" in various ways to represent the management knowledge. In one

embodiment, management knowledge may comprise interpretive knowledge,

procedural knowledge, and condition-action knowledge.

In one embodiment, interpretive knowledge consists of two Boolean indicators.

The description mechanism defines controls that can be used to represent indicators

(e.g., gauge controls, status indicator light controls, etc.). Since at any given time, these

indicators will either true or false, they can be represented using indicator lights whose

color is green if the condition is false (which is the desired state of affairs) or red if the

condition is true. The description mechanism allows defining "wires", which allow

information to flow throughout the system and be manipulated along the way. These

indicator lights are "wired" to the attributes of the managed element that are used in

the conditional part of the IF..THEN rules, and the wire's transform function will in

essence evaluate the conditional expression and output the corresponding color, which

will be wired to the appropriate attribute of the indicator light.

The procedural knowledge includes a single procedure which requires no

arguments. The easiest way to represent this may be with a button, which, when pressed, executes the procedure. In alternative embodiments, procedural knowledge

may comprise metylic procedures which require no arguments.

The condition-action knowledge include a single rule whose conditional part is

based on the "swap file size" indicator, and whose action part is the "increase swap file

size" procedure. This knowledge can be represented by connecting a wire from the

"swap file size too small" indicator to the "push" action of the button.

With the model knowledge defined, only a machine readable format is needed.

Again an XML file is used, which may be based on the DTD in the "control_panel.dtd"

file. The results are stored in the "samplepanel.xml" file.

The Application

Application Components

The application includes a number of components. Each of these components, or

modules, comprises hardware, software, or a combination of both. In one embodiment,

the application includes at least one parser /compiler 201.(-201_N), a database 202, a data

collector 203, a scheduler 204, a data listener 205, a peer manager server 206, peer

manager clients 207._.N, and an engine 210.

Parser /compiler 201 is responsible for reading the various definition files (e.g.,

managed element definitions, control panel definitions, etc.) expressed in a particular

format, such as, for example, XML, and converting the information contained in the file

into a single, object-based internal representation. There may be more than one

parser /compiler. Thus, all parsers /compilers convert information in the files into an equivalent set of internal "application" objects. In one embodiment, each of

parsers /compilers 201._.N handles one or more specific file formats. For example,

parser /compiler 201 handles for XML definition files. The parser /compiler may be one

or more separate functional modules or units.

Database 202 stores the objects produced by parser /compilers 201.-201_κ as well

as any objects created through other mechanisms. Objects may be manually entered by

user imported from other applications, or created by a discovery process that locates

new instances and creates objects for the instances. Database 202 may comprise one or

more memories or databases.

Engine 210 is a master controller for the application. Engine 210 takes control

panel objects with all their associated wires, managed objects and control objects and

causes them to run. Engine 210 is described in more detail below.

Data collector 203 is responsible for collecting data from the networked

environment on a periodic basis or on demand. In an alternative embodiment, data is

received via a "push" from an external service. In one embodiment, data collector 203

receives requests for data collection in a single, universal format and uses one or more

protocol handler(s) 213._.N, to gather data using an extendible range of protocols. In one

embodiment to actually collect the data, along with scheduler 204 for handling periodic

collection requests.

Scheduler 204 receives requests to execute jobs, such as periodic collection

requests at specified time intervals and is responsible for scheduling the jobs and

executing them at the appropriate time. In one embodiment, these jobs are objects that

implement a specific interface that scheduler 204 uses to cause the job to run. In one embodiment, as long as the job object implements the correct interface, it may perform

any action.

Data listener 205 is responsible for receiving data sent by external sources (such

as SNMP traps, for example) and distributing it to whichever object or objects that have

requested it.

Peer manager server 206 receives events from engine 210 and forwards them to

peer manager clients 207._.Nthat have requested to receive them. To that extent, peer

manager server 206 handles communications between objects in engine 210 and the

networked environment. Peer manager server 206 also receives requests from peer

manager clients 207.__Nto obtain or set attribute values or invoke methods on objects in

the engine 210 and sends them to engine 210. For example, peer manager server 206

sends descriptive information about the objects (either controlled or managed) that

clients use to create a user interface. As the control objects in engine 210 change state,

the control objects send notifications to peer manager server 206, which forwards them

to any correct user interface. Conversely, when a user interface control on a client

receives input, the user interface sends the input to peer manager server 206, which

forwards them to the corresponding control in engine 210.

Peer manager client 207. typically handles interaction with user interface (UI)

207. that correspond to the controls in engine 210. Peer manager client 207. receives

input from them and forwards peer management client 207. to engine 210 via peer

manager server 206. Conversely, it receives event notifications from peer manager

server 207 and forwards them to the appropriate UI components or other recipients. Peer manager clients 207._.N do not have to be connected to a user interface; it can be

part of a batch processing program or other application.

Objects

There are various kinds of objects used in the application that represent the

different managed elements, controls, wires, etc. that are needed. The objects may be

created manually by the user or imported from other databases. In one embodiment,

every application object has a globally unique identifier (GUID) associated with it when

the object is created or assigned to it at a later time.

In one embodiment, the different classes of objects used in the application

include managed element definition objects, managed element objects (referred to as

well as managed objects), control definition objects, control objects, wire objects, and

control panel objects. Each managed element definition object represents the definition

of a single class (or type) of managed element. For example, there could be a managed

element definition object for Apache web servers. Each managed element object

represents an device /application /service /etc. in the network environment that is being

managed. Each managed element object is associated with a particular managed

element definition object that defines the class /type that the managed element belongs.

For example, there would be a single managed element definition object for Apache

web servers, and multiple managed element objects, each of which is associated with

the Apache definition object, and represents an actual Apache web server that is being

managed. Managed objects are described in more detail below. Each control definition objects represents the definition of a single type of control

(such as a button or a gauge). Each control object represents an instance of a particular

type of control definition.

There is a single control definition object associated with each control object that

defines the control's type. Control objects are described in more detail below.

Each wire object represents a connection between attributes, methods, or events

of managed element objects and /or a control objects.

Each control panel object represents a control panel, and includes references to

all of the managed elements, controls, and wires within the panel.

Various other components may also be included in the application, but are not

essential. These include a discovery component that automatically discovers

devices /applications /services on the network and creates managed element objects

that correspond to what it found and an object creation user interface component that

allows users to manually create managed element objects through a graphical or text

based user interface.

Managed Objects & Control Objects

Managed objects and control objects have a very similar structure. They differ

mainly in that managed objects represent things being managed, while control objects

represent mechanisms for viewing or changing the state of the things being managed.

Managed objects are application objects that are typically created by a parser /compiler

from a management definition file. Each managed object is a program object (e.g., an instance of a Java or C++ class, for example), with methods for accessing the managed

object's attributes, methods, and events.

In one embodiment, each managed object and control object has a set of attribute

values, a get attribute value method, a set attribute value method, a list of "listeners"

for each attribute, zero or more data sources for each attribute, an invoke method, a

raise event method, and a list of "listeners" for each event.

Managed objects and controls have a set of zero or more attributes, and each

object maintains internally a set of the latest values for those attributes. The values can

be retrieved or set using the get attribute value and set attribute value methods,

respectively. In one embodiment, the get attribute value method takes the ID of an

attribute and returns its latest value. Alternately, the latest value is collected. The set

attribute value method takes an attribute ID and a new value as arguments, and sets the

value of the specified attribute. A list of "listeners" for each attribute allows for

"listening" for changes in the attributes of a managed object or control. All objects that

listen for changes in an attribute are notified when that attribute's value changes. The

zero or more data sources for each attribute define how to collect the information if the

value of the attribute is determined by collecting it from an external source. For

example, if an attribute's value comes from an SNMP agent, then the data source

contains enough information to collect the appropriate SNMP data.

Additionally, it is possible to SUBSCRIBE to (listen for) the value of an attribute

by calling the appropriate method on the managed object, which essentially registers a

listener with the manage object that is notified on a periodic basis of updates to the attribute value. To subscribe to an attribute, you specify the frequency at which you

want updates and pass a reference to a listener that receives the updates.

To handle a SUBSCRIBE request, the managed object selects a data source to use

for gathering the data. The data source can be taken from either the managed element

class definition associated with the managed object, or it can be specific to the managed

object and stored directly with it (this allows an instance of a particular managed object

class to override the data sources specified in the class definition). The data source

information specifies what protocol to use as well as any additional arguments that

need to be specified for that protocol (such as the IP address & community string for the

SNMP protocol). The managed object takes the data source information and passes it to

the data collector, specifying the frequency at which the data should be collected (as

specified in the SUBSCRIBE request) and passing a reference to itself. The data collector

will then collect the specified piece of data according to the schedule and pass it to the

managed object, which will use it to update the appropriate attribute and notify all

subscribers to that attribute's value.

Each managed object and control can raise events. This method can be used to

signal the managed object /control to raise a specified event. A list of "listeners" for

each event allow for "listening" for events raised by a managed object or control. All

objects that listen for events are notified whenever the event is raised.

Additionally, each managed object supports zero or more events. It is possible to

register with the object to receive notifications when a particular event occurs. Listeners

are registered to receive notifications of an event, and this causes the listener to be

notified when the event occurs. Managed objects handle requests for event notifications in a similar manner to requests for subscribing to attributes, with the exception that the

data source receives data via "push" from external sources.

Each managed object and control has methods that can be invoked by using this

single invoke method and passing as arguments a method ID and the arguments to

pass to the method. Code for handling an invoke method can be defined in managed

element /control definition, can be assigned an object, or can be hard coded.

Operation of the Application

Figure 3 is a flow diagram of one embodiment of the process performed by the

application. Referring to Figure 3, the process creates objects and stores them in

database such as database 102 (processing block 301). This may be performed by

passing data into the parser/compilers 201._.N (which is described in more detail below),

and /or by using an alternate method of creating objects, such as a discovery or object

creation user interface component.

Next, the process fills-in class references in control panels (processing block 302).

Control panels may contain references to a class of managed element (e.g., a class

reference) instead of a specific, individual managed element. In one embodiment, this

is performed using the <managed_element_class> tag defined in the control_panel.dtd.

This is analogous to saying, "This is a control panel for ", where the blank is a

specific Apache web server. By defining a control panel that references a class instead

of an instance, it is possible to create a separate panel for every instance of a particular

class using a single definition. This saves effort, since it makes it possible to write a

single control panel definition that can be used to generate many other control panels. For example, a control panel can be defined that references the managed element class

for Apache web servers, and then there would be a separate instance of the control

panel created for each instance of Apache web server.

In one embodiment, control panels that include class references cannot be used

directly. Instead, in such a case, a copy of the control panel may be made and the class

references are replaced with references to specific managed element instances (e.g., take

the control panel definition with the Apache class reference and create an instance of

the control panel that references a specific Apache web server).

Control panels with class references can be "filled-in" either manually (e.g., the

user specifies which managed elements replace the class references in the control panel)

or automatically. One embodiment of process for automatically filling in control panel

references generally comprises four steps is shown in Figure 4. The process assumes a

control panel with one or more class references and zero or more rules that are used to

determine which managed elements are eligible for replacing the class references.

Referring to Figure 4, the number and type of class references in the panel are located

by iterating through the references in the panel and extracting each reference that is a

class reference (processing block 401). This produces a list that in one embodiment

looks, for example, like <class reference to Apache Web Server, class reference to

Apache Web server, class reference to Cisco Router> for a control panel that has two

distinct class references to Apache web servers and one class reference to a Cisco router.

Optionally one could also have a rule such as, for example "at least one apache web

server must be on the same network segment as the Cisco router". Next, all permutations of managed objects in the database that match the list are

generated (processing block 402). For example, if one had three Apache web server

managed objects named Al through A3, and one Cisco router managed object named

Cl, the following permutations are generated: <A1, A2, Cl>, <A1, A3, Cl>, and <A2,

A3, Cl>.

Afterward, rules are applied to the permutation, if one or more rules were given,

to see if the managed objects are eligible for replacing the class references (processing

block 403). If any of the rules fail, the permutation is not eligible to fill in the control

panel and can be discarded. For example, if both A2 and A3 are on different network

segments than Cl, the permutation <A2, A3, Cl> would be discarded.

Then, for each permutation that satisfied the rules, a new control panel is created

by copying the original panel and replacing the class references with references to the

managed elements in the permutation (processing block 404). For example, two panels

would be created, one that had its class references replaced by references to the

managed objects Al, A2, and Cl, and another that had its class references replaced by

references to managed objects Al, A3, and Cl in the above example.

This embodiment of the process may create multiple control panels with no class

references from a single control panel with one or more class references. The user is

free to delete any or all of these panels after they are created, or could choose which to

keep as the process is executing.

Referring to Figure 3, once the class references have been filled into the control

panels, objects are passed to the engine (processing block 303). The objects that are

passed may be a subset of managed objects, controls, and Wires. There are many different ways to decide which objects are passed to the engine. One way is to simply

pass all objects in the database (e.g., database 104 of Figure 2) or to apply a set of rules

that determines which objects get passed.

Alternately, the user could be allowed to choose which objects get passed to the

engine.

After passing objects to the engine, the engine is initialized (processing block

304). The engine receives the managed objects, controls, and wires that were passed to

it for their proper operation. One possible process for initializing is as follows:

Given: a set of managed objects, a set of controls, and a set of wires Do:

For each wire in the set of wires do: Get the set of inputs to the wire. For each input of the wire do: // In the following IF statement the data is arranged to be delivered to //the input of the

// wire at the correct frequency. Each input of the wire can include the //frequency at which data should

// be delivered to the input. If no frequency is specified, a default is used. //Alternately, the frequency / / can be based on whenever the data changes

If the input is connected to an attribute of a managed object or control, then

Register the wire as a listener to the attribute Else if the input is connected to an event of a managed object or control, then

Register the wire to receive notifications of the event Else if the input is connected to a method of a managed object or control, then Arrange with the scheduler for the method to be invoked at the frequency specified by the Input, and have the scheduler notify the wire with the results after each invocation End If / / Note that the 3 cases in this IF statement cover all //possibilities End For.

Get the object that the output of the wire is connected to, and make sure that the wire has a reference to the object End For End Method One embodiment of a process for registering a wire as a listener to an attribute of

a managed object or control may be performed the following:

Given: a managed object or control, a wire, and the ID of the attribute the wire wants to receive data for, and the frequency at which the wire desires new values for the attribute

Do:

If the managed object or control has one or more data sources associated with the specified attribute, then

Choose one of the data sources / / this can be done based on arbitrarily //complex or simple rules

If no frequency is specified, Then let frequency = the default frequency End If If the frequency is a specified timer interval, Then

Pass the data source information, the frequency, the attribute name, and a reference to the managed object or control to the Data Collector, and arrange for the Data Collector to collect the data at the specified frequency and call the setAttribute Value method of the managed object or control every time new data arrives. Add the wire to the managed object or control's list of listeners for the specified attribute

Else If the frequency is "only when changed" Then

Pass the data source information, the attribute name, and a reference to the managed object or control to the Data Collector, and arrange for the Data Collector to collect only changes in the data and call the setAttribute Value method of the managed object or control every time new data arrives.

Add the wire to the managed object or control's list of listeners for the specified attribute End If Else

/ / In this case there is no data source associated with the attribute, so the / /attribute's value is stored in the

// managed object or control itself and is changed only when someone //calls the setAttribute Value method

/ / of the managed object or control. All we do in this case is register the / /wire to receive notifications after / / the setAttribute Value method is called

/ / Add the wire to the managed object or control's list of listeners for the specified attribute End If End Method

The process for registering a wire to receive notifications of an event is

essentially identical to the above-listed process for receiving attribute values, except

attribute, data source, and set attribute value are replaced with event, event source, and

raise event.

After engine 210 has been initialized, engine 210 is started (processing block 305).

Starting engine 210 allows data collector 203 to collect the requested data at the

specified frequencies and call the set Attribute Value process on the appropriate

managed object or control. One embodiment a basic loop operating in engine 210 is as

follows:

While the engine is running Wait for something to happen

If a setAttribute Value method has been called on a managed object or control, then Notify the peer manager server that an attribute has been changed (include the ID of the attribute and the

ID of the managed object or control) Get the list of listeners that are listening to the attribute on the specified managed object or control

For each listener do

Notify the listener that the attribute values has changed on the managed object or control

/ / The listener can do anything it wants to when notified End For Else if a raiseEvent method has been called on a managed object or control, then Notify the peer manager server that an event has been raised (include the ID of the event and the

ID of the managed object or control) Get the list of listeners that are listening to the event on the specified managed object or control

For each listener do Notify the listener that the event has been raised by the managed object or control

/ / The listener can do anything it wants to when notified End For Else if the peer manager server has requested that an action be performed, then If the peer manager server requested get the value of an attribute, then

Call the getAttribute Value on the managed object or control specified by the peer manager server, and pass as an argument the specified attribute name Return the value to the peer manager server Else If the peer manager server requested to set the value of an attribute, then Call the setAttributeValue on the specified managed object or control (this gets handled in the next pass through the loop) Else If the peer manager server requested to invoke a method, then

Call the invoke method on the specified managed object or control, passing as arguments the method ID and method arguments specified by the peer manager server End If End If End While

Engine 210 sits in the loop listed above, waiting for data to be delivered from

data collector 203, for scheduler 204 to do a scheduled action, or for input to come from

the peer manager server 206. Engine 210 handles whatever has happened, and then

repeats the loop. As described above, wires are added as listeners to the managed

objects or controls that their inputs are connected to, so that when engine 210 notifies a

listener (e.g., data listener 205), it is usually notifying a wire object. In one embodiment,

wire objects handle notifications using the following process:

While the wire is connected, do — .

Wait for a notification that a new value is available for one of this wire's inputs

Save the new value for the specified input

Decide whether to generate an output value

If an output should be generated, then

Get the values that have been saved for all inputs, or use defaults for inputs with no values Compute the output value by evaluating the wire's transform function using the inputs as arguments

If the output of this wire is connected to an attribute of a managed object or control, then

Call the setAttributeValue method on the managed object /control, passing the output value as an argument

Else if the output of this wire is connected to a method of a managed object or control, then

Call the invoke method on the specified managed object /control, passing the method name, the output value, and the result of any function of the input values as arguments to the method being invoked

Else if the output of the wire is connected to an event of a managed object or control, then

Call the raiseEvent method of the specified manage object /control, passing output value as an argument End If End If End While

An arbitrary process can be used to decide when an output value should be

generated. For example, an output can be generated each time a value is received for

any input, only after new values have been received for all inputs, or only if a specified

amount of time has elapsed since the last output was generated.

After engine 210 has been started, peer manager clients are added (processing

block 306). Engine 210 runs as described above indefinitely, without any sort of

connection to a user. At any time, a user may want to connect to the system to view its

current state and /or send input into the system to change its state. The user has access

to a user interface, which can be running on the same or a different machine than

engine 210 itself. The user interface creates a peer manager client object which

communicates with peer manager server 206 coupled to engine 210. Peer manager

clients 207._. , can communicate with peer manager server 206 via any of a number of standard or proprietary communications protocols (e.g., XML over HTTP, or Java

objects serialized over a TCP/IP socket). In one embodiment, peer manager clients 207_ι

. send requests to peer manager server 206 to do any of the following:

• Obtain a list of all the managed objects or controls that are inside of engine 210, to include the ID and type of each

• Obtain the current value of an attribute of a managed object or control that is inside of engine 210;

• Set the value of an attribute of a managed object or control that is inside of engine 210;

• Invoke a method on a managed object or control that is inside of engine 210;

• Receive notification of an event that was raised by any managed object or control inside of engine 210;

Any number of peer manager clients 207.._N can be connected to peer manager

server 206. Typically, each peer manager client 207,.,. has a user interface used by a

single user, but this need not be the case. Also, peer manager client 207._.N is usually

connected to a graphical user interface, but it could also be connected to a text or HTML

based interface, or could be used in batch mode by a program instead of a user. Peer

manager clients 207._.N can disconnect from peer manager server 206 at any time.

After peer manager clients are added, the user interface is setup and run

(processing block 307).

If peer manager client 207. is coupled to a user interface, such as user interface

217, then the user interface 217 uses the peer manager client 207.._N. to setup user

interface 217, change its appearance in response to changes in the objects in engine 210,

and to handle input from the user. On process used by a typical user interface to setup

comprises: Given: a reference to peer manager client object that is connected to a peer manager server

Do:

Get a list of the IDs and types of the managed objects and controls that are in the engine using the Peer Mgr. Client

Choose which managed objects and /or controls to display in the User Interface

For each object that is going to be displayed in the user interface, do

Use the type of the object to choose what kind of user interface component to display

Create an instance of the chosen user interface component

Store the ID of the associated managed object or control in the user interface component

Tell the peer manager client to deliver notifications of all events raised by the managed object /control

Add the user interface component to the user interface End For

An arbitrary process can be used to decide which objects to display in the user

interface. In one embodiment, only the user interface components for control objects, or

only for specific types of control objects, or for any objects whose attribute values meet

a certain criteria, are displayed.

After the user interface has been setup, user interface basically runs in a loop

gathering updates from engine 210 via the peer manager server 206, or input from the

user and handling the update/input. One embodiment of a process for handling the

user interface is as follows:

While the user interface is active

Wait for input from the user or for an event notification from the peer manager client If there was input from the user, then

Figure out which user interface component received the input Get the ID of the managed object or control that is associated with the user interface component

Figure out how to handle the input

If handling the input requires invoking a method, then

Use the peer manager client to invoke the appropriate method on the manage object/control whose ID is stored in the user interface component Else

Do whatever needs to be done to handle the input End If Else if an event notification came from the peer manager client then

Find all user interface components that are associated with the ID that is included in the event notification

Notify each user interface component that the event occurred End If End While

In one embodiment, any method can be used to determine how a user interface

component should respond to user input. Typically, each user interface component

includes logic to handle input, either by changing the internal state of the component

and/or by invoking a method on its associated managed object or control.

In one embodiment, each user interface component handles event notifications

any way it desires. Typically, the user interface component changes its state and /or the

way that it appears to the user, but it could do anything else as well.

Operation of the Parsers/Compilers

In one embodiment, parsers /compilers 201.._N. receive data that describes

management knowledge in a particular format or formats (such as XML) and convert it

into the corresponding objects used by the rest of the application, to include: managed

element definition, managed element, control definition, control, and wire objects. Tne

following describes the structure of a XML parser /compiler. Other parser /compilers

for other formats may be similar.

The XML parser/compiler includes two main blocks: a parser block and a

compiler block. The parser block reads in the data expressed in XML format (typically from a text file, but it could also read it from a source over the network) and converts it

into a closely corresponding, standard object format called the Document object model

(DOM). For more information on DOM see http://www.w3.org/TR/PR-DOM-Level-

1/ . The parser block uses standard parsing technology and will not be described

further herein.

The compiler block is responsible for taking the DOM object representation of

the XML data and converting it into the appropriate application object(s). The compiler

block has a process that corresponds to each different kind of node that can appear in

the DOM tree. For example, there is are methods that handle the "control_panel",

"control_reference", and "manage_element_reference" nodes that appear in the DOM

tree (these nodes correspond to the <control_panel>, <control_reference>, and

<managed_element_reference> tags in the XML document). Each method takes the

DOM tree node (and all of its children) as an argument, and returns an object.

The compiler block operates by taking the DOM object tree produced by the

parser block, looking up the method that corresponds to the root node of the DOM tree,

and calling that method with the root of the tree as the argument. The result of the

method call is a single application object or a vector containing multiple objects. In one

embodiment, every method in the compiler operates by iterating through the children

of the argument node, recursively calling the methods that correspond to those nodes,

combining the results, and returning a single value. One embodiment of a process used

by a compiler is as follows:

method ProcessNode (DOMNode argumentNode) returns Object let childrenList = argumentNode . getChildren( ) let childrenResults = new List for each child in childrenList do let method = LookupMethodFor(child) let result = Invoke(method) with (child) as argument add result to childrenResults end for let return Value = Process(childrenResults) / / "Process( )" in the above line will do different things for / / each different kind of DOMNode. For example, it may / / create a new Managed Object and use the objects in children / / results to populate the Managed Object. Note that the objects / / will have GUTDs associated with them, if necessary, when they / / are created

return returnValue }

Note that there are many other possible ways of parsing and compiling the XML

data into application objects, some of which are more efficient that this, or may involve

only a single pass over the data instead of a parse step followed by a compile step.

The Engine

Engine 210 takes as input a set of managed objects, a set of control objects, and a

set of control panel objects (each control panel object contains a set of wire objects).

Every control object and managed object referenced by any wire in the control panels

must be included in the sets of controls and managed objects.

For each control panel, engine 210 iterates through all wire objects in the control

panel. For each wire, the control panel iterates through the wire's inputs. For each

input of the wire, the control panel finds the managed object or control that the Input is

"connected" to, and registers the wire object to "listen" to the appropriate attribute,

event, or method based on the frequency that the input is supposed to be signaled. Listening to an attribute is equivalent to reading its value; listening to an event is

equivalent to receiving notification that the event occurred; and listening to a method is

equivalent to invoking that method. If the input is an attribute, the control panel

subscribes the wire to the attribute by calling the managed object or control's

SUBSCRIBE method and passing a reference to the wire as a listener. If the input is an

event, the control panel registers the wire to listen for the event on the managed object

or control. If the input is a method, the control panel creates a job object that invokes

the method and passes the result to the wire, and then will use the scheduler to

periodically execute the job.

For each wire, the control panel finds the managed object or control that the

wire's output is connected to, and sets the wire up to send the result to the appropriate

attribute, input, or method. Sending the result to an attribute or an input sets the

attribute or input's value, while sending the result to a method causes the method to be

invoked.

At any time the peer manager clients request that the server return information

and iterate through the controls inside the engine and create peer objects for them. It is

possible for a single control in the engine to have multiple peers associated with it (this

would happen when there were multiple UIs looking at the controls, for instance).

When the peer manager client creates a peer object for a control, it arranges to receive

all events from that control, and takes care of forwarding them to all connected peers.

Conversely, peer objects can send input to the Peer Manager for forwarding to the

appropriate control object. Therefore, the description above provides a machine interpretable mechanism

for describing management information that has the properties of portability,

completeness, simplicity, and support for automation, along with a management

system that interprets those descriptions. The solution described herein allows

capturing management knowledge by creating a machine readable and interpretable

description of the management knowledge, which is subsequently used by a

management application. This dramatically reduces the cost of creating a management

solution, since it is much less expensive, etc. than writing a custom program. Thus, it is

a simple and relatively inexpensive solution.

The description mechanism described here overcomes the limitation of being

usable only with a specific application, since it expresses information in a format that is

independent of any specific management application.

The solution described here overcomes the limitation of not being readily

understandable by end users by using an intuitive description mechanism that can be

easily converted to a format that an end user can understand (i.e. it uses a "control

panel" metaphor).

Furthermore, the way in which capturing management knowledge occurs is that

its description mechanism allows creating a "virtual management control panel" for the

managed element using the managed object, control, and wire definitions. To

demonstrate that the virtual control panel is capable of encapsulating management

knowledge, first note that it is capable of displaying in real-time all of the descriptive

(e.g., attribute & event) information relevant to the managed element. This is possible

because the description mechanism allows defining which attributes /events characterize a managed element, along with methods for accessing their current values,

and because it is possible to define a control that is capable of displaying any type of

value that an attribute may contain (e.g., controls with numeric or alphanumeric

indicators can be created, controls that graph data over time can be created, etc.).

Together, these allow a management application such as the one described herein to

collect and display all relevant attribute and event information for a managed element

in real time.

Further note that it is possible to use the description mechanism to define a way

of invoking all relevant methods needed to alter the managed element's state. This is

because the description mechanism allows defining which methods a managed element

supports, and because it is possible to define a control which invokes the method. A

management application such as the one described herein can use this information to

allow invoking methods on a managed element based on input which can come from

the user interface or from some other part of the system (i.e. from an event raised by an

object).

Also note that the wiring that connects attributes and events to other attributes

or methods and allows for conditional execution of methods. This is the case because a

wire allows an arbitrary set of inputs to be taken (which as described above can include

any of the relevant state information of a managed element), perform a calculation over

those inputs, and send an output to an arbitrary attribute or method. By suppressing

the output or by sending a null output, it is possible conditionally cause an action to

occur or not occur. Thus, wires allow defining rules in the form IF condition THEN

action. In other words, allows for describing rule based knowledge that includes, but is not limited to, such things as how to know when a problem has occurred, and what to

do to resolve the problem.

An Exemplary Embedded Embodiment

In one embodiment, the machine interpretable management knowledge is put it

into a machine readable format (such as

XML, for example), and then embed into a device, application, etc.

In one embodiment, a well defined protocol may be defined for querying the device or

application to see whether it has the management knowledge embedded in it. For

example, the HTTP protocol may be used to query a device or application to see

whether it has embedded management information, and that a request for a specific

URL made via HTTP to the device or application will return the data. This allows the

device or application to completely describe how to manage itself, without any external

data or specialized application.

In such a case, a management application could use the embedded information

to manage devices and applications. For each device /application that it wants to

manage, it can attempt to discover whether the device /application has embedded

information using

the following algorithm:

FOR EACH protocol that can be used to access embedded management knowledge DO Try to use the protocol to retrieve the management knowledge from the device IF it succeeds, THEN Take the knowledge and pass it to the appropriate parser /compiler 50 Exit the FOR EACH loop END IF END FOR

After the management knowledge is passed to the parser /compiler, the application

uses it as described herein.

Pseudo-Grammar for a "Managed Element Definition"

Managed Element.dtd

This is an XML Document Type Definition (DTD) file that specifies the format of

a valid managed element definition. It is essentially a grammar that defines the file

format for the managed definition. The managed element definition allows you to

define the attributes, methods, and events associated with a managed element.

^■1 ***********************************************************

** This "managed_element" definition defines what pieces **

** of data are needed to model a real-world entity (such **

** as a router or web server), along with methods for **

** gathering time-variant values for some or all of those**

** pieces of data. **

** **

** Managed_element definition includes a name which **

** uniquely identifies the managed_element type, along **

** with zero or more attribute, method, and /or event **

** definitions. ** *********************************************************** -

<!ELEMENT managed_element (type_name, (attribute I method I event)*)> <!ELEMENT type_name (#PCDATA)>

,^| ******** ******** ******** ***********************************

** "event" defines an event that is sent by the real- ** ** world entity that the managed element corresponds to. ** ** Each event is identified by a unique name, along with ** ** optional event parameters that are included in all ** ** notifications of the event's occurance. ** *********************************************************** -

-..ELEMENT event (name, event_param*, event_source*)>

<!ELEMENT event__param (name, type)>

^. j ***********************************************************

** "event_source" defines a mechanism for receiving **

** notifications from the real-world entity. Each event **

** source typically has one or more parameters that **

** hold information needed to setup the event_source to **

** send notifications of events. ** *********************************************************** --

< [ELEMENT event_source (snmp_trap I winnt_event_log external_event_source)>

<!ELEMENT snmp_trap (ip_address_value, oid_value, event_param_value*)> <!ELEMENT event_param_value (name, value)>

<!ELEMENT winnt_event_log (domain_name_value, host_name_value, event_type_value, event_category_value, source_name_value, event_param_value*)> <!ELEMENT domain_name_value (value)> <!ELEMENT host_name_value (value)> <!ELEMENT event_type_value (value)> <!ELEMENT event_category_value (value)> <!ELEMENT source_name_value (value)>

< [ELEMENT external_event_source (name, parameter*, event_param_value*)>

^ l **********************************************************

<!— ** "method" defines an action that can be invoked to ** -> <!-- ** change the state of the real-world entity that the ** — > <!— ** managed element corresponds to. ** ->

^ I ********************************************************** .

<!ELEMENT method (name, return_type, argument*, invoker*)> <!ELEMENT return_type (type)> <!— data type of method result -> <!ELEMENT argument (name, type)>

!— ** "invoker" defines a method for actually invoking a ** — > !— ** method, which typically communicates with the real- ** — > !— ** world entity that the managed element represents and ** — > !— ** changes its state. Methods can also just change the ** — > !— ** data stored in the managed element itself. Invokers ** — > !— ** can be one of the mechanisms predefined here, or an ** — > !— ** externally defined mechanism. ** — > - 1 ********************************************************** -^ !— invoker definition basically describes a mapping from the method arguments to the parameters needed by the invoker, along with a mapping from the result returned by the invoker to the method return type. ->

< [ELEMENT invoker (snmp_set I wmi_method I external_invoker)>

<!— Does an SNMP SET operation, given the IP address of the

SNMP agent, the OID to set, and the value to put into the OID — >

<!ELEMENT snmp_set (ip_address_value, oid_value, new_value)> <!ELEMENT ip_address_value (value)> <!ELEMENT oid_value (value)> < [ELEMENT new_value (value) >

<!— Invokes a method using WMI ->

<!ELEMENT wmi_method (domain_name, host_name, object_id, method_name, parameter*, return_value?)> <!ELEMENT method_name (#PCDATA)>

<!- Externally defined mechanism for invoking a method. Specified by giving the name of the invoker, optional parameters to the invoker, and a value to return -->

<!ELEMENT external_invoker (name, parameter*, return_value)>

<!ELEMENT return_value (value)> ^ I ********************************************************** ~

<!- ** "attribute" defines a single attribute of the managed** — > <!— ** element, and includes a name that uniquely identifies** — > <!— ** the attribute, optional description text (mainly for ** — > <!- ** displaying to users, the data type of the attribute, ** — > <!— ** and optional data sources if the value of the ** — > <!— ** attribute is obtained from an external source. ** — >

^ i ********************************************************** .-

<!ELEMENT attribute (name, description*, type, datasource*)>

^ I ********************************************************** - _,

<!— ** "datasource" identifies a method of collecting a ** — > <!-- ** particular piece of data that will be used to fill-in** — > <!— ** the value of one of a managed element's attributes. ** — > <!— ** Some data sources are predefined here, but external ** — > <!— ** data sources that are defined elsewhere can be ** — > <!— ** specified as well. ** — >

^ I **********************************************************

<!ELEMENT datasource (winnt_perf_counter I microsoft_wmi I snmp I extension_data_source )>

<!— Following are tags for predefined datasources, including — >

<!— Windows NT Performance Counters, Microsoft WMI, & SNMP — >

<!- (more to be added later) ->

<!ELEMENT winnt_perf_counter (domain_name, host_name, perf_counter_name)> <!ELEMENT domain_name (value)> <!ELEMENT host_name (value)> <!ELEMENT perf_counter_name (value)>

<!ELEMENT microsoft_wmi (domain_name, host_name, user_id, password, object_id, attribute_name)> <!ELEMENT user_id (#PCDATA)> <!ELEMENT password (#PCDATA)> <!ELEMENT object_id (value)> <!ELEMENT attribute_name (#PCDATA)>

<!ELEMENT snmp (ip_address, community _string, oid)> <!ELEMENT ip_address (value)> <!ELEMENT community_string (value)> <!ELEMENT oid (value)>  <!— parameters needed by the data source — >

<!ELEMENT extension_data_source (name, parameter*)>

-- 1 ********************************************************** -

<!— ** "type" identifies a particular data type, and is ** ~> <!— ** used to define the type of attributes, method args, ** — > <!— ** and so on. ** — >

<!— ** The type can be either one of the predefined types ** — > <!— ** defined in this document, or a specification of a ** — > <!— ** that is defined elsewhere. ** — >

^ I ********************************************************** ^

<!ELEMENT type (type_int32 I type_float32 I type_void I type_uint32 I type_uint64 I type_string I type_array I type_external )>

<!— Following are tags for built-in data types (more to be added) — >

<!ELEMENT type_void EMPTY> <!- VOID type ->

<!ELEMENT type_int32 EMPTY> <!- a 32-bit signed integer ->

<!ELEMENT type_uint32 EMPTY> <!- unsigned 32-bit integer ->

<!ELEMENT type_uint64 EMPTY> <!- unsigned 64-bit integer ->

<!ELEMENT type_float32 EMPTY> <!- a 32-bit IEEE float ->

<!ELEMENT type_string EMPTY> <!- a Unicode string ->

<!ELEMENT type_array (type)> <!— Array with elements of specified type — >

<!-- Following is specification for externally defined type. — >

<!— Externally defined types are specified by giving the — >

<!— type name, along with optional additional identifying — >

<!— parameters. For example, for a 3-dimensional array — >

<!- type, you might have (NAME="3d_ Array", PARAM width=10, ->

<!-- PARAM height=12, PARAM depth=5) ->

<!ELEMENT type_external-(name, constant_parameter*)>

<- 1 ********************************************************** --,

<!— ** "description" contains plain text that is typically ** — > <!— ** used for display in the user interface. Each desc- ** — > <!— ** ription has a language associated with it, allowing ** -> <!— ** for specification of equivlent descriptions in ** —> <!— ** many different languages. Note that generally you ** — >

<!— ** should have only one description per language. ** — > _<. ********************************************************** -

<!ELEMENT description (#PCDATA)> <!ATTLIST description language CD ATA "english">

********************************************************** -^

<!— ** "parameter" is a (name, value) pair used to associate** — > <!— ** a value with an identifier, where the value may be ** — > <!— ** a function over the attributes & methods defined in ** — > <!-- ** this managed element. ** — >

- 1 ********************************************************** -

<!ELEMENT parameter (name, value)>

<!ELEMENT constant_parameter (name, constant_value)>

<!— TODO: define VALUE (function over this managed element's attributes & methods), and CONSTANT_VALUE (literal). Note that VALUE may also include variable names (which method arguments get bound to, for example) — >

<!ELEMENT value (attribute_value I literal_value I variable)>

<!— attribute_value is used to indicate the value is equal to the value of one of this managed element's attributes. — >

<!ELEMENT attribute_value (name)>

<!— literal value is a constant value defined inline — > <!ELEMENT literal_value (string_value)> <!ELEMENT string_value (#PCDATA)>

<!— variable refers to a local named variable. The arguments passed to a method are available as variables for use in defining an invoker, for example. — >

<!ELEMENT variable (name)>

<!ELEMENT constant_value (#PCDATA)>

<!-

<!- ** Leaf tags used in definition of other tags. ** — >

^1 ********************************************************** - <!ELEMENT name (#PCDATA)>

WinNTworkstation

This is an example XML managed element definition referenced in

OpenRegExample. It adheres to the specification in the managed_element.dtd (i.e., in

XML parlance, it is a well-formed and valid XML document). The attributes, methods,

and events needed to managed the Windows NT workstation are defined in this file,

including the mechanisms to access their current values (i.e., the data sources).

<?xml version="1.0" standalone="yes" ?>

<!DOCTYPE managed_element SYSTEM "managed_element.dtd">

<!- MANAGED ELEMENT DEFINITION BEGINS HERE -> <managed_element>

<type_name> WinNTWorkstation </type_name>

^| _************ ΔTTPΓRT J FS _{**************}** ■_>

<name> swapFileSize </name>

<description> Current size of the swap file, in bytes </ description <type> <type_uint64/> </type> <datasource> <snmp> <ip_address><value><attribute_valuexname> snmpIPAddress </name>

< / attribute_value>< / valuex / ip_address> <community_string><valuexattribute_value><name> communityString

</name>

< / attribute_value>< / valuex / community _string> <oidxvaluexliteral_valuexstring_value> 1.2.3.4.5 </string_value>

< / liter al_valuex /valuex /oid> </snmp>

</datasource> </attributex!- END ATTRIBUTE swapFileSize -> <attribute>

<name> cpuUtilization </name> <description> Current percentage of CPU utilization, between 0.0 and 100.0 </description> <type> <type_float32/> </type> <datasource> <snmp> <ip_addressxvaluexattribute_valuexname> snmpIPAddress </name>

< / attribute_valuex /valuex / ip_address> <community_stringxvaluexattribute_valuexname> communityString

</name>

< / attribute_valuex / valuex / community _string> <oidxvaluexuteral_valuexstring_value> 1.2.3.4.7 </string_value>

< /literal_value>< /valuex / oid> </snmp> </datasource> </attributex!- END ATTRIBUTE cpuUtilization ->

<attribute> <name> totalVM </name> <description> Total amount of virtual memory on the computer, including both used and free VM, in bytes </description> <type> <type_uint64/> </type> <datasource> <snmp> <ip_addressxvaluexattribute_valuexname> snmpIPAddress </name>

< / attributejvaluex / valuex / ip_address> <comrnunity_string><value><attribute_value><name> communityString

</name>

< / attribute_value> < / value> < / community_string> <oidxvaluexliteral_valuexstring_value> 1.2.3.4.8 </string_value>

< / literal jvaluex / value> < / oid > </snmp>

</datasource> </attributex!- END ATTRIBUTE totalVM ->

<attribute> <name> available VM </name>

<description> Current amount of free VM, in bytes </description> <type> <type_uint64/> </type> <datasource> <winnt_perf_counter> <domain_namexvaluexattribute_valuexname> domainName </name>

< / attributejvaluex / valuex / domain_name> <host_namexvaluexattribute_valuexname> hostName </name>

</ attributejvaluex /valuex /host_name> <perf_counterjnamexvaluexliteral_value>

<string_value> Memory \ Available Bytes </string_value>

< / literal_valuex / valuex / perf_counter _name>

< / winnt_perf_counter > </datasource>

</attributex!-- END ATTRIBUTE available VM ->

<attribute> <name> contextSwitches </name> <description> Number of thread context switches that happened over the last second </description> <type> <type_uint32/> </type> <datasource> <winnt_perf_counter> <domain_namexvaluexattribute_valuexname> domainName </name>

</ attribute_valuex /valuex / domain_name> <host_namexvaluexattribute_valuexname> hostName </name>

< / attribute_value>< /valuex /host_name> <perf_counter_namexvaluexliteral_value>

<string_value> Thread \ Context Switches /sec </string_value>

< /literaljvaluex /valuex /perf_counter_name>

< / winnt_perf _counter > </datasource>

</attribute><!~ END ATTRIBUTE contextSwitches ->

<name> rootDriveFreeSpace </name> <description> Current amount of free space, in bytes, on the root hard drive </ description <type> <type_uint64/> </type> <datasource> <winnt_perf_counter> <domain_namexvaluexattribute_valuexname> domainName </name>

< / attributejvaluex / valuex / domain_name> <host_namexvaluexattributejvaluexname> hostName </name>

< /attribute_valuex /valuex /host_name> <perf_counter_namexvaluexliteraljvalue> <string_value> Disk(0)\Free Space </string_value> </ literaljvaluex /valuex / perf_counter_name>

< / winnt_perf _counter > </datasource>

</attributex!- END ATTRIBUTE rootDriveFreeSpace -> <attribute> <name> domainName </name> <description> The name of the Windows NT domain that the workstation is part of. </description> <type> <type_string/> </type> <!— No datasource since this is a static attribute — > </attributex!~ END ATTRIBUTE domainName ->

<name> hostName </name>

<description> Hostname of the Windows NT workstation </description>

<!— No datasource since this is a static attribute — > </attributex!- END ATTRIBUTE hostName ->

<name> snmpIPAddress </name>

<description> The IP address of the machine's SNMP agent. </ description

<!— No datasource since this is a static attribute — > </attributex!- END ATTRIBUTE snmpIPAddress ->

<name> communityString </name>

<description> The community string of the SNMP agent. </ description

<!— No datasource since this is a static attribute — > </attributex!~ END ATTRIBUTE communityString ~>

ι ********************* λ T-TTT- D *********************** ■>

<method> <name> growSwapFile </name>

<return_typextype> <type_void/> </typex/return_type> <argumentxname> amount </namextype> <type_uint64/> < / type> < / ar gument> <invoker> -

<wmi_method> <!-- We're going to invoke the WMI method changeSwapFileSize(int64 delta), passing the "amount" that we recieved as the "delta" argument. This is similar to defining the following method in Java:

public void growSwapFile(uint64 amount) return wmi(domainName, hostName, object_id).changeSwapFilesize(amount);

} — >

<domain_namexvaluexattribute_valuexname> domainName </name>

< / attribute_valuex /valuex / domain_name> <host_namexvaluexattribute_valuexname> hostName </name>

< / attribute_valuex / valuex / host_name> <object_idxvaluexattribute_valuexname> wmiRootDiskID </name>

</attribute_valuex/valuex/object_id> <method_name> changeSwapFileSize </method_name> <parameterxname> delta </namexvaluexvariablexname> amount </name>

</variablex/valuex/parameter> < / wmi_method > </ invoker > </methodx!- END METHOD gropSwapFile ->

<name> freeDiskSpace </name>

<return_type><type> <type_void/> </typex/return_type> <!— No arguments — > <invoker> <snmp_set> <ip_address_valuexvaluexattribute_valuexname> snmpIPAddress </name>

< / attribute_value>< /valuex /ip_address_value> <oid_valuexvaluexliteral_valuexstring_value> 1.2.3.4.37 </string_value>

< /literal_valuex /valuex / oid _value>

<!— note that for this SET, the new value is ignored, so we'll just pass a dummy string — > <new_valuexvaluexliteral_valuexstring_ alue> X </string_value>

< / literaljvaluex /valuex/ ne w_value > </snmp_set>

</invoker> </methodx!- END METHOD freeDiskSpace ->

^1 ********************* py p_NTTc ********************* ^

<event> <name> lowVM </name>

<event_paramxname> percentFree </name> <typextype_float32/x/type> < /event_param> <event_source> <snmp_trap> <ip_addressjvaluexvaluexattributejvaluexname> snmpIPAddress </name>

< / attributejvaluex / valuex / ip_address _value> <oid_valuexvaluexliteral_valuexstring_value> 1.2.3.4.78 </string_value>

< / literaljvaluex / valuex / oid_value> <event_param_value>

<name> percentFree </name>

< / managed_element>

Pseudo-Grammar for a "Management Definition File"

Control panel.dtd

This is an XML DTD that specifies the format of a valid "control panel"

definition. A control panel is essentially just a collection of managed elements, controls,

and the "wires" connecting them. It is the control panel that lets you capture the

management knowledge and make it machine interpretable.

^ I ********************************************************

** A controljpanel defines a set of managed elements, **

** controls, and the wiring between them. ** ******************************************************** -

< .ELEMENT control_panel (managed_element_reference I control_reference I wire )*>

<- ********************************************************

** wire defines a connection between the "outputs" of ** ** managed elements or controls (which can be their ** ** attributes, methods, or events) and the "inputs" of** ** other elements or controls (which can be attributes** ** or methods). Wires have one or more input ** ** connections, one output connection, and a **

** transform function that processes the wire^'s **

** inputs to turn them into the output value. **

** Each input is identified by a unique name that is **

** used to refer to that input's value in the xfor **

** function. ** ******************************************************** --_

<!ELEMENT wire (name, input_connection+, output_connection, transform?)>

<!— frequency optionally specifies how often the input should be "signaled", or fed into the wire ~>

<!ELEMENT input_connection (name,

(attribute I method I event I constant), frequency?)>

<!— attribute specifies the name of the managed element or control that the attribute belongs to (as specified in the NAME field of the managed element /control, along with the name of the attribute. — >

<!ELEMENT attribute (object_name, attribute_name)> <!ELEMENT object_name (#PCDATA)> <!ELEMENT attribute_name (#PCDATA)>

<!— method specifies the name of the managed element/ control, the name of the method, and values for the methods argument(s), if any — >

<!ELEMENT method (object name, methodjname, argument*)> <!ELEMENT method_name (#PCDATA)> <!ELEMENT argument (name, value)>

<!— event specifies the name of the manage object/ control along with the name of the event to listen to -> <!ELEMENT event (objectjname, event_name)> <!ELEMENT event jname (#PCDATA)>

<!-- frequency specifies how often a value should be fed into the wire. If can specify a set period or it can specify to be signaled whenever the value is changed. Only on_change can be specified for events — >

<!ELEMENT frequency (periodic I on_change)> <!— periodic contains the time between signals — > <!ELEMENT periodic (#PCDATA)> <!ELEMENT on_change EMPTY>

<!— output_connection can be either an attribute of a managed_element or contrl (which SETs the attribute's value), or it can be a method (which INVOKES the method). Arguments to the method can reference the values of any of the wire's inputs, as well as the result of the transform — >

<!ELEMENT output_connection (attribute I method)>

<!— transform is a script that computes a function which takes as arguments the values of the wire's inputs, and returns the output value of the wire. ~>

<!ELEMENT transform (script)>

-. i ********************************************************

** A managed_element_reference is used to identify a ** ** managed element that is included in this control ** ** panel. It can reference a specific instance of a ** ** managed element (such as the managed element that ** corresponds to a particular web server), or it can ** ** reference a specific class of managed element (as ** ** defined in a managed element definition), in which ** ** case this control panel can be assembled using any ** ** instance of the specified class (i.e. you can ** ** define a control panel that will work with any **

** instance of the "Web Server" managed element type).*

** **

** The name specified for the managed element must be unique among the names specified in the control panel definition, to allow the element to be ** unambiguously identified. ** .***************************************************** --_

<!ELEMENT managed_element_reference

(name, (managed_element_class I managed_element_guid ) )>

<!— managed_element_class corresponds to the "typejname" field of the managed_element definition — > <!ELEMENT managed_element_class (#PCDATA)>

<!— managed_element_guid corresponds to the globally unique identifier of a specific managed element instance --> <!ELEMENT managed_element_guid (#PCDATA)>

********************************************************

** A control_reference specifies an instance of a ** ** particular control type. The control type can be ** ** one of the built-in types (as defined in this file)** ** or can be an externally defined type, in which case" ** you specify its type and values for the parameters " ** it requires. The attributes, methods, and events ** ** that the built-in controls support are defined in **

** the "controls.doc" file.

** **

** The name specified for the control must be ** ** unique among the names specified in the control ** panel definition, to allow the control to be ** ** unambiguously identified. **

<!ELEMENT control_reference (name, (button I gauge I switch I status_light I alphanumeric_display I dial ) )>

^ I *******************************_***************************

** button is a simple push button. It has one attribute **

** that can optionally be set, "push_handler", which is *

** a script that should be executed when the button is *

** pressed. It also supports one action, "push", and **

** sends one event, "buttonjpushed", as defined in **

** controls.doc. ** ********************************************************** -^ <!ELEMENT button (push_handler)? > < [ELEMENT push_handler (script) >

^ I ********************************************************

** gauge is an indicator that displays a value between**

** a minimum and maximum value. Its attributes **

** include its initial minimum & maximum values **

** (mandatory) & an optional initial value (which is **

** put into the current jvalue attribute at startup. **

** Events sent by gauge are defined in controls.doc. **

** All values must be set to valid numeric literals. ** ******************************************************** -^

<!ELEMENT gauge (minimurnjvalue, maximumjvalue, initial_value?)> <!— All values must be valid numeric literals. — > <!ELEMENT minimurnjvalue (#PCDATA)> <!ELEMENT maximumjvalue (#PCDATA)> <!ELEMENT initial jvalue (#PCDATA)>

^ I ********************************************************

** switch is a two-position (typically on/off) toggle.**

** It has one attribute that can be set, **

** "initia position", which can be set to the TRUE **

** position or the FALSE position. ** ******************************************************** -

<!ELEMENT switch (initial_position?)> < [ELEMENT initiaLposition (true I false) >

- • I ********************************************************

** status_light is a 4-color indicator light. It has **

** one attribute that can be set, its "initial_status"**

** Which can be one of blue, green, yellow, or red. ** ******************************************************** -

<!ELEMENT status ight (initial_status?)> <!ELEMENT initial_status (blue I green I yellow I red)>

^•1 ********************************************************

** alphanumeric_display displays a one-line text ** string. It has one attribute that can be set, its ** ** "initial value". ** ******************************************************** ->

<!ELEMENT alphanumeric_display (initialjvalue)?>

**********************************************************

<!-

** dial has minimum and maximum value attributes, which **

** must be set, along with an optional initial value. ** ********************************************************** --_

<!ELEMENT dial (minimumjvalue, maximumjvalue, initial_value?)>

^ I ********************************************************

** value **

<!ELEMENT value (#PCDATA)>

_ ********************************************************

** constant ** ******************************************************** .^

<!ELEMENT constant (#PCDATA)>

<!- ********************************************************

** "script" is used to define a piece of program code **

** that can be executed to perform an action and /or

** generate a return value. The program code can be

** written in any language. The "language" attribute *

** of the script tag specifies the language that is **

** being used, while the text between the script tags *'

** is a valid piece of code in the specified language.** ******************************************************** ^

<!ELEMENT script (#PCDATA) > <!ATTLIST script language CDATA "default" >

^ I ********************************************************

** LEAF NODES. These are used in other definitions. ** ************************************************_******** .-

<!ELEMENT name (#PCDATA)> <!ELEMENT true EMPTY> <!ELEMENT false EMPTY> <!ELEMENT blue EMPTY> <!ELEMENT green EMPTY> <!ELEMENT yellow EMPTY> <!ELEMENT red EMPTY> Samplep anel .xml

This is an XML file that defines a simple control panel for a

WindowsNTWorkstation managed element. It includes some knowledge of hoe to

interpret the raw data provided by the managed element's attributes /methods /events,

some knowledge of processes that are used to change the element's state, and

knowledge of how to react to certain conditions in the managed element's state.

<?xml version="1.0" standalone="yes" ?>

<!DOCTYPE controLpanel SYSTEM "control_panel.dtd">

<control_panel>

<!— We're defining a panel that can be used with any instance of the "WinNTWorkstation" managed element class. We'll assign it the name "elementl" which will be used to reference it throughout this file. —>

<managed_element_reference>

<name> elementl </name>

<managed_element_class> WinNTWorkstation </managed_element_class> < / managed_element_ref erence>

<!-- ********* INDICATORS ********* ->

<!— Here we are defining controls & wires for the two interpretive indicators in our example. We'll assume that both start off GREEN ->

<!- ********* "swap file size too small" indicator ********* _>

<control_reference> <name> swapTooSmalllndicator </name> <status_light> <initial_status> <green/> </initial_status> </status_light> < / control_ref erence> !— *_**_********** g_wap indicator Wire ****_*******_***_**** _>

<!— Here is the wire that makes the swap indicator work. It takes as inputs the cpuUtilization and contextSwitches attributes of the WinNTWorkstation element. — >

<wire> <name> swapIndicatorWire </name>

<!— cpuUtil wire input is connected to the cpuUtilization attribute — > <input_connection> <name> cpuUtil </name> <attribute>

<object_name> elementl </object_name> <attribute_name> cpuUtilization </attribute_name> </attribute>

<!^„ We _W1π i_e the inputs signal at the default frequency, so no frequency is specified here —>

< / input_connection>

<!— contextSwitches input is connected to the contextSwitches attrib — <input_connection> <name> contextSwitches </name> <attribute>

<object_name> elementl </object_name> <attribute_name> contextSwitches </attribute_name> </attribute>

<!— We will let the inputs signal at the default frequency, so no frequency is specified here — >

< / input_connection>

<!— output of the wire is connected to the "current_status" attribute of the status indicator control (see controls.doc for a description of the status indicator) ->

<output_connection>

<attribute> <object_name> swapTooSmalllndicator </object_name> <attribute_name> current_status </attribute_name>

</attribute>

< / output_connection>

<!— here is the function that computes what value to output based on the values of the inputs ~>

/ / This is a piece of Java code that will be compiled / / and used to compute the output value of the wire. / / In this code we can reference the values of the / / wire's inputs as we would reference a local varaible / / in Java. Note that we have to use < in place of / / the less than character, > in place of the greater / / than, and & in place of the ampersand. These will // be automatically converted when this file is parsed.

if (cpuUtil < 20.0f && contextSwitches > 20) return StatusIndicator.RED; else return StatusIndicator.GREEN;

</script> </ transform

</wire><!— END WIRE swapIndicatorWire ->

**************** CPU Thrashing Indicator

<control_reference>

<name> cpuThrashinglndicator </name>

<status_light> <initial_status> <green/> </initial_status>

</status_light> < / control_reference>

_<-! ***************** _f~"pτ j TT-irashincr Wire ******************** -_>

<!— Here is the wire that makes the CPU Thrashing indicator work. It takes as inputs the available VM and totalVM attributes of the WinNTWorkstation element. — > <wire> <name> cpuThrashinglndicatorWire </name>

<!— availVM wire input is connected to the available VM attribute ~>

<input_connection> <name> availVM </name> <attribute> <object_name> elementl </object_name> <attribute_name> available VM </attribute_name> </attribute>

<!~ We will let the inputs signal at the default frequency, so no frequency is specified here — >

< / input_connection>

<!— totalVM input is connected to the total VMattrib — >

<input_connection> <name> totalVM </name> <attribute> <object_name> elementl </object_name> <attribute_name> totalVM </attribute_name> </attribute>

< / input_connection>

<!— output of the wire is connected to the "current_status" attribute of the φu thrashing indicator control (see controls.doc for a description of the status indicator) — >

<output_connection>

<attribute> <object_name> uThrashinglndicator </object_name> <attribute_name> current_status </attribute_name>

</ attribute >

< / output_connection>

<!— here is the function that computes what value to output based on the values of the inputs — >

/ / This is a piece of Java code that will be compiled / / and used to compute the output value of the wire. / / In this code we can reference the values of the / / wire's inputs as we would reference a local varaible / / in Java. Note that we have to use < in place of / / the less than character, > in place of the greater / / than, and & in place of the ampersand. These will // be automatically converted when this file is parsed. if (availVM < (0.15 * totalVM)) return StatusIndicator.RED; else return StatusIndicator.GREEN;

</script> </transform> </wirex!— END WIRE φuThrashinglndicatorWire — >

_<!__ _{****************} ^c_j-ease _{Swap Size} Button

<!— Here we're defining a button that executes the procedure. It contains a simple script that executes the logic of the procedure. — >

<control_reference> <name> increaseSwapSizeButton </name> <button> <push_handler> <script language="Java"> / / Here we have a small Java script. Within this script / / we can refer to any of the objects defined in this / / definition file as we would refer to Java objects. / / The management application that reads this definition / / file will interpret this correctly. This illustrates / / how we can integrate more complex code into // the "control panel"

long growSize = elementl. swapFileSize / 10;

if (elementl. rootDriveFreeSpace < growSize) elementl. reeDiskSpace();

elementl. growSwapFile(growSize);

</script> < / push_handler > < /button </ control reference>

<-! ****************** ~o ition-Artinn Wirp ******************* ->

<!— This wire handles the WHEN..DO condition-action rule that automatically increases the swap file size when it is too small. All we need to do for this is to wire the output of the "swap too small" indicator to the "increase swap size" button. — >

<wire> <name> actionWire </name>

<input_connection>

<name> swapTooSmall </name>

</attribute>

< / input_connection>

<output_connection> <method> <object_name> increases wapSizeButton </object_name> <method_name> push </method_name> </method>

< / output_connection>

<!— No transform is necessary. The input always causes the output to be signaled. — > </wire>

< / control_panel>

Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.

Claims

CLAIMSWe claim:

1. A method comprising:

receiving management knowledge for a plurality of managed elements in a

machine inteφretable format to create a description for each of the plurality of

elements;

inteφreting the plurality of descriptions to create an internal representation for

each of the managed elements; and

managing the plurality of managed elements based on the internal

representation.

2. The method defined in Claim 1 wherein the management knowledge

comprises inteφretive knowledge.

3. The method defined in Claim 1 wherein the management knowledge

comprises procedural knowledge.

4. The method defined in Claim 1 wherein the management knowledge

comprises condition-action knowledge.

5. The method defined in Claim 1 wherein the management knowledge is

understandable to a user.

6. The method defined in Claim 1 wherein the management knowledge is

received from a memory embedded in at least one of the plurality of elements.

7. The method defined in Claim 6 further comprises: querying the at least one element to determine if management knowledge is

embedded in the at least one element; and

receiving a resource location indication to request embedded management

knowledge.

8. The method defined in Claim 7 wherein the resource location indication

comprises a universal resource locator (URL).

9. The method defined in Claim 1 wherein the plurality of elements

comprises at least a device, an application, and a service.

10. The method defined in Claim 1 wherein the management knowledge

comprises at least one attribute, at least one method and at least one event.

11. The method defined in Claim 1 wherein the management knowledge

comprises a control with zero or more attributes, methods and events.

12. The method defined in Claim 1 wherein the management knowledge

comprises at least one control, at least one wire and at least one control grouping.

13. The method defined in Claim 1 wherein the management knowledge

comprises a connection between two or more of a plurality of attributes, a plurality of

methods, and a plurality of events.

14. The method defined in Claim 1 wherein the management knowledge is

represented by at least one control and at least one wire connecting to the at least one

control.

15. The method defined in Claim 1 wherein the internal representation

comprises a plurality of objects.

16. The method defined in Claim 15 further comprising storing the plurality

of objects.

17. The method defined in Claim 1 further comprising:

creating objects corresponding to the management knowledge-

storing the objects in a database;

filling class references in control panels;

passing objects to an engine;

running the engine;

adding peer manager clients;

running a user interface.

18. The method defined in Claim 17 wherein filling class references in control

panels comprises:

identifying a number and type of class references in a panel;

generating a set of all permutations of managed objects in the database that

match the class references;

applying rules to the permutations; and

creating a new control panel for each permutation that satisfied the rules.

19. The method defined in Claim 18 wherein creating a new control panel

comprises copying an original control panel and replacing class references with

references to managed elements in the permutation.

20. The method defined in Claim 18 further comprising deleting one or more

newly created control panels for one or more permutations that satisfied the rules.

21. The method defined in Claim 18 wherein identifying a number and type

of class references in the panel comprises iterating through the references in the panel.

22. An apparatus comprising:

means for receiving management knowledge for a plurality of managed

elements in a machine inteφretable format to create a description for each of the

plurality of elements; and

means for inteφreting the plurality of descriptions to create an internal

representation for each of the managed elements; and

means for managing the plurality of managed elements based on the internal

representation.

23. The apparatus defined in Claim 22 wherein the management knowledge

comprises inteφretive knowledge.

24. The apparatus defined in Claim 22 wherein the management knowledge

comprises procedural knowledge.

25. The apparatus defined in Claim 22 wherein the management knowledge

comprises condition-action knowledge.

26. The apparatus defined in Claim 22 wherein the management knowledge

is understandable to a user.

27. The apparatus defined in Claim 22 wherein the management knowledge

is received from a memory embedded in at least one of the plurality of elements.

28. The apparatus defined in Claim 27 further comprises:

means for querying the at least one element to determine if management

knowledge is embedded in the at least one element; and means for receiving a resource location indication to request embedded

management knowledge.

29. The apparatus defined in Claim 28 wherein the resource location

indication comprises a universal resource locator (URL).

30. The apparatus defined in Claim 22 wherein the plurality of elements

comprises at least a device, an application, and a service.

31. The apparatus defined in Claim 22 wherein the management knowledge

comprises at least one attribute, at least one method and at least one event.

32. The apparatus defined in Claim 22 wherein the management knowledge

comprises a control with zero or more attributes, methods and events.

33. The apparatus defined in Claim 22 wherein the management knowledge

34. The apparatus defined in Claim 22 wherein the management knowledge

methods, and a plurality of events.

35. The apparatus defined in Claim 22 wherein the management knowledge

is represented by at least one control and at least one wire connecting to the at least one

control.

36. The apparatus defined in Claim 22 wherein the internal representation

comprises a plurality of objects.

37. The apparatus defined in Claim 36 further comprising means for storing

the plurality of objects.

38. The apparatus defined in Claim 22 further comprising: means for creating objects corresponding to the management knowledge;

means for storing the objects in a database;

means for filling class references in control panels;

means for passing objects to an engine;

means for running the engine;

means for adding peer manager clients;

means for running a user interface.

39. The apparatus defined in Claim 38 wherein filling class references in

control panels comprises:

means for identifying a number and type of class references in a panel;

means for generating a set of all permutations of managed objects in the database

that match the class references;

means for applying rules to the permutations; and

means for creating a new control panel for each permutation that satisfied the

rules.

40. The apparatus defined in Claim 39 wherein the means for creating a new

control panel comprises means for copying an original control panel and means for

replacing class references with references to managed elements in the permutation.

41. The apparatus defined in Claim 39 further comprising means for deleting

one or more newly created control panels for one or more permutations that satisfied

the rules.

42. The apparatus defined in Claim 39 wherein the means for identifying a

number and type of class references in the panel comprises iterating through the

references in the panel.

43. An apparatus for managing a plurality of managed elements in a

networked environment, the apparatus comprising:

a first module to convert the management knowledge into a set of internal

objects;

a database to store objects created by the first module;

an engine to cause objects to run;

a data collector for collecting data from the networked environment;

a scheduler for scheduling actions;

a data listener for receiving data sent from external sources and distributing the

data to any object requesting the data;

peer manager clients; and

peer manager server to interface the engine to peer manager clients.

44. The apparatus defined in Claim 43 wherein the data collector uses a

plurality of protocol handlers to collect data using a plurality of protocols.

45. The apparatus defined in Claim 43 wherein the data collector collects data

on a periodic basis.

46. The apparatus defined in Claim 43 wherein the data collector collects data

on demand.

47. The apparatus defined in Claim 43 wherein the database also stores

objects imported from other applications.

48. The apparatus defined in Claim 43 wherein the database also stores

objects created by discovery.

49. An article of manufacture having one or more recordable media having

executable instructions stored thereon, which, when executed by one or more

processing devices, cause the one or more processing device to:

receive management knowledge for a plurality of managed elements in a

elements;

inteφret the plurality of descriptions to create an internal representation for each

of the managed elements; and

manage the plurality of managed elements based on the internal representation.

50. The article of manufacture defined in Claim 49 wherein the management

knowledge comprises inteφretive knowledge.

51. The article of manufacture defined in Claim 49 wherein the management

knowledge comprises procedural knowledge.

52. The article of manufacture defined in Claim 49 wherein the management

knowledge comprises condition-action knowledge.