Excerpt from Chapter 4: a Guided Tour of the Common Information Model Repository

Excerpt from Chapter 4: A Guided Tour of the Common Information Model Repository Before we take a hands-on look at Microsoft’s implementation of the Common Infor- mation Model (CIM) repository, let us first examine its structure as defined by the DMTF. In the previous chapters, you have gleaned an idea of the structure and purpose of the CIM. In simple terms, it consists of the following four components: I Classes that define the structure of the information held in the store I Associations that define the relationships between elements in the repository I Methods that define the behavior of the managed objects I Properties that define individual characteristics of each managed object Each of these components can have associated instances that hold the management data. They were designed with the basic purpose of providing a platform-independent means of describing the manageable aspects of all types of logical and physical components in the enterprise. The objective of this chapter is not to describe every class, property, method, and association within the CIM schema and Win32 extended schema. First, this would not make particularly interesting reading, and second, it would prove somewhat over- whelming as an introduction to the CIM. Instead, the focus of this chapter is to examine the classes and associations that hold the elements of most interest to users of WMI. This includes the WMI system classes that define the properties and methods relevant to WMI’s security model, the classes that define the WMI provider architecture, and the classes of the CIM schema. By the end of the chapter, you should have a solid enough knowledge of the structure of the repository to move through it with confidence. We shall use Microsoft’s WMI CIM Studio to look at the classes within the CIM repository. During the course of the chapter, we also shall look briefly at the Managed Ob- ject Format (MOF) so that you can better understand some of the terminology used in the WMI CIM Studio. For a more complete list of the syntax and semantics used in the MOF, you can refer to the platform SDK documentation available from the MSDN Web site. Recall from the previous chapter that the CIM is a conceptual model for storing enterprise management information—it is not a physical implementation (that is, the DMTF does not supply a downloadable version of WBEM that you can install as part of your operating system). It is the responsibility of vendors such as Microsoft, Intel, or Hewlett-Packard to adhere to the DMTF’s CIM standard and produce their own physical implementations. Microsoft has done this for its range of Windows operating systems. 1 2 Excerpt from Chapter 4: A Guided Tour of the Common Information Model Repository The CIM repository supplied as part of WMI is a data store structured in accordance with the DMTF’s CIM. It is supplied with any of Microsoft’s WMI-compliant operating systems (Windows 9x/2000/NT4.0/WinXp/.NET): It holds management information structured in accordance with the CIM. The aim of this chapter is to familiarize you with the CIM repository that is shipped with WMI. This will serve two purposes: first, it will give you some idea of the vast array of information that you can retrieve from the repository, and second, it will provide you with an introduction to the structure and relationships of the existing classes. This knowledge will prove useful especially if you are faced with the task of in- strumenting your own product within the CIM repository or need to elicit management information from the repository about managed objects. To explore the repository, we shall use the tools supplied with the WMI SDK, so if you did not install the SDK during your study of Chapter 3, you should do so now. I Metadata “Metadata” is a new term to those who are not familiar with data modeling. The Greek word “meta-” is a prefix that means “behind” or “hidden.” If you are familiar with HTML scripting, you will have encountered the prefix in metatags. Metatags describe the characteristics of information presented on a Web page (for example, to specify text displaying Bold or in Italics). Metadata is “data that describes data” or, more pre- cisely, definitional data. Admittedly, this is a broad definition, so let us define metadata more fully in terms of the CIM. We know from previous chapters that the information available from CIM is described by a series of classes and associations, and the elements contained therein (methods, properties, and references). These constructs describe the data available to WMI client applications and are classified as metadata, as you can see in Table 4.1. The information in the Property and Type columns is metadata, as it describes the information we can retrieve, which is listed in the Value column. The Property and Type columns represent “data about data.” The information in the Value column is instance data—the data that metadata describe. Metadata is a generic term and applies to Table 4.1 Metadata Examples Property (metadata) Type (metadata) Value (instance data) Model String CD99A_EXPRESS Version Real32 1.64 BIOSVersion String 1.23.54.244 Read_errors Sint32 0 Excerpt from Chapter 4: A Guided Tour of the Common Information Model Repository 3 a broad spectrum of data; for example, class information is metadata. Metadata also includes descriptive information about the context, quality and condition, or characteristics of the data, such as WMI system classes and properties. It is important to make the distinction between metadata and instance data because the CIM repository was envis- aged by the DMTF primarily, although not exclusively, as a store for metadata. I Dynamic and Static Data As well as understanding the distinction between metadata and instance data, it is important to understand that the data in WMI is categorized further as either dynamic or static. A simple rule of thumb is that metadata is inherently static and instance data more often is dynamic. As with all generalizations, however, there can always be ex- ceptions to the rule. Dynamic data is characterized by frequent change. Instance data commonly falls into this category, because the values associated with instance data often change during a managed object’s lifetime. For example, the value assigned to a property that rep- resents the amount of free space left on a disk partition is dynamic in nature, because during the day-to-day operation of the disk drive, the value normally will change. Other reasons that the data may change include: 1. The data may persist in other places, such as Active Directory, a database, the Internet, or simply a file on disk. 2. A WMI class can have properties that are retrieved from several sources, thus unifying separate data sources into one logical means of accessing it and its relationships. For example, the Win32_Service might obtain the Started property at run time and most of the other properties from the registry. Static data is slow or nonchanging data, such as class or association definitions or a static property value such as a BIOS version number (although these values can change if the BIOS is stored on flash memory that can be reprogrammed) or a manu- facturer’s name. WMI class definitions often fall into this category because the classes that define a managed object do not change with great frequency. Dynamic data (for example, the Read_errors value in the Value column in Table 4.1), is provided externally by WMI providers. Static data and metadata are stored in the CIM repository. I Dynamic Data and the CIM Repository An important concept when retrieving dynamic (volatile) data is temporal correctness. For data to be temporally correct, it must be valid in relation to the time of the original query. When a managed object supports dynamic data, it is counterintuitive to import 4 Excerpt from Chapter 4: A Guided Tour of the Common Information Model Repository that information into the repository with no means of updating it. Imagine that we are responsible for monitoring the amount of free space on the disk drive partition of a network server. Because the network server is heavily utilized, the space remaining on the disk changes constantly during its day-to-day operation. Without a mechanism for keeping track of these changes, management applications that requested information on the amount of free space could end up retrieving out-of-date information. The solution designed by Microsoft is a WMI provider, a software component that reacts to requests for dynamic data with information that is temporally correct. (Chapter 12 covers WMI providers in detail.) Figure 4.1 shows an example architecture without using WMI providers for dynamic data, and Figure 4.2 demonstrates an architecture that uses WMI providers. Figure 4.2 shows a management application requesting instance or property data that is supplied dynamically. In this example, class and association information is held statically in the CIM repository. The example does not illustrate the surfacing of events or method invocation. Figure 4.2 also demonstrates how WMI providers retrieve dynamic data directly from the managed object to respond to the request. The Windows Management service then returns all of the requested information to the client application. Although Figure 4.2 shows a preferred arrangement, it does not preclude storing instance information in the CIM repository, which even may be the preferred solution for situations in which the instance information is not expected to change during the lifetime of the managed object (that is, it is static).

Load more