Im folgenden werden Managementobjektklassen für die Objekte «Client» und «Server» eines Systemdienstes modelliert. Diese Klassen sollen möglichst generisch sein, d.h. ein effizientes Management möglichst vieler verschiedener Systemdienste erlauben. Die definierten Klassen sollen also unabhängig von einem konkreten Dienst sein. Dies soll aber eine Spezialisierung oder Erweiterung der generischen Klasse für ein Werkzeug zum Management eines konkreten Dienstes nicht ausschließen.
Markus Gutschmidt zerlegt in seiner Dissertation ,,Ein Objektmodell für ein integriertes Management von Systemdiensten mit Client/Server-Struktur`` [Gut95] einen Server in die funktionalen Komponenten «Funktionseinheit», «Bedienstation» und «Bedieneinheit», «Warteschlange» und «Auftrag». Die Zerlegung und Begriffsbildung geht auf die Verkehrstheorie zurück. Zu diesen Komponenten definiert er entsprechende Managementobjektklassen mit den folgenden Beziehungen. Ein Server ist eine Funktionseinheit, die aus mindestens einer Bedienstation besteht. Eine Bedienstation kann aus mehreren Bedieneinheiten aufgebaut sein. Dies entspricht einem Server, der parallel Aufträge über mehrere Prozesse oder Threads bearbeiten kann. Weiterhin kann ein Server keine, genau eine oder mehrere Warteschlangen für Aufträge besitzen und keinen, genau einen oder mehrere Aufträge enthalten.
In dieser Arbeit wird versucht, einen Systemdienst und seine zugehörigen managed objects mit den Konzepten und Sichten des RM-ODP zu modellieren. Daher handelt es sich bei den Modulen «Client» und «Server» eines verteilten Dienstes um Software-Komponenten und damit zur Laufzeit um Computational Objects. Folglich werden die MOCs Client und Server von der Klasse compObject abgeleitet. Ein Server stellt seinen Dienst an einer oder mehreren Schnittstellen (Computational Interfaces) zur Verfügung. Systemseitig realisiert wird ein Dienst durch Prozeduren (Basic Engineering Objects) innerhalb eines oder mehrerer Prozesse (Capsules).
Markus Gutschmidt ordnet den Komponenten Bedienstation/Bedieneinheit, Warteschlange und Auftrag eigene Managementinformation und -funktionalität zu. Hier wird die Information und Funktionalität in der Klasse Server bzw. Client zusammengefaßt. Diese Vereinfachung wird dadurch gerechtfertigt, daß die meisten der derzeit etablierten und verbreiteten Systemdienste keine Managementschnittstellen für Einzelkomponenten ihrer Client- und Servermodule beinhalten. In den später untersuchten Diensten NFS und NIS ist beispielsweise ein Management der Warteschlangen oder einzelner Aufträge gar nicht möglich. Weiterhin soll es sich bei den Klassen Server und Client um generische Basisklassen handeln. Konkrete Server und Clients, die ein Management ihrer Komponenten erlauben, können durch Unterklassen von Server und Client mit Aggregationsbeziehungen zu neuen Managementobjektklassen für ihre Komponenten modelliert werden.
Das hier beschriebene Modell eines Servers wird in Abbildung 4.8 verdeutlicht. Die obere Hälfte zeigt den Computational Viewpoint. Das Computational Object «Server» besitzt eine Dienst- und eine Managementschnittstelle. Ein Client nutzt den Dienst durch Binden der Server-Schnittstelle. Eine Managementanwendung überwacht über das Computational Object «Manager» den Server. In der unteren Hälfte wird der Engineering Viewpoint gegenübergestellt. Client und Server sind jeweils durch einen Prozeß (Capsule) realisiert und kommunizieren über einen Kanal. Der Agent, der dem Manager Informationen über den Server bereitstellt, ist in diesem Fall ebenfalls ein eigener Prozeß, der auf dem gleichen System wie der Server läuft und somit über eine lokale Schnittstelle ( local binding) mit dem Server kommuniziert. Der Agent kann weitere Schnittstellen zu anderen Managed Objects besitzen. Unter der Annahme, daß die Managementanwendung auf einem anderen Rechner läuft, tauschen Agent und Manager Informationen wiederum über einen Kanal aus.
Bei der Modellierung der Klassen Server und Client stehen die Betriebsaspekte Steuerung und Überwachung eines Dienstes im Vordergrund. Die Managementinformation und Funktionalität wird, wie in Kapitel 2.1.4 erläutert, durch Analyse der Anforderungen aus den folgenden Funktionsbereichen definiert: