Defining Classes and Relationships

Applies To: System Center Operations Manager 2007

The basic strategy of selecting a set of classes to provide a model for an application is to identify the application’s different components and define an appropriate class to represent each one. Each class definition will include its base class, its relationships with other classes, and a set of properties to hold the values required for the different monitoring scenarios targeted at the class.

Because a service model can be created for any kind of application on various computing platforms or even to support monitoring of physical devices, it is difficult to provide a single process that applies to all scenarios. The following guidance applies to designing a model for a typical application that is running on one or more Windows-based servers. Many applications fit into this basic architecture and can have an effective model designed with this fairly simple process. This basic strategy can also be extrapolated to other kinds of applications.

Each class listed here includes a short description of the base class that is typically used. Additional detail on the implications of the base class and criteria for selecting an appropriate one are provided in Choosing a Base Class.

Define Application Roles

The first class that should be defined is one to represent the installation of the application on a particular computer. This can be known as an application role. For many applications, a single class will be sufficient for this purpose. However, more complex applications may have multiple classes to represent different kinds of servers or different core services that require unique monitoring. This class is typically hosted by the Windows Computer class so that it can be discovered on any agent where the application is installed.

One thing to consider in this step is which application roles might be installed on separate computers. One function of a class is to act as a target for workflows specific to the application that has workflows targeted at the class running on the agent managing an instance of that class. If two components of an application will always be installed on the same computer, they can frequently be represented by a single class. If there is a potential for them to be installed separately however, they should each have their own class so that any targeted workflows will run on the appropriate agent.

The DNS 2008 Server management pack provides an example of a single class used to represent an application. An instance of the DNS 2008 Server class is discovered on any computer that is running Windows 2008 Server that has DNS installed. Any monitors and rules specific to the DNS Server class can be targeted at this class in addition to discoveries for identifying other DNS components that may be installed on the server.

DNS 2008 Server class

The SQL Server 2008 management pack, on the other hand, has four separate classes for its primary functions: the DB Engine class, the Analysis Services class, the Integration Services class, and the Reporting Services class. These are distinct services in SQL Server that will each have unique monitoring and can be installed separately from another. SQL Server requires a separate class for each role in order to independently measure the health state of the different components and use them as targets for unique monitoring scenarios.

Computer Role classes for SQL Server 2008

The base class used for application roles will typically be the Windows Computer Role class or the Windows Local Application class. These are both hosted by the Windows Computer class. Classes based on the Windows Computer Role class are considered a primary function of a server, and their health state will be automatically rolled up to their hosting computer. The Windows Local Application class is intended to represent smaller applications, and its health state will not roll up to the computer.

Computer role classes typically do not have a key property, because they usually have only a single instance on any given computer. There are exceptions to this standard, however, for applications that can have multiple instances installed. SQL Server, for example, can have multiple instances installed on a single computer, and the class for each role has a key property for the instance name.

Define Application Components for Each Application Role

After each of the application’s primary roles are identified (a single role for a simple application), identify those components hosted by each role that require a distinct health state. The application role alone may be sufficient for a simple application, but more complex applications may benefit from one or more additional classes for additional components of the application. These components will typically be hosted by one of the computer role classes that are defined in the previous step or by another application component.

Application components typically share a one-to-many relationship with their hosting class. In other words, a single computer role instance will usually hold multiple instances of a single application component. If only a single instance of the application component is expected, it is frequently of minimal value to create a unique class for it.

For example, the DNS Server class hosts a class named DNS Zone. Each instance of the DNS Zone class represents the different zones that can be installed on a single DNS server. Creating a separate class lets each zone have its own health state.

DNS Server classes

Another example is the Windows Server 2008 Internet Information Services 7.0 management pack, which defines a class named IIS 7.0 Server Role that is discovered on any computer that has IIS 7.0 installed. This class hosts classes representing the different kinds of components that may be installed: Web server, FTP server, and SMTP server. Each IIS installation may have any combination of these installed. Each Web server, in turn, may have multiple Web sites that are represented by the IIS 7.0 Web Site class. In this case, the server role hosts the Web server, and the Web server hosts the Web site. The same is true for FTP sites.

Application Component classes for IIS 7.0

Application component classes should typically use the Windows Application Component class for a base class. This abstract class is unhosted. This means that the class inheriting from it can create its own hosting relationship with the application’s computer role. It will typically require a key property, because multiple instances of the class are usually expected for the hosting role.

Identify Dependencies Between Classes

The health state of any class can depend on the health state of another as long as they share a hosting or containment relationship. For example, when a monitor targeted at an application role class reports a negative health state, the computer that is hosting the object can also show a negative state. Similarly, the health of an application role can depend on any of the application components that it hosts.

Most of the health dependencies required for a service model will already exist by the time that classes and hosting relationships are defined. Containment relationships have to be defined for any additional classes whose health depends on the health of another class that it does not already share a hosting relationship with.

For example, in the Windows Server 2008 Internet Information Services 7.0 management pack, the IIS 7.0 Web Server class hosts classes called IIS 7.0 Web Site and IIS 7.0 Application Pool. Web sites and application pools are both components that can be created independently on a Web server, and any particular instance of one can exist without any particular instance of the other. However, one or more Web sites can be configured to use a particular application pool, and the health of the Web site will depend on the health of any application pool that it is configured to use. In order to support this dependency, the management pack includes a containment relationship between the IIS 7.0 Web Site class and the IIS 7.0 Application Pool class.

Containment relationship between IIS 7.0 classes

Define Application Class

Distributed applications typically define a top-level class to represent the application itself. Containment relationships are defined between this class and each of the application’s role classes (which in turn, host the application’s components). This provides an overall health state for the application. All applications will not have such a class. It is created only for those applications where a single consolidated health state for all the application’s roles and components in a particular environment is relevant.

For example, the Active Directory management pack includes a class named Active Directory Topology Root. This represents the overall Active Directory installation in a particular environment. This class contains classes for the Active Directory Forest, Sites, and Domains so that it can provide an overall health state for the environment.

The SQL Server management pack, by contrast, does not have a class representing the whole environment. The nature of SQL Server is such that there is no concept of an overall environment but instead distinct installations on different servers. There would be minimal value in providing an overall measurement for the health of all instances of SQL Server.

The application class should typically be a singleton. Because it represents the overall application installation in the environment, there should not be a requirement for multiple instances of it. If the class is based on the Distributed Application class, it will be included in the list of Distributed Applications in the Operations console.

Groups

The final step in the service model design is to define any required groups. Groups are singleton classes that contain a collection of other objects. They can be useful in a service model for different reasons, as detailed here.

Health Rollups

Groups can be used for a health rollup for instances of a particular class. For example, a distributed application may include multiple computers that have a particular computer role installed. In addition to a health state for each computer role instance and a health state for the whole application, a health state may be required for all instances of the particular role. This functionality is supported by creating a group that contains all instances of the class to consolidate.

An effective exercise of identifying any required health rollup groups is to draw the desired diagram view for the application. This should include all the classes created in the previous steps. If these classes are insufficient to create the required diagram view, health rollup groups can be defined to complete the requirements.

Rollup of health from classes to containing group

Groups used for health rollups can be based on either the Instance Group class or the Computer Role class. If based on the Instance Group, they are the same as any other instance group and will appear in the Groups list in the Authoring pane of the Operations console. If they are based on the Computer Role class, they will not appear in this list.

Instance Groups

Instance groups can be used to distinguish a set of objects that do not have a unique class for monitoring. These are the same as typical instance groups that a user can create in the Operations console.

For example, the Active Directory 2008 management pack includes a group named RODC Group that contains all read-only domain controllers. These are instances of the Active Directory Domain Controller Server 2008 Computer Role class for which the Read-Only Domain Controller property is true. This group is then used for overrides that disable rules that are not relevant to a read-only domain controller. One alternative would be to create a special class for read-only domain controllers inheriting from the Domain Controller class. However, it was determined that there were not enough unique monitoring scenarios for the read-only domain controller to warrant specializing the Domain Controller class. The RODC Group is sufficient to achieve the desired functionality.

These groups are typically based on the Instance Group class. Any group based on this class will appear in the Groups list in the Authoring pane of the Operations console.

Computer Groups

Computer groups contain a collection of computer objects on which another object exists. This is distinctly different from the instance groups containing the application objects themselves. This type of group can be used to support such group functionality as views and user roles for the computers hosting a particular application.

For example, the SQL Server management pack includes a group called SQL 2008 Computers that contains all computers with at least one SQL Server 2008 component installed. This can be used to provide a database administrator access to the servers hosting SQL Server through a user role or a view of all computers that are running instances of SQL Server in a state view.

Computer groups for SQL Server 2008

Computer groups are based on the Computer Group class. Any group based on this class will appear in the Groups list in the Authoring pane of the Operations console.

See Also

Concepts

Classes
Relationships
Choosing a Base Class

Other Resources

Creating Classes and Relationships