Wie die Übersicht in Kapitel 3.7.2 zeigt, liegt ein Schwerpunkt der MIB auf der Einführung von generischen Konzepten für das Anwendungsmanagement. Im folgenden wird untersucht, inwiefern die von der MIB definierte generische Managementinformation und -funktionalität durch die ODP-Basisklassen des Objektmodells abgedeckt wird.
Die Application Management MIB führt eine dienstorientierte Sicht (service level view) ein. Es gibt daher eine Tabelle, die einer Anwendung ein oder mehrere benannte Dienste zuordnet. Dies entspricht genau der Sicht des Objektmodells, bei dem sich eine Anwendung aus ein oder mehreren Computational Objects zusammensetzt, die an ihren Schnittstellen Dienste anbieten. Weiterhin gibt es eine Tabelle, die die Prozesse beschreibt, die einen Dienst realisieren. Im Modell entspricht dies Instanzen von capsule, die über die Enthaltenseinshierarchie Basic Engineering Object, Cluster, Capsule einem Dienst (Computational Object) zugeordnet werden können.
Für Dienste wie NFS-, FTP- oder WWW-Server ergeben sich wichtige Leistungsdaten aus der Statistik der Dateizugriffe. Relevante Fragestellungen sind hier ,,Auf welche Dateien wurde wie oft (lesend oder schreibend) zugegriffen?`` oder ,,Wie groß war die übertragene Datenmenge (in Bytes) im Mittel?``, etc. Hierzu definiert die MIB eine Tabelle applOpenFileTable mit Einträgen zu den offenen Dateien einer Anwendung. Die folgende Tabelle listet die wichtigsten Attribute eines Eintrags und deren Bedeutung auf:
applOpenFileOpenTime Öffnungszeitpunkt der Datei applOpenFileName Dateiname applOpenFileReadRequests Anzahl Lesezugriffe applOpenFileReadFailures Anzahl Lesefehler applOpenFileBytesRead Anzahl gelesener Zeichen applOpenFileLastReadTime Letzter Lesezugriff applOpenFileWriteRequests Anzahl Schreibzugriffe [...] analog für Schreibzugriffe applOpenFileSize Dateigröße
Da das RM-ODP keine Konzepte für Dateien enthält, wird der Dateizugriff im Objektmodell über eine neue Klasse fileInterface modelliert, die eine Unterklasse von operationInterface ist. Für diese Klasse wird die feste Rolle «Client» angenommen. Sie modelliert eine Dateischnittstelle für die Anwendung zum Betriebssystem. Das entsprechende serverseitige Interface und die zugehörigen Engineering Interfaces sind Teil des Betriebssystems und werden nicht weiter modelliert.
Die Klasse fileInterface erhält die zusätzlichen Attribute FileName und Size für den Dateinamen und die Dateigröße. Sie abstrahiert von einer Schnittstelle mit den Methoden read(), write() etc. zum Zugriff auf Dateien. Jeder dieser Methoden sind entsprechende Unterklassen von interactionInfo zugeordnet. Um beispielsweise die Anzahl der Lesezugriffe auf eine geöffnete Datei festzustellen, ist das Attribut Count der zur Methode read() gehörenden Instanz von interrogationInfo auszulesen. Den letzten Zugriffszeitpunkt würde analog das Attribut Last liefern. Die Anzahl der Lesefehler wäre in einer entsprechenden Instanz von terminationInfo festgehalten. Das Attribut Bytes von interactionInfo gibt Auskunft über die Anzahl der gelesenen oder geschriebenen Zeichen. Der Zeitpunkt an dem die Datei geöffnet wurde, ist identisch mit dem Zeitpunkt an dem die Anwendung die Klasse fileInterface für diese Datei instantiiert hat.
Diese Information steht nur solange zur Verfügung, wie eine Anwendung eine Datei geöffnet hat. Wird die Datei geschlossen, wird der Eintrag in der SNMP-Tabelle bzw. die Instanz von fileInterface mit allen zugehörigen Interaction Infos gelöscht. Sollen die Daten auch in einer langfristigen Statistik über den Dateizugriff ausgewertet werden, bedarf es - analog zum bereits erwähnten Log - generischer Managementobjektklassen, die Funktionalität zur Führung von Statistiken verkörpern. Diese könnten für obigen Anwendungsfall wiederum geeignet spezialisiert werden. Diese Statistikklassen müßten neben Funktionalität zur Sammlung und Auswertung von Datenreihen, wie z.B. Mittelwertbildung, auch die Möglichkeit zur dauerhaften Speicherung der Daten in einer Datenbank bieten, damit Analysen über einen längeren Zeitraum (Tage, Wochen, Monate) durchgeführt werden können.
An dieser Stelle soll noch einmal angemerkt werden, daß genau wie bei der Application Management MIB natürlich eine Instrumentierung der Anwendungen erforderlich ist, um diese Art von Managementinformation auslesen zu können. Ein Agent innerhalb der Anwendung bzw. die Anwendung selbst muß zur Laufzeit die im Objektmodell spezifizierten Klassen wie compObject, fileInterface oder interactionInfo implementieren, die für eine Managementapplikation die sog. Managed Object Boundary darstellt.
Analog zur Tabelle der offenen Dateien definiert die Application Management MIB eine Tabelle applOpenConnectionTable mit Einträgen der offenen Kommunikationsverbindungen einer Anwendung. Ohne weitere Vertiefung listet Tabelle 4.1 zu den wichtigsten Variablen eines Eintrags die im Objektmodell korrespondierenden Klassen und Attribute. Alle Variablen eines Eintrags von applOpenConnectionEntry besitzen das Präfix applOpenConnection im Namen. Die Bedeutung sollte sich aus dem Namen ergeben.
| MIB-Variable | Klasse | Attribut |
| ID | channel | ID |
| OpenTime | channel | OpenTime |
| Transport | channel | TransportProtocol |
| NearEndAddr | engInterface | Reference |
| bzw. | basicEngObject | BindingEndpointID |
| FarEndAddr | engInterface | Reference |
| bzw. | basicEngObject | BindingEndpointID |
| Application | channel | ApplicationProtocol |
| ReadRequests | interrogationInfo | Count |
| ReadFailures | terminationInfo | Count |
| BytesRead | interrogationInfo | Bytes |
| LastReadTime | interrogationInfo | Last |
| WriteRequests | announceInfo | Count |
| [...] | analog Lesen |
Die Application Management MIB beschreibt auch ein einfaches Modell (siehe Abbildung 4.11) für das Auftragsmanagement. Ein Auftrag (unit of work) bzw. eine Transaktion setzt sich aus einer Anfrage (request) eines Clients ( invoker) und der Antwort (response) eines Servers ( performer) zusammen. Ein Strom von Transaktionen kann einer Datei, einer Netzverbindung oder der Standardeingabe/-ausgabe zugeordnet sein. Eine Anwendung kann Client oder Server für ein- oder mehrere Transaktionsströme sein. Die MIB definiert mehrere Tabellen mit Status- und Leistungsinformationen zu Transaktionsströmen. Dabei können verschiedene Typen von Transaktionen berücksichtigt werden. Die Tabellen besitzen u.a. Attribute zum Zählen von Transaktionen, zum Bestimmen des Zeitpunkts der letzten Transaktion und zur Messung der Zeitdauer zwischen Absenden der Anfrage und Empfang der Antwort auf Client-Seite bzw. zwischen Empfang einer Anfrage und Absenden der Antwort auf Server-Seite.
Es handelt sich hierbei um Managementinformation auf einer höheren Ebene als bei den vorher besprochenen Tabellen. Während dort nur die Anzahl der Zugriffe auf Dateien/Verbindungen und die übertragene Datenmenge in Bytes gemessen werden kann, wird hier Leistungsinformation zu konkreten, auch für Menschen unterscheidbaren Aufträgen definiert. Ein Beispiel mag dies verdeutlichen. Bei einem FTP-Server kann die Menge an übertragenen Bytes über dessen Kommandoschnittstelle Bedeutung haben. Ein menschlicher Administrator wird aber vielmehr Interesse daran haben, wieviele Aufträge, das heißt get- und put-Kommandos über die Schnittstelle abgewickelt werden.
Im Objektmodell kann diese Information wiederum über Computational Interfaces und deren Interaction Infos modelliert werden. Beispielsweise hat ein Server (compObject) eine Schnittstelle (operationInterface), an der er Aufträge aus einem Transaktionsstrom entgegennimmt. Zu jedem Transaktionstyp gehört eine Instanz der Klasse interrogationInfo. Deren Attribute geben Auskunft über die Anzahl der Aufträge bzw. Transaktionen (Count) und über die Bearbeitungszeit des letzten Auftrags ( LastDelay). Natürlich kann eine Anwendung mehrere Transaktionsströme bedienen. Hierzu wird die Anwendung entweder in mehrere Computational Objects aufgeteilt oder ein Computational Object instantiiert mehrere Schnittstellen. Die zugehörigen Engineering Interfaces können an einen Kanal oder an eine Dateischnittstelle des Betriebssystems gebunden sein. Es wird an dieser Stelle verzichtet, die genaue Abbildung der Tabellenattribute auf die Klassen und Attribute des Objektmodells anzugeben.
Die letzten beiden Tabellen der Application Management MIB behandeln den Status und die Kontrolle von Anwendungsprozessen. Die erstere ergänzt nur leicht die entsprechende Tabelle der System Application MIB. Die Beziehung zum Objektmodell wurde daher in Abschnitt 4.5.3 bereits beschrieben. An Steuermöglichkeiten definiert die MIB ,, Pushbutton-Variablen`` zum Stoppen (suspend), Weiterlaufen (resume) und Beenden (terminate) von Prozessen. Diese Funktionalität ist durch die entsprechenden Methoden der Klasse capsule abgedeckt.
Bei der Application MIB wird auf eine graphische Gegenüberstellung der Basisklassen mit den MIB-Tabellen verzichtet. Einerseits ist die Übereinstimmung der bereitgestellten Information nicht leicht ersichtlich (interactionInfo), andererseits enthält die MIB sehr viele reine Index-Tabellen deren Abbildung auf Beziehungen zwischen den MOCs nur schwierig dargestellt werden kann. Trotzdem wurde gezeigt, daß die für das Anwendungsmanagement wichtige Information und Funktionalität aus der Application Management MIB in den ODP-Basisklassen hinreichend modelliert ist.