DIDACTITIEL ISAPI AVEC LES COMPOSANTS INTERNET DE DELPHI 5/6/7 enterprise

Définition

Les applications ISAPI sont des DLL qui sont stockées sur un serveur Web HTTP et peuvent être exécutées par des requêtes client. Le client peut adresser une requête au serveur Web et l'application serveur répond à cette requête en donnant un résultat en format MIME.

L'adressage

Un exemple : vous voulez afficher l'image JPEG ornella1.jpeg à travers une application ISAPI « myisapi.dll » située sur le serveur Web « www.monsite.com » sous le répertoire « /scripts ». L'adresse que vous aurez à envoyer aura cette formulation :

http://www.monsite.com/scripts/myisapi.dll/Getimage?ImgName=ornella1.jpg&ImgId=231
---------------------- ------  ----------- --------- ----------------------------
        1                 2          3         4                   5

Les différentes sections de cette adresse sont :

1. L'adresse Web de votre site ;
2. Le répertoire virtuel où se trouve votre ISAPI (en général \\MON_SERVEUR\inetpub\scripts) ;
3. Le nom de votre DLL ;
4. L'action définie dans votre DLL qui traitera la requête ;
5. Paramètres de l'application séparés de l'adresse principale par le signe ? (les paramètres sont séparés entre eux par des &).

CGI vs ISAPI, cache et variables

(merci à JJM pour le débat chaud, « fructueux » et clarifiant sur ce sujet :-)

Différence CGI / ISAPI

Un CGI est une application console standard. Chaque requête est traitée par une nouvelle instance de l'application. Une application ISAPI est par contre une DLL qui est chargée lors du premier appel et reste en mémoire tant que le serveur n'est pas arrêté.

Pour la programmation des CGI, voir l'excellent tutoriel du non moins excellent Paul Toth ;-)

Avantages et inconvénients: ISAPI est forcément plus rapide et quasi obligatoire lors d'un grand volume de requêtes. La programmation d'une ISAPI doit par contre être bien plus pointue, car vu que la DLL reste en mémoire, une action mal programmée peut complètement bloquer le serveur Web (bien qu'il existe sous IIS la possibilité de le charger dans un espace mémoire isolé).

Variables dans une ISAPI

Un autre problème réside dans les variables globales externes à l'objet TWebmodule. Celles-ci peuvent entraîner des conflits entre les différentes requêtes de l'ISAPI. Elles sont de ce fait fortement déconseillées (ou alors, les protéger par threading).

Pour les autres variables, internes à l'objet TWebmodule (private ou public), un problème peut également se poser si le cache est utilisé. Les variables de ce style sont « safe-thread » et ne sont pas affectées par d'autres requêtes simultanées, mais peuvent par contre l'être par une requête précédente. Et pour expliquer cela, voici le principe de fonctionnement d'un TWebmodule en mode cache :

• un TWebmodule est créé tout d'abord lors d'une première requête (après déchargement p.ex.) ;
• à la fin de la requête, l'objet n'est pas détruit, il est mis en file d'attente dans un pool ;
• lors d'une prochaine requête, il y a vérification de la présence d'une instance libre dans ce pool et s'il y en a une, elle est utilisée, sinon, une autre instance est créée (max. 32 instances). Mais si une instance est libre, elle est récupérée telle quelle, à savoir en l'état final ou l'a laissée la requête précédente. Donc si cette requête a changé certaines valeurs d'une variable, ce sont ces valeurs qui seront également récupérées.

Pour éviter ce genre de conflits, plusieurs solutions peuvent s'offrir :

• ne pas utiliser de variables globales à l'intérieur de l'objet, mais utiliser plutôt des paramètres à passer d'une requête à l'autre ;
• désactiver le cache connexion (vous perdez en rapidité) ;
• bien veiller à initialiser, dans le beforedispatch de chaque action, les variables qui pourraient être affectées par une action antérieure ;
• bien veiller à coder principalement à l'intérieur d'une action. Je préconiserai l'ouverture et la fermeture des tables ou queries, la mise en place de filtres ou toute autre action susceptible de modifier certaines valeurs, dans l'action elle-même. Une table, p.ex. peut très bien être créée, définie et détruite dans l'action plutôt que placée dans le WebModule. Le safe-threading est à ce prix.

Concernant le nombre d'instances Webmodule limité à 32, cela ne signifie aucunement que seules 32 connexions simultanées sont permises. Il s'agit d'instances Webmodule créées. Prenons comme hypothèse un temps de réponse de 50 ms. IIS peut dans ce cas renvoyer 38 400 pages par minute. Si vous partez du principe qu'en moyenne vos utilisateurs affichent une page par minute (sauf cas extrêmes évidemment), ceci implique que vous pourriez assurer la connexion à 38 400 utilisateurs simultanés. On a donc une marge, disons… assez large :-)

Création d'une DLL ISAPI avec Delphi

Vous devrez avoir la version Client/serveur de Delphi pour avoir les composants Internet. Ils peuvent cependant être acquis séparément pour les autres versions. (P.-S. Ces exemples sont tirés d'un projet fait sous D5 enterprise. version anglaise). Vous devez également connaître les principes du langage HTML, car, dans certains cas, vous serez appelé à créer toute la page « à la mimine ».

Création d'un nouveau projet -> Fichier / Nouveau puis…

Vous choisissez ISAPI/NSAPI (NSAPI étant un serveur Netscape)et vous obtenez votre Webmodule qui sera le conteneur de tous vos objets :

Les événements d'un Webmodule :

• AfterDispatch : cet événement est appelé après qu'une requête a été envoyée à une des WebActions ;
• BeforeDispatch : la même chose, mais avant. Vous pouvez faire vos initialisations de variables ici ;
• OnCreate,OnDestroy : l'ouverture et la fermeture d'une base de données peuvent se faire ici (recommandé par Borland, mais peut se faire également dans le code même de l'action). Pour les tables et requêtes par contre, je recommanderai de le faire dans l'action elle-même. !!! Le OnDestroy est appelé uniquement lors du déchargement de la DLL.