As figure 2 shows, there are basically three different strategies for achieving a seamless interaction of components located in different architectural domains (see also [12]):
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: SNMP agents, for example, are often used to perform monitoring of simple network devices. 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 complexity. For an in-depth discussion of this subject, the reader is referred to [13].
An alternative is the Management Gateway approach. It is then possible to manage services, systems and networks in different management architectures from a single point of control as demonstrated in [14] and [15]. It is even possible to apply the power of a management architecture with rich functionality to any resource in the different architectural domains. In management architectures having no notion of a management functional model such as the Internet framework, the application of management functionality ``borrowed'' from other architectures is particularly useful. Furthermore, a translation algorithm has already been specified by the OpenGroup Joint Inter-Domain Working Group (JIDM) [16] that allows the transformation of Internet SMI to CORBA IDL; the appropriate interworking architecture has been recently submitted [17] to the OMG in response to the CORBA/TMN Interworking RFP. Thus, the standardization process for CORBA/SNMP management gateways is currently underway. Furthermore, our experiences with building management gateways [18] have shown that implementations of required CORBAservices (like e.g., Notification, Topology) are also not available on the marketplace today. At their current stage, one has to use proprietary mechanisms for achieving interoperability; another issue is that management gateways are complex pieces of software and are likely to become bottlenecks with respect to performance [19]. However, one can expect that this situation will be improved in the near future as the recent proposals for new services will be adopted.
The third solution is to place the burden of integrating the different architectures on the managing system. Such a Multiarchitectural Manager supports a set of management protocols which are implemented onto the platforms' communication stack. A conversion between different management protocols is therefore not necessary. The transformation of the management information descriptions is often handled by tools bundled with the management platform like MIB-compilers and therefore need not be handled by the developer. Furthermore, the service APIs of available management platforms can easily be accessed thus yielding the opportunity of reusing a large amount of platform services. In our opinion, this solution represents a good compromise between the quality of the integration and the amount of work that has to be undertaken.
Although the gateway-based approach seems to be very promising as a long-term solution, the manager-based integration approach currently demands the least amount of work. Thus, we decided to follow the integration on the side of the managing system for the design and implementation of our interoperability solution. In the following two sections, we will therefore discuss two approaches for doing the platform-based integration and identify the reusable platform services. Section IV explains how our prototype implementation works.