Principes et conseils Conception des états pour les applications J2EE
Rubriques
Introduction

La gestion efficace de l'état de l'application est un aspect important dans la conception des applications réparties. Cette recommandation fournit un aperçu de certaines considérations et mécanismes de conception courants pour la gestion de l'état dans une application J2EE.
Les considérations de conception liées à la gestion de l'état doivent être traitées pendant la phase d'élaboration du projet. L'architecte logiciel doit examiner les approches générales de la gestion de l'état dans le cadre des activités liées à la discipline Analyse et Conception Détail de l'enchaînement d'activités : Définition d'une architecture candidate. Pendant l' Activité :
Analyse architecturale, l'architecte logiciel doit examiner l'évolutivité et les exigences de performances de l'application pour déterminer les techniques de gestion de l'état à utiliser pour que l'application atteigne ses objectifs de performances. Au fur et à mesure que s'affine la conception de l'application dans la phase d'élaboration, l'architecte doit définir des mécanismes de conception et d'implémentation spécifiques J2EE pour la gestion des informations relatives à l'état pour l'application dans l' Activité : Identification des mécanismes de conception.
Comme indiqué dans Concepts :
Configurations de déploiement J2EE, les applications J2EE peuvent être constituées de plusieurs couches logiques
distribuées sur plusieurs niveaux physiques (machines).
Après un aperçu technique succinct de la gestion de l'état, les paragraphes qui suivent décrivent les différents mécanismes de conception et d'implémentation de la gestion des états qui peuvent être utilisés sur les nombreux niveaux de l'application.
Notez que l'architecte logiciel doit documenter les mécanismes qui ont été sélectionnés dans le cadre de l'Artefact : Document d'architecture logicielle et fournir des directives sur l'utilisation de ces mécanismes dans le cadre des directives de conception propres au projet.
Aperçu technique

Il se construit de plus en plus d'applications interagissant d'une manière ou d'une autre avec l'Internet. Même si les fondements sur lesquels repose l'Internet sont par nature sans état, il n'est pas rare que la construction d'une application commerciale quelconque nécessite une gestion des états. Considérons une application Internet dans laquelle l'utilisateur clique sur un lien d'une page A pour accéder à une page B. L'application traitant la requête pour la page B n'a plus accès aux informations servant à traiter la page A. Si ce comportement est acceptable pour des pages Web statiques, il n'en va pas de même pour la plupart des applications commerciales, qui nécessitent des informations sur le traitement précédent.C'est là qu'interviennent les mécanismes
de gestion des états fournis par J2EE.
Etats transitoire et persistant
Avant de se plonger dans les principes et conseils relatives à gestion des états, il est important de différencier les types d'informations sur les états. Ces informations peuvent être divisées grosso modo en deux catégories : transitoires (n'existent que tant que l'application
est active) et persistantes (existent après l'arrêt de l'application).
Les informations sur un état transitoire existent tant que l'entité maintenant ces informations est en vie. C'est le cas, par exemple, des informations d'état stockées dans un champ d'une classe Java ordinaire. Si, pour une raison quelconque, le conteneur hébergeant cette classe est arrêté, les informations d'état sont perdues, à moins d'avoir été dupliquées ailleurs, par exemple sur un serveur de sauvegarde.
L'état persistant existe tant que le magasin de données servant à conserver les informations d'état existe. Les informations d'état persistantes sont généralement stockées dans un fichier ou une base de données, et sont chargées lorsque l'application en a besoin. Toutes les modifications apportées aux informations d'état persistantes doivent être écrites dans la base de données. Les aspects liés à l'intégrité du magasin de données persistantes et à sa capacité de restauration doivent être cohérents avec ceux des données auxquelles l'application accède. Les informations stockées dans un magasin de données tel qu'une base de données relationnelle sont un exemple d'informations d'état persistant.
Etat de session

Les clients Web doivent souvent pouvoir effectuer plusieurs requêtes de navigateur et accéder d'une page à une autre, tout en conservant des informations qui leur sont spécifiques telles que les articles d'un panier d'achat. Les applications Web satisfont ce besoin en créant un ID de session et en y associant les données d'état. L'ID de la session et l'état associé sont appelés "état de session".
L'état de session est constitué de données associées à une interaction particulière entre un client et une application Web pendant une courte période (des minutes ou des heures et non des jours). Pour cette raison, un état de session est composé de données à faible durée de vie, généralement supprimées après une certaine durée de validité afin d'économiser les ressources.
L'état de session peut être stocké sur le client ou sur le serveur, comme indiqué dans les sections qui suivent. En raison de son importance pour les applications Web, la plate-forme J2EE fournit des mécanismes taillés sur mesure pour la gestion de l'état de session.
Mécanismes de base de la persistance 
Les mécanismes suivants sont communément utilisés par les applications Web pour stocker l'état.
Cookies
Les cookies sont de petits fichiers texte stockés sur les clients Web. Un serveur peut stocker des cookies sur un client. Les requêtes suivantes du client envoient le cookie au serveur, qui accède ainsi aux données stockées dans le cookie.
L'utilisation des cookies pose certains problèmes :
- De nombreux utilisateurs, croyant que les cookies compromettent la sécurité et/ou la confidentialité, les désactivent.
- La taille de l'en-tête des cookies est limitée, ce qui limite la quantité de données stockable.
- Certains protocoles tels que WAP ne prennent pas en charge les cookies.
- Si un client se connecte à partir d'un emplacement différent (une autre machine, par exemple), les cookies stockées à son emplacement initial ne sont pas disponibles.
- Les données d'état doivent pouvoir être stockées dans des chaînes.
Réécriture des adresses URL
La réécriture des adresses URL est un mécanisme incorporant l'état de session dans les adresses URL référencées sur chaque page. Lorsqu'un serveur Web génère des pages à fournir à un client, il code l'état de session à l'intérieur de l'adresse URL de la page. Lorsque l'utilisateur clique ensuite sur l'adresse URL, les données qui y sont stockées sont renvoyées au serveur, qui peut alors rétablir le contexte de la session. Un mécanisme similaire fait appel à des champs HTML masqués. Les problèmes posés par ces mécanismes sont les suivants :
- Toutes les pages d'une session données doivent être manipulées par le serveur, faute de quoi ce dernier ne peut plus suivre la session.
- L'état est perdu lorsque le client ferme son navigateur ou accède à une adresse URL spécifique par un lien ou par un favori.
- Comme dans le cas des cookies, les données d'état ne sont pas disponibles lorsque le client se connecte à partir d'un emplacement différent.
- Comme dans le cas des cookies, les données d'état doivent pouvoir être stockées dans des chaînes.
Fichier plat
Un fichier plat constitue l'une des méthodes les plus simples pour conserver les informations d'état persistantes. Dès l'initialisation, le fichier plat est lu pour définir les valeurs d'état initiales. Chaque fois que l'état est modifié, le fichier doit être réécrit pour enregistrer la modification. Certains inconvénients du fichier plat sont les suivants :
- L'évolutivité de l'application est compromise, car l'application doit verrouiller l'objet application pour empêcher un accès aux données globales pendant que ses variables d'état sont mises à jour et réécrites dans le fichier plat.
- Dans la plupart des cas, la mise à jour des données nécessite la réécriture de tout le fichier.
- Les fichiers plats ne permettent pas toujours une restauration en cas d'erreur.
XML

La conservation des informations d'état persistantes dans un fichier XML constitue une amélioration par rapport au fichier plat. Le fichier XML présente notamment les avantages suivants sur le fichier plat pour le stockage de l'état de l'application :
- Un fichier XML comporte une structure absente d'un fichier plat.
- Un fichier XML peut être soumis à l'analyse syntaxique des API standard.
- Un fichier XML est généralement plus portable.
Base de données

La capacité maximale de restauration est apportée par la conservation des informations d'état persistantes dans une base de données. Certains des avantages de la conservation de l'état d'une application dans une base de données sont :
- La structure est fournie par la conception des tables.
- Il n'est pas nécessaire de réécrire l'état de l'application toute entière lorsqu'une variable est mise à jour. Seules les informations mises à jour doivent être réécrites.
- La cohérence peut être conservée par la coordination de la restauration de l'état de l'application avec celle de la base de données de production.
- Dans les situations exigeant une fiabilité élevée, le serveur de base de données peut être mis en clusters.
Il est possible d'accéder aux bases de données par l'API JDBC.
JDBC permet également d'accéder à d'autres sources de données en tableaux, comme les feuilles de calcul et les fichiers plats.
Mécanismes spécifiques J2EE 
La plate-forme J2EE fournit des mécanismes spécifiques pour gérer les états. Il s'agit de mécanismes de haut niveau qui peuvent être configurés de manière à utiliser un ou plusieurs des mécanismes de base décrits plus haut.
Contexte de servlet

Les servlets peuvent utiliser le contexte de servlet pour enregistrer les données applicables à plusieurs clients et sessions de clients.
Les données stockées dans le contexte de servlet sont essentiellement des variables globales de l'application J2EE. Pour cette raison, l'utilisation d'un état d'application peut influer sensiblement sur la conception de l'application. L'architecte logiciel doit prendre en compte les éléments suivants dans l'Activité :
Identification des mécanismes de conception pour déterminer si le contexte de servlet convient :
- Le contexte de servlet peut être conservé dans un processus unique, pour éviter qu'il soit partagé entre plusieurs serveurs ou clusters. Si cette solution ne répond pas aux besoins d'évolutivité de l'application, l'architecte doit envisager de stocker l'état comme un état de session.
- Le contexte de servlet fait partie de la mémoire du processus, et n'est donc généralement pas conservé à la fin du processus.
- Plusieurs unités d'exécution peuvent accéder aux données globales. Le verrouillage et la synchronisation des données globales peut affecter l'évolutivité de l'application.
Objet session HTTP 
Les servlets et les JSP peuvent stocker des données associées à une session de client particulière dans l'objet session HTTP. Le stockage des données dans des objets session peut poser des problèmes d'accès par les différents serveurs.
Certains fournisseurs permettent d'acheminer les requêtes des clients vers un même serveur, pratique désignée généralement "affinité du serveur".
L'objet session HTTP est disponible sur le serveur pendant le traitement des requêtes clients, mais peut ou non être stocké sur le serveur entre les requêtes.
Le serveur doit pouvoir être configuré pour utiliser tous les mécanismes de base de la persistance décrits plus haut : stockage de l'état de session sur le client dans des cookies, ou sur le serveur dans des fichiers ou dans une base de données. Il doit également permettre de dupliquer les données de la session en mémoire sur plusieurs serveurs.
Le mécanisme est sélectionné par configuration du serveur, les JSP et les servlets étant codés indépendamment du mécanisme sélectionné et accédant à l'objet session par une API spécifiée dans la spécification du servlet.
Enterprise JavaBeans 
Les Enterprise JavaBeans comportent des mécanismes de stockage d'état de haut niveau, basés sur les mécanismes de bas niveau décrits précédemment, tels que bases de données et fichiers. Des beans de session avec état sont utilisés pour stocker les données associées à une session client particulière, les beans d'entité pour stocker les données à durée de vie plus longue. Voir Principes et conseils :
EJB pour une description de l'état stocké par les EJB.
Conception de l'état de session
Les clients Web doivent souvent pouvoir effectuer plusieurs requêtes de navigateur et accéder d'une page à une autre, tout en conservant des informations qui leur sont spécifiques telles que les articles d'un panier d'achat. Les applications Web satisfont ce besoin en créant un ID de session et en y associant les données d'état. L'ID de session est stockée sur le client par un ou deux mécanismes :
- cookie - le navigateur client envoie ce cookie au serveur à chaque requête pour lui permettre de rétablir l'état de la session.
- Réécriture de l'adresse URL - l'ID de la session est codé à l'intérieur des adresses URL dans les pages envoyées au client par le serveur. Lorsque le serveur clique sur l'une de ces adresses URL, l'ID de la session est envoyée au serveur pour qu'il rétablisse l'état de la session.
Le serveur est configuré pour utiliser l'approche sélectionnée. Les servlets et les JSP doivent être codés de manière à fonctionner indépendamment de la méthode configurée. Plus précisément, utilisez les méthode
HttpServletResponse.encodeURL() pour coder toutes les adresses URL. Cette méthode vérifie si la réécriture des adresses URL est activée et, si oui, effectue le codage.
Les données associées à un ID de session peuvent être stockées dans l'objet session HTTP, où les JSP et les servlets peuvent y accéder, ou dans des beans de session.
L'ID de la session et les données associées doivent être configurés pour expirer après un délai, pour que les données de session qui n'ont pas été utilisées après une longue période ne consomment pas indéfiniment des ressources. Il appartient à l'architecte de choisir une durée de vie appropriée.
Choix du mécanisme approprié
Les architectes doivent envisager de stocker l'état de session sur le client pour des raisons de simplicité et de performance. Lorsque l'état est géré et stocké sur le client, les serveurs n'ont pas à étendre leurs ressources pour stocker les informations d'état ou pour assurer leur cohérence. Ce choix présente néanmoins l'inconvénient de nécessiter l'envoi des informations du client vers le serveur, ce qui pose des problèmes de latence du réseau. Des problèmes de sécurité peuvent également se poser si vous ne souhaitez pas que le client ait accès aux données d'état de session.
Dans ce cas, le cryptage peut apporter une réponse.
Si votre application comporte de grandes quantités d'état de session, il est généralement préférable de les stocker sur le serveur, généralement moins sujet aux limitations de taille ou de type.
D'une manière générale, les états de session liés à des problèmes de présentation doivent être stockés dans l'objet session HTTP, et les beans de session avec état doivent stocker l'état nécessaire à l'implémentation correcte de la logique métier. La réplication des données d'état doit être évitée. Il est préférable de déplacer les données répliquées dans la session HTTP et de les passer en paramètres dans le bean de session sur des appels de méthode de bean de session, selon les besoins.
Si les données de session stockées sur le serveur doivent survivre à une panne de noeud de serveur, envisagez un mécanisme qui les conserve ou les duplique.
Conception d'un état à persistance plus longue
Les données de session conviennent à des données client à courte durée de vie destinées à disparaître après un certain délai. Mais certaines données doivent parfois être conservées sur des durées plus longues.
Le mécanisme approprié à ces données dépend de leur nature.
Cookies, fichiers plats, fichier XML et bases de données peuvent être envisagés. Pour l'accès aux bases de données, un bean d'entité est généralement le meilleur choix. Voir Principes et conseils :
beans d'entité pour plus d'informations.
|