Dependency Information Models and Applications

  Modeling dependencies of managed objects has to be seen in the context of the description of management information in general which has always been an important part in the definition of management architectures like OSI (Open Systems Interconnection) management standardized by the ISO [#!iso10165-X!#]. The syntax and semantics are defined in the so called information model; its access in the communication model. The focus of management information traditionally lay on attributes and properties of single objects. Although, e.g. OSI management already defined a General Relationship Model (GRM, [#!iso10165-7!#]), it was never widely used in IT-management. Only in recent years the issue regained more interest [#!rodr00!#]--mainly with the increasing number and complexity of the inter-service, -system and -domain dependencies.

Examples for typical information specific to single managed objects are variables of the Management Information Bases (MIBs, [#!rfc1213!#]) defined in the Internet Management Architecture, like ...mib-2.system.sysLocation that is defined to store the system's location. This kind of information is either stored at the real objects (hardware components, applications, etc.) and accessible via management agents using standardized protocols or within the corresponding object representation at the management tools.

The following subsections focus on another aspect of modeling management information: the so called dependency models. Various types of such models are illustrated together with their applications. Although most model types could also be used for the management of lower (communication) layers, they are analysed with regard to service dependencies, i.e., we leave aside models at the lower OSI layers, like network topologies. Of course, knowledge about the underlying communication structures is also essential, e.g., to diagnose problems or to identify bottlenecks, but this has to be (and to a satisfactory part already is) carried out by very different techniques than the ones needed on the level of end user- and supplementary services, with a much higher degree of complexity and dynamics.

  

Figure: Simple environmental service dependency graph