Applies To: System Center Operations Manager 2007
This topic has been updated in the latest version of the System Center Management Pack Authoring Guide on the TechNet Wiki.
The main element of a service model is a class. This represents some object being managed. It could represent a computer, a database, a service, a disk, an application, or any other kind of object that requires monitoring. A management pack may define any number of classes to represent the application it is monitoring in addition to using existing classes in other management packs and management pack libraries.
Each monitored object that appears in the Operations console is an instance of a particular class. All instances of a class have a common set of properties and a common means of being monitored. Each of these instances is created by a discovery that uses logic specific to the particular class to identify the instances and collect the values of their properties.
Like all management pack elements, classes have an ID and a Display Name. These terms may be used differently in different consoles. In this documentation, ID will refer to the unique name of the class that is only seen in the Authoring console while Name and Display Name will refer to the language-specific name that appears in the Operations console.
All instances of a particular class will share a common set of properties. The values for these properties are provided by discoveries and can vary among different instances. Properties are used to represent details of the object, such as a unique name, configuration settings, and other details that may be interesting to the user or that are required for monitoring scenarios.
A key property uniquely identifies each instance of a particular class. If a property is marked as a key property, each instance of the class must have a unique value, and the value may not be null. For hosted classes, the value must only be unique for all instances of the class that have the same hosting parent. For unhosted classes, it must be unique for all instances of the class in the management group. Hosting relationships are discussed more in the Relationships section.
Classes do not always require a key property. A key property is only required if more than one instance of a class is expected for a single parent. If only a single instance is expected, a key property is not required but may still be defined.
For example, SQL Database Engine has a key property of Instance Name because a single computer can have more than one instance of SQL Server installed. When there are multiple instances on a particular computer, each instance must have a different value for Instance Name in order to clearly distinguish between the different objects. The IIS Web Server class, by contrast, does not define a key property because there can be only one instance installed on any computer.
All objects have a Path Name property that is calculated from the object’s key property or properties and those of its hosting parent(s). For unhosted objects, the Path Name will be the key property of the class itself. The Path Name can be used to uniquely identify any instance of a class in the management group.
Base Classes and Inheritance
Every class must specify a base class that identifies an existing class that the new one will specialize. The management pack libraries that are included with Operations Manager 2007 contain several classes that can be used as the base for custom classes in management packs. A management pack will typically have at least one class inheriting from a library class and potentially other classes inheriting from classes in the same management pack.
The concept of a base class can be illustrated with the Windows Server Operating System management pack. This management pack includes classes representing logical disks installed on the agent computer. The following diagram shows the classes Windows Server 2003 Logical Disk and Windows Server 2008 Logical Disk. These classes are both based on Logical Disk (Server) that is defined in the Microsoft.Windows.Server.Library mp file. Logical Disk (Server) is in turn based on Logical Disk, which itself is based on Logical Device, and so on through Logical Hardware, Logical Entity, and finally Entity. All classes can trace a similar inheritance path and will always end up at Entity, which is the root of the class structure in Operations Manager. This is the only class that does not have a base class, and all other classes eventually inherit from it.
Inheritance of properties between classes
Entity has a single property named Display Name. This is inherited by all classes inheriting from it. All classes eventually inherit from Entity. That is why all classes have a Display Name property. No other classes in this example have properties until Logical Device, which defines Name, Description, and DeviceID. DeviceID is specified as the key property. These properties are all inherited by Logical Disk and Logical Disk (Server). Logical Disk (Server) then adds the additional properties Size, Drive Type, and File System. The bottom-level classes that are specific to the version of operating system inherit the entire set of properties provided by those classes above them in the inheritance tree. This concept is illustrated in Viewing Classes in the Consoles.
System.Library cannot be opened in the Authoring console because of the Entity class. The Authoring console performs checks to make sure that a management pack is valid before it opens it. One of these checks is to make sure that all classes have a base class, and because Entity does not have one, the Authoring console considers it an invalid management pack.
In addition to inheriting its properties and relationships, any monitoring targeted at a class will be inherited by any other classes that use it as a base. Additional monitoring and discovery can be added to the new class, and any management pack objects targeted at the new class will apply only to the new class and not the base class.
Most classes have one or more instances identified and created through the discovery process. These are also known as concrete classes because they actually have instances. Abstract classes and singleton classes are special kinds of classes that behave differently and are used for particular scenarios.
Abstract classes have no instances and exist only to act as a base class for other classes. All properties and relationships that are defined at the abstract class level are inherited by child classes and do not have to be defined again. Any monitoring objects targeted at the abstract class are similarly inherited by lower-level classes. Most of the classes that are defined in management pack libraries are abstract, since they are only provided to act as base classes for classes that are defined in custom management packs.
Abstract classes are used where there is a common set of properties, relationships, monitoring, or grouping that can be defined across all further specializations of a class. In the previous example, all of the classes shown above Windows Server 2003 Logical Disk and Windows Server 2008 Logical Disk are abstract. They exist only for the lower-level classes to inherit from.
Singleton classes are used when there is one and only one instance of a class. The class is the instance and always exists. No discoveries can be defined for singleton classes. Their single instance is instead being created when the management pack is installed. Similarly, a key property is not required for a singleton class, since it will only ever have a single instance. Common uses of singleton classes are for Groups and Distributed Applications, because there is only a single instance of these classes required throughout the management group.