8.2 Pipeline ASP.NET et cycle de vie des applications
La section 8.1 présente l'architecture système d'IIS et le processus global de traitement des requêtes HTTP. À partir de là, nous pouvons savoir que chaque site Web ASP.NET correspond à une application Web, qui peut répondre aux requêtes HTTP et fournir aux utilisateurs les informations requises. Alors, comment exactement une application ASP.NET répond-elle aux requêtes HTTP ? Quelles procédures de traitement spécifiques sont incluses ? Cela implique le cycle de vie des applications ASP.NET.
8.2.1 Cycle de vie des applications ASP.NET*
Cette section prend IIS 6 comme exemple pour présenter étape par étape le processus de traitement des requêtes HTTP par les applications ASP.NET. Le processus d'IIS 7 présente quelques modifications mineures par rapport à IIS 6, mais est généralement cohérent.
1 Le navigateur émet une requête HTTP pour accéder à une page Web ASP.NET.
Supposons que cette requête est la première requête adressée à l’application ASP.NET à laquelle appartient cette page Web.
Lorsque cette requête atteint le serveur Web, HTTP.SYS se charge de la recevoir. Selon l'URL de cette requête, HTTP.SYS la transmet au pool d'applications correspondant à cette application ASP.NET, et au pool d'applications exécuté dans cette application. Les processus pool Worker sont responsables du traitement des demandes[1].
Une fois que le processus de travail a reçu cette requête, il charge une extension ISAPI "aspnet_isapi.dll" dédiée au traitement des pages ASP.NET et lui transmet la requête HTTP.
Une fois que le processus de travail a chargé aspnet_isapi.dll, aspnet_isapi.dll est responsable du chargement de l'environnement d'exécution de l'application ASP.NET - CLR [2].
Le processus de travail fonctionne dans un environnement non géré (en référence au système d'exploitation Windows lui-même), tandis que les objets dans .NET fonctionnent dans un environnement géré (en référence au CLR aspnet_isapi.dll agit comme un pont pour communiquer entre les deux). les demandes reçues (provenant d'un environnement non géré) sont transmises à l'objet .NET correspondant (dans un environnement géré) pour traitement.
2 Créez l'objet ApplicationManager et le domaine d'application
Une fois le CLR chargé, la classe ApplicationManager est responsable de la création d'un domaine d'application. Chaque application ASP.NET s'exécute dans son propre domaine d'application et est identifiée par un identifiant d'application unique.
Chaque domaine d'application correspond à une instance de la classe ApplicationManager, qui est responsable de la gestion des applications ASP.NET exécutées dans le domaine (comme le démarrage et l'arrêt d'une application ASP.NET, dans une application ASP.NET spécifiée, créer des objets, etc.) .
3 Créer un objet HostingEnvironment
Lors de la création d'un domaine d'application pour une application ASP.NET, un objet HostingEnvironment est créé, qui fournit certaines informations de gestion pour l'application ASP.NET (telles que l'identité de l'application ASP.NET, le répertoire virtuel et le répertoire physique correspondants), et fournit des fonctionnalités supplémentaires (telles que l'enregistrement d'un objet dans le domaine d'application, l'usurpation d'identité d'un utilisateur spécifique, etc.).
4 Créez des objets ASP.NET Core pour chaque requête
Lorsque le domaine d'application est créé, un objet ISAPIRuntime est créé et sa méthode ProcessRequest() est automatiquement appelée. Dans cette méthode, l'objet ISAPIRuntime crée un objet HttpWorkerRequest basé sur la requête HTTP entrante. Cet objet encapsule diverses informations de la requête HTTP de manière orientée objet (c'est-à-dire que les informations de la requête HTTP d'origine sont encapsulées en tant qu'objet HttpWorkerRequest). Ensuite, appelez la méthode StartProcessing() de l'objet ISAPIRuntime pour démarrer tout le processus de traitement des requêtes HTTP (il s'agit du « HTTP Pipeline : HTTP Pipeline »). Au début de ce processus de traitement, un objet de type HttpRuntime est créé, et le L'objet HttpWorkerRequest créé précédemment est utilisé comme Les paramètres de la méthode sont transmis à la méthode ProcessRequest() de cet objet HttpRuntime.
Des travaux très importants sont effectués dans la méthode ProcessRequest() de la classe HttpRuntime, parmi lesquels les plus étroitement liés aux ingénieurs logiciels Web sont :
La méthode ProcessRequest() de la classe HttpRuntime crée un objet HttpContext basé sur les informations de requête HTTP fournies dans l'objet HttpWorkerRequest.
L'objet HttpContext est important car cet objet contient deux autres objets très courants dans la programmation ASP.NET : HttpResponse et HttpRequest.
Les informations contenues dans l'objet HttpRequest proviennent de la requête HTTP d'origine. Par exemple, son attribut Url représente l'URL dans les informations de la requête HTTP d'origine.
L'objet HttpResponse possède certaines propriétés et méthodes permettant de générer des informations à renvoyer au navigateur.
La classe Page fournit les propriétés correspondantes pour référencer ces deux objets, vous pouvez donc utiliser directement les propriétés « Requset » et « Response » pour accéder à ces deux objets dans la page Web ASP.NET. Par exemple:
classe partielle publique _Default : System.Web.UI.Page
{
protected void Page_Load (expéditeur de l'objet, EventArgs e)
{
Réponse .Write (Demande .Url);
}
}
La propriété Context de la classe Page fait référence à l'objet HttpContext, le code ci-dessus peut donc également être réécrit sous la forme suivante :
classe partielle publique _Default : System.Web.UI.Page
{
protected void Page_Load (expéditeur de l'objet, EventArgs e)
{
this.Context.Response .Write(this.Context.Request .Url);
}
}
Concernant les trois objets HttpContext, HttpResponse et HttpRequest, vous devez maîtriser les points suivants :
l L'objet HttpContext contient deux objets, HttpResponse et HttpRequest. Vous pouvez obtenir des informations relatives aux requêtes HTTP à partir de l'objet HttpRequest, et le contenu à afficher dans le navigateur peut être obtenu en appelant la méthode HttpResponse.
l Pour chaque requête HTTP, ASP.NET crée un objet HttpContext, accessible pendant tout le traitement HTTP.
5 Allouez un objet HttpApplication pour gérer la requête
En plus de créer l'objet HttpContext, la méthode ProcessRequest() de la classe HttpRuntime accomplit également un autre travail très important : appliquer l'allocation d'un objet HttpApplication à une instance de la classe HttpApplicationFactory [3] pour gérer chaque étape de l'ensemble du traitement de la requête HTTP. pipeline.
L'objet HttpApplicationFactory est responsable de la gestion d'un pool d'objets HttpApplication [4]. Lorsqu'une requête HTTP arrive, s'il y a un objet HttpApplication disponible dans le pool, cet objet est directement alloué pour traiter la requête HTTP. Sinon, un nouvel objet HttpApplication est chargé. créé.
6 L'objet HttpApplication démarre le pipeline HTTP
L'objet HttpApplication est chargé d'assembler l'ensemble du « pipeline de traitement des requêtes HTTP (HTTP Pipeline) ». Le « pipeline de traitement des requêtes HTTP » peut être comparé au « pipeline de production » dans une usine moderne. L'objet HttpContext créé à l'étape précédente est le « produit » à traiter par ce pipeline de production. Lorsqu'il traverse différentes parties du « pipeline de production », il sera traité et traité spécifiquement.
Comment se déroulent ces « processus et traitements » spécifiques ?
En termes simples, lorsque l'objet HttpContext traverse différentes parties du « pipeline de production », l'objet HttpApplication déclenchera une série d'événements [5]. Un composant spécifique - le module HTTP (Module HTTP) peut répondre à ces événements. Dans ce code de réponse à l'événement, l'objet HttpContext peut être "traité et traité". En ce sens, le module HTTP peut être considéré comme un "pipeline de production". » les travailleurs. Le module HTTP est en fait le « filtre ISAPI » introduit précédemment.
L'objet module HTTP est créé dans la méthode InitModules() [6] de l'objet HttpApplication. Nous écrivons généralement du code dans la méthode Init() [7] de l'objet module HTTP afin qu'il puisse répondre à des événements spécifiques déclenchés par HttpApplication. objet.
ASP.NET fournit des modules HTTP prédéfinis pour répondre à des événements spécifiques, et les ingénieurs logiciels Web peuvent également écrire leurs propres modules HTTP et les insérer dans le « pipeline de traitement des requêtes HTTP » [8].
Au milieu du pipeline (après traitement des événements liés), l'objet HttpContext est reçu par l'objet Page final (c'est pourquoi l'objet HttpContext est accessible dans la page ASP.NET via la propriété Context définie par la classe Page).
Chaque page ASP.NET consultée sera convertie en une « classe de page dérivée de la classe Page ».
Remarque : La classe Page implémente l'interface IHttpHandler, qui définit une méthode ProcessRequest().
Une fois la classe de page ASP.NET générée, elle est automatiquement compilée dans un assembly, puis sa méthode ProcessRequest() est automatiquement appelée (car la classe Page implémente l'interface IHttpHandler, elle doit avoir cette méthode). Dans cette méthode, le code écrit par l'ingénieur logiciel Web est exécuté (le cas échéant). Le résultat de l'exécution de la méthode ProcessRequest() est à nouveau porté par l'objet HttpContext, le contrôle est retransféré au « pipeline de traitement des requêtes HTTP » et l'objet HttpApplication continue de déclencher les événements suivants. À ce stade, s'il existe des modules HTTP spécifiques qui répondent à ces événements, ils seront automatiquement appelés.
L'objet HttpContext amène le résultat final du traitement à la fin du "pipeline de traitement des requêtes HTTP", et ses informations sont extraites et transmises à nouveau au processus de travail en utilisant aspnet_isapi.dll comme pont. Le processus de travail transfère ensuite les résultats du traitement de la requête HTTP à HTTP.SYS, qui est chargé de renvoyer les résultats au navigateur.
Selon l'introduction précédente, l'ensemble du pipeline HTTP peut être divisé en trois sections : étape de prétraitement, étape de traitement et étape de post-traitement (Figure 8 ‑14).
Figure 8 ‑ 14 Trois étapes du pipeline HTTP
Comme le montre la figure 8-14, les étapes de pré-traitement et de post-traitement du pipeline HTTP font principalement appel à plusieurs modules HTTP et sont pilotées par des événements. Le travail effectué au cours de ces deux étapes consiste principalement à exécuter divers attributs. de l'objet HttpContext.
Le traitement des requêtes HTTP est finalement complété dans la « phase de traitement » par un objet qui implémente l'interface IHttpHandler. Chaque classe de page générée par les pages Web ASP.NET implémente cette interface. L'objet PageHandlerFactory [9] est responsable de la création d'un objet de traitement de requête HTTP approprié.
On voit que l'objet qui implémente l'interface IHttpHandler est responsable du traitement des requêtes HTTP, c'est pourquoi il est appelé "Handler (handler)".
Outre les pages Web ASP.NET les plus courantes, les ingénieurs logiciels Web peuvent également créer leurs propres objets qui implémentent l'interface IHttpHandler et les insérer dans le pipeline HTTP pour gérer les requêtes HTTP.
Lorsque la requête HTTP est traitée, les objets associés sont libérés, mais le domaine d'application créé, HttpApplication et les autres objets survivent toujours pour répondre à la requête HTTP suivante.
7 Résumé du cycle de vie des applications ASP.NET
Cette section présente le cycle de vie des applications ASP.NET. Il s'agit d'un processus assez complexe qui peut être plus facile à comprendre avec l'analogie populaire suivante :
l « Pipeline de traitement des requêtes HTTP » est une « chaîne d'assemblage de production » dans une usine moderne, et l'objet HttpContext est le produit à traiter sur cette chaîne d'assemblage.
l L'objet HttpHandler (gestionnaire HTTP) est le cœur de l'ensemble de la « ligne de production de produits », qui est responsable de l'assemblage du produit en forme.
l HttpModule (module HTTP) équivaut à des travailleurs auxiliaires sur la « ligne de production ». Ils effectuent un "pré-traitement" (préparation à l'assemblage du produit) et un "post-traitement" (préparation à la livraison du produit, comme l'étiquetage) sur le produit (objet HttpContext) ).
l L'objet HttpApplication est le "leader" de l'ensemble de la "ligne de production". Il est responsable de l'affectation des travailleurs à la "ligne de production" (initialisation et chargement de tous les HttpModules enregistrés), puis du déclenchement d'une série d'événements (appelés "ASP. NET" "), un HttpModule spécifique est chargé de répondre à des événements spécifiques.
-------------------------------------------------- ----------------------------------
[1] Si le processus de travail n'existe pas, le programme de surveillance IIS WAS en créera un, sinon le processus de travail existant sera réutilisé.
[2] En mode intégré IIS 7, puisque le CLR est préchargé, cette étape n'est pas nécessaire.
[3] « Instance de classe » et « objet de classe » ont la même signification et font tous deux référence à des objets créés en utilisant des classes comme modèles.
[4] Le pool d'objets (pool d'objets) est une méthode d'organisation d'objets courante dans les systèmes logiciels orientés objet. Il peut être considéré comme un conteneur d'objets. Le pool d'objets contient plusieurs objets créés à l'avance. Lorsque le monde extérieur a besoin d'un objet, il peut directement retirer un objet prêt à l'emploi du pool et l'utiliser, évitant ainsi la perte de performances causée par la création fréquente d'objets.
[5] HttpApplication définit un certain nombre d'événements. Pour une liste complète des événements, veuillez consulter MSDN.
[6] Cette méthode sera automatiquement appelée lors de l'obtention de l'objet HttpApplication.
[7] Tous les modules HTTP doivent implémenter l'interface IHttpModule, et la méthode Init() est définie par cette interface.
[8] Des modules HTTP personnalisés peuvent être ajoutés au flux de traitement des requêtes HTTP en insérant un contenu spécifique dans Web.Config.
[9] Il s'agit d'un autre noyau du cadre technologique ASP.NET