next up previous contents
Next: Ressourcen-Auslastung Up: Szenarienbasierte Definition der Managementinformation Previous: Auswertung der Log-Daten

Einzelaufträge

Um Einzelaufträge, die der Server empfängt, steuern und beobachten zu können, ist die generische Klasse Request eingeführt worden. Um detailliertere Informationen über die Anfrage an einen Web-Server untersuchen zu können, wird im Objektmodell eine neue Klasse HTTP-Request eingeführt. Trift eine Anfrage beim Server ein, so wird diese Klasse instantiiert. Alle Attribute der Klasse Request werden mit der gleichen Bedeutung übernommen.

Die Attribute HTTP_Method und HTTP_Version der neuen Klasse HTTP_Request enthalten den Methoden-Namen (GET, POST usw.) und die Version des HTTP, mit denen die Anfrage gestellt wurde. Das Attribut Request_URI enthält den URI, in dem der Name und der Verzeichnispfad der gewünschten Datei angegeben sind. In dem Attribut General_Header sind die Header-Felder als Variable=Wert-Paare gespeichert, die sowohl für Requests als auch für Responses gelten. Sie enthalten Daten über die gerade zu übertragene Nachricht. Folgende Variablen können dabei einen Wert enthalten: Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade oder Via (siehe dazu auch den Internet Draft zu HTTP 1.1 in [MBLF+97]).

In dem Attribut Request_Header sind die Header-Paare abgespeichert, die Informationen über den Client und über die Anfrage an sich enthalten. Diese gelten nur für Requests. Folgende Variablen sind hier vorhanden: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, From, Host, If-Modified-Since, If-Match, If-None-Match, If-Range, Max-Forwards, Proxy-Authorization, Range, Referer und User-Agent.

Das Attribut Entity_Header enthält die Paare von Header-Feldern, die Angaben über den Inhalt der Antwort geben, also der zurückgeschickten Datei, die in dem Attribut Request_URI genannt wird. Folgende Variablen sind hier möglich: Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, ETag, Expires, Last-Modified und extension-header.

Falls eine Anfrage mittels der HTTP-Methode POST gestellt wurde, werden mit der Anfrage Daten übertragen, die der Server mit Hilfe von weiteren Programmen verarbeitet. Diese zurückgeschickten Daten könnten in einem Attribut Entity_Body abgespeichert werden. Möchte man das Risiko nicht eingehen, daß die übertragenen Daten einen zu großen Umfang erreichen und dadurch zuviel Speicher verbrauchen, so könnte mit Hilfe eines weiteren Attributs eine Obergrenze in Bytes angegeben werden, die das Attribut Entity_Body höchstens umfassen darf. Somit wäre eine detailliertere Bearbeitung der Aufträge an einen Server möglich.

Um sowohl an einen Web-Server eingehende Requests als auch vom Proxy-Server bearbeitete Requests (siehe dazu Abschnitt [*]) mit der gleichen Managementanwendung beobachten und steuern zu können, die ja in diesem Fall beim Proxy sowohl eintreffen als auch von diesem an Web-Server weitergeschickt werden, wurde das Attribut Incoming des Typs Boolean in der Klasse HTTP_Request definiert. Dadurch können eintreffende (Wert: true) und ausgehende (Wert: false) Requests unterschieden werden.

Eine weitere Fragestellung beim Management von Einzelaufträgen ergibt sich beim Nachprüfen, ob die Aufträge erfolgreich bearbeitet wurden, ob sie in einer bestimmten Zeitspanne bearbeitet wurden usw. Ein Ansatz zum Lösen dieser Aufgaben hat die Firma Tivoli in Form der Application Response Measurment (ARM)-Technik entwickelt. Mit Hilfe einer ARM-API wird verteilten Anwendungen ermöglicht, kritische Informationen zu den stattfindenden Transaktionen zu melden. Diese Informationen können Managementanwendungen dazu nutzen, Meldungen zu verschicken, die Fehlfunktionen sichtbar machen.

Um zu überprüfen, ob eine Transaktion in einer bestimmten Zeit durchgeführt wurde, muß eine gewünschte Zeitspanne festgelegt werden. Im Rahmen des ARM wird die Zeit vom Absenden der Anfrage bis zum Ankunftzeitpunkt der Antwort betrachtet. Diese Zeit umfaßt jegliche Übertragungsverzögerungen durch den Netzverkehr und Bearbeitungsprobleme durch Ressourcenmangel auf dem Ziel-System, auf dem die Antwort generiert wird. Dabei kann auch nachgeprüft werden, wo die meiste Zeit während der Transaktion verbraucht wurde oder verlorenging.

Um die Ressourcen-Auslastung des Systems zu überprüfen, wird im Rahmen des ARM auch die Anzahl der stattfindenden Transaktionen betrachtet und der Benutzer, die diese Transaktionen anwenden. Die Methoden der ARM-Technik können als Anregung für die Entwicklung des Objektmodells übernommen und auf entsprechende Klassen darin abgebildet werden. Im nächsten Abschnitt über die Ressourcen-Auslastung und in dem Abschnitt Schnittstellen zum Server später im Kapitel wird konkret darauf eingegangen.


next up previous contents
Next: Ressourcen-Auslastung Up: Szenarienbasierte Definition der Managementinformation Previous: Auswertung der Log-Daten
Copyright Munich Network Management Team