Mise à jour du 06/06/2024.
Le contexte d'une application se définit comme l'ensemble des ressoures, données et services d'une même application web. On peut simplifier en énonçant que le contexte est l'application elle-même. Dans ce modèle de conception, le serveur web est simplement une ressource qui permet à l'application d'interagir avec le monde extérieur (utilisateur ou système) via un réseau TCP/IP. Ainsi, un même serveur est une ressource qui peut être partagée par plusieurs applications. Les interactions entre le serveurs et les applications passent nécessairement par des sessions qui permettent aux applicationx de dialoguer avec un correspondant donné (). Dans la suite de cet article, nous assimilons les contextes aux applications elles-même et traiteront de "l'application".
Comme vu précéemment, une application doit pouvoir gérer :
Pour pouvoir fonctionner, la plupart des applications s'appuient sur des ressources. Une "ressource" peut se définir comme un objet délivrant des données ou rendant un service à l'ensemble du code de l'application. La plupart des ressources ont un lien "externe" avec un autre composant logiciel. C'est le cas d'un gestionnaire de connexions à un SGBD par exemple.
Stocker les ressources est relativement aisé compte tenu de la création du dictionnaire des données (cf. DataMap). La vraie question est : qui et quand doivent être créées ces ressources ? Si on le fait au moment du chargement du serveur, l'échec de chargment d'une application se traduirait par l'échec de toutes les applications. Ce n'est donc pas le bon niveau. En revanche, si c'est lors de la construction du contexte que sont créées les ressources, un échec éventuel de cette création ne concernera que cette application. Le serveur, lui, se limitera à conserver un dictionnaire des contextes ce qui facilitera la réalisation d'applications d'administration ou de supervision.
Maintenant que l'on a décidé qui créera les ressource et quand, il faut étudier le moyen de rendre le plus générique possible cette création. Les ressources sont toujours créées via un paramétrage externe pour les adpater à leur contexte d'emploi. Par exemple un gestionnaire de connexion à un SGBD doit connaitre les paramètres du compte, ceux d'accès au serveur de données, le schéma de la base de données, etc. Le moyen le plus adaptés est de stocker ces paramètres dans un fichier de configuration.
Cela pose la question de l'organisation de la configuration du serveur dans son ensemble. En général, le serveur dispose de son propre fichier de configuration. Toutefois, nous ne faisons pas le choix d'y integrer la configuration de toutes les applications. En effet, une application doit pouvoir être arrétée, reconfigurée et être relancée sans qu'il soit nécessaire d'interrompre les autres applications. A la place, la configuration du serveur référencera pour chaque application son fichier de configuration. Un article est dédié à la configuration.
La construction du contexte d'une application par le serveur comprend plusieurs étapes :
Charger une application revient, vu du serveur, à céer son contexte et le maintenir en mémoire. A sa construction, comme abordé dans un autre article, un contexte reçoit le nom d'un fichier de configuration qui contient les paramètres nécessaire à la création des ressources dont il est responsable.
Il reste cependant un point à résoudre : comment transmettre au contexte le dictionnaire des fabriques de classe qui le concerne ? Contrairement à Java, C++ ne dispose pas d'un mécanisme dit de "réflexion" qui permet à partir d'une chaîne de caractères d'instancier un objet.
La solution retenue ici est de créer une méthode abstraite dans une classe abstraite dont tout objet de contexte applicatif devra héritée. C'est cette méthode qui instanciera les fabriques de classe de création des ressources utilisées par l'application. Ainsi, on créé la classe abstraite IContext dont la classe concrète dérivée invoquera dès sa construction la méthode abstraite loadResourcesFactories(). Une fois ces fabriques de classe chargées, les ressources à proprement parler seront ensuite créées en intégrant les propriétés transmsies au constructeur du contexte (configuratin) et éventuellement un dictionnaire des données ne pouvant pas être transmises par voie de configuration.
Rédaction par Jean-Marie Piatte (1983-2021)