Die System Application Installed Group beschreibt zwei Tabellen für installierte SW-Pakete und deren Elemente, also Dateien. Zur Bereitstellung der Managementinformation ist es erforderlich, daß die Anwendungen als Software-Pakete vorliegen und - wie es unter UNIX üblich ist - mit einem zentralen Installationswerkzeug (package utility) installiert werden. Bei PC-Systemen kann die Information zum Teil aus einer globalen Datenbank des Betriebssystems (registry) ausgelesen werden. Da die Klassen Package und InstallElement des Objektmodells neben der Software Standard Group Definition gerade auf dieser MIB basieren, wird von ihnen der gleiche Informationsumfang zur Verfügung gestellt. Eine Ausnahme bildet das Attribut sysApplInstallElmtRole, welches für ausführbare Dateien Abhängigkeiten und Einschränkungen über boolesche Werte (z.B. «required» oder «dependent») definiert und einem Agenten ermöglicht, zur Laufzeit der Anwendung Aussagen über ihren Status zu machen. Das Attribut RequiredObjects der Klasse capsuleTemplate bietet diese Information in allgemeinerer Form.
In der zweiten Gruppe System Application Run Group gibt es eine Tabelle, die einen Eintrag für jede gerade ausgeführte Anwendung besitzt. Dieser Eintrag setzt sich neben einem Index aus der Startzeit und dem Status der Anwendung zusammen. In der MIB ist der Status der Anwendung identisch mit dem Status des zugehörigen Hauptprozesses und kann die Werte «running», «runnable», «waiting», «exiting» und «other» annehmen. Die Klasse compObject kann hier durch die drei vorhandenen Statusattribute genauer differentieren. Allerdings ist hierfür eine Instrumentierung der Anwendung nötig, da diese Statusangaben nicht aus der Prozeßliste extrahiert werden können. Eine zweite Tabelle enthält die Prozesse zu den Anwendungen aus der ersten Tabelle. Die für Prozesse typische Managementinformation wie Prozessorzeit, belegter Arbeitsspeicher und Aufrufparameter kann wiederum den Klassen capsule bzw. capsuleTemplate entnommen werden.
Beiden Tabellen dieser Gruppe ist eine weitere Tabelle zugeordnet, die Einträge beendeter oder abgebrochener Anwendungen bzw. Prozesse enthält. Befinden sich keine Prozesse der Anwendung mehr in der Prozeßliste, gilt die Anwendung als korrekt (complete) beendet. Im anderen Fall muß von einem Fehler ausgegangen werden und der Exit-Status ist failed. Die Tabellen dienen als eine Art Log (history) speziell für Anwendungen. Diese Funktionalität wird von dem Objektmodell nicht geboten. Es ist auch nicht sinnvoll, ein Log für Anwendungen ins Modell aufzunehmen. Da Logging und History-Funktionen elementare Managementfunktionen in vielen Bereichen darstellen, wäre es besser, hierfür generische Klassen zu entwerfen, die diese Funktionalität einer Managementanwendung generell zur Verfügung stellen. Ein Anwendungslog könnte dann eine Spezialisierung einer generischen Klasse Log sein.
In Abbildung 4.10 sind die generischen Klassen des Objektmodells den Tabellen der MIB gegenübergestellt. Die Information der Tabellen der sysApplInstalledGroup wird von den Klassen Package, compObjectTemplate und InstallElement abgedeckt. Analog wird die Information der sysApplRunGroup bis auf die History-Daten von den Klassen compObject, capsuleTemplate, capsule und UNIXProcess bereitgestellt. Insgesamt übertrifft der Informationsgehalt der Basisklassen den der MIB, wobei zusätzlich noch Operationen für ein aktives Management vorgesehen sind.
Die Managementinformation zu den laufenden Anwendungen kann im wesentlichen durch Polling der Prozeßliste gesammelt werden. Um eine feine Granularität der Information zu gewährleisten, müßte ein Agent dieses Polling in kurzen Abständen durchführen, was aber dazu führen kann, daß der Agent einen großen Teil der Rechenressourcen des Systems für sich verschlingt. Überhaupt ist es schwierig, allein aus der Analyse der laufenden Prozesse den Start und das Ende von Anwendungen zu identifizieren. Noch schwieriger gestaltet sich das Management im verteilten Fall, bei dem sich eine Anwendung aus Prozessen auf verschiedenen Systemen zusammensetzt und auf funktionierende Kommunikationsverbindungen angewiesen ist. Hier kann effizientes Management nur durch Instrumentierung der Anwendungen mit expliziten Managementschnittstellen erreicht werden, wie sie die folgende MIB fordert.