Domaines des requêtes, sessions et applications

un lien ou sur un bouton dans une page Web, vous ordonnez au navigateur d’atteindre un document provenant d’un serveur HTTP et de l’afficher. Le navigateur peut atteindre un fichier HTML à partir du serveur et l’afficher, ou bien exécuter un programme qui produit une sortie et affiche du HTML.

Dans les deux cas, un clic – ou « requête » – entraîne l’extraction et l’affichage d’un document. Le seul instant où le programme tourne sur le serveur Web se situe entre le moment où vous cliquez sur le bouton/lien et le moment où la page est affichée dans le navigateur. A l’instant où vous lisez la page Web, le programme sur le serveur est déjà fini. Une fois la page affichée, vous pourriez cliquer sur d’autres de ses options – mais vous ne le pourriez pas ! Vous pourriez fermer la fenêtre ou appuyer sur le bouton Retour (Back) du navigateur, ou bien changer l’URL pour le faire pointer vers un tout autre serveur.

C’est pour cela que les applications Web sont dites « stateless » (sans état) parce que chaque action menée par le navigateur est considérée comme une requête séparée, sans relation avec les autres. Donc, chaque requête conduit le navigateur à appeler votre programme une fois – avec ou sans paramètres – et à recevoir en réponse une page à afficher sur l’écran. Les variables que vous utilisez dans votre programme pour traiter cette requête sont dites « cantonnées au niveau de la requête ».

Autrement dit, les variables sont créées quand la requête commence et supprimées quand elle se termine. Elles n’existent donc que pendant la requête. Chaque technologie Web permet de traiter facilement les données au niveau des requêtes, parce que c’est l’une des parties les plus élémentaires d’une application Web. D’ailleurs je n’ai trouvé aucune différence notable entre les technologies Web en matière de requêtes.

Il arrive souvent que les données doivent être conservées après la requête : un concept qui va à l’encontre la nature stateless du Web. Par exemple, si vous consultez un site d’achat en ligne comme Amazone, vous examinez les articles et cliquez sur le bouton Ajouter au panier pour stocker les données dans votre panier ou chariot. Quand vient le moment de payer, le système rappelle tout ce que vous avez placé dans le panier et commence à poser des questions sur le mode de livraison et le type de paiement.

De la même manière, mon application de saisie de commandes demande le client dont vous souhaitez saisir les commandes sur le premier écran ; sur le deuxième écran, elle demande des renseignements sur le lieu de livraison et, sur le troisième, des renseignements sur quels articles vous souhaitez commander. Le système a besoin de mémoriser toute cette information, parce que, quand la commande sera finalement enregistrée sur disque, il devra se rappeler des renseignements concernant le client et la livraison, à partir des écrans précédents.

Le temps qui s’écoule entre le moment où vous rendez visite à un site Web et celui où vous le quittez constitue une « session ». En principe, le logiciel génère un numéro de session unique chaque fois que vous visitez un site Web, et il utilise ce numéro pour consulter vos données sauvegardées dans un fichier base de données, un fichier stream, ou un espace utilisateur. Quand vous avez fini, le logiciel doit supprimer cette session.

Si vous décidez de fermer la fenêtre ou de passer à un autre site Web, le système doit se souvenir du fait que vous n’êtes jamais revenu (dans un délai raisonnable) et supprimer votre session pour raison d’inactivité. L’une des principales différences entre les technologies Web est la manière dont elles effectuent le stockage des données au niveau de chaque session.

Donc, quand vous comparerez les différentes technologies Web de ce numéro de System iNEWS, faites bien attention à la manière dont elles traitent les données au niveau session. Bien entendu, quand vous aurez terminé votre commande (soit dans mon application de saisie de commandes, soit sur un site du genre Amazone), les données ne seront plus sauvegardées dans votre session parce qu’elles deviendront une commande permanente dans le système, prêtes à être traitées.

Les données sauvegardées de cette manière sont dites en « domaine d’application » (application scope), parce qu’elles sont désormais permanentes dans l’application et ne sont plus les données transitoires faisant partie de la requête ou de la session.

Compte tenu de notre intention dans cette série d’articles, les données au niveau application sont gérées par mon programme de service RPG, et donc ne font pas partie de ce que vous comparerez en examinant les technologies Web.