Bei der bisherigen Gatewayarchitektur wurde noch nicht festgelegt, wie die
Kommunikation des Gateways mit den SNMP-Agenten abläuft. Es wurde lediglich
angemerkt, daß die OSI-Attribute ihren Wert direkt mittels SNMP-PDUs aus
der MIB der jeweiligen SNMP-Agenten erhalten bzw. die Global
Polling-Komponente die SNMP-Tabellen auf Veränderungen überprüfen
kann.
Für die Einbindung der SNMP-Manager-Funktionalität ist es daher
naheliegend, jedem Attribut bzw. der Global Polling-Komponente die
Möglichkeit zu geben, selbstständig SNMP-PDUs zu verschicken bzw. die
Antworten zu empfangen. Damit wäre in jedem Attribut bzw. in der Global
Polling-Komponente ein eigener SNMP-Manager integriert. Das heißt aber
auch, da jedes Attribut genau eine SNMP-Variable repräsentiert, daß für
jede in den SNMP-Agenten vorhandenen Variablen ein SNMP-Manager im Gateway
existiert. Damit ist aber ein sinnvoller Einsatz von SNMP-GetNextRequests- bzw.
-GetBulkRequest-PDUs ausgeschlossen. Weiterhin wäre die Integration einer
neuen SNMP-Programmierschnittstelle, der ,,Update`` einer vorhandenen
Programmierschnittstelle oder das Einführen einer neuen SNMP Version nur
durch das Verändern aller Attribute bzw. der Global Polling-Komponente
möglich. Schließlich wäre es denkbar, die SNMP-Kommunikation des Gateways
mit den SNMP-Agenten selbst für das Management bereitzustellen. Dazu
müßten globale Datenstrukturen eingeführt werden, die von jedem
SNMP-Manager im Gateway aktualisiert werden. Diese Datenstrukturen könnten
Statistiken wie die Anzahl aller empfangenen, fehlerhaften SNMP-PDUs
enthalten.
Die Diskussion dieses Ansatzes hat gezeigt, daß es sinnvoll ist, die
SNMP-Programmierschnittstelle in eine eigene, globale
Komponente im Gateway einzubinden: der SNMP-API. Sie besteht aus einer
Instanz der C++-Klasse SNMP und kapselt in dieser die verwendete
SNMP-Programmierschnittstelle. Dabei werden folgende Methoden der Klasse
SNMP auf die Funktionen der Programmierschnittstelle abgebildet (siehe auch 6.1.1):