|
|
CIMV2 Namespace Usage
This document aligns with Win32 Logo Requirements, and MSI and SMBIOS MOF Additions as of 01/25/99 and defines the proper usage of the classes defined in the CIMV2 namespace. Generally, one of four cases may apply:
1) CIM classes which can be freely subclassed. The only restriction being that instances must always apply to the local machine.
2) CIM classes that cannot be subclassed directly. All the instances of the CIM class are required to be instances known to the win32 instrumentation. As a result subclasses may only be added to the provided Win32 subclasses.
3) CIM classes that can be subclassed even though Win32 classes exist. In this case the set of instances provided by the Win32 classes are not assumed to be complete - that is, the instrumentation supplied cannot detect all relevant instances. It is expected that subclasses of the CIM class will be provided that return instances that are not discovered by the Win32 subclass providers.
4) CIM classes that cannot be subclassed. These are either classes that are at a level of abstraction that makes subclassing undesirable (such as CIM_ManagedSystemElement) or that are simply not relevant to the local environment (such as CIM_Cluster). Note it is never acceptable in the CIMV2 namespace for third parties to instrument CIM classes directly.
1) The following classes may be freely subclassed. Subclasses should only be added where the instances introduced are local to the machine.
Classes* CIM_FRU* CIM_SupportAccess* CIM_Configuration* CIM_MonitorResolution* CIM_RedundancyGroup and its subclasses* CIM_ManagementController* CIM_Statistics and its subclasses* CIM_StorageError
Associations* All CIM_Product associations (Exception is the CIM_ProductSoftwareFeatures association which is addressed in the section, "Win32 associations with specific meaning")* All CIM_FRU and CIM_SupportAccess associations* All CIM_Configuration associations * All CIM_Statistics associations* CIM_Realizes and most associations of the Physical Model (Exception is the CIM_Container association which is addressed in section 3.* CIM_DeviceSoftware * CIM_AssociatedSensor and its subclasses* CIM_BIOSLoadedInNV* CIM_StorageDefect* CIM_RedundancyComponent and its subclasses* CIM_ActsAsSpare* CIM_CollectionOfSensors* CIM_DeviceServiceImplementation* CIM_DeviceSAPImplementation
2) Win32 subclasses are provided for the following classes. Only direct subclasses of Win32 classes can be added. That is, the CIM classes should not be subclassed directly. All instances must be known to the CIMV2 instrumentation.
Classes* CIM_UnitaryComputerSystem* CIM_OperatingSystem* CIM_FileSystem and its subclasses* CIM_LogicalFile and its subclasses* CIM_Process* CIM_Thread* CIM_Printer* CIM_Scanner * CIM_NetworkAdapter and its subclasses* CIM_Controller and most of its subclasses (e.g., Video, SCSI, Serial, Parallel, PCI, PCMCIA, USB)* CIM_POTSModem* CIM_MediaAccessDevice and its subclasses (e.g., CIM_DisketteDrive, CIM_WORMDrive and CIM_MagnetoOpticalDrive)* CIM_UserDevice and its subclasses * CIM_SystemResource and its subclasses* CIM_Job* CIM_JobDestination
Associations* CIM_HostedJobDestination* CIM_JobDestinationJobs* CIM_OSProcess* CIM_ProcessThread * CIM_FileStorage* CIM_DirectoryContainsFile * CIM_OperatingSystemSoftwareFeature * CIM_HostedFileSystem* CIM_BootOSFromFS * CIM_InstalledOS* CIM_RunningOS* CIM_ProcessExecutable* CIM_AllocatedResource* CIM_ResidesOnExtent* CIM_ComputerSystemResource* CIM_Export* CIM_Mount
3) The following Win32 subclasses are instrumented to return a specific and limited set of instances. There may be instances relevant to the local machine that are not provided by the Win32 classes and as a result subclasses are permitted of both the Win32 and CIM classes. Direct subclassing of Win32 classes is allowed. Other subclasses of the CIM classes are allowed for instances local to the machine and not already known to the Win32 providers. You must be careful not to return instances that are already returned by the Win32 providers.
Classes* CIM Battery - Win32 classes represent laptop or UP (COM-port attached) batteries* CIM_PowerSupply and CIM_UninterruptiblePowerSupply - COM-port attached UPSs are represented* CIM_StorageExtent and its subclasses - Win32 classes represent logical disks (subclass of CIM_LogicalDisk), partitions (subclass of CIM_DiskPartition) and the logical view of SCSI/RAID-based media (subclass of CIM_VolumeSet) * CIM_Processor - Win32 classes represent "a device capable of interpreting a sequence of machine instructions on a Win32 system"* CIM_PhysicalElement and its subclasses - Win32 classes representing data available from SMBIOS (e.g., system slots, connectors and enclosures)* CIM_Memory and its subclasses - SMBIOS data is available (e.g., system memory arrays and cache)* CIM_CoolingDevice and its subclasses - Win32 classes represent data available from SMBIOS (e.g., fans and refrigeration elements)* CIM_Sensor and its subclasses - Win32 classes represent data available from SMBIOS (e.g., temperature and voltage sensors)* CIM_Product - ComputerSystemProduct and software "products" (installed by the Microsoft Software Installer, MSI) are defined and instantiated * CIM_Setting - Many subclasses exist containing System Device, User, boot, MSI resource and other information* CIM_Service, CIM_ServiceAccessPoint and their subclasses - Services represent functionality hosted on the System and OperatingSystem. All OS drivers and Services are instantiated by the CIMV2 instrumentation. * CIM_SoftwareFeature, CIM_SoftwareElement, CIM_Checks, CIM_Actions and their subclasses represent the MSI (Microsoft Software Installer) view of applications. Other installation technologies and individual applications may choose to add other subclasses at the same level in the schema.
Associations* CIM_SystemComponent and its subclasses - Many subclasses exist associating devices, users, software and other classes* CIM_AssociatedBattery* CIM_AssociatedCooling * CIM_DeviceConnection - Win32 classes are various types of "ControlledBy" associations* CIM_BasedOn - Win32 classes reference subclasses of CIM_LogicalDisk based on CIM_DiskPartition or CIM_VolumeSets* CIM_MediaPresent - Win32 between subclasses of CIM_VolumeSet or CIM_DiskPartition * CIM_AssociatedMemory - Win32 SMBIOS instrumentation exists for Win32_AssociatedProcessorMemory, relating a Win32_Processor and its cache* CIM_Container - Win32 instantiates a memory container, with data from SMBIOS* CIM_ElementSetting - Win32 subclasses exist associating devices and their settings, users with desktops, and many other elements* CIM_HostedService, CIM_HostedAccessPoint and their subclasses, CIM_ServiceServiceDependency, CIM_ServiceSAPDependency, CIM_SAPSAPDependency, CIM_ServiceAccessBySAP - Win32 classes represent the associations of OS drivers and services* All associations defined in the Application Model - Win32 classes represent the MSI view of applications * CIM_ProductSoftwareFeatures - Win32 subclass defines the "product" under which an MSI Software Feature is installed
4) For the following classes subclassing and direct instantiation is not allowed. These are high level classes or classes that contain instances that are not "local" to the machine.
Classes* CIM_ManagedSystemElement and CIM_LogicalElement (Subclasses addressed separately)* CIM_System and CIM_ComputerSystem (Subclasses addressed separately)* CIM_LogicalDevice (Subclasses addressed separately)* CIM_VirtualComputerSystem* CIM_Cluster* CIM_ClusteringService
Associations* CIM_ApplicationSystemSoftwareFeature* CIM_ComponentCS* CIM_HostedClusterService* CIM_ClusterServiceAccessBySAP* CIM_HostingCS* CIM_ParticipatingCS* CIM_DeviceAccessedByFile (N/A for Win32 environment)
GENERAL NOTESWhere CIM classes are included in the CimWin32 MOF, these classes reflect the CIM V2.2 Schema, released by the DMTF (Desktop Management Task Force) in September 1998. Several areas where the CimWin32 MOF differs are discussed below: * Qualifiers exist in CIM as versatile and user-definable meta-data for the Schema. Creating new qualifiers is allowed by the CIM Specification. Several examples of new qualifiers (like the "Dynamic" qualifier) can be found in the CimWin32 MOF. * Many of the CIM Schema keys (identified using the Key qualifier) are labeled as "propagated" and are meant for object identification in an enterprise environment. These "propagated" keys are typically not needed in the CIMV2 namespace, which reflects the local platform. In these cases, the keys are identified with the CIM_Key qualifier only. If the CimWin32 MOF is exported, the CIM_Key qualifier can be directly replaced with the Key qualifier. The data contained within the CIM_Key properties does not have to be modified. * Schema-specific properties and methods can be added to CIM classes. This is allowed by the CIM Specification. Microsoft uses this feature throughout the CimWin32 MOF, identifying additions as "Schema ("Win32")". * CIM classes, with a few exceptions, are marked with the ABSTRACT qualifier throughout the CimWin32 MOF. The "Abstract" qualifier states that there are no direct instances of the class. (In other words, all instances are only instances of subclasses, and not the "Abstract" class itself.) The use of the ABSTRACT qualifier disallows the installation of a Provider (declaring itself the instrumentation for the class). At a CIM class level, a provider would have to be aware of the entire instance-level population, which is very unlikely. In only a few cases does the Win32 Provider instrument CIM classes directly. One example is the instrumentation of CIM_LogicalFile in the CIMV2 namespace. * The CimWin32 MOF does not consistently include an Override qualifier. This will be corrected in the next release of the MOF. Where property, method or reference names are duplicated in subclasses, these are actually overrides of the parent classes' constructs. * Where the Write qualifier is not explicitly listed for a property, it is assumed that the qualifier is FALSE. This is different than the CIM Schema definition (default value of TRUE). Changing a qualifier's default value is allowed by the CIM Specification.
|
