Nach der Funktion werden zwei Arten von ISAPI-DLLs unterschieden: ISAPI-Filter und ISAPI-Erweiterungen (ISAPI-Extensions). ISAPI-Filter erledigen Aufgaben wie Zugriffskontrolle, Verschlüsselung oder Transferkontrolle. Sie liefern seltener direkt sichtbare Inhalte an den Client zurück. ISAPI-Erweiterungen hingegen produzieren Ausgabedaten, die unmittelbar zur Anzeige auf dem Browser des Client bestimmt sind. Die nachfolgenden Ausführungen beziehen sich ausschließlich auf die Extensions.
Das ISAPI-Prinzip hat gegenüber anderer Verfahren, insbesondere gegenüber dem verwandten CGI (Common Gateway Interface, siehe CGI-Tutorial von Stefan Müller) etliche Vorteile. Einmal geladen, verbleibt die DLL im Speicherraum des Servers. Damit entsteht bei wiederholten Aufrufen ein Geschwindigkeitsvorteil gegenüber Varianten mit erneutem Laden. Als DLL wird das Programm auch nur einmal geladen, selbst wenn mehrere Clientanforderungen zeitgleich zu beantworten sind. Beim CGI-Verfahren hingegen startet für jede Anforderung eine neue Instanz des Programms. Damit wird bei ISAPI wertvoller Arbeitsspeicher auf der Servermaschine eingespart. Gegenüber den in der UNIX-Welt weit verbreiteten CGI-Scripts entstehen Vorteile dadurch, daß die DLLs echten Programmcode darstellen, der unmittelbar ablauffähig ist. Scripts hingegen müssen interpretiert werden. All das führt in der Praxis dazu, daß ISAPI-Lösungen ein überdurchschnittlich gutes Zeit- und Ressourcenverhalten zeigen.
Die Servererweiterung tritt in Aktion, wenn sie mit der Methode GET von der Adreßzeile des Browsers aus oder über POST von einem Formular aufgerufen wird. Die GET-Anforderung hat die Form:
http://hostname/scripts/isapidll.dll?Parmeter1+Parmeter2 |
Im Formular wird verwendet:
<FORM ACTION="/scripts/isapidll.dll" METHOD="POST"> |
Die Variablenparameter kommen in diesem zweiten Fall meist aus den Steuerelementen des Formulars.
Damit der Webserver normgerecht mit der Servererweiterung kommunizieren kann, sind zwei standardisierte Eintrittspunkte für die DLL definiert. Zur Parameterübergabe gibt es je eine einfach zu handhabende Datenstruktur.
Beim Laden der DLL ruft der HTTP-Server einmalig eine Prozedur namens GetExtensionVersion auf. Diese stellen Sie als Programmierer in der DLL bereit. GetExtensionVersion liefert an den Server zwei Kurzinformationen über Versionsnummer und Namen Ihrer DLL zurück.
Das Anfordern von Ausgabeaktionen erfolgt, wenn der Server die zweite Export-Prozedur der DLL namens HttpExtensionProc aufruft. Diese ist quasi das Hauptprogramm der ISAPI-Extension. Zugleich legt der Server die Eingabedaten der Client-Anforderung in einem Datenblock namens ECB (Extension-Control-Bloc) ab und übergibt den Zeiger darauf als Parameter an HttpExtensionProc. Jetzt hat Ihre Prozedur die Aufgabe, die dynamische Antwort zu generieren und über den Server an den Client-Browser zurückzuschreiben.
Treffen zwei oder mehr Anfragen gleichzeitig ein, läuft HttpExtensionProc in mehreren Fäden (Threads) parallel ab. Jeder Thread hat dabei seinen eigenen Datenblock ECB. Somit erhält jeder Client auch die von ihm geforderte Antwort.
In der Microsoft-Spezifikation sind noch weitere optionale Eintrittspunkte beschrieben. So beispielsweise zum Entladen der DLL aus dem Serverraum. Diese Aktivitäten sind aber normalerweise nicht notwendig.
Delphi 3, 4 und 5 stellen in der Client/Server-Version spezielle Applikationsobjekte zur Verfügung. Das Basisobjekt TWebApplication und dessen Nachfahr TIsapiApplication besitzen die notwendigen Eigenschaften und Methoden für die Generierung von ISAPI-DLLs. Damit wird die Programmierung gebührend erleichtert. Die Methoden der Objekte gleichen im Wesentlichen den oben beschriebenen Eintrittspunkten GetExtensionVersion und HttpExtensionProc. Zum Auswerten der Client-Anforderung stehen spezielle Objekte TWebRequest und TIsapiRequest bereit, die Routinearbeit abnehmen. Für die Erzeugung von HTML-Ausgaben gibt es unterstützende Objekte, beispielsweise TWebResponse und abgeleitet TIsapiResponse.
Diese Seiten demonstriert die komplette ISAPI-Programmierung ohne die Spezialobjekte der Client/Server-Version und wendet sich damit an die Besitzer aller Delphi-Produkte. Ein Umstieg oder Einstieg auf die Komponenten der Client/Server-Suite wird Ihnen dadurch sicher erleichtert.Hinweise: Mit Delphi 1 haben Sie keine Möglichkeit zur ISAPI-Programmierung, da nur 32-bit-DLLs geeignet sind. Alle hier beschriebenen Routinen wurden unter Delphi 3 getestet. Programmierer mit Delphi 2 müssen sicher geringe Korrekturen, beispielsweise bei einigen Stringoperationen vornehmen.
Zum Testen Ihrer Servererweiterungen sollten Sie möglichst uneingeschränkten Zugriff auf einen Webserver haben. Geeignet ist durchaus auch ein passender kleiner Freeware-Server wie der Sambar-Server, der als Localhost läuft.
Viele Webmaster und Server-Administratoren beklagen die ungewöhnlichsten Fehlermeldungen bei Testläufen von Serveranwendungen. Weil die Servererweiterungen keine eigenständigen Programme sind, erscheint im ersten Moment eine Untersuchung von Fehlern mit dem Debugger als schwierig. Dank der hervorragenden Leistung des Borland-Debuggers ist aber auch dieses Problem zu lösen.
|
Das funktioniert natürlich auch mit anderen als den Microsoft-Servern.
J. Hummel, 2000