|
|
A DMI component provider is any product that provides management information to the DMI. Components provide their information in MIF files that are installed in the component MIF data store. Attribute values may exist statically or be derived dynamically through component-specific instrumentation.
The DMI-SP builds, maintains and represents the management data of DMI-enabled components in its MIF data store.
The MIF data store model
The components of a product are described with a language called the ``Management Information Format'', or MIF. The MIF has a defined grammar and syntax. A MIF file is an ASCII text file describing a product's manageable ``attributes'', classified into meaningful ``groups'' (see ``The MIF data store model'' above.) A group ID must be a non-zero, 32-bit unsigned integer and must be unique within the scope of the containing definition. As shown in the figure, the groups found in a MIF do not have to appear in sequential order, nor is a Group 1 required; however, sequential ordering is more readable and easier to maintain.
Each product provides its own MIF file. When a manageable product is initially installed into the system, the information in its MIF file is added to the database and is then available to the Service Provider and thus to management applications.
The values associated with each MIF attribute are either stored directly in the database or provided by program code (instrumentation) that runs when the value is requested.
An attribute can be accessed individually, or as an entry in a ``table'' (with particular instances of that attribute within the table designated by their ``keys''). Values can also be designated as read-only, read-write or write-only.
Each group definition includes a ``class name'' string. The generic formula for constructing a class name is as follows:
Defining body|specific name of group|version number of this group definition
For example, the class name string ``DMTF|ComponentID|001'' for the required Component ID group shows that the DMTF defined the MIF encoding for this group; that this group defines the attributes about the identity of the component this MIF defines; and that this definition is the first formal version released for use with the DMI.
Different components can have similar attributes, such as peripheral devices that use a serial port, even though they may serve different needs (a serial printer versus an external faxmodem). If the attributes are grouped into well-focused categories, then dissimilar components that share a common set of attributes still can be categorized by class name for management applications that want to manage that class of attributes.
Because the DMI categorizes components by class name at the group level rather than the component level, we recommend that a MIF developer use DMTF-approved Standard Groups definitions to express product attributes whenever possible. Developers can augment their component MIFs with additional private groups for attributes that are unique or proprietary to their products.
To facilitate the needs of the international marketplace, a component developer can create alternate language versions of the same component's MIF data. All DMI 2.0 Service Providers support the component-level language functions, DmiAddLanguage(3dmi) and DmiDeleteLanguage(3dmi), that enable a component's installation program to expand the languages defined for a single component's MIF data.
DMI language expressions are encoded in ISO 8859-1 format. Multiple language support enables the DMI user to:
MIF Pragma definitions provide additional information about the component, group or attribute. As far as the DMI Service Provider is concerned, the literal value assigned to the pragma statement is simply an octet string. Refer to the DMI Specification for a discussion of DMTF conventions for using pragma statements.
MIF file grammar, requirements and restrictions are described completely in the DMI Specification. In this document, ``Modeling products with MIF files'' gives some basic guidelines for writing effective MIF files. Additional documents describing MIF definitions and MIF samples are available from the DMTF home page.
A MIF file that contains only static data (data coded into the MIF file at the time of its creation) quickly becomes outdated, since the manageable aspects of most products change over time. A DMI component's ``instrumentation'' consists of code that maintains attributes with up-to-the-minute values.