Figure LR.31 - CompoundResource, ResourceCollection, and ResourceElement

PhysicalResource and its subclasses are designed to model the physical aspects of a managed Resource in as much detail as is necessary. Similarly, LogicalResource and its subclasses are designed to model the logical aspects of a managed Resource in as much detail as is necessary. Sometimes, however, it is easier to think of device components using a slightly higher level of abstraction. Note, for example, that it is common to think of a “device” – this has the connotation of aggregating the physical and logical aspects of the device together into a single managed entity.<br/>The purpose of the CompoundResource hierarchy is to provide this abstraction. Conceptually, the CompoundResource class hierarchy provides a framework in which the PhysicalResource and LogicalResource class hierarchies can be aggregated into. This enables the application to construct application-specific views of the Resource or set of Resources that are being managed.<br/>The reason that the ability to construct views is deemed so important is because different applications have different purposes and need to focus on different parts of the network and/or different aspects of devices. The CompoundResource framework enables an application-specific view to be constructed from a standard template.<br/>The CompoundResource may contain:<br/>        • one or more PhysicalResources must be present<br/>        • one or more LogicalResources must be present<br/>        • and CompoundResources can be aggregated as well<br/>For example, a Router could be modeled as a CompoundResource, composed of physical (e.g., Cards) and logical (e.g., route processing) aspects to it.<br/>Note that CompoundResource is a subclass of Resource. This enables a CompoundResource to inherit all of the characteristics and behavior of a Resource. Even more importantly, ResourceSpecification can be subclassed to templatize the creation of CompoundResources. This also applies to Characteristics, CharacteristicValues, Versions, and other entities. If CompoundResource wasn’t a subclass of Resource, all of this work would have to be repeated. This would make it very difficult to synchronize these characteristics of CompoundResource with the same characteristics of PhysicalResource and LogicalResource.<br/>The CompoundResource class hierarchy is shown in the Figure below.<br/>A key point is that each managed entity that is part of a CompoundResource can be individually managed. The CompoundResource is an abstraction that enables the physical and logical aspects of a complex entity, such as a Router, to be looked at using one (instead of multiple) objects. As such, it (and its subclasses) facilitates the coordination of configuration, monitoring, troubleshooting commands to be applied to different aspects of the CompoundResource. It also enables policies to be written that coordinate the physical and logical aspects of the CompoundResource.<br/>The *-* cardinality of the association between CompoundResource and Resource enables additional PhysicalResources, LogicalResources, and optionally CompoundResources to be aggregated into this specific CompoundResource.<br/>