Expressed in terms of traditional management architectures ([14]), management middleware lies between the communication infrastructure and the management applications. The degree of interoperability between different management architectures depends on how similar their functionality has been defined; an important requirement is that middleware defined in one architecture can also be used from another one. On the one hand, this implies that middleware needs to be defined in a precise and open manner. On the other hand, it is necessary to provide the communication infrastructure in order to access the middleware from another architecture; this aspect of interoperability is covered by the management gateways mentioned in 3.2.3.
An example may illustrate this: The OSI management architecture presents with the Systems Management Functions (SMF) a rich set of management functionality specified in terms of object classes. As CORBA possesses, at its current stage, only few similar management middleware, it is important to provide a means of using the SMFs from a CORBA environment. Therefore, it is necessary to map the OSI middleware to CORBA services. Examples of particular good candidates for such a mapping are the Metric Objects and Attributes or the object classes defined in the Summarization function.
The mechanisms of mapping middleware specified in different management architectures are encapsulation and data abstraction. The purpose of encapsulation is to hide implementation- and architecture-specific details: CORBA has, for example, no notion of OSI distinguished names as it uses a completely different naming scheme based on the Object Naming Service. For accessing OSI middleware from a CORBA object, it is important that the interfaces of the OSI middleware are given in IDL. This can be done by encapsulating the OSI SMFs with wrapper objects having an IDL interface. The fact that OSI relies on the object-oriented paradigm eases the transition of the middleware interfaces into IDL. It is therefore possible to reuse the knowledge and specifications of existing standards without needing to modify their implementation because it is irrelevant whether the implementation of a system is object-oriented; the important thing is that the interfaces of its components make them appear as objects ("Perception is reality"). The restriction is that such management functionality has to be defined at compile time of a CORBA agent.
In the Internet management architecture, management functionality is implicitly contained in object-based MIBs. Furthermore, as the Internet SMI has no notion of inheritance, it is difficult to reuse its functionality in object-oriented environments.
Another issue is the portability of the language in which object implementations are written. Software written in programming languages that need to be compiled is, generally spoken, unsuitable for Management by Delegation because the generated binaries are bound to the architecture of the target system. A solution for this problem is to provide management service implementations (generated through cross-compiling) for each architecture that needs to be supported. Due to the high degree of heterogeneity in todays' networked environments, this approach is unfeasible. The other possibility is to implement management services in scripting languages that are interpreted on the managed system or in a portable binary code as it is done with PERL or Java. This issue is covered in the following subsection.