Introduction
La gestion efficace des états d'une application est un élément important de la conception des applications réparties.
Ces instructions fournissent une présentation de certains des mécanismes et considérations de conception courants pour
la gestion d'états d'une application J2EE.
Les considérations de conception relatives à la gestion d'états doivent être traitées pendant la phase d'élaboration du
projet. L'architecte logiciel doit examiner les approches générales concernant la gestion d'états dans le cadre
des activités associées à la discipline d'analyse & de conception Activité : Définition d'une architecture
potentielle. Pendant la Tâche : Analyse de
l'architecture, l'architecte logiciel doit examiner l'évolutivité et les exigences de performances pour
l'application afin de déterminer les techniques de gestion d'états qui devront être utilisées pour permettre à
l'application de répondre aux objectifs de performances. La conception de l'application étant détaillée pendant la
phase d'élaboration, l'architecte devra définir les mécanismes de conception et d'implémentation spécifiques J2EE
pour la gestion d'information d'état, avec l'application dans la Tâche : Identification des mécanismes de conception.
Comme décrit dans Concept : Configurations de déploiement J2EE, les
applications J2EE peuvent se composer de plusieurs couches logiques réparties entre un et plusieurs niveaux physiques
(machines). Après une brève présentation technique de la gestion d'états, ces instructions traitent des différents
mécanismes de conception et d'implémentation de la gestion d'états pouvant être utilisés dans les nombreux niveaux de
l'application.
Remarque : l'architecte logiciel doit documenter les mécanismes sélectionnés en tant que partie du Produit : Document d'architecture
logicielle et il doit aussi fournir les instructions relatives à l'utilisation de ces mécanismes en tant
qu'instructions de conception relatives à un projet.
Présentation technique
Il y a une tendance grandissante à construire des applications réparties qui interagissent avec Internet d'une manière
ou d'une autre. Bien que les fondements d'Internet soient par nature sans état, il faut souvent gérer les états
pour la construction de n'importe quel type d'application métier. Considérez une application Internet où
un utilisateur clique sur un lien de la page A à la page B. L'application qui traite la requête pour la page B n'a
plus accès à l'information qui a servi à traiter la page A. Ce comportement est acceptable pour les pages Web
statiques mais la plupart des applications métier ont besoin des informations sur le traitement précédent. C'est à ce
moment-là que les mécanismes de gestion d'états fournis par J2EE entrent en jeu.
Etat persistant et état transitoire
Avant de se plonger dans les instructions relatives à la gestion d'états, il est important de différencier deux types
d'information d'état. Les informations d'état se divisent en deux catégories : transitoire (existe uniquement tant
que l'application est active) et persistant (existe toujours après que l'application soit terminée).
Les informations d'état transitoires existent tant que l'entité contenant ces informations existe. Il s'agit par
exemple des informations d'état stockées en tant que zone dans une classe Java classique. Si le conteneur qui héberge
cette classe se termine pour quelque raison que ce soit, les informations d'état seront perdues à moins que les données
aient été copiées ailleurs, comme sur un serveur de secours, par exemple.
Les informations d'état existent tant que le magasin de données qui sert à maintenir ces informations existe. Les
informations d'état sont généralement stockées dans un fichier ou une base de données ; elles sont ensuite téléchargées
lorsque l'application le nécessite. Tous les changements, quels qu'ils soient, apportés aux informations d'état
doivent être mentionnés dans la base de données. L'intégrité et la reprise du magasin de données persistantes
doivent être cohérentes avec les données auxquelles l'application accède. Un exemple d'état persistant est stocké sous
forme d'information dans un magasin de données tel qu'une base de données relationnelle.
Etat de session
Les clients sur le Web demandent souvent de pouvoir faire des requêtes de navigation multiples, navigant d'une page à
l'autre, tout en conservant des informations spécifiques au client telles que des articles dans un panier. Cela est
possible grâce aux applications Web qui créent une session ID et associent des données d'état à cette session. On
appelle cette session ID et l'état qui lui est associé, un état de session.
L'état de session est associé par le biais de données à une interaction particulière d'un client avec une application
Web sur un lapse de temps assez court (minutes ou heures plutôt que journées). L'état de session est donc une donnée à
courte durée de vie couramment supprimée après une période de temporisation afin d'éviter de consommer des ressources.
L'état de session peut se stocker chez le client ou sur le serveur, comme décrit dans les sections à venir. La
plateforme J2EE fournit des mécanismes spécialement personnalisés pour la gestion d'état de session en raison de son
importance dans les applications Web.
Mécanismes de persistance élémentaires
Les mécanismes suivants sont les mécanismes couramment utilisés par les applications Web pour stocker des états.
Cookies
Les cookies sont de petits fichiers texte stockés chez les clients sur le Web. Un serveur peut stocker des cookies chez
le client. Les requêtes ultérieures du client envoient le cookie au serveur, donnant ainsi au serveur accès aux données
d'état stockées dans le cookie.
Les problèmes relatifs aux cookies sont les suivants :
-
Beaucoup d'utilisateurs pensent que les cookies compromettent la sécurité et/ou la confidentialité et les
désactivent.
-
La taille des en-têtes de cookies est limitée, ce qui limite la quantité de données à stocker.
-
Certains protocoles, tels que le protocole WAP (Wireless Access protocol), ne prennent pas en charge les cookies.
-
Si un client se connecte à partir d'un autre emplacement (une autre machine, par exemple), les cookies stockés dans
cet autre emplacement ne sont pas disponibles.
-
Les données d'état doivent être représentées par des valeurs de chaîne.
Réécriture d'URL
La réécriture d'URL est un mécanisme consistant à insérer l'état de session dans les URL référencées à chaque page.
Lorsqu'un serveur Web génère des pages à livrer à un client, il encode l'état de session dans les URL de la page.
Ainsi, lorsque le client clique sur l'URL, les données d'état stockées dans l'URL sont renvoyées au serveur, lui
permettant de rétablir le contexte de la session. Un mécanisme similaire utilise les zones masquées du langage HTML.
Les problèmes relatifs à ces mécanismes sont les suivants :
-
Toutes les pages d'une session donnée doivent être traitées par le serveur, sinon celui-ci peut perdre la trace de
la session.
-
L'existence de l'état s'arrête lorsque le client ferme son navigateur ou se connecte à une URL particulière en
saisissant ou en utilisant un signet.
-
De même que pour les cookies, les données d'état ne sont pas disponibles lorsque le client se connecte à partir
d'un autre emplacement.
-
De même que pour les cookies, les données d'état doivent être représentées par des valeurs de chaîne.
Fichier à plat
Un fichier à plat est l'une des méthodes les plus simples pour conserver des informations d'état persistantes. Dès
l'initialisation, le fichier à plat est prêt pour établir les valeurs d'états initiales. Chaque fois que l'état
est changé, il faut réécrire le fichier pour sauvegarder l'état. Les inconvénients du maintien de l'état d'une
l'application dans un fichier à plat sont les suivants :
-
L'évolutivité de l'application est fortement touchée car l'application doit verrouiller l'objet de l'application
pour empêcher l'accès aux données globales tandis que les variables de l'état de l'application sont mises à jour et
réécrites dans le fichier à plat.
-
La plupart du temps, la mise à jour des données demande de complètement réécrire le fichier.
-
Les fichiers à plat ne fournissent pas toujours de reprise en cas d'erreur.
XML
La maintenance d'information d'état persistante dans un fichier XML est d'un niveau supérieur par rapport au fichier à
plat. Les avantages du maintien de l'état d'une application dans un fichier XML par rapport à un fichier à plat
sont les suivants :
-
Un fichier XML fournit une structure qui n'est pas présente dans un fichier à plat.
-
Un fichier XML peut s'analyser à l'aide d'API standards.
-
Un fichier XML est généralement plus portable.
Base de données
Maintenir les informations d'état persistantes dans une base de données permet d'avoir une capacité de reprise
maximum. Les avantages du maintien de l'état d'une application dans une base de données sont les suivants :
-
La conception des tables fournit une structure.
-
Il n'est pas nécessaire de réécrire l'état de l'application lorsqu'une variable de l'application est mise à
jour. Seules les informations mises à jour doivent être réécrites.
-
Il est possible de maintenir la cohérence en coordonnant la reprise de l'état de l'application avec la reprise de
la production.
-
Pour des situations de grande fiabilité, le serveur de la base de données peut être mis en cluster.
Il est possible d'accéder aux bases de données via l'API de la connectivité JDBC. La connectivité JDBC permet aussi
d'accéder à d'autres sources de données tabulaires, dont les tableurs et les fichiers à plat.
Mécanismes spécifiques à J2EE
La plateforme J2EE fournit des mécanismes spécifiques pour la gestion d'état. Il s'agit de mécanismes très élaborés que
l'on peut configurer pour utiliser un ou plusieurs des mécanismes décrits jusqu'à présent.
Contexte de Servlet
Les servlets peuvent utiliser le contexte de servlet pour sauvegarder des données applicables à des clients et des
sessions de client multiples.
Les données stockées dans le contexte de servlet sont essentiellement des variables globales pour l'application
J2EE. Par conséquent, l'utilisation de l'état de l'application peut avoir une incidence significative sur la
conception de l'application. L'architecte logiciel doit faire figurer les éléments suivants pendant la Tâche : Identifier les mécanismes de conception, en déterminant si le contexte de
servlet est approprié :
-
Le contexte de servlet peut être maintenu dans un seul processus, sans être donc partagé entre de multiples
serveurs (clusters). Si cela ne correspond pas aux besoins d'évolutivité de l'application, l'architecte doit
alors envisager de stocker l'état en tant que session état.
-
Le contexte de servlet fait partie de la mémoire du processus et n'est donc pas maintenu lorsque le processus est
fini.
-
De multiples unités d'exécution peuvent accéder aux données communes. Le verrouillage et la synchronisation de
ces données peuvent avoir une incidence sur l'évolutivité de l'application.
Objet Session HTTP
Les servlets et les pages JSP peuvent stocker des données associées à une session client particulière dans l'objet
session HTTP. Si le stockage de données se fait dans des objets session, il peut y avoir quelques problèmes concernant
la manière dont les données de session sont rendues disponibles entre de multiples serveurs. Certains fournisseurs vous
donnent la possibilité d'acheminer les requêtes des clients vers le même serveur, pratique connue en tant que "affinité
au serveur".
L'objet session HTTP est disponible sur le serveur pendant le traitement des requêtes du client, mais peut être ou ne
pas être stocké sur le serveur entre les requêtes. Le serveur devrait être configurable pour utiliser les mécanismes de
persistance élémentaires décrits plus haut, dont le stockage de l'état session dans les cookies du client, dans les
fichiers ou une base de données du serveur. Il devrait aussi fournir la possibilité de répliquer les données de session
en mémoire dans les serveurs.
Le mécanisme est sélectionné en configurant le serveur - les pages JSP et les servlets sont codés indépendamment du
mécanisme sélectionné, accédant à l'objet session à l'aide d'une API précisée dans la spécification du servlet.
Enterprise JavaBeans
Enterprise JavaBeans comprend des mécanismes très élaborés pour stocker les états, qui sont fondés sur les mécanismes
de niveau inférieur décrits précédemment, comme les bases de données et les fichiers. Les beans session avec état sont
utilisés pour stocker des données associées à une session de client particulière, alors que les beans entity sont
utilisés pour stocker des données à durée de vie longue. Voir Instructions : Enterprise JavaBean (EJB) pour des
informations sur les états stockés par les EJB.
Conception d'état session
Les clients sur le Web demandent souvent de pouvoir faire des requêtes de navigation multiples, navigant d'une page à
l'autre, tout en conservant des informations spécifiques au client telles que des articles dans un panier. Cela est
possible grâce aux applications Web qui créent une session ID et associent des données d'état à cette session.
La session ID est elle-même stockée chez le client par le biais d'un ou deux mécanismes :
-
le cookie - le navigateur du client envoie ce cookie au serveur à chaque requête permettant ainsi au serveur
de rétablir l'état session.
-
la réécriture d'URL - la session ID est encodée dans les URL contenues dans les pages que le serveur livre au
client. Lorsque l'utilisateur clique sur une de ces URL, la session ID est envoyée au serveur, permettant à
celui-ci de rétablir l'état session.
Le serveur est configuré pour utiliser l'approche qui a été sélectionnée. Les servlets et les pages JSP devraient être
codés pour pouvoir travailler sans tenir compte de la méthode configurée. Utilisez en particulier la méthode
HttpServletResponse.encodeURL() pour encoder toutes les URL. Cette méthode vérifie si la réécriture d'URL est activée
et si c'est le cas, réalise l'encodage.
Les données associées à une session ID peuvent être stockées dans l'objet session HTTP, où les pages JSP et les
servlets peuvent accéder à ces données, ou dans les beans session.
La session ID et les données associées devraient être définies avec une période de temporisation afin que les données
de session n'ayant pas été utilisées sur une longue période ne consomment pas les ressources indéfiniment. L'architecte
doit sélectionner une période de temporisation appropriée.
Sélection du mécanisme approprié
Les architectes doivent envisager la possibilité de stocker l'état session chez le client pour des raisons de
simplicité et de performances. Lorsque l'état est géré et stocké chez le client, les serveurs n'ont pas besoin
d'étendre les ressources pour stocker les informations d'état ou pour garantir sa cohérence. L'inconvénient de stocker
les informations d'état chez le client est qu'il faut envoyer l'information au serveur à chaque fois, ce qui entraîne
des problèmes de latence réseau. Il faut aussi prendre en compte la sécurité, si vous ne voulez pas que certaines
données d'état session apparaissent chez le client. Dans ce cas, le chiffrement peut être une option.
Si votre application contient une grande quantité d'états session, il est préférable de les stocker sur le serveur où
il y a moins de restrictions en termes de taille et de type.
L'état session lié aux questions de présentation doit généralement être stocké dans l'objet de session HTTP, alors que
les beans session avec état doivent contenir l'état requis pour implémenter correctement la logique métier. Il vaut
mieux éviter de dupliquer les données d'état. Déplacez plutôt toute donnée d'état dupliquée dans la session HTTP et
faites passer ces données dans le bean session en tant que paramètres selon l'appel de méthode du bean session, comme
il se doit.
Si les données de session stockées sur le serveur doivent subsister après l'échec d'un noeud du serveur, envisagez
alors la possibilité d'utiliser un mécanisme pour faire subsister ou pour répliquer les données de session.
Conception d'état à durée de vie longue
Les données de session servent pour les données client à durée de vie courte qui ont une période de temporisation. Vous
pouvez aussi avoir besoin de données qui subsistent beaucoup plus longtemps.
Le mécanisme approprié pour de telles données dépend de la nature des données qui sont stockées. Les cookies, les
fichiers à plat, les fichiers XML et les bases de données sont des options. Pour accéder aux bases de données, un bean
entity reste généralement la meilleure option. Voir Instructions: Bean entity pour plus de détails.
|