Le déploiement d’un site WebDev – Définitions (1/3)

A force de pratiquer le déploiement des sites WebDev, et de se heurter aux diverses épines du rosier, voici un ensemble de posts techniques qui aideront (je l’espère!) d’autres aventuriers à déployer leurs sites ou webservice.

Ce premier post servira d’introduction: il tentera de définir divers mécanismes d’inteprétation des sites WebDev. Il devrait être suivi par deux autres textes plus orienté sur les configuration des serveurs Apache et IIS.

LE client-serveur qu'on aime...

Le client-serveur à la lyonnaise… (Gestan)

Le serveur d’application WebDev est presque un module CGI

Un serveur Web est au minimum un passe-plat de fichiers, au mieux une grosse moulinette qui produit des fichiers (html mais pas uniquement) via du code écrit avec potentiellement n’importe quel langage (script PHP ou WebDev).

Le serveur web est configuré pour démarrer ces sous-programmes via des règles de comparaison sur les urls accédés, et saura déterminer le code à invoquer pour produire ce fichier html.

A chaque fois qu’un fichier correspondant au masque sera demandé par le navigateur, notre serveur exécutera une commande du type ‘interpreteur.exe monscript.awp’, qui générera du html sur la sortie standard (c’est ce flux qui sera ‘attrapé’ et renvoyé au navigateur). Noter que le script interprété aura accès à certaines variables positionnées par le serveur Web appelant (comme l’URL initiale qui a servi a invoquer l’interpréteur, le type de requête HTTP, etc).

Bref, résumé en quelques lignes c’est la définition d’un module CGI (cf Wikipedia). Le moteur d’application de webdev est un module CGI, et presque de la même façon que PHP.

Le presqu’interpréteur WebDev est un exécutable localisé dans REPERTOIRE-DU-SERVEUR-D’APPLICATION-WEB/AWP/wd1X0awp.exe . On notera que toutes les versions historiques des interpréteurs sont installées dans ce répertoire, (de même que le module de paybox)..

Similaire à PHP, mais pas entièrement…

Les exécutables CGI sont invoqués par le serveur web de la même manière qu’un utilisateur tapant la ligne de commande sur l’invite de commande: (chargement de l’exe en mémoire->allocation contexte d’exécution->[exécution de l’interpréteur et récupération du flux généré]->libération du contexte->libération de la mémoire). Le problème est que ce processus est très lourd pour un serveur web censé pouvoir générer des pages à des centaines d’utilisateurs en simultané.

Les développements ultérieurs de CGI ont consisté à minimiser cette charge en gardant l’interpréteur en mémoire plutôt que que de laisser à l’OS le soin d’allouer/libérer des contextes d’exécution. C’est le module fastcgi de PHP qui est positionné en mémoire une fois pour toute, qui économise 2 des 5 étapes.

WebDev a choisi une autre approche : lorsque le wd1X0awp.exe est invoqué pour générer une page, le module se met en relation avec le service d’application WebDev (un service s’appelant wd1X0admin.exe sous windows, un demon sous linux) qui gère plusieurs aspects de l’exécution de l’interpréteur: récupération des paramètres du projet webdev, création de session persistantes pour les pages/scripts AWL, et invocation de l’interpréteur du script WLangage.

De fait, c’est ce serveur d’application, résident en mémoire, qui invoquera au final l’interpreteur WLangage (plutot que wd1x0awp.exe).

Les contextes d’exécution persistant / non persistant d’une application Web(Dev)

Il y a deux grandes façons d’aborder le développement Web: une approche client-serveur ‘sans-état’ où chaque page visitée est indépendante de tout contexte de navigation (hormis quelques variables stockable dans les cookies ou des paramètres d’url). Ou une voie proche des clients lourds, où chaque fenêtre s’appuie sur un set important d’informations persistantes valide durant toute la session de travail de l’utilisateur.

Pour éviter la gymnastique intellectuelle d’une navigation ‘sans contexte’, WebDev propose les deux modes au développeur.

Lorsqu’un utilisateur accède à une portion de site ‘en persistant’, un processus wd1X0session.exe dédié est démarré et vivra tant que l’utilisateur naviguera sur le site. La session est identifiée par un token spécifique, et chaque action utilisateur sera accompagnée de ce token, et sera routé par wd1x0admin.exe sur la bonne session côté serveur.

Fin de la torture

Voilà, ce gros préambule digéré, nous pouvons passer à la suite des réjouissances: la configuration d’un site WebDev sous Apache et IIS.

Une autre (bonne) définition du mot ‘Torture’

 

 

Les commentaires sont fermés.