La gestion de sessions dans Windows Azure restant l’une des questions les plus posées en termes d’architecture Web, voici une petite synthèse sur le sujet !

Lorsque l’on conçoit des applications Web, la nature « stateless » du protocole HTTP force les architectes à prêter une attention particulière à la façon de maintenir l’état de l’application. Bien qu’en principe les applications doivent être conçues pour minimiser l’état conservé sur chacun des nœuds d’une ferme, il est généralement nécessaire de gérer une forme d’état applicatif ou de session pour stocker de l’information entre les requêtes. Les bonnes pratiques standard pour la gestion d’états d’applications ASP.NET s’appliquent généralement aux applications Web sous Windows Azure, mais il y a quelques différences qu’il faut bien prendre en compte.

Les applications ASP.NET ont toujours offert deux types d’option pour la gestion de l’état : côté serveur et côté client. Le choix de l’une ou l’autre méthode dépend de la structure de l’application ainsi que de l’environnement d’exécution, comprenant des paramètres tels que la bande passante disponible, l’architecture réseau, etc. Pour des recommandations générales sur le choix d’une méthode, vous pouvez lire l’article « Recommandations sur la gestion d’état ASP.NET » sur MSDN.

Approches côté serveur

Application State

L’Application State est un stockage de données accessible par tous les objets d’une application ASP.NET. L’Application State est stocké en mémoire sur le serveur et permet donc d’accéder aux données beaucoup plus rapidement qu’en interrogeant une base de données, par exemple. Contrairement au Session State, qui est spécifique à une session utilisateur, l’Application State s’applique à tous les utilisateurs et toutes les sessions. Il s’agit donc d’un bon endroit où stocker de petites quantités de données fréquemment utilisées et qui ne changent pas d’un utilisateur à l’autre. Pour plus d’informations, vous pouvez vous reporter à l’article « Vue d’ensemble de l’état de l’application ASP.NET » sur MSDN.

Application à Windows Azure

Bien que l’Application State soit supporté et fonctionne au sein de Windows Azure, il faut noter que l’Application State n’est pas partagé entre les multiples serveurs Web servant une même application (i.e. de multiples instances de Rôles Web). Votre application ne peut donc pas s’attendre à trouver les mêmes données d’état sur les différentes instances d’une requête à l’autre.

Session State

Le Session State ASP.NET peut être utilisé pour stocker un état par utilisateur, ce qui vous permet de stocker et de retrouver des variables lorsque l’utilisateur navigue les différentes pages ASP.NET d’une application Web. ASP.NET propose trois modes de fonctionnement pour le Session State : InProc, StateServer et SQLServer. L’on peut également définir des fournisseurs d’état de session personnalisés.

Application à Windows Azure

Tout comme l’Application State, le mode InProc est supporté et fonctionne dans l’environnement Windows Azure, mais il n’est pas partagé entre les différentes instances de rôles servant la même application. Le Session State en mode InProc doit être uniquement utilisé pour les déploiements qui ne requerront jamais plus d’une seule instance de Rôle Web (à noter que Windows Azure n’offre pas de garantie de service pour les déploiements consistant d’une seule instance).

Le mode StateServer pour l’état de session n’est pas supporté pour les applications Windows Azure, car il n’existe pas la possibilité de déployer le service Windows StateServer.

Le mode SQLServer est valide dans l’environnement Windows Azure, et permet de stocker les sessions dans SQL Azure. Cette approche permet au même état de session d’être accédé par de multiples instances de Rôles Web. Pour créer les structures de données nécessaires dans SQL Azure, il est nécessaire de lancer un script spécifique (différent de celui fourni par ASP.NET pour créer les structures dans SQL Server). Le script est disponible sur le blog de l’équipe SQL Azure.

Une autre option pour les applications Windows Azure est de stocker l’état de session dans le Stockage Windows Azure. Cela peut être accompli en utilisant un fournisseur d’état de session personnalisé. Un exemple est inclus dans le projet « AspProviders » des Samples Windows Azure : http://code.msdn.microsoft.com/windowsazuresamples

Cet exemple vous permet de stocker les Sessions (ainsi que les Memberships, Roles et Profiles) dans le Stockage Windows Azure. Le choix d’utiliser SQL Azure ou les Tables Windows Azure devra se faire sur la base des besoins de l’application ainsi, potentiellement, que de l’équation économique. D’une façon générale, si l’application gère ses données dans des Tables Windows Azure, il est logique d’y stocker également les Sessions, et de ne pas utiliser une instance SQL Azure spécialement pour cet usage.

Profile Properties

La fonctionnalité de Profil ASP.NET permet d’associer des informations persistantes à un utilisateur, puis d’accéder aux valeurs de ces propriétés via une API fortement typée, depuis n’importe quel point de l’application. Pour utiliser ces profils, vous devez modifier le fichier de configuration de votre application ASP.NET pour spécifier le fournisseur de profils, ainsi bien entendu que les propriétés elles-mêmes. Vous trouverez plus d’informations sur cette fonctionnalité dans l’article MSDN « vue d’ensemble des propriétés du profil ASP.NET ».

Application à Windows Azure

Pour stocker les Profils dans SQL Azure, vous devez utiliser des scripts SQL modifiés ; vous les trouverez à cette adresse : http://support.microsoft.com/kb/2006191/en-us

Une autre option est, tout comme pour les Sessions, de stocker les données de Profils dans des Tables Windows Azure. Là encore, le projet « AspProviders » des Samples Windows Azure inclut un fournisseur personnalisé pour les Profils. Et tout comme pour les Sessions, il paraît logique de stocker ces données dans le même référentiel que le reste de l’application.

Approches côté client

Il existe plusieurs approches pour gérer l’état côté client lorsque l’on développe des applications ASP.NET traditionnelles, et l’ensemble de ces méthodes reste disponibles dans Windows Azure. Ces options peuvent potentiellement réduire la charge globale côté serveur, étant donné qu’elles ne consomment aucunes ressources sur le serveur et sont entièrement gérées par le client. En revanche, comme l’information doit être transmise à chaque requête, il y a en pratique une limite à la quantité d’information qu’il est possible de gérer de cette façon.

·         View State.

o   Les pages ASP.NET Web Forms ont toutes une propriété ViewState, qui est une structure permettant de retenir automatiquement des valeurs pour de multiples requêtes de la même page

o   Cette propriété est utile pour stocker de petites quantités d’informations dans une page avec « post back »

o   Le View State est en pratique transmis sous la forme d’un champ caché mais est haché, ce qui offre une meilleure sécurité qu’avec un simple champ caché.

·         Control State.

o   Le Control State est semblable au View State mais s’applique à un contrôle particulier sur la page

·         Champs cachés.

o   Vous pouvez inclure des informations spécifiques dans un champ caché au sein de la page avec le contrôle HiddenField.

o   Cette méthode permet de stocker de petites quantités d’informations dans une page avec « post back » ou post vers une autre page.

·         Cookies.

o   Vous pouvez utiliser des Cookies pour stocker de petites quantités d’informations sur le client. Le client inclut alors cette information avec toutes les requêtes suivantes.

·         Paramètres de requête.

o   Il est possible de passer des informations d’état simples directement sous forme de paramètres dans l’URL d’une page. L’on est cependant limité par la taille maximum d’un URL.

·         Frames cachées.

o   Cette technique permet de stocker des données côté client, sans imposer des allers-retours au serveur.

o   L’on créer une frame cachée sur la page, qui charge une page contenant les données à stocker. L’on peut alors accéder à ces données directement depuis la page en JavaScript.

En synthèse

·         Ne pas utiliser l’Application State si vous pouvez l’éviter (dans le cas d’une nouvelle application).

·         Utiliser le Provider Model ASP.NET pour stocker l’état de l’application dans SQL Azure ou les Tables Windows Azure (en s’appuyant sur les Samples cités plus haut, ou le provider standard pour SQL Azure).

·         Assurez-vous que les Rôles Web et le référentiel de données d’état sont dans le même centre d’hébergement ! L’application devra faire appel au stockage à chaque requête, il est donc important de localiser les deux composants au même endroit.

·         Ne pas utiliser le stockage d’état InProc si vous souhaitez avoir plus de deux instances.

·         Tous les objets à stocker dans l’état doivent être sérialisables. En effet, dès lors que l’on n’utilise pas le mode InProc, seuls les types .NET de base ou les types sérialisables sont utilisables.

·         Stockez l’état au même endroit que le reste des données de l’application.

·         Utilisez le stockage Windows Azure (par exemple les Tables) pour une évolutivité maximale si vous avez un nombre d’utilisateurs extrêmement élevé.