[ zurück ]

Das ISAPI-Grundkonzept nebst Kommunikationsschema


ISAPI-Programme sind Anwendungen, die auf der Serverseite im Intranet oder Internet laufen. Konkret handelt es sich um DLLs, die der Webserver zusätzlich lädt und damit in seiner Funktionalität wächst. Das hier beschriebene ISAPI-Konzept wird nur auf HTTP-Servern unterstützt, die unter MS-Windows laufen. Deren Zahl und Marktanteil wächst gegenwärtig beständig. Außer dem Microsoft-Internet-Informations-Server (ISS) und dem Microsoft-Personal-Webserver (PWS) unterstützen auch eine Reihe weiterer kommerzieller Server (z.B. O'Reillys-Webserver) und Freeware-Server (z.B. Sambar-Server) ISAPI-DLLs.

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.

Kommunikationsschema ISAPI

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.

Screen

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-Möglichkeiten zur ISAPI-Programmierung.

Delphi ab Version 2 Standard bringt alle Bedingungen mit, um ISAPI-DLLs programmieren zu können. Die einzige spezielle Voraussetzung ist die kleine Bibliothek namens Isapi.PAS, die von Borland/Inprise mitgeliefert wird oder vom Inprise-Webserver geladen werden kann. Sie enthält die Definition der Datenstrukturen und der Eintritts-Prozeduren. Schauen Sie bitte im Verlauf dieses Projektes gelegentlich in diese Definitionen.

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.

Debuggen von ISAPI-DLLs

Noch bevor Sie in die Programmierung einsteigen, ein Wort zur Fehlersuche:

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.

  1. Beenden Sie die Arbeit Ihres Webserver (ISS oder MS-PWS oder sonstiger).
  2. Setzen Sie in Delphi Haltepunkte an den interessanten Stellen Ihres ISAPI-Projektes und rekompilieren Sie das Programm.
  3. Rufen Sie "Start"-"Parameter" aus dem Delphi-Menü auf und tragen Sie Serverpfad und Startparameter für Ihren Webserver ein!
    • beim ISS:
      Host-Anwendung: C:\winnt\system32\inetsrv\inetinfo.exe
      Startparameter: -e w3svc
    • beim PWS:
      Host-Anwendung: C:\Programme\websvc\system\inetsw95.exe
      Startparameter: -w3svc
  4. Rufen Sie unter Delphi mit "Start"-"Start" die zu testende ISAPI-DLL nebst dem nun mitstartenden Webserver auf.
  5. Rufen Sie vom Browser aus Ihre DLL auf. Wenn diese bis zum ersten Haltepunkt gelaufen ist, können Sie in Delphi mit "Start"-"Auswerten/Ändern" wunderbar die Variablen Ihrer Extension betrachten.

Das funktioniert natürlich auch mit anderen als den Microsoft-Servern.


[ Seitenanfang ] [ ISAPI ]

J. Hummel,   2000