The second step provides a mechanism for the exchange of management data between managed objects in the different domains i.e. the mapping of CMIS requests to SNMP PDUs. The concepts behind this mechanism are described in detail in [23] and will just be sketched out for the sake of brevity. The main aspects of the communication model transformation are the Name Mapping and the Service Mapping.
Name mapping describes the task of computing the corresponding SNMP Object Identifier (OID) from a given name specified in a CMIS request and depending on the containment hierarchy. This is necessary because the OSF has obviously no notion of SNMP OIDs.
Service mapping implies the transformation of CMIS services into
adequate SNMP PDUs. First, the managed objects to which an operation
applies have to be identified, i.e. the set of instances lying in the
scope of the request have to be determined. These instances are then
checked whether their attributes meet the filter criteria. The
obtained set of MO instances is then subject to the operations
according to the figure above.
Incoming SNMP traps are received by
the QAF and transformed into CMIP notifications issued by the
corresponding object instance. CMIS services like M-CREATE and
M-DELETE can be mapped in the case of tables to SNMP-GET requests:
This is done by modifying the corresponding Row Status
variables according to the conventions of the SNMP framework. The
M-CANCEL-get service is the only CMIS-operation that cannot be mapped
to an appropriate SNMP command.
By now, it should have become clear that a QAF does not only act as a converter of protocol data units; it is particularly necessary to perform a mapping between the heterogeneous management information models. This must be done for achieving coexistence and cooperation between management architectures while the agents remain simple. Q-adapter functions are dual-role entities: From the perspective of a managing system, they act as managed systems; from an agent's point of view, they appear as managing systems.