The goal of this approach is to perform the integration work on the ``lowest level'' as possible. The XMP/XOM (X/Open Management Protocol, X/Open OSI-Abstract-Data Manipulation) approach [20] has been for a long time the best-known representative of this idea. Initially, its purpose was to enable architecture-independent management by presenting a uniform API for the SNMP and CMIP management protocols and a mapping of ASN.1 constructs into C data types. From today's point of view, this approach failed due to the missing transparency with respect to the underlying protocols. Additionally, its complexity led to the fact that it was only used as a C-based interface to CMIP while the SNMP communication is handled by a separate and easier-to-use dedicated SNMP stack. Furthermore, the recently standardized TMN/C++ API developed by the NM-Forum and described in [21] is now replacing XMP.
The main problem for using XMP in conjunction with CORBA stems from the fact that XMP assumes that every incoming Protocol Data Unit (PDU) has a fixed format. While this is true for SNMP and CMIP, CORBA event messages are a method call on an arbitrary consumer object (see also section III-C.2). Of course, the Postmaster-daemon being responsible for the maintenance of the XMP-stack in network management systems like HP OpenView and IBM NetView could act in the role of an event consumer. Consequently, if typed event communication is used, the consumer interface must be modified every time if new event types have to be considered. This happens very frequently, e.g. if new resources are introduced into the CORBA environment. Furthermore, the above described extensions of the Postmaster-daemon require the availability of its source code - if commercial platforms are used, this is obviously impossible.