Using DMI
5.1 Using DMI Overview
This chapter provides an introduction to the Desktop Management Task Force (DMTF) special interest group, manageability, and the Desktop Management Interface (DMI).
5.2 What is DMTF?
The DMTF was formed in May of 1992 as a cooperative effort of eight companies: Digital Equipment Corporation, Hewlett-Packard, IBM, Intel, Microsoft, Novell, Sun, and SynOptics. The objective of the DMTF was to provide a simple solution for desktop manageability.
The DTMF created a standard interface that handles communication between any management application and all the manageable products on -- or attached to -- a desktop PC or server.
This standard is called the DMI. For more information on the DMI, refer to the DMI Specification Version 2.0 at http://www.dmtf.org
The DMI is:
Independent of any specific operating system, hardware platform, or management protocol
Easy for vendors to adopt
Scalable, to accommodate a wide range of products from very simple to very complex and extensible
Mappable to existing management and remote protocols
5.3 DMI Functionality
DMI functionality for the SEA includes the following:
Dynamic installation and removal of component instrumentations and management application
Responsibility for all runtime access to the MIF data
Assurance that at least one group (the component ID group) is in each MIF file
Responsibility for launching the component instrumentation, if necessary
Slicing commands. When a management application requests more than one attribute value from a component in a single command, the SP sends commands to the component instrumentation for each attribute
Assurance that commands serialize to a component instrumentation and ensure that commands are allowed to run to completion. Multiple requests for a particular component instrumentation must be queued
Forward indications based on subscription and filters to each registered management application and timestamp incoming indications before forwarding them
Send indications to all registered management applications that subscribe to receive indications when components are installed or removed from the MIF database
Appear to management applications as a component with ID 1 (one). As a component, it must support the standard ComponentID group. Additionally, the DMI SP must support the subscription and filter standard group. Also, similar to a component, it may define additional groups beyond the ComponentID group
5.4 Architecture of DMI
Customers may use the DMI-based solution included in the SEA product in several ways. For example, it may act as another SNMP subagent. Additionally, DMI-based management applications may be written to directly interact with SP.
In the SNMP subagent mode, the SNMP requests are mapped to DMI requests and are communicated with DMI SP. In the direct mode, the management applications may directly interact with the SP using DMI.
Figure 5-1 illustrates the overall architecture of how the DMI solution relates to the Enterprise Agents.
Figure 5-1 DMI and Enterprise Agents
5.4.1 DMI Service Provider
The DMI SP is the core of the DMI solution. Management applications and Component instrumentations communicate with each other through the SP. The SP coordinates and arbitrates requests from the management application to the specified component instrumentations. SP handles runtime management of the Component Interface (CI) and the Management Interface (MI), including component installation, registration at the MI and CI level, request serialization and synchronization, event handling for CI, and general flow control and housekeeping.
Figure 5-2 illustrates the elements that exist within a single system, or are directly attached. The management application may be used as a DMI browser.
Figure 5-2 DMI Service Provider