4.1 Defining the Base Classes of the Inheritance Hierarchy

  The inheritance hierarchies of today's object-oriented management frameworks are usually not very deep and the degree of reuse is limited because the predominant part of relevant management information is often specified in resource-specific classes. Consequently, the base classes do not contain a large amount of information. On the other hand, one must recognize that - in general - different distributed applications share a lot of common properties: e.g., they are delivered as packages that consist of modules implementing a service which is instantiated as a process. What we need is a framework that allows us to describe the relevant aspects of any kind of distributed application (in our case: management systems) in a way that it is suitable for management purposes. As described in [13], RM-ODP [6] provides a standardized framework that covers the different aspects of distributed applications and therefore has been taken as the basis for deriving generic application management instrumentation.

For the purpose of technical management, the computational and engineering viewpoint languages fit best because they standardize descriptions of the resources that we are interested in; the reasons for the restriction on two out of five viewpoints are detailed in [17]. However, the viewpoint language concepts only make assertions about object classes and do not provide information about the class properties or its operations. Thus, parts of the management information and services described in section 3 become attributes and methods of these enhanced base MOCs. Some of these abstract base MOCs are depicted on the highest level of Figure 3 and reflect the characteristics of distributed applications w.r.t. configuration and fault management. For the ease of understanding, we now describe the amount of management information covered by these generic MOCs by applying them to the components of a specific network management platform, namely IBM NetView for AIX (the appropriate component names are given in parentheses):

A Computational_Object stands for a running service (e.g., a platform topology service) that is instantiated as a process or - in RM-ODP terminology - Capsule (e.g., ``gtmd''). The static configuration information about this service, i.e., information about the software module is described in the Computational_Object_Template (e.g., ``Generalized Topology Manager''). In order to reflect the structure of large software packages, we have defined an additional abstract class Package (e.g., ``IBM NetView for AIX'') that serves as a container for the different software modules.

Although the base MOCs are abstract classes that must be further refined, one has to recognize that these MOCs based on RM-ODP concepts make that many required attributes and methods are already defined at the top of the inheritance hierarchy: Important characteristics relevant to software packages are present; in addition, instrumentation for installing and updating them is specified. Descriptions of services and their technical realization (as processes) are available. Services and applications can be started, stopped, suspended and resumed. This covers a large amount of MIB-instrumentation that is usually defined only on lower, i.e., resource-specific levels (e.g. every SNMP group or table contains Name and Description attributes). Consequently, we can then guarantee a minimum amount of instrumentation commonly applicable to all kinds of distributed applications.