Composants web (web tiers) ludovic.maitre@free.fr

Plan (1/3) Composants web (web tiers) Le conteneur web Servlets Java Les rôles du serveur web Technologies utilisées sur le serveur web Technologies web spécifiques à J2EE Le conteneur web Servlets Java JavaServer Pages (JSP) Syntaxe XML pour les JSP Balises personnalisées Bibliothèques de balises standard (standard tag libraries) Java Standard Tag Library (JSTL)

Plan (2/3) Règles de conception des composants web Quand utiliser des servlets ? Utilisation de servlets comme contrôleurs Exemple de Servlet contrôleur Utiliser des servlets pour générer du contenu binaire Exemple de servlet génératrice de contenu binaire Eviter les servlets qui génèrent du texte statique Exemple de Servlet utilisée à mauvais escient pour générer du texte Utiliser les redirections et inclusions à bon escient

Plan (3/3) Résumé Où utiliser les JSP ? Utiliser les JSP pour la présentation des données Utiliser les JSP pour générer du XML Utiliser les JSP pour générer du texte non-structuré Utiliser les JSP comme modèles (templates) Encodage des pages JSP Eviter d'utiliser trop de balises logiques Utiliser les directives d'inclusion et les balises d'inclusion JSP à bon escient Exemple Utiliser des balises personnalisées pour éviter les éléments de script Mauvais exemple de JSP se comportant comme un contrôleur Résumé

Composants web (web tiers) Le serveur web d’une application J2EE (web tiers) rend disponible la logique d'une application sur le web. C’est le serveur web qui gère la communication avec les clients web et qui répond à leurs requêtes. Cette section décrit les technologies utilisées sur le serveur web dans le cadre d’une application J2EE.

Les rôles du serveur web (1/2) Un serveur web traite des requêtes http. Dans le cadre d’une application J2EE le serveur web (web tiers) gère les relations entre les clients web et l’application. Le serveur web produit typiquement du contenu HTML ou XML, bien qu’il puisse générer d’autres types de contenu. L’architecture J2EE préconise d’implémenter la logique métier dans le serveur d’EJB mais il est possible d’implémenter la logique métier directement sur le serveur web.

Les rôles du serveur web (2/2) Le serveur web assure les fonctions suivantes dans une application J2EE : mise à disposition de la logique métier sur le web: le serveur web gère les relations entre les clients web et la logique métier de l’application création dynamique de contenu: le serveur web génère dynamiquement du contenu, dans n’importe quel type de format: HTML, images, sons, video,… présentation et collecte des données: le serveur web transforme les requêtes HTTP PUT et GET dans une forme compréhensible par la couche métier de l’application et présente les résultats contrôle du flux de navigation: la logique implantée dans le serveur web détermine quel écran de l’application envoyer au client. En effet c’est souvent le serveur web qui adapte la présentation et l’enchaînement des écrans en fonction des capacités du client maintien des informations d’état: le serveur web dispose d’un mécanisme simple et flexible pour conserver des informations durant toute la durée d’une session utilisateur support de plusieurs clients: par le biais des types MIME un serveur web peut envoyer de l’information vers n’importe quel type de client et étendre les capacités de publication implémentation de la logique métier

Technologies utilisées sur le serveur web Technologies “traditionnelles” comme CGI : la génération de contenu dynamique sur le web a d’abord utilisé la technologie Common Gateway Interface (CGI). Cette technologie permet de déclencher des programmes lors de requêtes HTTP, le résultat du programme étant alors renvoyé comme réponse. L’inconvénient de cette technologie est qu’à chaque appel du CGI, le programme externe doit être rechargé ce qui représente une perte de temps non-négligeable. Les limitations des CGIs ont ensuite été palliées en utilisant des extensions propres à chaque serveur web. On parle de NSAPI (pour les serveurs Netscape), de modules d’extension pour le serveur Apache Apache), et d’ISAPI (pour Microsoft Internet Information Server). L’inconvénient de ces techniques est qu’elles sont spécifiques à chaque serveur et donc non-portables.

Technologies web spécifiques à J2EE (1/2) Les technologies web utilisées sur un serveur J2EE sont portables, sécurisées et standardisées. Une application web est un assemblage de composants de serveurs web, de contenu et d’informations de configuration. L’environnement d’exécution d’une application web est appelé le conteneur web (web container). Tous les fichiers d’une application web sont contenus un fichier Web Application Archive (WAR) qui contient également un fichier de description de dépliement rédigé en XML. Les spécifications de la plate-forme J2EE définissent un contrat entre le conteneur web et les composants web, qui définit le cycle de vie des composants, les comportements que le composant implémente et les services que le serveur rend aux composants.

Technologies web spécifiques à J2EE (2/2) Les spécifications J2EE définissent 2 types de composants web : les Servlets Java (“servlets”) et les JavaServer Pages (pages JSP) Une servlet est une classe Java qui étend un serveur J2EE, produisant du contenu dynamique en réponse aux requêtes du serveur. Le serveur transmet les requêtes de services à la servlet via l’interface standard javax.servlet, que chaque servlet doit implémenter. Une page JSP est une page HTML qui comporte des balises spéciales qui produisent du contenu dynamique personnalisé en fonction de la requête. Les pages JSP sont habituellement transformées en servlets lors du déploiement. La technologie JSP permet d’avoir une approche centrée sur le document (document centric) plutôt que sur la programmation lors de la conception d’une application.

Le conteneur web Une application J2EE est exécutée à l’intérieur d’un conteneur web. Le conteneur web gère le cycle de vie des composants web et distribue les requêtes aux composants. Il fournit aussi des interfaces standards pour accéder au contexte, notamment aux informations de session et aux informations sur la requête courante. Le conteneur web fournit une interface consistante aux composants, indépendamment du serveur web, c’est ce qui permet de porter et déployer un composant sur différents serveurs web Java sans modification du code.

Servlets Java (1/2) Les servlets Java sont des classes qui étendent les serveurs web compatibles J2EE. Une servlet produit du contenu dynamique en réponse aux requêtes portant sur une ou plusieurs URLs. Les servlets sont des classes Java compilées portables tant au niveau du code source (car elles respectent les spécifications sur les Servlets Java) qu’au niveau binaire (car elles sont compilées en byte-code Java, par définition portable d’une plate-forme à l’autre sans modification). En plus de produire du contenu dynamiquement, les servlets supportent plusieurs fonctionnalités applicatives.

Servlets Java (2/2) On peut ainsi déclencher des servlets en fonction d’évènements, en implémentant l’interface listener, ou déclencher un ou plusieurs servlets filters, des classes chargées de pré- ou post- traiter la requête ou la réponse d’une servlet lors de l’appel à sa méthode service. Les servlets peuvent aussi être distribuables, le serveur web peut alors supporter des mécanismes d’équilibrage de charge et transmettre les informations de sessions entre les différents nœuds d’un cluster ; pour cela les servlets doivent être marquées comme distributable dans le descripteur de déploiement de l’application web et respecter des contraintes propres aux servlets distribuables. Ces contraintes assurent que le code de la servlet continue à fonctionner correctement lors du déplacement d’un nœud de cluster à l’autre.

JavaServer Pages (JSP) (1/2) Les JSP sont la technologie la plus appropriée pour les applications web qui produisent des pages HTML dynamiquement en modifiant uniquement les champs de données et pas la structure de base de la page. Une page JSP contient un modèle de document statique et des balises spécifiques pour inclure du texte ou exécuter une partie de la logique applicative. Le contenu statique est servi comme du HTML normal. Les balises JSP sont de 3 types: des directives: ce sont des instructions qui contrôlent le comportement du compilateur de pages JSP, et qui sont donc évaluées avant la compilation, des éléments de scripts: ce sont des blocs d’instructions Java inclus dans la page JSP entre des délimiteurs <% et %>. des balises personnalisées (custom tags ou custom actions): elles sont définies par le programmeur et génèrent du contenu dynamique lorsque la page est demandée.

JavaServer Pages (JSP) (2/2) Les spécifications JSP définissent un jeu de balises standards implémentées par toutes les implémentations de serveurs web Java. Les balises personnalisées et les éléments de script génèrent du contenu dynamique inclus dans la page lorsqu’elle est demandée. Les pages JSP peuvent générer n’importe quel type de contenu textuel ,mais sont à l’origine prévues pour générer du contenu structuré tel que du HTML, XML, XHTML,…. Les pages JSP sont plus faciles à écrire que les servlets car elles ressemblent à des documents structurés classiques et sont manipulable dans des environnements d’édition web classiques (Macromedia Dreamweaver MX par exemple). En général les pages JSP sont compilées en servlets lors du déploiement.

Syntaxe XML pour les JSP Les spécifications JSP définissent une syntaxe XML alternative pour les pages JSP. Les pages en syntaxe JSP standard ne sont en effet pas conformes à XML. Les pages JSP écrites en syntaxe XML peuvent être validées avec un schéma XML pour vérifier les erreurs les plus fréquentes. Ce type de syntaxe peut aussi faciliter l'intégration avec les outils de développement. Un fichier JSP ne peut pas mélanger les 2 types de syntaxe. Ecrire les pages JSP en XML n'est pas la même chose que de générer du XML à partir de pages JSP. La syntaxe XML pour JSP n'est qu'une manière différente d'écrire une page JSP, le contenu généré par une page JSP en XML est en tout point identique à celui d'une page JSP traditionnelle équivalente.

Balises personnalisées (1/2) La technologie JSP permet au programmeur de définir leurs propres bibliothèques de balises, ce type de balises est remplacé par du contenu dynamique lorsque la page est envoyée au client. Le contenu dynamique est crée par un gestionnaire de balises, que le programmeur crée et distribue dans un fichier archive de bibliothèque de balises. Le programmeur définit la syntaxe pour chaque balises et implémente le comportement à effectuer pour chaque balise dans la classe de gestion des balises (tag handler class). Les auteurs de pages peuvent ensuite importer et utiliser les balises définies dans les bibliothèques de balises comme s'ils utilisaient des balises traditionnelles.

Balises personnalisées (2/2) Les balises personnalisées procurent plusieurs avantages dans la conception d'une application J2EE : les balises personnalisées sont réutilisables alors que les éléments de script ne le sont pas en général les bibliothèques de balises personnalisées permettent de définir des services de haut niveau portables entre conteneur de JSP les balises personnalisées facilitent la maintenance d'une application, en évitant de répéter du code de pages en pages. Il suffit de modifier en un endroit le comportement d'une balise pour que toutes les pages contenant la balise soient modifiées les balises personnalisées permettent aux développeurs de se focaliser sur leur métier de base. Les auteurs de page peuvent utiliser des balises standards et personnalisées plutôt que d'avoir à jongler avec des balises et des éléments de scripts qui leurs sont étrangers. les balises personnalisées offrent aux auteurs de pages un moyen simple d'utiliser la logique métier dans leurs pages les balises personnalisées permettent une séparation plus claire entre présentation des données et logique métier, ce qui simplifie la maintenance, montre plus clairement l'utilité de chaque composant et permet aux programmeurs et auteurs de pages de travailler plus indépendamment.

Bibliothèques de balises standard (standard tag libraries) Les bibliothèques de balises standard sont des jeux de balises qui fournissent un jeu de fonctionnalités basiques pour les pages JSP. Les balises standards fournissent typiquement des fonctions de : inclusion de ressources web, chaînage de requête (request forwarding), logique conditionnelle, itérations sur des collections d'objets, transformations XSLT, internationalisation, gestion des informations d'état, formulaires HTML. Certaines compagnies ont produit leurs propres bibliothèques de balises profondément intégrées dans leurs outils de développement et J2EE. D'autres organisations produisent des bibliothèques de balises génériques pour les applications J2EE. C'est le cas par exemple de l'Apache Taglibs, qui est une bibliothèque Open source contenant des douzaines de balises personnalisées.

Java Standard Tag Library (JSTL) La Java Standard Tag Library (JSTL) fait maintenant partie du Java Community Process (sous la référence JSR-52, A Standard Tag Library for JavaServer Pages). Après sa standardisation, JSTL fournira une riche couche de fonctionnalités de haut niveau et portables pour tous les conteneurs web compatibles JSP. Les librairies standard fournissent souvent la plupart des fonctionnalités requises pour le développement de pages JSP et sont testées et optimisées par la communauté des développeurs. Utiliser une librairie de balises standard de haute qualité permet ainsi de gagner un précieux temps en développement.

Règles de conception des composants web

Quand utiliser des servlets ? Les servlets sont la plupart du temps utilisées pour implémenter la logique de l'application et générer des données binaires. Utiliser les servlets pour implémenter des services : les servlets ne sont habituellement pas des composants visuels, à l'exception de certaines qui génèrent du contenu binaire. En fait les servlets sont surtout utilisées comme un service d'accès aux informations de l'application. Une servlet peut ainsi rendre n'importe quel service (application de modèles, sécurité, personnalisation, contrôle de l'application) et ensuite choisir un composant de présentation (souvent une page JSP) pour lui transmettre la requête et s'occuper de sa présentation. Comme une servlet peut être assimilée à un service, un filtre de servlet peut être assimilé à une extension ou une personnalisation du service fournit par la servlet.

Utilisation de servlets comme contrôleurs Les servlets sont la technologie de prédilection pour implémenter un contrôleur sur le tiers web, qui déterminera comment traiter une requête et choisira la prochaine vue à afficher. Un contrôleur active les opérations d'une application et prend des décisions, qui sont essentiellement des tâches procédurales bien adaptées à l'intégration dans le code d'une servlet. Les pages JSP ne doivent pas être utilisées comme contrôleur car si l'on mélange les balises et le code du programme, elles deviennent difficiles à lire et à maintenir, particulièrement pour les concepteurs web, qui ne sont pas des programmeurs.

Exemple de Servlet contrôleur public class extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse res)throws...{ String creditCard = req.getParameter("creditCard"); String jspPage ="/process"+creditCard +".jsp"; ServletContext sc =getServletContext(); RequestDispatcher rd =getRequestDispatcher(jspPage); rd.forward(req,res); }

Utiliser des servlets pour générer du contenu binaire Le contenu binaire doit être généré par des servlets. Les servlets qui génèrent ce type de contenu doivent définir l'entête HTTP Content-Type pour préciser le type MIME du contenu généré. Une servlet peut écrire soit sur un objet OutputStream soit sur un objet PrintWriter , mais pas les deux. Une JSP ne peut pas créer du contenu binaire. Une servlet écrit ses données binaires dans un objet OutputStream récupéré à partir de l'objet ServletRequest , comme montré dams l'exemple de code suivant.

Exemple de servlet génératrice de contenu binaire public class JpgWriterServlet extends HttpServlet { public void service(HttpServletRequest req, HttpServletResponse rsp)throws...{ rsp.setHeader("Content-type","image/jpg"); OutputStream os =rsp.getOutputStream(); //...now write binary data to the OutputStream... }

Eviter les servlets qui génèrent du texte statique Les servlets composées principalement d'instructions println sont de préférence implémentées sous forme de pages JSP. Il faut utiliser des pages JSP pour créer du contenu textuel et le combiner avec un modèle et des valeurs obtenues dynamiquement. Il est en effet beaucoup plus aisé de maintenir une JSP qu'une servlet pour ce genre de tâches.

Exemple de Servlet utilisée à mauvais escient pour générer du texte public class PopulateServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res)throws ...{ ... if (dbConnectionClosed){ PrintWriter out =response.getWriter(); out.println("<html>"); out.println("<body bgcolor=white>"); out.println("<font size=\"+5 \"color=\"red \">Can't connect</font>"); out.println("<br>Confirm your database is running"); out.println("</body></html>"); }

Exemple de Servlet utilisée à mauvais escient pour générer du texte La bonne technique est de détecter l'erreur dans la servlet et de rediriger la requête vers une page JSP si c'est le cas. Ce principe permet de maintenir une bonne séparation entre les fonctions et la présentation. PopulateServlet.java: public class PopulateServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse res)throws ...{ ... if (dbConnectionClosed){ ServletContext ctx =getServletContext(); ctx.getRequestDispatcher("/db_failed.jsp").forward(req,res); } db_failed.jsp: <html> <body> <br><font color="red">Unable to Connect</font> <br>Confirm that your database is running </body>

Utiliser les redirections et inclusions à bon escient Une servlet peut utiliser deux méthodes de l'objet RequestDispatcher, forward et include, pour créer une réponse en faisant appel à d'autres composants. Ces deux méthodes sont conçues avec des intentions fondamentalement différentes : RequestDispatcher.forward() délégue totalement le traitement d'une requête à un autre composant. Dans ce cas il faut veiller à ce que le corps de la servlet soit vide sinon une exception est générée, RequestDispatcher.include() construit une réponse contenant les résultats à partir de plusieurs ressources web

Où utiliser les JSP ? Les pages JSP sont habituellement utilisées pour créer du contenu structuré ou des données textuelles non-structurées. Elles sont particulièrement adaptées lorsque la valeur des données change entre les requêtes mais que leur structuration ne change pas (ou peu).

Utiliser les JSP pour la présentation des données Les pages JSP sont particulièrement appropriées pour produire du contenu structuré. Les vues pour visualiser les données d'une application d'entreprise sont traditionnellement en HTML, XHTML et DHTML. Les pages JSP sont utilisées lorsque le contenu est partiellement statique, avec quelques éléments remplis dynamiquement à l'exécution. Une page JSP contient une partie fixe appelée "template data" (à ne pas confondre avec les mécanismes de modèles décrits par la suite). Les balises personnalisées ou les éléments de script sont peuvent être placés à divers endroits des données statiques et sont substitués à l'exécution par du contenu dynamique. Les pages JSP ne peuvent pas produire de contenu binaire et ne sont pas très adaptées à la production de contenu à grande variabilité ou à la direction de requêtes, on préférera utiliser des servlets dans ce cas. Les pages JSP peuvent accéder facilement à la logique métier d'une application, en incluant des beans par exemple.

Utiliser les JSP pour générer du XML Les pages JSP sont une bonne technologie pour générer du XML avec une structure fixe. Elles sont particulièrement adaptées pour générer des messages XML dans des formats standards, où les balises sont fixes et où seules les valeurs d'attribut ou les données brutes varient entre les appels à la page. Les documents XML peuvent aussi être générés à partir de modèles, en agrégeant par exemple plusieurs documents XML pour constituer un seul document composite.

Utiliser les JSP pour générer du texte non-structuré Il est tout à fait possible de générer du texte brut (ASCII, Postscript) à partir d'une JSP. Par exemple une JSP peut générer les mails à envoyer aux clients d'une application.

Utiliser les JSP comme modèles (templates) Les JSP peuvent aussi être utilisées pour agréger du contenu provenant de plusieurs sources, comme cela est expliqué par la suite.

Encodage des pages JSP Les JSPs utilisent la classe javax.servlet.jsp.JSPWriter pour écrire le contenu sur le flux de sortie (la réponse envoyée au client). Cette classe s' assure que le contenu envoyé au client est correctement encodé, mais cela à un impact : l'encodage automatique du texte empêche de produire du contenu bianire à partir d'une JSP.

Eviter d'utiliser trop de balises logiques Les bibliothèques de balises standard fournissent des balises dites “logic tags” qui permettent de faire des boucles, des itérations, d'évaluer des expressions et de prendre des décisions conditionnelles. Il faut éviter ce genre de balises qui finalement apportent peu de bénéfices car elles entraînent une séparation moins claire entre la présentation et la logique de l'application. A la place, il vaut mieux implémenter la logique dans une balise personnalisée qui fait appel à un entreprise beans. Ainsi une fine couche de code (le gestionnaire de balises ou tag handler) lie la balise personnalisée à un beans et utilise ses méthodes. Cette approche permet de lier la vue (page JSP ou servlet) à un accès direct au modèle de données (contenu dans le beans), permettant ainsi de conserver la logique et la présentation séparées.

Utiliser les directives d'inclusion et les balises d'inclusion JSP à bon escient La directive include des JSP et la balise jsp:include ont la même syntaxe mais des buts différents. Une directive d'inclusion incluse le texte littéralement dans la page et ne permet pas de traiter du contenu dynamique. L'inclusion a lieu lorsque la page JSP est compilée. Par exemple l'instruction suivante inclut une page dans la JSP lors de la compilation : <%@include file="header.jsp"@%> La balise JSP include inclut du contenu dynamique ou statique à chaque fois que la page est servie et permet donc d'inclure du contenu dynamique à l'exécution (à chaque fois que la page est servie).

Exemple <jsp:include page="/servlets/currentUserInfoServlet"/> La directive JSP d'inclusion sert plutôt pour réutiliser du contenu et rendre modulaire ses pages web, tout en réduisant leur taille. Il faut prendre en compte que le fait que le fichier est inclus à la compilation et donc la servlet résultante est plus grosse qu'une servlet qui inclut les pages à l'exécution (mais cette dernière solution réclame plus de temps). A chaque fois qu'une page JSP est demandée dans le cas d'un inclusion par la balise JSP include, les pages liées ont recompilées. De plus les composants utilisés (par exemple des JavaBeans ou d'autres objets fournis par le conteneur) doivent être re-déclarés dans chacune des pages inclues et partagés entre les pages via l'utilisation de l'objet HttpSession. Les directives d'inclusion peuvent être problématiques pour supporter l'internationalisation. Ainsi le header HTTP contentType:charset des pages inclues ne peut être assigné différemment dans les pages inclues et la page qui inclut. (le contentType de cette page l'emporte) Note d'implémentation: certains conteneurs web comme Tomcat ne prennent pas automatiquement en compte les modifications faites aux fichiers inclus par la directive include. Si vous changez un fichier inclus, il faut "toucher" (modifier la date de dernière modification) les documents parents qui incluent le fichier.

Utiliser des balises personnalisées pour éviter les éléments de script Il est préférable d'utiliser des balises personnalisées plutôt que des éléments de script (scriptlets) pour les raisons suivantes : le code scriplet n'est pas réutilisable le code scriptlet mélange logique et présentation de l'application dans la même page le code scriptlet ne permet pas de bien séparer les rôles entre les développeurs de pages web et de code Java Un concepteur web aura par exemple du mal à modifier du code Java pour lui appliquer une présentation : <%out.println("<a \"href=\""+url +"\">"+text);%></a> le code scriptlet est plus difficile à lire et à maintenir que des balises personnalisées Les informations de débogage d'une scriptlet peuvent être difficiles à interpréter, en définissant du code associé à une balise personnalisée on peut localiser plus facilement l'erreur Le code de scriptlet est plus difficile à tester, avec des balises personnalisées, on dispose de composants personnalisés prêt à subir des tests unitaires Éviter de rediriger des requêtes à partir de pages JSP Quand une page JSP appelle RequestDispatcher.forward elle se comporte comme un contrôleur. Les contrôleurs sont de préférence implémentés dans des servlets, pas dans des composants de présentation.

Mauvais exemple de JSP se comportant comme un contrôleur <%String creditCard =request.getParameter("creditCard"); if (creditCard.equals("Visa")){%> <jsp:forward page="/processVisa.jsp"/> <%}else if (creditCard.equals("American Express")){%> <jsp:forward page="/processAmex.jsp"/> <%}%>

Résumé (1/3) Le serveur web d’une application J2EE rend disponible les applications sur le World Wide Web. Les pages JSPs et les servlets sont des composants web qui succèdent aux anciennes technologies côté serveur telles que les CGIs et qui assurent une portabilité inégalée. Le conteneur web fournit des services de haut niveau aux composants web en matière de transactions,accès aux données, gestion des états, sécurité et distribution. L’utilisation de bibliothèques de balises personnalisées améliore la qualité du code source et facilite la maintenance des applications. Le patron de conception Modèle-Vue-Contrôleur est recommandé pour la plupart des applications web interactives car il permet de créer des applications réutilisables, et d’ajouter de nouveaux types de clients, processus et vues facilement.

Résumé (2/3) Le serveur web d’une application est une couche de service neutre, habituellement conçu sur le modèle MVC, qui simplifie la création d’applications web interactives. Le modèle de conception le plus simple a un seul contrôleur qui reçoit les requêtes des navigateurs, les distribue dans l’application et affiche les résultats. Il est possible d’utiliser plusieurs contrôleurs web pour gérer nativement des clients web utilisant des protocoles différents. Un mécanisme de modèles (templates) permet d’améliorer la mise en page des écrans de l’application. Le mécanisme de modèle permet d’utiliser un fichier modèle pour assembler des vues individuelles en une vue composée sur l’application. Les servlets sont principalement utilisées pour générer des données binaires et contrôler l’application. Les pages JSP sont principalement utilisées pour créer du contenu textuel et des références à des données externes. Les filtres de servlets peuvent être utilisés pour étendre les fonctionnalités d’une servlet existante, d’un JSP ou d’un autre filtre de servlet.

Résumé (3/3) Les états d’une application web ont 4 types de portées : portée application, portée session, portée requête et portée page. Les états de portée session ont le plus d’impact sur la charge engendrée par une application web car ils sont proportionnels au nombre d’utilisateurs. Il est recommandé d’utiliser des beans de session avec états pour conserver les données de session. Les applications uniquement web peuvent stocker les informations de session dans les attributs de session HTTP. Certains produits J2EE permettent à une application d’être distribuée pour augmenter sa disponibilité et sa scalabilité mais cette possibilité n’est pas encore standardisée. Les servlets, JSP et balises personnalisées d’une application web distribuable doivent respecter des contraintes supplémentaires.