DMI

Imagine this: You're a system administrator and you want to deploy a new software package to the 500+ PCs under your "control." You have no idea if any of the users installed the software on their own. Although you may have a rough idea of what hardware the PCs contain, you're clueless as to which versions of which drivers are installed. And things change so often that you can't pinpoint those machines that can run the software without lulling the users to sleep while they wait for their computers to respond. What do you do? Do you slink around at night, collecting as much information as possible from each individual PC. Do you risk upsetting management and send companywide e-mails asking each user what he or she has (and hope to receive somewhat correct answers). Or if you're more prepared, do you start sifting through all those spreadsheets that you endeavored to keep up-to-date with every change in every PC.

Now, imagine that all of those PCs, their components, peripherals and software are DMI-compliant. You fire up one program, survey all the PCs and get a list of everything that comprises every PC. Cool, ain't it? DMI makes it possible.

DMI lets compliant components and applications manage the desktop seamlessly. It's comprised of four elements, the first of which is a format for describing management information, or MIF. The second is a SP (Service Provider) entity, which is a middle layer that sits between manageable components and management applications. The third element is a set of APIs that is supported by the SP. One API communicates with the management applications, and the other communicates with the components. The final element, which is new to DMI 2.0, is a set of services that enables remote communication.

Figure 1: The Architecture of DMI

Figure 1 depicts the DMI architecture. Central to the architecture is the concept of the SP, which is an active, resident piece of code running on a computer system that mediates between the MI (Management Interface) and the CI (Component Interface) and performs services on behalf of each.

You can access information about the managed components (stored in the SP database) by using MIF files.

Figure 2: DMI 1.X Architecture

Figure 2 depicts an overview of the DMI version 1 architecture. Though version 1 is now outdated, this figure is more comprehensible and conveys the concepts of DMI more clearly than a diagram of version 2. The Service Layer (which became known as the Service Provider) acts as the middleman between the components and the management applications. It also collects the information from the MIF files and stores them in the MIF database.

The MIF language's grammar and syntax describe a managed component. MS Windows users can relate to the MIF files as they are conceptually similar to the .INI files used for a long time by Windows. The MIF database is similar to the Windows Registry. Each instance of a managed component must provide its own MIF file. (Like .INI files, MIF files are simple text files that can be edited in a text editor.) The file can merely contain the Component ID group (MIF file structure is covered next) or it can be quite complex, describing many attributes of the managed component. Each attribute can have a single value, or if needed, multiple values that are stored in tables and looked up via index keys. Once a manageable component is installed, its MIF is added to the MIF database, making it available to the service layer and thus to the management applications. Management applications requiring information about a managed component would contact the service layer, which would look up the information in the MIF database and return it to the management application. A better available solution is for the component vendor to provide a piece of executable code (instrumentation) that can be executed to dynamically obtain the requested value.

Network administrators already know that they can achieve somewhat similar results by using SNMP. However, DMI is more advantageous: It allows management programs to access the MIFs about which they have no previous information. This is possible due to the standard component ID group, which is a base set of information common to all MIFs. This group includes items such as component type, ID number, product name, version, serial number and time and date of installation.

In addition, MIF developers don't have to register their MIFs with anyone. It's highly desirable to standardize MIFs, but an MIF is usable even before the standardization process is complete. In contrast, current SNMP consoles can't access information from unfamiliar SNMP MIBs.