API-Schnittstelle

Wie in Kapitel schon erklärt, kann über die API-Schnittstelle mit Hilfe von Anwendungsprogrammen die Funktionalität eines Servers beeinflußt werden. Vordefinierte Funktionen können genutzt werden, um verschiedene Eigenschaften eines Web-Servers an eigene Bedürfnisse anzupassen. Diese Funktionen können auch dazu verwendet werden, um den Server zu konfigurieren oder zu steuern, also um Managementaufgaben darauf auszuführen. Es ist allerdings schwer, hier allgemeingültige Aussagen darüber zu treffen, da sich die Hilfsfunktionen je nach Hersteller und auch je nach Programmiersprache in ihrer Funktionalität stark unterscheiden.

Im Rahmen dieser Diplomarbeit wird anhand des Netscape Enterprise Servers dessen API untersucht, für deren Nutzung sowohl C- als auch Java-Funktionen zur Verfügung stehen. Diese Funktionen können z.B. zur Steuerung und Überwachung von Threads, zum Senden von Daten an den Server über Sockets oder zum Abfragen von Daten über eintreffende Requests verwendet werden, um diese nach eigenen Bedürfnissen weiterverarbeiten zu können. Das Untersuchen jeder Hilfsfunktion würde allerdings den Rahmen der Diplomarbeit sprengen, so daß nur beispielhaft anhand einiger Funktionen die Abbildung der Funktionalität auf Attribute und Funktionen der Klassen im Objektmodell gezeigt werden soll.

So gibt es z.B. Hilfsfunktionen, die die Daten, Header- und Statusinformationen, die an Clients zurückgeschickt werden, abfragen, bearbeiten oder beeinflussen können. Die Funktion protocol_set_finfo fragt z.B. die Länge des Inhalts, den Inhalt und das Datum einer Datei ab, wann sie zuletzt geändert wurde. Die gewonnen Daten können nach eigenem Bedarf weiterverarbeitet werden. Um solche Daten zu Managementzwecken zur Verfügung zu haben, wird im Objektmodell die Klasse Response eingeführt, von der die Klasse HTTP-Response vererbt wird. Generiert ein Web-Server einen Response, so wird eine Instanz der Klasse HTTP-Response erzeugt, die Attribute werden mit den entsprechenden Werten belegt. Sobald der Response abgeschickt ist, wird auch die Instanz beendet. So ist immer eine aktuelle Sicht der gerade generierten Antworten gegeben, wobei vor allem der HTTP-Status-Code, der in dem Attribut HTTP-StatusCode gespeichert ist, von großer Bedeutung ist. Damit hat man aktuell immer eine Sicht auf richtig oder fehlerhaft bearbeitete Anfragen und kann gleich kontrollieren, ob die vorhandenen Fehler aufgrund von Server-internen Problemen oder aufgrund von fehlerhaft gestellten Anfragen entstanden sind.

Das Attribut Reason_Phrase enthält die zum Status Code gehörende Erklärung in Worte (siehe dazu Anhang ). In dem Attribut General_Header sind die Header-Felder als ''Variable - Wert''-Paare abgespeichert, die Angaben zu der übertragenen Nachricht enthalten, aber nicht zu dem Inhalt der Nachricht. Diese Header-Variablen können sein: Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade oder Via (siehe dazu HTTP 1.1 in [MBLF⁺97]). In dem Attribut Response_Header sind die Header-Paare abgespeichert, die Informationen über den Server und über die Zugriffsberechtigung auf die gewünschte Ressource enthalten: Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary und WWW-Authenticate. Das Attribut Entity_Header enthält die Paare von Header-Feldern, die Angaben über den Inhalt der Antwort geben, also der zurückgeschickten Datei. 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. Der Inhalt der zurückgeschickten Datei könnte in einem Attribut Entity_Body abgespeichert werden, wobei das nicht unbedingt notwendig ist, zumal bei großen Dateien viel Speicher dafür benötigt werden würde. Analog zu der Klasse HTTP_Request wird auch in der Klasse HTTP_Response das Attribut Incoming des Typs Boolean definiert, um zwischen eingehenden und ausgehenden Responses zu unterscheiden.

Zwei weitere Funktionen protocol_uri2url_dynamic und protocol_uri2url bilden physikalische URIs auf virtuelle URIs ab oder setzen aus zwei gegebenen URI-Strings einen URL zusammen. Damit können Anfragen, die an eine bestimmte Adresse gerichtet sind, auf eine neue Adresse umgeleitet oder virtuelle URLs auf konkrete physikalische Verzeichnisse abgebildet werden. Beide Funktionalitäten werden mit den in der Klasse WWW-Server vorhandenen Attributen Alias und Redirect abgedeckt.

Ebenso kann die Funktionalität anderer Funktionen, die die Portnummer oder den Hostnamen des Servers abfragen, auf schon vorhandene Attribute der Klasse WWW-Server abgebildet werden. Informationen über die eingehenden Request-Daten können auf Attribute der Klasse HTTP-Request abgebildet werden. Eine letzte Funktion, die hier aufgegriffen wird, ist system_rename. Mit ihr können Dateien umbenannt werden. Diese Funktionalität kann für die Administration der Log-Dateien sehr nützlich sein. Falls man eine aktuelle Log-Datei umbenennen möchte, um auf den alten Namen eine neue zu öffnen, die mit neuen Log-Daten gefüllt wird, ist diese Funktion anzuwenden. Dazu wird die Funktion rename(oldFile,newFile) in die Klasse WWW-Server aufgenommen.