Is-A and Has-A Relationships

"Is-A" and "Has-A" Relationships

You may be familiar with modelling in SNMP. Modelling in CIM is fundamentally different because its basic means of linking one component with another is through is a (Joe is an instance of a DogOwner, which is a Human) rather than through has a (Joe has a dog); the has a relationship being modelled, where needed, by means of an association.

The difference may superficially appear small, but it actually turns the model on its head. Appendix B gives more examples and a more complete explanation, but in this section, I try to explain its impact on the model. You can think of the has-a abstraction as being structural ("of what is this entity composed ?") and inheritance as being subtyping. By contrast the is-a abstraction is behavioural ("what does this entity do, what behaviour does it have?") and its inheritance is subclassing.

To make this more concrete, start with the example of an Internet Protocol (IP) table ^[4] and the way it is described using a has-a system such as SNMP and an is-a system such as CIM.

Figure 5.5 illustrates some of the subdivisions of IP within the standard SNMP MIB-II. IP itself is addressed as 1.3.6.1.2.1.4, meaning that it is the fourth item in 1.3.6.1.2.1, within the SNMP MIB-II. This is itself the first sub-item of 1.3.6.1.2, which is known as IETF Management. This process continues to the top of the tree, which is known as 1 or "ISO Assigned Object Identities." The part of the SNMP tree below IP, as shown in Figure 5.5, contains the IP address table (which holds the IP address of every port on the device) and the IP routing table (which holds the information to route packets, a definition of the next hop for each possible destination). This is a has-a relationship: IP has an IP address table which has-an IP address entry. (Note: I have dotted the upper links in Figure 5.5 because the containment hierarchy is not always strictly applied above tables.)

Figure 5.5: Part of the SNMP MIB-II Subtree

Contrast this with Figure 5.6, which contains that part of the CIM model concerned with IP routing tables.

Figure 5.6: Part of the CIM Network Model

A CIM_NextHopIPRoute is a CIM_NextHopRoute, which is a CIM_ManagedElement. Similarly a CIM_IPProtocolEndpoint is a CIM_ProtocolEndpoint, which eventually is a CIM_ManagedElement. Notice that a CIM_IPProtocolEndpoint is a peer of a CIM_TCPProt-ocolEndpoint and a CIM_LANEndpoint and (not shown in Figure 5.6) a CIM_BGPProtocolEndpoint: this is not unreasonable ”they are all protocol endpoints and therefore all share some properties such as a protocol type (IPv4, IPv6, IPX, AppleTalk, DECnet, SNA, etc.) and some associations (e.g., with a service), which they can inherit from CIM_ProtocolEndpoint.

This intrinsic similarity between IP and TCP as service endpoints is lost in the SNMP representation because TCP appears in a totally different subtree: rooted at 1.3.6.1.2.1.6. In the CIM model, any behaviour associated with all protocol endpoints can be encapsulated in one place: in CIM_ProtocolEndpoint. Any changes affecting all end-points can then be made in one place.

^[4] The precise meaning of this is not important at the moment ”assume that it is a collection of tables used in an IP router to decide how to handle received packets.