WO2002093429A1

WO2002093429A1 - A generic interface for system and application management

Info

Publication number: WO2002093429A1
Application number: PCT/US2002/014532
Authority: WO
Inventors: Stan Froyd; Mike J. Little; Dov Zimring
Original assignee: Occam Networks
Priority date: 2001-05-15
Filing date: 2002-05-06
Publication date: 2002-11-21
Also published as: US6725233B2; US20020174091A1

Abstract

Data available in a system (850) is identified. Each data is categorized as a scalar data or a tabular data. The tabular data is associated with data from a table and the scalar data is not. Each data is further categorized as a parameter data or a statistic data. The statistic data is pulled (817) from the system. The parameter data is either pulled from the system or pushed (816) to the system. The data is grouped into groups based on logical relations:tips of data in the groups. A blank form (815) is developed for each group of data. Each blank form has one or more fields defined to accommodate the data in the group. Using the blank form, the data is pushed to the system and to pulled from the system.

Description

A GENERIC INTERFACE FOR SYSTEM AND APPLICATION MANAGEMENT

FIELD OF THE INVENTION

[0001] The present invention relates generally to field of system interface. More

specifically, the present invention is directed to sending and receiving data to and from a system.

BACKGROUND

[0002] Embedded systems are growing more and more complex, requiring a

range of external management applications such as SNMP, Command Line

Interfaces, TNM, WBEM, etc. These applications have completely different

interfaces, network protocols and purposes but must all interface to the low-level

internals of the system.

[0003] In order for a system to perform successfully in a user environment, it is

necessary that the user be able to configure the system to operate as desired, and

to be able to observe the device for troubleshooting and monitoring purposes.

Further, the system needs to be able to provide its configuration at any moment

and needs to be able to be restored to captured configuration. The configuration

may possibly be editted offline. This functionality is collectively known as

"management".

[0004] Management may be effected through a variety of user interfaces. The

most common is Command Line Interface (CLI), where configuration and display commands are entered in text mode and promptly executed. Another common

interface is Simple Network Management Protocol (SNMP) where configuration - and monitoring data is transmitted over the network.

[0005] A technology currently in development by Sun Microsystems and various

partners is working towards a much broader and more abstract framework. JMX

(Java Management Extensions) is a Java based model for implementing management services independent of a management protocol. Sun's model is

much broader in scope and is also incomplete; the specifications are in an early

form of definition by the JMX community. JMX completely replaces the internal

applications with their own framework.

[0006] It would be advantageous to have an interface definition that allows

implementers of device drivers and low-levςl system services to provide

configurable attributes and statistics to the higher-level system management

applications without knowing anything about the system management

applications.

SUMMARY OF THE INVENTION

[0007] In one embodiment, method for providing a generic interface is disclosed. Data available in a system is identified. Each data is categorized as a scalar data

or a tabular data. The tabular data is associated with data from a table and the

scalar data is not. Each data is further categorized as a parameter data or a

statistic data. The statistic data is pulled from the system. The parameter data is either pulled from the system or pushed to the system. The data is grouped into

groups based on logical relationships of data in the groups. A blank form is

developed for each group of data. Each blank form has one or more fields

defined to accommodate the data in the group. Using the blank form, the data is

pushed to the system and pulled from the system.

BRIEF DESCRIPTION OF THE DRA INGS

[0008] The present invention is illustrated by way of example in the following drawings in which like references indicate similar elements. The following

drawings disclose various embodiments of the present invention for purposes of

illustration only and are not intended to limit the scope of the invention.

[0009] Figures 1A and IB provide exemplary illustrations of an Interface

Manager.

[0010] Figure 2 is an illustration of an exemplary hierarchy of forms and form

classes defined by the present invention.

[0011] Figure 3 is an exemplary illustration of three instances of a form.

[0012] Figure 4 is a table illustrating exemplary XML (Extensible Markup

Language) tags.

[0013] Figure 5 is an exemplary illustration of a push operation and an XML file

mapping the push operation.

[0014] Figure 6 is an exemplary illustration of a tree representation of an XML

document describing a CLOCK SET command.

[0015] Figure 7 is an exemplary illustration of a pull operation and an XML file

mapping the pull operation.

[0016] Figure 8 is an exemplary illustration of interfaces between the internal

manager, CLI and SNMP. DETAILED DESCRIPTION

[0017] In one embodiment of the present invention, a method for providing a generic interface is disclosed. A framework is used for delivering data to and

from the system. The framework consists of different delivery vehicles or forms to carry different types of data.

[0018] The following detailed description sets forth numerous specific details to provide a thorough understanding of the invention. However, those of

ordinary skill in the art will appreciate that the invention may be practiced

without these specific details. In other instances, well-known methods,

procedures, protocols, components, algorithms, and circuits have not been

described in detail so as not to obscure the invention.

[0019] Generally, a system is managed by using high-level applications that

collect data from or send data to the system. The system may also be managed

by issuing commands using a command line interface (CLI).

[0020] In one embodiment of the present invention, a framework is provided for

system management that is abstracted from the low-level elements of the system

to be managed and the high-level applications that manage them. Collectively,

this framework is called the Internal Manager or IMGR of the system.

[0021] The IMGR performs as an abstraction layer between system implementation and system management applications independently of both

applications. The IMGR provides a generic interface for saving and restoring

system state. The IMGR also provides a generic interface that allows for the retrieval of data (e.g., scalar and tabular data) from the system. For example, the

IMGR provides an interface definition that allows implementers of device drivers and low-level system services to provide configurable attributes and

statistics to the higher-level system management applications without knowing

anything about the system management applications. The IMGR also allows

system management application developers (e.g., CLI, SNMP, etc.) to work

autonomously, promoting code reuse and information hiding as well as

programmer productivity. In addition, the IMGR provides a uniform interface

across the system that can handle the complicated task of saving and restoring

system state.

[0022] The IMGR is a system wide construct that allows the low-level

developers of a system to provide access to data (e.g., parameters, statistics, etc.)

of the system without having any knowledge of the applications that will use

this data. It is a system wide abstraction layer, below which are kernel device

drivers and various system services software and above which are the

applications that provide management services. Using this framework,

applications can be insulated from the system implementation and vice versa.

[0023] Figures 1A and IB provide exemplary illustrations of an Interface

Manager. Referring to Figure 1A, the system 115 includes hardware

components, operating software, device drivers, etc. As described herein, a

range of different management applications is used to control and manage the

system 115. [0024] In one embodiment, the IMGR 110 is created between the command line

interface (CLI) 105 and the low-level elements (e.g., kernel device drivers and various system services software, etc) of the system 115. The IMGR 110 lies between the user management (CLI, SNMP, etc.) and the operating software

and serves as an intermediary abstraction layer. The IMGR 110 operates to

provide translations of functions of the low-level elements in the system 115 to the CLI 105. Although the CLI 105 is used in this discussion, it would be

apparent to one skilled in the art that the description may also be applicable to

other management applications (e.g., SNMP application, etc.) at the same layer as the CLI 105, as illustrated in Figure IB.

[0025] The IMGR 110 defines an abstract interface and a framework gluing

internal applications (at the CLI 105) to the system 115 they are to manage. In

one embodiment, it is assumed that only data is conveyed between the IMGR

110 and the operating software in the system 105.

[0026] The IMGR 110 provides a representation of system data based on an

extensible interface that uses a notion of forms with special operations. These

forms can be "pulled" from the system to retrieve attributes such as system

settings and statistics or pushed into the system to handle configuration. The

IMGR 110 is based on object-oriented concepts requiring a programmer to

implement specific interfaces. These interfaces make available certain

operations to the managers such as, for example, the concept of a "GETNEXT" operation that can be used on any table of meta-data to traverse its rows and columns irrespective of the underlying data type and bounds of the table. [0027] In one embodiment, the IMGR 110 includes a group of Java objects which are extensions of a base form object. Each form carries data. Both the

application layer (e.g., CLI layer 105) and system layer 115 (with its operating

software) are knowledgeable of particular editions of these forms, which are the basis of communications between these layers. In addition to carrying data, the

forms may also operate on the data they carry. For example, the form may

format the data for user presentation, or it may assist in traversing instances of a

table.

[0028] The data from the system 115 can be statistic data or parameter data.

Statistic data are data maintained by the operating software. Statistic data are

thus considered to be read-only from a management point of view. For

example, there is no SET type of operation for statistic data. Thus, statistic data

can only be pulled from the system. For example, a number of times the clock

has been read is considered a statistic data. Statistic data can also be considered

as counters maintained by the operating software.

[0029] As described above, data may be parameters or statistics. Data that is not

statistic data is considered parameter data. Individual parameter data may be

read-only (RO) or read-write (RW). Thus, all parameter data can be pulled and

some parameter data can be pushed. Referring to Figure IB, data sent from the

IMGR 110 to the system 115 is parameter data and not statistic data. However, data sent from the system 115 to the IMGR 110 can be either statistic data or parameter data.

[0030] The base form object can be implemented as a data structure defined with one or more fields to carry the data to the system 115 or from the system 115.

Data are gouped onto the same form based on logical relationships of the data.

New forms can be added to accommodate different groupings of data. In one

embodiment, there is one operating software function for pulling (populating)

the form, and zero or one function for push the form. At the upper interface

(e.g., CLI layer 105), however, it may take several forms to satisfy a particular

CLI command.

[0031] In one embodiment, when a form is pulled (from the system), all

parameter data will be filled out by the operating software in the appropriate

fields. When a form is pushed (to the system), the operating software will look

only for those fields in the form which have the RW (read-write) attributes. For

example, a SETCLOCK operation involves pushing parameter data, while a

READCLOCK operation involves pulling parameter data. If information about

the number of times the clock has been read is required, a CLOCKREAD

operation would pull statistic, using a separate form. Thus, parameter data is

different from statistic data. Note that a form is merely a snapshot of data (or an

instance) at a particular time.

[0032] When a form carrying data from the system 115 is received by the IMGR

110, the IMGR 110 presents the form to the management applications or the CLI 105. In one embodiment, the data in the form are automatically formatted for

presentation to the CLI 105 or for presentation to the management applications at the CLI layer. Similarly, when the IMGR 110 presents a form to the operating software in the system 115, the data in the forms is presented according to an

appropriate data structure understood by the operating software. Thus, code

that places data in a form and code that extracts data from the form are

knowledgeable about a layout of the form such that the data in the form can be

consistently interpreted. In one embodiment, it is acceptable to have RO

parameter data and RW parameter data on the same form. Note that multiple

instances of the same form can be extracted with each instance possibly having

different data.

[0033] There may be multiple forms to carry different types of data with each

form used to carry one or more data. A form may be used to carry data in

response to different actions. For example, the same form may be used to carry

statistic data from the system 115 in response to different actions issued by the

CLI 105 or by the management applications. Similarly, the same form may be

used to carry parameter data from or to the system 115 for different actions.

There may be different forms for different commands.

[0034] A form may be pulled from the system 115 to gather system attributes

(e.g., system configurations, settings, statisistics, etc.). For example, a filled-out

form can be pulled up from the operating software as a result of a

GET/SHOW/ DISPLAY command from the CLI 105. A form may be pushed to the system 115 to set system configuration. For example, parameter data

associated with a command SET /CONFIGURE is pushed in a form to the operating software in the system 115. There is a one-to-one correspondence

between a form and platform code that fills out or reacts to a form. Knowledge

of the different forms is required for the different push and pull operations

between the management applications/CLI 105 and the system 115. These forms form a basis of communication between the management

applications/CLI 105 and the system 115

[0035] Figure 2 is an exemplary illustration of hierarchy of forms and form

classes. In one embodiment, the interaction between the CLI 105 and the IMGR

110 is performed using commands in a command set. For example, the

command set may include a GET NEXT command that can be used to traverse

rows and columns of a table data structure. As described herein, each of the

commands in the command set is associated with a form and that there may be

multiple distinct forms.

[0036] Referring to Figure 2, a form 205 may be designed to work with a single

data ("scalar data") in a scalar entity class 210 or with a row of data in a table

("tabular data") in a table entry class 215. The data in the table entry class 215

may be further subclassed as parameter data 225 or statistic data 226. Similarly,

the scalar entity class 210 may be further subclassed as parameter data 227 or

statistic data 228. Thus, a form 205 may be categorized as one of the four

following abstract subclasses: InternalManager - Table - Parameter

InternalManager - Table - Statistic

InternalManager - Scalar - Parameter

InternalManager - Scalar - Statistic.

The tabular data may be accessed as an instance. For example, the form may

correspond to exactly one row of the table, and rows of a table can be

differentiated by some combination of columns of the table. Different instances

of the same table can be used so that specific entries in the table can be located,

or so that the table can be traversed. In one embodiment, a form 205 cannot be

used to carry a mixed combination of scalar data and tabular data. In another

embodiment, a form 205 does not support tables within tables.

[0037] In one embodiment, the command set supported by the IMGR 110 should

at least have pull management commands for pulling statistic from the system

115. This allows for at least some monitoring capabilities. In another

embodiment, data originally placed on one form may be presented in multiple

forms. For example, data pulled from the system 115 to the IMGR 110 may be

placed on one form, but the IMGR 110 may extract the data from the one form

and place them onto multiple forms before they are presented to the management applications or the CLI 105. The operating software of the system

115 fills out the forms to be pulled from the system. The operating software of

the system 115 also processes forms pushed down to it by the IMGR 110. [0038] In one embodiment, it is acceptable to have both parameter data and statistic data on the same form. Thus, a form may be a parameter form, a statistic form, or a parameter and statistic form. For example, an interface index

item might appear on the same form as an interface statistic data in order to

correlate the interface and the associated statistic data. The interface index item

may also appear on several forms carrying parameter and/or statistic data. In one embodiment, just because a data is on a parameter form, it isn't necessarily

settable, though other items on the same form might be settble. In one

embodiment, a speed of the interface may be settable, but not its identity. For

example, it is likely that statistic data would be pulled from the system

frequently and repetitively (e.g., for monitoring purpose), and as such, forms

used to carry statistic data may be handled differently for optimization.

[0039] Figure 3 is an exemplary illustration of three instances of a form.

Referring to Figure 3, the three instances 305, 310 and 315 of the same form 300

are received at three different times. Each instance provides a snap shot of the

data on the form 300 at a particular time. In one embodiment, each form is

timestamped when it is used to carry the data. The timestamp may be used to

compare how much a statistic data has changed since a previous pull operation.

For example, the instance 305 of the form 300 has a time stamp field 320. In one

embodiment, the instance 305 is stored so that it can be used to compare with a

next instance of the same form. [0040] In one embodiment, a delta value is pulled rather than an absolute value.

For example, the instance 310 of the form 300 has a delta value 325. The delta value 325 indicates a differece from the absolute value 322 in the instance 305.

In another embodiment, for each pull operation, an indicator may be set on the

form to indicate to the system 115 that the fields on the form need to be updated

only when the system 115 has different values than the default startup values for those fields. When a pull operation is not successful, a "fail" condition may be returned to the management applications or to the CLI 105.

[0041] Each of the fields on a form may carry non-null values or null values. In

one embodiment, when there is a push operation, any fields on the form that

have null values may be disregarded by the system 115. The system 115 needs

to extract data from those fields that have non-null values. The non-null values

may or may not be acceptable by the system 115. For example, a non-null value

may be alphanumeric when the system 115 expects a numeric value. When this

occurs, error condition may be communicated by the system 115 to the

management applications or the CLI 105.

[00421 In another embodiment, each form may be associated with a "save" and a

"restore" function. For example, when the "save" function is invoked for a

particular form, data corresponding to the fields on that form are pulled from

the system 115. The data then sent to a destination (e.g., user, management

application, data file, etc.). When the "restore" function is invoked, the

previously saved data is placed into the appropriate form. The form is then pushed down to the system 115. The data is then extracted from the form to complete the restore operation.

[0043] An instance of a form may have scalar data or it may have tabular data.

As described herein, when a form is used to carry tabular data, each instance of

the form carries one row of data from the table. An indicator may be sent along

with the form to provide information regarding where the row is in the table. It

is assumed that the table remains constant during the lifespan of the push or pull operations.

[0044] When a command associated with a pull operation (e.g., SHOW

command) is issued using the CLI 105, an interpreter resolves the command into

an object/method pair. The "object" is a glue that calls a static method in the

form class which in turn pulls an instance of the form up from the system 115

and generates display information back to the CLI 105. The form can also be

read by the method of the glue object.

[0045] When a command associated with a push operation (e.g., CONFIG

command) is issued using the CLI 105, the command can also be resolved to an

object/method pair. In this example, an empty instance of the form is created

and the command parameters are translated into settings of the fileds of the

form. The form is then pushed to the operating software in the system 115 to

effect the push operation.

[00461 When the IMGR 110 is used to interface with SNMP (as shown in Figure

IB), most of the SNMP code is automatically generated by an agent software (e.g., AdventNet software from AdvenNet, Inc. of Pleasanton, California) when it interprets a Management Information Base (MIB) file. In one embodiment, lowest levels of this agent code are edited to effect the "instrumentation" part of SNMP operations. In one embodiment, when a GET command on an object is

processed by the runtime agent, a form containing the item is pulled up from

operating software, and the value of the data is read from the form. Similar

processing is performed for a GETNEXT command. GETFIRST and GETNEXT

functions are provided as static methods in the form. SET commands are also

handled one varbind at a time. In one embodiment, a new empty form is

created, set the varbind value into the form field, and push it down to the

operating software. SNMP may be used for monitoring.

[0047] The IMGR 110 expects the operating software to provide a static pull and

a static push function. In both cases, a reference to a form instance is passed as

an argument. In one embodiment, when the form is for a table, another

argument specifies the sequence number (not the instance) of the entry in the

table (the table is assumed to remain constant during the lifespan of the

operation).

[0048] In the case of pull operations, there is an additional flag argument

indicating that the operating software should only fill out the fields of the form

that have different values than the default startup values of the system. In the

case of push operations, any fields of the form that are null can be disregarded -

only the fields that are non-null need to be acted upon. The form provides public methods for setting and getting the fields of the form. In one

embodiment, the same form can be used for push and pull operations. [0049] In one embodiment, "native" methods are used where the C code of the platform accesses the methods and fields of the Java class. In the pull direction

(from the system to the applications), the setter methods of the form object are

used to fill out the form, while in the push direction, the fields of the form are accessed directly. Other approaches include use of "exec" functions called from within the form, or via the reading of 'proc' files.

[0050] In one embodiment, FAIL indications are returned if the pull operations do not succeed. In the case of push operations, even though there may be

careful checking by SNMP and by CLI before pushing a form, there may be

situations that a pushed form might not be acceptable by the operating

software. A set of exceptions is provided for these situations.

[0051] Figure 4 is a table illustrating exemplary XML (Extensible Markup

Language) tags. The XML document can be viewed as a description document

providing descriptions about how to interpreret parameter data and statistic

data. Each tag occurs in the XML document as a <tagname>...</tagname>

combination. Attributes are enclosed in the tag fields with their values bounded

by a pair of double quotation marks such as, for example, <tagname

attribute="value">.

[0052] The <cli> tag 405 is the top-level element of the XML document. All

other tags are subtags of this top-level <cli> tag 405. This <cli> tag 405 has no attributes and text inside the <cii> tag 405 is ignored. The <mode> tag 410 contains the mode of the management command. There should be only one <mode> tag 410 in the XML document. The <mode> tag 410 has a single

attribute which identifies the name of the mode such as, for examples, <mode

name='global'> or <mode name="exec">. The <command> tag 415 is the top-

level tag for a single command. It has no attributes and text inside the <command> tag 415 is ignored. The <command> tag 415 contains a single

<keyword> tag such as, for example,

</keyword>

</command>.

The <keyword> tag 420 specifies the text of a command keyword in

the command set of the CLI such as, for example SHOW, ENABLE or

LOGOUT. The text is supplied by the single attribute "text". The keywords

may contain other <keyword> tags to specify subkeywords.

[0053] The <help> tag 425 specifies help information for the command / keyword. The <help> tag 425 has no attributes. The text enclosed by the <help>

tag 425 defines the help text for the outlying tag, i.e. for a keyword or argument.

One example of the help information follows: <keyword text="show"> <help>Show running system information </help> <keyword text="clock">

</keyword> [0054] The <action> tag 430 specifies that there is a executable action for the enclosing keyword. For example, the action specified within the <action> tag

430 is carried out for the associated command when the carriage return is

presses. The "object" and "method" attributes of the <action> tag 430 specify an object and a method in the system by name. A collection of Java type

interfaces is created for the "objects" and "methods" that get invoked during

run-time. One example of the object and the method follows:

</action>.

[00551 The <arg> tag 435 defines an argument type for an <action> tag 430. The

<arg> tag 435 has no arguments and text in the <arg> tag 435 is ignored. A

single <type> tag or <help> tag may be inserted in the body of the <arg> tag

435. One example of the <arg> tag 435 follows:

<arg>

<help>destination address or hostname</help>

</arg> [00561 The <type> tag 440 describes a Java type for input to the invocation of the

object, method pair specified by the <action> tag 430. The Java type name is entered as a "type" attribute of the <type> tag 440. Other text in the body of the

<type> tag 440 other than those associated with the "type" attribute is ignored. [0057] In this example, XML is used to describe the command language. XML is advantageous because there are a lot of available XML tools (e.g., editor tool,

browser tool, etc.) for development. Although XML is used, one skilled in the

art would recognize that other generalized markup languages might also be

used to describe or map the management commands to the objects of the

system, where the objects are low-level functions implemented in the system.

[0058] Figure 5 is an exemplary illustration of a push operation and an XML

document mapping the push operation. The XML document 525 describes

statically all the keywords, arguements, and mapping from a CLOCK SET

command to action in the system that will cause the action corresponding to the

CLOCK SET command to be carried out. The CLOCK SET command is made

available to a user or a management application interfacing with the system

even though the system may not have the exact CLOCK SET command in its

own command set. The XML document 525 describes the hierarchy of the

CLOCK SET command keyword by keyword. Each command is associated with

an action defined as an "object" and a "method".

[0059] The command 505 illustrates the "help" feature by specifying the "?" as

part of the of command argument. This "help" feature is also illustrated in the command 510 and 515 to get additional information about the format (e.g., time,

month, year) of the CLOCK SET command. The command 420 illustrates a complete CLOCK SET command with all the possible arguments or parameters specified. The XML document 525 describes the CLOCK SET command 505-520 using the XML tags described in Figure 4. At run-time, the command CLOCK

SET issued by the user or the management application is recognized by the

interpreter as corresponding to the command keyword CLOCK shown on line

527 and the keyword SET shown on line 528. There may be multiple command

keywords in the same XML document in addition to the CLOCK command.

The interpreter will parse the XML document 525 to determine if the command

is a valid command. In the current example, the help information requested in

the commands 505-515 is enclosed in the <help> tags on lines 530, 535, 540 and

545 respectively.

[0060] Depending on the format of each of the CLOCK SET commands 505-520,

a form containing information extracted from the arguments/ parameters of the

XML document 525 is pushed to the operating software at the lower-layer. The

operating software then executes the action specified by the "object" and

"method" attribute of the <action> tag shown on line 529. Results (i.e., statistical

data) associated with this action is then pulled up from the lower layer and

displayed to the user or presented to the management application in another

form.

[0061] Figure 6 is an exemplary illustration of a tree representation of an XML

document describing a CLOCK SET command. An XML document created

using the tags described in Figure 4 is translated into a tree format that can be interpreted at run-time. The structure of the tree corresponds to the tags and

attrbutes in the XML document. The tree also contains all of the texts enclosed by any of the tags so that every piece of information in the XML document is reflected in the resulting tree. Each tree describes what the command is and

what the expected arguments /parameters are. In one embodiment, a Java

Document Object Model (DOM) library is used to parse the XML document into

a resulting tree or DOM tree. The DOM tree contains a collection of Java objects

that represent the tags, attributes, and text of the corresponding XML document.

The DOM tree in Figure 6 corresponds to the CLOCK SET command described

in the XML document 525 illustrated in Figure 5. Note that there are only two

keyword nodes 605, 610 corresponding to the keywords CLOCK and SET

respectively. Note also that there are four argument nodes 620-635 under the

action node 615. The four argument nodes 620-635 correspond to the

arguments for "time", "day of month", "month" and "year" of the CLOCK SET

command. The DOM tree and its collection of Java objects are translated into a

collection of Java run-time classes.

[0062] Figure 7 is an exemplary illustration of a pull operation and an XML

document mapping the pull operation. The pull operations in this example

include a SHOW CLOCK command 705 and a SHOW CLOCK DETAIL

command 710. The XML document 715 illustrates a description of the above

two commands 705 and 710 using XML keyword tags described in Figure 4.

The XML document 715 describes the SHOW CLOCK command using keywords, sub-keywords, help text, arguments, and specification of actions to be carried out by the lower-layer operating software.

[0063] The XML document 715 is presented in its source format and is normally

compiled using an XML compiler so that it can be used by a run-time system.

When a user or a management application issues the command, the run-time

system performs object mapping, method mapping and the arguments / parameters are provided to the operating software of the system to carry out the

action. For example, when the command SHOW CLOCK 705 is issued, the run¬

time system executes the action associated with an object CLOCK and a method

SHOW, shown on line 720. When the command SHOW CLOCK DETAIL 710 is

issued, the run-time system executes the action associated with an object

CLOCK and a method SHOWDETAIL, as shown on line 725. The run-time

system invokes a collection of Java system interfaces corresponding to the object

and method specified in the action. The run-time system then collects data

(parameter data) from the system, put them in a form and presents the form to

the user or to the management application.

[0064] Using the method of the present invention, commands that are associated

with the system and that are used to control the system can be shielded from the

user. These commands can be described and expressed using a universal

description language such as, for example, XML. A set of common commands is

created by describing all of the commands associated with the system. For

example, XML can be used to create a new set of commands that describe commands associated with a Lucent router such that the new set of command is

consistent with commands associated with routers from Cisco. One skilled in the art would recognize that commands for other vendors can also be

implemented. Using this method also shield the users from changes or version

upgrades applied to the operating software of the system. In addition, when a

new system is used, the commands can be made to be the same by describing and mapping the commands to the objects and methods of the new system.

Thus, as shown in Figures 1A and IB, by having the internal manager as the

middle layer, the command set available in the upper layer through the CLI is

independent of the system of the lower layer.

[00651 Figure 8 is an exemplary illustration of interfaces between the internal

manager, CLI and SNMP. The run-time versions of the commands described

using the generalized markup language such as, for example, XML, may be

stored in a command description file 802. When the user 801 enters a command,

the CLI 805 searches the command description file 802 for the corresponding

definition to carry out the command. The method of the present invention can

also be used in a network environment using, for example, simple network management protocol (SNMP) and management information base (MIB). MIB

modules specify targets of management operations. The MIB modules are

interpreted to identify the target of management operations. [0066] Instead the user or the management application issuing commands

through the CLI, management commands are issued using SNMP 810. SNMP 810 interfaces with the IMGR 110 to access information from the system 850. In

one embodiment, the IMGR 110 is divided into several IMGR packages 820, 825, and 830. Each of the IMGR packages 820, 825 and 830 corresponds to a group of related services provided by the system 850. For example, the services may be

grouped under IP routing, ATM routing, etc.

[0067] The IMGR package 825 transfers data between the system 850 and SNMP

using forms 815, as described above. The IMGR package 825 includes a client

interface 814, pullers 817 and pushers 816. When a command is issued by a uer

801 though the CLI 805, the command is sent to the appropriate IMGR package

825. For example, when the command is a SET CLOCK command, the CLI 805

sends the command to the IMGR package 825 because it recognizes that the

IMGR package 825 processes system related commands including the SET

CLOCK command. The CLI 825 is abie to make this recognition because, at an

earlier time, the client interface 814 in the IMGR package 825 was registered

with the CLI 805. This registration allows the client interface 814 to indicate to

the CLI 805 that the client interface 814 handles system related commands. The

client interface 814 is aware of the specific actions of the system 850.

[0068] The IMGR package 825 fills the form 815 with parameter data for push

operations. The IMGR package 825 may also use the form 815 to extract

parameter data and/ or statistic data using pull operations. For example, when

a GET operation is processed by the IMGR package 825, the form 815 containing the appropriate data is pulled up from the system 850. The data is then read from the form 815 by the SNMP 810.

[0069] Consider the following example of the results of an SNMP GET operation:

.1.3.6.1.2.1.17.4.3.1.1.255.255.255.255.255.3 = ff ff ff ff ff 03

This can be rewritten as:

{DotldTpFdbTable}.{Macadress}.(255.255.255.255.255.3} = ff ff ff ff ff 03

And interpreted as:

The MAC address of the Fdb Table entry whose MAC address is

255.255.255.255.255.3 is ff:ff:ff:ff:ff:03

In this example, within the FdbEntry form, there is a field containing a

MacAdress object. Access methods are provided to provide the value of the

address in the two different schemas that SNMP requires: as a string

("255.255.255.255.255.3") as used for instancing an object, and as a 6-byte OCTET

STRING used for the value. Internally, the MacAddress is kept as a 6-element

integer array.

[0070] The GET operation described above can also be used to get a

configuration of the system 850. A blank form 815 is pushed to the system by

the pushers 816. Recognizing that the action is associated with a SAVE

operation, the operating software of the system 850 fills out the blank form with

configuration data. The filled-out form 815 is then pulled from the system 850

by the pullers 817. The configuration data may then be saved in a configuration file 818 for a subsequent restore operation. In one embodiment, the

configuration file is saved in XML format. When a restore function is invoked, the configuration file 818 is processed into CLI command lines. The CLI command lines are fed back to the CLI 805.

[0071] From the above description and drawings, it will be understood by those

of ordinary skill in the art that the particular embodiments shown and described are for purposes of illustration only and are not intended to limit the scope of

the invention. Those of ordinary skill in the art will recognize that the invention

may be embodied in other specific forms without departing from its spirit or

essential characteristics. References to details of particular embodiments are not

intended to limit the scope of the claims.

Claims

CLAIMSWhat is claimed is:

1. A method, comprising: identifying data available in a system, each data categorized as a scalar data or a tabular data, wherein the tabular data is associated with data from a table and the scalar data is not, each data is further categorized as a parameter data or a statistic data, wherein the statistic data is pulled from the system, and wherein the parameter data is either pulled from the system or pushed to the system;

grouping the data into groups based on logical relationships of data in the groups;

developing a blank form for each group- of data, each blank form having one or more fields defined to accommodate the data in the group; and

using the blank form to push the parameter data to the system and to pull the parameter data or the statistic data from the system.

2. The method of claim 1, further comprising filling the blank form with the parameter data to push to the system.

3. The method of claim 1, wherein the form is one in a group consisting of table-parameter, table-statistic, scalar-parameter and scalar-statistic.

4. The method of claim 1, wherein the statistic data and the parameter data can be carried on the same form, and wherein the tabular data and the scalar data cannot be carried on the same form.

5. The method of claim 1, wherein the forms are pushed to the system or pulled from the system in response to actions associated with commands.

6. The method of claim 5, wherein the command is issued from a command line interface (CLI), an application, or by using Simple Network Management Protocol (SNMP).

7. The method of claim 6, wherein the command provides parameter data to fill out the forms to be pushed to the system.

8. The method of claim 7, wherein the parameter data and the statistic data are used by an operating software in the system to fill out the forms to be pulled from the system.

9. The method of claim 8, wherein the form pulled from the system is timestamped.

10. The method of claim 9, when multiple pulling of the same forms is performed, each pulling of the form provides an instance of the data.

11. The method of claim 10, wherein after a first instance of the form is pulled, subsequent pulling of the same form provides delta data values for all fields in the form having values changed from a previous instance.

12. The method of claim 11, wherein between the system and a layer where the command is issued is an intermediary layer, the intermediary layer reformats the data pulled from the system and the data pushed to the system.

13. The method of claim 12, wherein the intermediary layer reformats the pulled data so that the pulled data is understood by the command, and the intermediary layer reformats the pushed data so that the pushed data is understood by the operating software in the system.

14. The method of claim 1, wherein an instance of a form carrying the parameter data pulled from the system is saved when the parameter data includes a state of the system at a time the parameter data is pulled.

15. The method of claim 14, wherein the saved parameter data that includes the state of the system is used to restore the system to the same state as when the parameter data is pulled.

16. A computer readable medium having stored thereon sequences of instructions which are executable by a digital processing system, and which, when executed by the digital processing system, cause the system to perform a method comprising: identifying data available in a system, each data categorized as a scalar data or a tabular data, wherein the tabular.data is associated with data from a table and the scalar data is not, each data is further categorized as parameter data or a statistic data, wherein the statistic data is pulled from the system, and wherein the parameter data is either pulled from the system or pushed to the system;

developing blank forms for each group of data, each blank form having one or more field defined to accommodate the data in the group; and

using the blank form to push data to the system and to pull data from the system.

17. The computer readable medium of claim 16, further comprising filling the blank form with the parameter data to push to the system.

18. The computer readable medium of claim 16, wherein the form is one in a group consisting of table-parameter, table-statistic, scalar-parameter and scalar-statistic.

19. The computer readable medium of claim 16; wherein the statistic data and the parameter data can be carried on the same form, and wherein the tabular data and the scalar data cannot be carried on the same form.

20. The computer readable medium of claim 16, wherein the forms are pushed to the system or pulled from the system in response to actions associated with commands.

21. The computer readable medium of claim 20, wherein the command is issued from a command line interface (CLI), an application, or by using Simple Network Management Protocol (SNMP).

22. The computer readable medium of claim 21, wherein the command provides parameter data to fill out the forms to be pushed to the system.

23. The computer readable medium of claim 22, wherein the parameter data and the statistic data are used by an operating software in the system to fill out the forms to be pulled from the system.

24, The computer readable medium of claim 23, wherein the form pulled from the system is timestamped.

25. The computer readable medium of claim 24, when multiple pulling of the same forms is performed, each pulling of the form provides an instance of the data.

26. The computer readable medium of claim 25, wherein after a first instance of the form is pulled, subsequent pulling of the same form provides delta data values for all fields in the form having values changed from a previous instance.

27. The computer readable medium of claim 26, wherein between the system and a layer where the command is issued is an intermediary layer, the intermediary layer reformats the data pulled from the system and the data pushed to the system.

28. The computer readable medium of claim 27, wherein the intermediary layer reformats the pulled data so that the pulled data is understood by the command, and the intermediary layer reformats the pushed data so that the pushed data is understood by the operating software.

29. The computer readable medium of claim 16, wherein an instance of a form carrying the parameter data pulled from the system is saved when the parameter data includes a state of the system at a time the parameter data is pulled.

30. The computer readable medium of claim 29, wherein the saved parameter data that includes the state of the system is used to restore the system to the same state as when the parameter data is pulled.

31. A method, comprising:

identifying one or more data items available in a system, each of the data items is defined as a scalar data item or a tabular data item, wherein each of the data items is further defined as a statistic data item or a parameter data item, the tabular data item associated with a table;

identifying a set of actions available in the system, the set of actions processing the data items in the system;

mapping each action in the set of actions to a method, wherein the method is used when a command is issued to the system from outside the system, the command being in a set of commands used by applications to interact with the system, wherein the commands are independent of the system;

pushing the data items to the system using commands that send parameter data items; and

pulling the data items from the system using commands that send parameter data items or statistic data items from the system.

32. The method of claim 31, wherein the set of actions are specific to the system.

33. The method of claim 31, wherein mapping each action in the set of actions to a method comprises describing each of the actions in a description file associated with the corresponding metrtod.

34. The method of claim 33, wherein mapping further comprises describing the data items associated with each of the actions in the description file.

35. The method of claim 34, wherein the description file is created using a generalized markup language.

36. The method of claim 35, wherein the generalized markup language is Extensible Markup Language (XML).

37. The method of claim 31, wherein the data items are pushed to the system or pulled from the system using one or more forms defined to carry the data items, the one or more forms having fields corresponding to the data items to be carried by the one or more forms.

38. The method of claim 37, wherein the form used to pull the data items from the system includes a timestamp.

39. The method of claim 38, wherein a delta value is placed in the form pulled from the system when multiple instances of the same form are pulled, wherein the delta value provides a difference from a previous instance.

40. The method of claim 37, wherein the form used to push the data items to the system includes null and non-null fields, wherein the non-null fields contain parameter data items, and wherein the system does not process the null fields.

41. The method of claim 31, wherein an operating software in the system fills the forms with the data items to be pulled from the system and extracts the data items from the forms pushed to the system.

42. The method of claim 31, wherein the application used to interact with the system is a command line interface (CLI).

43. The method of claim 31, wherein the application used to interact with the system employs Simple Network Management Protocol (SNMP).

44. The method of claim 31, wherein the application used to interact with the system is a system management application.