Comme vous n’êtes pas certains qu’une session navigateur utilisera de manière homogène le même job serveur, vous devez concevoir un mécanisme pour stocker l’information d’état pour chaque session navigateur active.
Il faut donc que l’information de commande soit stockée sur le serveur dans un format accessible à de multiples jobs, et chaque navigateur doit recevoir un ID unique qui est associé à la commande. Vous pourriez faire cela à l’aide de fichiers de travail, mais il est plus simple et plus rapide d’utiliser un objet User Space. Le postulat de base est le suivant.
Un espace utilisateur contient une matrice de structure de données des commandes (c’est-à-dire, chaque élément de la matrice de structure de données est une commande). Quand un navigateur démarre une nouvelle commande (de la première page où un numéro de client ou un numéro de commande est entré), un numéro ID unique (le prochain élément disponible dans la matrice) et un tampon horodateur sont attribués pour identifier de manière unique la session navigateur.
Le numéro ID et le tampon horodateur doivent être renvoyés par chaque page suivante de la commande. Ce sont les champs cachés Id (tampon horodateur) et IdNum (index de matrice) de la figure 3. Le numéro ID sert à mapper une structure de données (basée sur un pointeur) à l’élément pertinent de la matrice de structure de données dans l’espace utilisateur.
Quand la commande est bouclée, le numéro ID est libéré afin qu’une autre requête puisse l’utiliser. Le tampon horodateur est nécessaire pour le cas où l’utilisateur commencerait à utiliser incorrectement le bouton retour arrière (par exemple, l’utilisateur termine trois commandes, puis utilise ce bouton pour revenir à la page adresse de la première commande et changer les détails).
Cela est fait pour tenir compte des utilisateurs qui simplement ferment le navigateur ou naviguent vers une autre page. Il faut aussi une routine chargée de libérer des numéros ID d’après le temps écoulé. Voyons comment la persistance est appliquée dans l’application de saisie de commandes (Order Entry).
La figure 4 montre la définition des trois structures de données dans PERSIST_H. Persist_Header_t et Persist_Item_t sont les mêmes que les structures de données Order_Header_t et Order_ Item_t originales (définies dans ORDER_H), excepté que tous les champs sont de type caractère (rappelons qu’un navigateur n’utilise que des champs caractère).
Persist_Order_t définit l’information statique qui doit être stockée pour une commande. Outre l’information évidente (en-tête et articles), la structure de données contient aussi des champs de travail (Count et errFree) uniques pour chaque commande. Le module PERSORDER contient trois sous-procédures exportées (PERSIST_ NewOrder, PERSIST_GetThis Order, et PERSIST_ReleaseThisOrder) et une sous-procédure interne (TimeOut). La figure 5 montre les définitions globales dans le module PERSORDER.
Les points principaux à noter sont les suivants :
-
La matrice Handles identifie le prochain élément disponible. L’index de l’élément blanc suivant indique que l’élément est disponible. Une valeur est placée dans un élément pour indiquer qu’il est en service.
-
La matrice de structures de données Orders contient l’information d’état pour les commandes en cours de traitement. PERSIST_NewOrder et PERSIST_GetThisOrder renvoient un pointeur vers l’élément approprié de cette matrice de structures de données.
-
En cas d’erreur, PERSIST_NewOrder et PERSIST_GetThis Order renvoient un pointeur vers la structure de données Dummy_Order (afin que le programme appelant n’échoue pas s’il essaie de référencer une structure de données basée sur le pointeur renvoyé).
Handles et Orders sont basés sur des pointeurs et sont mappés à l’espace utilisateur ORDERS. La figure 6 montre la définition de la sous-procédure PERSIST_New Order. Les points principaux à noter sont les suivants. En A, la sous-procédure renvoie l’ID (tampon horodateur), le numéro ID (index vers l’élément utilisé dans la matrice de structures de données Orders), et un pointeur vers l’élément réel de la matrice de structures de données Orders.
Si l’espace utilisateur n’a pas encore été chargé, la sous-procédure GetStorageSpace() (définie dans le module PERSSPACE) charge l’espace utilisateur (ORDERS) et renvoie un pointeur vers l’espace utilisateur (en B). Ce pointeur renvoyé est le pointeur repère (basing pointer) pour la matrice Handles. La matrice Orders (elle aussi basée sur un pointeur) suit immédiatement la matrice Handles dans l’espace utilisateur. GetStorage Space() crée l’espace utilisateur s’il n’existe pas déjà.
En C, la sous-procédure Time Out() est appelée pour vérifier si certaines commandes devraient être libérées parce qu’elles ont dépassé le délai (timeout). En D, le prochain élément disponible est déterminé à partir de la matrice Handles.
En E, un tampon horodateur est attribué pour la commande requise, et en F, un pointeur vers l’élément correspondant de la matrice de structures de données Orders est attribué. Cela devrait vous donner une bonne idée du processus. Vous pouvez examiner à loisir les autres sousprocédures de persistance.
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
Tech - Par
Paul Tuohy - Publié le 08 octobre 2010
