Deep Into MIF
Detailed descriptions of the MIF grammar and language are outside our scope, but here's an overview of the MIF file format. (A detailed description can be found in the DMI 2.0 specs.)
Here's a sample structure of a MIF file.
start component
start path
end path
start enum
end enum
start group
start attribute
start enum
end enum
end attribute
end group
start table
end table
end component
The start and end keywords relate to scope and are always associated with a keyword indicating the block being scoped. The MIF uses the Unicode 1.1 or ISO 8859-1 for its character set. The default is the ISO 8859-1 character set unless the first two octets of the MIF file are 0xFEFF (hexadecimal). The file is tokenized using keywords; white space (blanks, tabs, carriage returns, line feeds and comments) is ignored but used to separate tokens and render the file more readable. The MIF tokens are keywords, integer constants and string literals. Case is insensitive, unless within a quoted string literal. White space between string literals is ignored. Comments are allowed, follow the C++ // comment format and run to the end of lines.
Only one component definition is allowed within an MIF file; hence every manageable component needs its own file. The syntax of the component definition is:
start component
name = "component name"
[description = "description string" ]
[pragma = "pragma string" ]
(component definition goes here)
end component
Within a component definition, multiple group definitions can occur, each making up a logical set of a collection of attributes. The component ID group is the simplest form of an MIF file.
Management Applications
These are the applications that manage the desktop through communication with the SP. One such application is Intel's LANDesk Client Manager. HP provides a HP-UX DMI 2.0 SDK that includes a sample management application (www.software.hp.com). The applications can be simple console applications, a network management protocol agent or full-blown graphical applications that let users browse the MIF database and administer various desktop functionality, such as installation and removal of components. The management application initiates management requests. Connectivity to other network management protocols, such as SNMP or CMIP (Common Management Information Protocol), is accessible via a management application that acts as an agent, brokering requests/results between SNMP and DMI or CMIP and DMI.
Figure 3: Managing Multiple Applications Using DMI
Figure 3 shows how DMI can be used to manage multiple applications--depicting DMI 2.0's newly adopted Remote Management architecture.
The Service Provider
The DMI SP coordinates and arbitrates requests from management applications to the specified component instrumentations. It handles the run-time management of the MI and the CI, which entails component installation, registration at both levels, request serialization and synchronization, and general flow control and housekeeping.
By interface design, commands at the MI level are either satisfied at the DMI SP or passed directly to the CI.
Sample DMI SP Block Diagram.
|
REPORTS
ANALYTICS
Follow 
