Relationships
Applies To: System Center Operations Manager 2007
Note
This topic has been updated in the latest version of the System Center Management Pack Authoring Guide on the TechNet Wiki.
Relationships are defined between classes to indicate an association between a particular instance of one class and the particular instance of another. There are three types of relationship as listed below and detailed in the following sections.
Hosting relationship
Containment relationship
Reference relationship
Hosting Relationship Type
The most important and most restrictive relationship between classes is the hosting relationship. A class hosted by another class is called a hosted class, and an instance of the class is called a hosted object. If a class is not hosted by another, it is called an unhosted class, and an instance of the class is called an unhosted object.
When one object is hosted by another, that object relies on its hosting parent for its very existence. If the hosting parent is removed, the hosted child will also be removed. For example, a logical disk cannot exist without the computer that it is installed on. Therefore, the Logical Disk class is hosted by the Windows Computer class. This means that every instance of the Logical Disk class must have an instance of the Windows Computer class to host it. If a computer is removed from the management group, any instances of the Logical Disk class hosted by it will also be removed.
Sample Logical Disk hosting relationships
.gif "Hosting Relationship for Logical Disk class")
A hosted object can have only one hosting parent, but one parent can host multiple children. For example, a particular disk can be installed on only a single computer, but one computer can have several disks installed.
Hosted objects are affected by their hosting parents in the following ways:
Identity |
As described in Classes, an object is identified by its key property. If the object is unhosted, the value of its key property must be unique for the whole management group. For hosted classes however, the key property value must be unique only for all objects that have the same hosting parent. To uniquely identify a hosted object, the key property of both the object and the object’s parent are required. For example, the key property of the Logical Disk class is Device ID. Every computer in a particular environment will have a logical disk that has a Device ID of C: and possibly several other common disk letters. Because every disk object requires a unique value for its key property, the Logical Disk class cannot be unhosted. It is hosted by the Windows Computer class that has its own key property of Principal Name, which is the computer’s name. The key property only has to be unique for the hosting parent. In this case, this means that the Device ID only has to be unique for each computer. This makes logical sense, because a particular computer cannot have two disks that have the same Device ID. The path for each Logical Disk instance will be the computer name followed by the Device ID, as shown in the previous diagram. |
Managing Agent |
If an object is hosted, it will be managed on the same computer as its hosting parent. If it has an instance of the Windows Computer class as a hosting parent (meaning that the object’s class is either hosted directly by the Windows Computer class or has the Windows Computer class somewhere in its tree of hosting parents), the object will be managed by the health service on that computer. For example, the Logical Disk class is hosted by the Windows Computer class. This means that each Logical Disk object will be managed on the computer where the disk is installed. If an object is unhosted, by default it is managed by the agent on the Root Management Server. For example, groups are unhosted classes, and any monitors or rules targeted at a group are run on the RMS. |
Available Properties |
Any workflows targeted at a class have access to that class’s properties in addition to the properties of any of its hosting parent(s). For example, a script in a monitor using the Logical Disk class as its target might require the name of the computer. Because an object can have only one hosting parent, we know the computer that hosts any particular instance of the Logical Disk class. The monitor can access the properties of the targeted object and the properties of that target’s hosting parent. |
The SQL Server management pack provides another example of hosting relationships. The hosting relationship between the Windows Computer class, the SQL 2008 DB Engine class, and the SQL 2008 DB class is shown here.
Hosting Relationships for SQL Server 2008 Classes
.gif "Hosting relationship for SQL Server 2008 classes")
The SQL 2008 DB Engine class represents an instance of SQL Server 2008 installed on a particular computer. Because a database can be installed on only a single database engine, the SQL 2008 DB Engine class hosts the SQL 2008 DB class. There can be several databases with the same name in a management group, but any databases installed on a particular instance of the SQL Server class must have a unique name. The database engine, in turn, is hosted by the Windows Computer class. There can be several SQL Server instances with the same name in a management group. Each one on a particular computer must have a unique name.
Because there are two hosting relationships, the path name for each database will be the computer name followed by the instance name followed by the database name. An example is shown in the following diagram.
Sample Database hosting relationships
.gif "Sample Database Hosting Relationship")
Containment Relationship Type
The containment relationship type is less restrictive than the hosting relationship. It declares that one class is related to another class, although one is not required for the other.
Containment relationships are typically used for one of two purposes:
Health rollup |
Dependency monitors mean that the health of one object depends on the health of another object and can be associated with either a hosting or a containment relationship. If one object depends on the health of another, but the two are not in a common hosting relationship, a containment relationship between the two should be created. |
Group membership |
Objects are included in a group through a containment relationship between the group and the member object. |
Unlike a hosting relationship, a containment relationship is many-to-many. This means that one object can contain multiple objects, and a single object can be contained by multiple other objects. For example, one group can contain multiple objects, and a single object can be a member of multiple groups.
Reference Relationship Type
The reference relationship is the most general of the available relationship types. A reference relationship is used when the parent and child classes are not dependent on one another; for example, a database could reference another database that it is replicating. One database is not dependent on the other, and the objects are discovered separately. Health rollup cannot be performed across reference relationships.