Statusmanagement

Statusattribute sind nötig, um feststellen zu können, ob ein Dienst verfügbar ist und wie die aktuelle Nutzung des Dienstes ist. Darüber hinaus muß für die Administration Funktionalität vorhanden sein, die es erlaubt, den Status des Servers zu beeinflussen.

Die Definition der Statusattribute basiert auf der State Management Function der ISO [ISO93]. Dort wird der Status einer Ressource über die folgenden drei Attribute ausgedrückt. Die Auswahl der zulässigen Werte ist für die Anwendung auf einen Server angepaßt.

Betriebsbereitschaft (Operational State):

Dieses Attribut gibt an, ob ein Server einen Systemdienst bereitstellt. Hierzu muß der Server installiert und in Betrieb sein. Die Betriebsbereitschaft nimmt den Wert «enabled» ein, falls der Server in der Lage ist, Aufträge entgegenzunehmen, und «disabled», wenn dies nicht der Fall ist. Außerdem ist der Wert «unknown» möglich, wenn die Betriebsbereitschaft zu einem bestimmten Zeitpunkt nicht bestimmt werden kann. Auf dieses Attribut ist nur lesender Zugriff von Seiten des Managers möglich.

Nutzung (Usage State):

Dieses Attribut gibt an, ob ein Dienst zum gegenwärtigen Zeitpunkt genutzt wird, das heißt, ob ein Server gerade einen oder mehrere Aufträge bearbeitet. Ein Server ist «idle», wenn er nicht benutzt wird, «active», wenn er einen oder mehrere Aufträge bearbeitet, aber noch freie Kapazitäten zur gleichzeitigen Bearbeitung weiterer Aufträge besitzt, und «busy», falls er völlig ausgelastet ist. Außerdem ist wieder der Wert «unknown» für die Nutzung möglich. Auch dieses Attribut kann natürlich nur gelesen werden.

Administration (Administrative State):

Der Administrationszustand gibt an, ob ein Server seinen Dienst erbringen darf («unlocked») oder nicht («locked»). Solange ein Server Aufträge bearbeitet, aber keine neuen mehr akzeptieren darf, befindet er sich im Zustand «shutting down». Der ISO-Standard sieht vor, eine Steuerung einer Ressource durch schreibenden Zugriff auf dieses Attribut zu ermöglichen. Bei objektorientierter Modellierung sollte diese ,,Push-Button-Semantik`` aber vermieden werden. Zum Sperren bzw. Entsperren einer Ressource werden daher Methoden lock() und unlock() eingeführt. Da allerdings nur wenige der verbreiteten Server tatsächlich gesperrt werden können, wird für den Fall, daß diese Funktionalität auf einen Server nicht anwendbar ist, der zusätzliche Wert «not applicable» vorgesehen. Wiederum ist auch der Wert «unknown» möglich.

Server, die über ihren Status noch detaillierter Auskunft geben können, sollten durch eine Unterklasse von Server mit zusätzlichen Attributen modelliert werden. Der ISO-Standard definiert die beschriebenen Attribute allgemein für das Statusmanagement aller Arten von Ressourcen. Ist ein Attribut nicht sinnvoll anwendbar auf ein Objekt, wäre es denkbar, dieses wegzulassen oder seinen Wertebereich einzuschränken. Die Statusattribute und die Methoden lock() und unlock() werden deshalb der Oberklasse compObject von Server zugeordnet, da sie prinzipiell für alle laufenden Anwendungen Gültigkeit besitzen. Strikte Vererbung läßt allerdings kein Weglassen eines Attributs in einer vererbten Klasse zu. Hingegen verstößt das Beschränken des Wertebereichs eines Attributs in einer Unterklasse nicht gegen Regeln der Objektorientierung. Aber auch die Beschränkung führt zu Problemen, falls der Manager auf eine spezielle Ressource über eine Instanz einer allgemeineren Oberklasse zugreift. Diese Problematik wird in [ISO91] genauer diskutiert. Auch einige objektorientierte Sprachen, wie z.B. IDL, lassen eine Einschränkung nicht zu, wenn das Attribut vom Typ «Aufzählung» ist. Soll der Wertebereich in der Unterklasse erweitert werden, muß das Attribut in diesem Fall als «String» modelliert werden.

Bei einer Zustandsänderung des Attributs OperationalState sollte vom Server eine asynchrone Meldung mit Nennung des neuen Betriebszustands erzeugt werden. Die im UNIX-Umfeld verbreiteten Server schreiben zum Teil beim Starten und beim ordnungsgemäßen Stoppen einen Eintrag in ein Log. Damit ein Agent eine asynchrone Meldung für die Managementanwendung erzeugen kann, muß er das Log regelmäßig abfragen (polling). Wünschenswert wäre daher eine Instrumentierung des Servers zur Erzeugung ,,echter`` asynchroner Meldungen. Hierbei ergibt sich aber das Problem der Abhängigkeit von einer bestimmten Managementarchitektur: CORBA events, SNMP traps oder OSI notifications. Da ein Server, der abrupt terminiert, kaum in der Lage sein wird, eine Meldung über Änderung seines Betriebszustands abzusetzen, ist es für die Implementierung der Klasse erforderlich, daß der Agent die Betriebsbereitschaft überwacht und die Meldung für den Manager erzeugt.