There are basically three different strategies for achieving a seamless interaction of components located in different architectural domains (see also [15]):
The first approach consists in placing the burden of integrating the different architectures on the managing system. Such a multiarchitectural Operations System Function (OSF) supports a set of management protocols which are implemented onto the OSF's communication stack. A conversion between different management protocols is therefore not necessary. The transformation of the management information descriptions is often left to the management applications and not handled by the OSF infrastructure. The experiences with XOM/XMP show that this kind of integration is unsatisfactory: Multiarchitectural OSFs distinguish at the top of the topology hierarchy between the different supported architectures. The application of one architecture's specific features (such as the OSI scoping and filtering facilities) to managed objects in another architecture is impossible.
An alternative is 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 ([18], [6]).
The third solution is the Q-adapter function. It is then possible to manage services, systems and networks in different management architectures from a single point of control. It is even possible to apply the power of the OSI management architecture to any resource in the different architectural domains, as shall be described in section 4.1. 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. For these reasons, we decided to follow this approach for the design and implementation of our interoperability solution.