Instructions: Conception des états pour les applications J2EE
Ces instructions portent sur les mécanismes de conception de gestion des états d'une application J2EE.
Relations
Description principale

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.