2 Umbrella Management: Achieving Interoperability

  A major objective of Enterprise Management consists in presenting a unified, all-encompassing view on networks, systems, services and applications. It is oriented towards the providers' goals and gives them the ability to control any kind of managed resource according to their management requirements, policies and organizational conditions. Enterprise Management follows a top-down approach and should therefore not be constrained by technical specifics. On the other hand, the amount of management frameworks providers have to deal with is already determined by the nature of the managed resources: LAN components usually have SNMP agents while telecommunication components are managed according to the OSI/TMN framework; distributed applications and services might provide a CORBA-based management instrumentation. Umbrella Management has to cope with the heterogeneity of Management and focuses on the technology-related aspects of cooperation between entities involved in the management process. Its objective is to abstract from the heterogeneity of the underlying management architectures by defining means of interoperability. It is therefore fundamental for integrated Enterprise Management (see Figure 2).

  

Figure 2:: Umbrella Management as a basis for Enterprise Management

There are basically three strategies for achieving interoperability between systems located in different architectural domains (see also [10]):

The first approach consists in the integration at the resource level, i.e., the managed systems support more than one management protocol; they are equipped with Multiarchitectural Agents. This is usually unfeasible for the following reasons: Often, agents are used to perform monitoring of simple network devices like hubs or bridges. They should not consume a large amount of resources and are usually built into the firmware of the device; the implications are that these agents can neither be enhanced to support another management protocol nor should they introduce additional overhead.

An alternative is to place the burden of integrating the different architectures on the MS. Such a Multiarchitectural Manager supports a set of management protocols which are implemented onto the platforms' communication stack. Thus, conversions between different management protocols are not necessary. The transformation of the management information descriptions is often handled by tools bundled with an MS like MIB compilers and therefore need not be handled by the developer. In addition, the service APIs of MSs can easily be accessed thus yielding the opportunity of reusing the large amount of platform services (see also section 5). On the other hand, these APIs are specific to a concrete MS product: the portability of interoperability solutions based on this integration paradigm is often restricted.

The third solution is the Management Gateway (MG) approach. It is then possible to manage services, systems and networks in different management architectures from a single point of control as demonstrated in [15] and [21]. It is even possible to apply the power of a management architecture with rich functionality to any resource in different architectural domains. In management architectures having no notion of a management functional model such as the Internet (SNMP) framework, the application of management functionality ``borrowed'' from other architectures is particularly useful. Standardized mappings between the OSI, Internet and CORBA information models have been developed by the Joint Inter-Domain Working Group of Opengroup and NM-Forum [9]; the appropriate interworking architecture has been recently submitted to the OMG in response to the CORBA/TMN Interworking RFP. Our experiences with building MGs [12] have shown that they represent powerful instruments for bridging the gaps between different management architectures as neither the managing nor the managed systems need to be modified. This is a crucial feature w.r.t. the service provider scenario described in section 1. While design principles of MGs are today reasonably well understood, our experiences have also shown that they are complex systems and - due to their high relevance for enterprise management - need to be managed as well; in the next sections, we will describe why we consider MGs as a special case of MSs and show what their management instrumentation may look like.