다음을 통해 공유

Operations Manager Management Pack Authoring - Choosing a Base Class

  • 아티클

This document is part of the Operations Manager Management Pack Authoring Center.

.

Each class that is defined in the service model must have a base class, and selecting the appropriate one is important to achieve the expected operation of the class in the overall service model. The base class may be selected from a class available in a management pack library or an abstract class that is defined in your management pack.

Criteria for Selecting a Base Class

The following should be considered when you select a base class for a particular class.

Inheritance

A class will inherit various characteristics of its base class. These characteristics affect which base classes you can use from management pack libraries and which abstract classes that you might create to have other classes inherit from.

Properties

Typically, abstract classes in management pack libraries will not have properties other than the Display Name property inherited from the Entity class. Abstract classes that are defined by your own management pack may define properties that are inherited by other classes. This saves the lower level classes from each replicating the same property definition.

Relationships

If a class is hosted, any class that uses it as a base class will be hosted by the same parent class. For example, the Windows Computer Role class is frequently used as a base class and is hosted by the Windows Computer class. Any classes that use the Windows Computer Role class as a base class will also be hosted by the Windows Computer class. If a class is to be hosted by a class other than the Windows Computer class, it must use another base class, such as the Windows Application Component class, which is unhosted. Because that base class is unhosted, the class will either remain unhosted or have a custom hosting relationship that is defined for it.

Monitoring

A class will inherit any monitoring targeted at its base class. This is actually how the standard set of aggregate monitors (Availability, Performance, Security, and Configuration) is applied to all classes. These monitors are applied to the Entity class in the System library. Because all classes inherit from this class, all classes inherit those aggregate monitors.

Logical Grouping

In addition to inheritance, use of a custom abstract class in your management pack can help in logically grouping common classes. For example, you may have multiple kinds of computer roles in the application that will each inherit from the Windows Computer Role class. Even if there will be no common monitoring between the classes, there is still value in creating a single abstract class that will act as a base class for individual classes representing each role. This would enable such functionality as creating a single view that targets the abstract class and which would include all computer roles in the application. This also allows for easy specification of all computer roles for criteria in groups and overrides. It basically gives other management pack elements the option of directly targeting a single specific class or all the related classes, depending on the particular scenario.

Side Effects

Different base classes in management pack libraries may have special functionality that is specific to that class. For example, any class that uses the Distributed Application class as a base class is considered a distributed application and will be included in that view in the Operations console. Some classes in the management pack libraries are intended for internal purposes only and should not be used by custom management packs because of unintended effects.

Instead of individually documenting all classes, you should limit your use of abstract classes from the management pack libraries to the list of common base classes here. Any side effects from the particular class are described in this table.

Custom Base Classes

Rather than using only abstract classes from management pack libraries, it is a common strategy to create abstract classes within your management pack for other classes to inherit from. Such a class can provide the previously discussed benefits of inheritance and logical grouping for similar classes in your management pack.

For example, the SQL Server management pack includes four classes for each of its primary server roles. Each should inherit from the Windows Computer Role class and be hosted by the Windows Computer class. However, instead of directly inheriting from this class, an abstract class named SQL Role is created based on the Windows Computer Role class. The individual computer role classes are then based on this custom class.

With this strategy, the management pack can easily include views by using the SQL Role class as a target that displays information for all SQL-related services. Also, because each of the SQL services can have multiple instances installed on a single computer, they require a key property. Instead of including this property on each class, it is defined on the SQL Server Role class and is inherited by the other classes. Each class then adds additional properties specific to that service.

The following table provides the list of classes from management pack libraries that should be used as the base class for classes that are defined in your management pack. They may be used directly as the base class for concrete classes or for custom abstract classes that other classes in your management pack will inherit from. This set of classes will be sufficient to achieve almost any scenario required by any service model.

Class ID Display Name Library Hosting Relationship When to Use Effects
Microsoft. Windows. ComputerRole Windows Computer Role Microsoft. Windows. Library Hosted by Windows Computer. Indicates a primary role of a server. Health automatically rolled up to computer. Column added to the Windows Computer state view.
Microsoft. Windows. LocalApplication Windows Local Application Microsoft. Windows. Library Hosted by Windows Computer. Application that is running on a computer but not the primary server role. Health automatically rolled up to computer.
Microsoft. Windows. ApplicationComponent Windows Application Component Microsoft. Windows. Library Unhosted A component of an application. A hosting relationship can be created by using another class, typically based on ComputerRole or LocalApplication.
System.Service Distributed Application System.Library Unhosted Represents an application for health rollup. Instances listed in the Distributed Applications view.
System. ApplicationComponent Application Component System.Library Unhosted Used for application components not hosted by a computer that is running Windows.
Microsoft. SystemCenter. InstanceGroup Instance Group Microsoft. SystemCenter. InstanceGroup. Library Unhosted Singleton Base class for groups of instances of one or more classes. Included in the Groups list in the Operations console.
Microsoft. SystemCenter. ComputerGroup Computer Group Microsoft. SystemCenter. Library Unhosted Singleton Base class for computer groups. Included in the Groups list in the Operations console.
System.Group Group System.Library Unhosted Singleton Base class for groups used for health rollup. Not included in the Groups list in the Operations console.