Choosing a Base Class

發行項
05/13/2011

適用於: System Center Operations Manager 2007

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. For more information, see the links here.

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.

Conceptual view of property inheritance

屬性繼承的概念檢視

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.

Conceptual view of relationship inheritance

關聯性繼承的概念檢視

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.

Conceptual view of workflow inheritance

工作流程繼承的概念檢視

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.

SQL Server Computer Role Classes

SQL Server 電腦角色的自訂類別

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.