Core Service-Related Classes Provided by WMI
Let's take a brief look at the core service-related classes provided by WMI. These classes are shown in Figure 8-3. The CIM_ManagedSystemElement, CIM_Setting, and CIM_StatisticalInformation classes provide root classes for operational, setting, and statistical data, respectively. As you can see from looking at the Win32_BaseService class, a wide range of information is provided by WMI about services, as well as about basic methods for defining, modifying, starting, stopping, and deleting services.
NOTE
Class names prefixed with "CIM_" indicate classes defined by the DMTF, whereas classes prefixed with "Win32_" are defined by Microsoft. If you intend to add new classes to the CIMV2 namespace, you should decide on a name for your schema that is familiar to you, such as a trademark, to ensure that no one else uses the same name.
Figure 8-3. Core service-related classes provided by WMI
CIM_ManagedSystemElement
The CIM_ManagedSystemElement class is the base class for all the operational data held in the CIMV2 namespace. It represents all the physical and logical components of the system. CIM_ManagedSystemElement is a base class for exactly two derived classes: CIM_LogicalElement and CIM_PhysicalElement.
NOTE
You should never derive a class using CIM_ManagedSystemElement as a base. If you do, you are basically saying that the data you are defining is neither physical nor logical; however, the CIM schema claims that every element of a system is either physical or logical and cannot be both.
CIM_ManagedSystemElement defines the following fundamental set of properties for which every component of a system is expected to supply values:
- Caption A short textual description (a one-line string) for the object.
- Description A textual description of the object of unlimited size.
- InstallDate The date and time value indicating when the object was installed. A lack of a value does not indicate that the object is not installed.
- Name The label by which the object is known. Derived classes can override the name to make the property a key, but they do not have to.
- Status An enumeration indicating the current state of the object
NOTE
These properties and those defined for the other classes described in this section are described in the WMI SDK and CIM Studio. To take a look at a property description in CIM Studio, select the class that contains the property, and click the Help For Class button.
Win32_BaseService
The Win32_BaseService class represents executables that are installed in the Service Control Manager's registry database. Instances of this class identify services or device drivers. Your service should derive a class using Win32_Service (discussed in the next section) as its base class. A device driver would derive a class using Win32_SystemDriver as its base class.
NOTE
You should never derive a class from Win32_BaseService. Doing so tells the system that you have changed the operating system architecture.
The properties supported by the Win32_BaseService class include the following:
|
|
|
|
|
|
|
|
|
|
|
|
NOTE
In CIM Studio, some properties have a yellow arrow icon. This yellow arrow indicates that the property is inherited from a base class.
Win32_Service
The Win32_Service class represents a service on a Microsoft Win32 computer system. A service application conforms to the interface rules of the Service Control Manager as discussed in Chapters 3 and 4 of this book.
In WMI, the service class should be used for managing the service, not for providing access to the service's tasks. For example, it would be inappropriate to declare a DHCPService class derived from Win32_Service and implement a method in the class to obtain a new DHCP address. However, it would be entirely appropriate to implement a method in a derived class that would allow you to restrict the range of addresses that could be returned by the service.
The Win32_Service class supports the following properties:
- CheckPoint
- ProcessId
- WaitHint
CIM_ServiceAccessPoint
The CIM_ServiceAccessPoint class represents access points for your service, such as the command-line parameters accepted by an application and port 80 in the context of a protocol service. Use this class to manage the access point. Provide instances of this class if you need to control, for example, which machine hosts the access point.
CIM_Setting
You know that setting data is represented separately from operational data. The CIM_Setting class provides a base class for all setting data. Any time you want to add setting-related data for your service, you should make it accessible by deriving from the CIM_Setting class.
Notice the CIM_ElementSetting association between CIM_Setting and CIM_ManagedSystemElement that defines which CIM_ManagedSystemElement a particular setting applies to. You should always derive a class from an association class to establish the particular association between your CIM_ManagedSystemElement class (typically a Win32_Service or CIM_ServiceAccessPoint class) and the CIM_Setting-derived class that configures it. You can store the setting data in the CIM repository (as you saw in the joke class example earlier in this chapter), but I don't advise it because the CIM repository is not meant as a general-purpose store. Rather, save the information elsewhere—in the registry, for example—and use the WMI registry provider to retrieve the information.
CIM_StatisticalInformation
The CIM_StatisticalInformation class provides a location for statistical data in the CIMV2 namespace. You can select any of the classes under this class and look at an instance of it to see its current statistics. For example, look at Win32_PerfRawData_PerfDisk_PhysicalDisk under CIM_StatisticalInformation\Win32_Perf\Win32_PerfRawData.
NOTE
Some of the class names include multiple underscores. Strictly speaking, this is not allowed—these are cases in which Microsoft has not conformed to the rules. Be careful to include only one underscore in each of your class names; this underscore should separate the trademark-derived name from the class name.
Association Classes
An important feature I have only touched on is association classes, which link classes together. One example of an association class that you have seen is CIM_ElementSetting, which links CIM_ManagedSystemElement classes to the settings that represent their configuration parameters.
You must understand the more important association classes to use WMI properly. The next few sections describe the important associations you should be aware of.
CIM_Dependency
Most of the associations that link two CIM_ManagedSystemElement classes are one of two types—a CIM_Dependency association or a CIM_Component association. CIM_Dependency associations represent functional dependency between objects. Dependencies show which components another component depends upon. For example, the Win32_DependentService association class (derived from CIM_ServiceServiceDependency, which is derived from CIM_Dependency) is used to indicate a dependency relationship between services. If a service fails to start due to a dependent service, it is possible to follow the dependency chain until you locate the service that is causing all the trouble.
If you open CIM Studio and expand the tree under CIM_Dependency, you will see well over 40 association classes, each representing a different type of dependency that can be expressed in the WMI model. Some of them are specific to services and their associated objects. CIM_Dependency is frequently used as a base class.
CIM_Component
The CIM_Component association class is used to identify that a component is part of another component. Classes derived from CIM_Component represent the association between a system component and the various CIM_ManagedSystemElement classes that make up the system. CIM_Component is frequently used as a base class.
CIM_ElementSetting
CIM_ElementSetting associates a setting with the CIM_ManagedSystemElement class for which it provides configuration parameters. You must derive a class from the CIM_ElementSetting association class to associate any settings you add to the CIMV2 namespace with the CIM_ManagedSystemElement-derived class that the settings apply to.
CIM_Statistics
The statistics association class links a CIM_ManagedSystemElement-derived class to the various statistics that apply to it. You must derive a class from the CIM_Statistics association class to provide a way for users to get at a CIM_ManagedSystemElement-derived class object's statistics.
CIM_ServiceServiceDependency
This class is derived from the CIM_Dependency association class. Use it to define any dependency relationships that exist between services. It is actually quite unusual to see a class such as CIM_ServiceServiceDependency as part of the CIMV2 namespace, because service dependencies are typically defined as properties of the service itself.
CIM_ServiceAccessBySAP
This class is also derived from the CIM_Dependency association class and should be used to define associations between a service and the access points that can be used to access the service.
Win32 Service-Related Classes
The next few sections describe some of the Win32 service-related classes you should be aware of. These include classes related to the system, classes related to user accounts, and classes that specify execution dependencies for groups of services. Some of the classes are shown in Figure 8-4.
Win32_ComputerSystem
The Win32_ComputerSystem class represents a computer in the Win32 environment. It includes multiple properties related to booting, power, hardware, owners, and other information. The Win32_ComputerSystem class ultimately derives from the CIM_System class. Typically you will never add anything to the CIM_System class or any of its descendants. Although system manufacturers might derive a class from Win32_ComputerSystem to define specific features of their Win32 systems, it is highly unlikely.
Win32_Process
The Win32_Process class is strictly limited to the processes known to the Win32 system. You should not add instances or properties to this class, but you can establish associations to process instances. For example, you could use associations to expose the details of how your service maps to a set of processes and threads.
Figure 8-4. Some Win32 service-related classes
Win32_Account
The Win32_Account class contains information about user accounts and group accounts known to the Win32 system. User or group names recognized by a Windows domain are descendants (or members) of this class.
Win32_SystemAccount
The Win32_SystemAccount class represents the LocalSystem account.
Win32_LoadOrderGroup
The Win32_LoadOrderGroup class identifies which load order group a service can be dependent upon. The two important associations for the Win32_LoadOrderGroup class are the Win32_LoadOrderGroupServiceMembers class, which represents a component (or membership) association between a base service and a load order group, and the Win32_LoadOrderGroupServiceDependencies class, which represents a dependency association between a base service and a load order group that the service depends on to start running. The difference between the two can be represented this way: the component association says "this service or driver is a member of this group," whereas the dependency association says "this service or driver is dependent on this group."
Software Installation Classes
Figure 8-5 shows the main classes involved in software installation. These classes directly reflect the information used to control the Microsoft Windows Installer technology. If you use Windows Installer to install your service, these installation classes will be populated for you automatically, and you will be able to install, uninstall, and repair your installation by using WMI.
Figure 8-5. Classes involved in software installation
Win32_Product is a concrete class that is a collection of physical elements, software features, and/or other products, acquired by a consumer as a unit. Instances of this class represent products installed by the Windows Installer. A product generally correlates to a single installation package.
The CIM_SoftwareElement class breaks up a CIM_SoftwareFeature object into a set of individually manageable or deployable elements for a particular platform. A software element's platform is uniquely identified by its underlying hardware architecture and operating system (for example, Microsoft Windows 98 or Windows 2000).
EAN: 2147483647
Pages: 126