Etude de J2EE et du Web-tier
publicité
Architecture J2EE Etude du Web-tier Composants Web Servlets / JSP et JavaBeans Patrick Itey ([email protected]) - INRIA PLAN - Rappels Rappels sur les architectures distribuées: – les serveurs d'application – la programmation par composants – composant / conteneur / structure accueil Rappels sur l'architecture J2EE : – Principes – Les composants utilisés – Topologies d'une application J2EE – Technologies utilisées 07/11/2002 © P. Itey - INRIA 2 Rappels : Architectures distribuées Ce sont des applications dont les fonctions sont réparties entre plusieurs systèmes. On les appelle aussi architectures multi-tiers. Dans une architecture distribuée type, les fonctions sont réparties entre un système client (station de travail, terminal,…) et un système serveur (serveur PC, Unix, mainframe…). 07/11/2002 © P. Itey - INRIA 3 Rappels : architectures distribuées Chaque système contient une partie de l’application, les parties manquantes sont exécutées sur les autres systèmes participants à l’application et les informations sont échangées par le réseau © P. Itey - INRIA 07/11/2002 4 Rappels : architectures distribuées 3 catégories : – 1- fonctions de présentation • interface utilisateur… – 2- fonctions applicatives / orientées métier : • validation des données • modélisation des processus métiers (prise de commande,…) – 3- fonctions de stockage 07/11/2002 © P. Itey - INRIA 5 Rappels : fonction de présentation sur la couche présentation, une application cliente est chargée de l’affichage et de la saisie des données : – – – – browsers web (http/HTML), applets (RMI), contrôles ActiveX (DCOM), clients CORBA (IIOP) 07/11/2002 © P. Itey - INRIA 6 Rappels : fonction applicative sur la couche application, un serveur d’application maintient des composants métiers utilisés pour modéliser sous forme d’objet les processus de l’application (ex: factures, caddies,…) : – – – – présentation, outils métiers, CGI, servlets… 07/11/2002 © P. Itey - INRIA 7 Rappels : fonction de stockage sur la couche données, les serveurs du système d’information d’entreprise stockent les composants métiers : – – – – bases de données relationnelles ou objets, intégrés (ERP), legacy (mainframe), annuaires d’entreprise,… 07/11/2002 © P. Itey - INRIA 8 Motivation pour les serveurs d'application Simplifier le développement Plus grande séparation entre les 3 couches Le développeur peut se concentrer sur la logique de son application; le reste est pris en charge par la structure d'accueil : – sessions, persistance, transactions, sécurité, nommage, charge 07/11/2002 © P. Itey - INRIA 9 Motivation pour les serveurs d'application (suite) Gain en productivité : – Fournir des services standards pour : • le développement d'application multi-tiers • le support de plusieurs types de client – Mise sur le marché des applications distribuées plus rapidement 07/11/2002 © P. Itey - INRIA 10 Motivation pour les serveurs d'application (suite) Intégration avec l’existant : – mettre à la disposition des développeurs des moyens standards d'accès aux données des systèmes déjà existants dans l’entreprise. 07/11/2002 © P. Itey - INRIA 11 Motivation pour les serveurs d'application (suite) Maintenance et sécurité : – mettre en place des mécanismes standards pour gérer la sécurité sur tous les systèmes d’une application distribuée – mais peu de possibilités pour mettre en place la sécurité au niveau du client, sauf dans le cas de clients Java. 07/11/2002 © P. Itey - INRIA 12 Motivation pour les serveurs d'application (suite) Liberté de choix : – grande diversité de serveurs J2EE commerciaux ou libres – mécanismes et technologies standards pour la création d'application : cela permet d'utiliser des produits d'éditeurs différents • environnements de développement et serveurs J2EE issus de plusieurs éditeurs. • utilisation de ses propres composants pour les fonctions spécifiques de l'application et de crées par des éditeurs de logiciels pour les fonctions de base. 07/11/2002 © P. Itey - INRIA 13 Motivation pour les serveurs d'application (suite) Réponse adaptée à la demande : – les applications supportent la montée en charge sans avoir à être recodées (dans les specs ;-) ) – mécanismes simples pour répartir la charge entre plusieurs serveurs, sur les différentes couches de l'application 07/11/2002 © P. Itey - INRIA 14 Programmation par composants Les limites de la programmation traditionnelle – plus adaptée à la programmation de “petits projets” (programming in the small) – tout est à la charge du programmeur : • la liaison entre les différentes couches de l’application (présentation, application, données), • construction de objets utilisées sur les couches, la définition des fonctions… 07/11/2002 © P. Itey - INRIA 15 Programmation par composants – la structure de l’application est peu visible et particulière à chaque application (fichiers…) – l’évolution de l’application est difficile : ajout de fonctionnalités, modification des conditions d’installation… – le développement, la génération des exécutables et leur déploiement ne sont pas standardisés 07/11/2002 © P. Itey - INRIA 16 Programmation par composants Programmation par composition (ou constructive) : – motivée par la réutilisation des logiciels déjà existants et propose de créer des applications réparties par assemblage de composants logiciels existants. – concept du “programming in the large” où l’on définit des composants génériques qui sont ensuite réutilisables dans plusieurs applications. 07/11/2002 © P. Itey - INRIA 17 Programmation par composants Dans cette approche on décrit l’architecture de l’application à l’aide d’un langage déclaratif qui permet de préciser : – le modèle de construction des composants: – interfaces – attributs – implémentation – la description des interactions entre composants (connecteurs) – la description de variables d’environnement (placement, sécurité…) 07/11/2002 © P. Itey - INRIA 18 Architecture à base de composants 07/11/2002 © P. Itey - INRIA 19 Composants Un composant est un module logiciel autonome, configurable et installable sur plusieurs plates-formes Un composant : – exporte des attributs, propriétés et méthodes, – peut être configurable, – est capable de s’auto-décrire (introspection) 07/11/2002 © P. Itey - INRIA 20 Composants Les composants sont les briques de bases configurables d’une application par composition. Parmi les différentes technologies de composants, on peut citer : – COM/DCOM, – JavaBeans, – Enterprise Java Beans, – composants CORBA 07/11/2002 © P. Itey - INRIA 21 Conteneur Un conteneur encapsule les composants et prend en charge les services liés au système : – nommage, – sécurité, – transaction, – persistance, …. 07/11/2002 © P. Itey - INRIA 22 Structures d'accueil – Espaces d’exécution des conteneurs et des composants – Servent de médiateur entre les conteneurs et les services systèmes (sandbox). – Peuvent prendre en charge le téléchargement de code additionnel (navigateur Web…). – La Java Virtual Machine est la structure d’accueil d’une application J2EE. 07/11/2002 © P. Itey - INRIA 23 PLAN - Rappels Rappels sur les architectures distribuées: – les serveurs d'application – la programmation par composants – composant / conteneur / structure accueil Rappels sur l'architecture J2EE : – Principes – Les composants utilisés – Topologies d'une application J2EE – Technologies utilisées 07/11/2002 © P. Itey - INRIA 24 Principes de J2EE L’architecture J2EE est une architecture d’application distribuée à base de composants Elle identifie et donne les spécifications des composants de l’application : – composants logiciels ou beans (EJB), – conteneur – serveurs – clients 07/11/2002 © P. Itey - INRIA 25 Principes de J2EE (suite) 07/11/2002 © P. Itey - INRIA 26 Principes de J2EE (suite) Les conteneurs isolent les beans du client et d’une implémentation spécifique du serveur. Les beans sont installés dans la partie serveur d’une application J2EE. 07/11/2002 © P. Itey - INRIA 27 Principes de J2EE (suite) Les conteneurs et serveurs implémentent les mécanismes de bas niveau utilisés par les applications : – transactions, – persistance, – gestion de la mémoire, – sécurité 07/11/2002 © P. Itey - INRIA 28 Principes de J2EE (suite) Les spécifications J2EE s’intéressent aux activités d’une application liées : – au développement, – au déploiement, – à l’exécution 07/11/2002 © P. Itey - INRIA 29 Composant J2EE C'est une unité logicielle de niveau applicatif. En plus des JavaBeans, qui font partie du J2SE, J2EE supporte les types de composants suivants : – applets & application clientes, – composants Enterprise JavaBeans (EJB), – composants Web, 07/11/2002 © P. Itey - INRIA 30 Composant J2EE (suite) Les applets et applications clientes sont exécutées sur le poste du client Les composants EJB, Web fonctionnent sur le serveur Les concepteurs et développeurs d'applications développent les composants d'une application J2EE. 07/11/2002 © P. Itey - INRIA 31 Conteneur de composants J2EE Tous les composants J2EE dépendent à l'exécution d'une entité système baptisée conteneur (container). Les conteneurs fournissent aux composants des services de bases comme : – la gestion du cycle de vie, – la sécurité, – le déploiement et l'exécution en thread. 07/11/2002 © P. Itey - INRIA 32 Conteneur de composants J2EE Comme c'est le conteneur qui gère ces services, la plupart des paramètres de configuration de ces services peuvent être configurés lors du déploiement des composants en fonction de la plate-forme d'accueil : – Par exemple un fournisseur d'Enterprise Java Bean peut spécifier un nom de base de données auquel le composant doit accéder et c'est seulement lors du déploiement que les informations d'accès à la base (nom d'utilisateur et mot de passe ) seront configurées. 07/11/2002 © P. Itey - INRIA 33 Composants clients J2EE La plate-forme J2EE prévoit plusieurs types de clients pour accéder à une même application et interagir avec les composants côté serveur : – les Applets, – les applications autonomes 07/11/2002 © P. Itey - INRIA 34 Rappel : les applets Ce sont des clients Java qui s'exécutent dans un navigateur Web et qui ont accès à toutes les possibilités du langage Java. Les applications J2EE les utilisent pour avoir des interfaces utilisateurs plus puissantes que celles connues en HTML. Les applets communiquent avec le serveur par HTTP. 07/11/2002 © P. Itey - INRIA 35 Rappel : applications autonomes S'exécutent dans leur propre conteneur client. Le conteneur client est un jeu de librairies et d'API qui supportent le code client, et mettent à sa disposition un moyen d'accéder aux composants métiers de l'application. Les applications clientes ont des interfaces utilisateurs qui peuvent directement interagir avec le tier EJB en utilisant RMI-IIOP. 07/11/2002 © P. Itey - INRIA 36 Rappel : applications autonomes Les clients ont un accès complet aux services de la plate-forme J2EE comme : – les services de nommage JNDI, – l'envoi de messages – et JDBC. Le conteneur client gère l'accès à ces services et les communications RMI-IIOP. 07/11/2002 © P. Itey - INRIA 37 Appli clientes Java Web Start Ce sont des applications autonomes reposant sur les JFC et Swing et capables d'utiliser les services de la plate-forme J2EE par l'intermédiaire de la technologie Java WebStart. Elles peuvent être installées par le web, Elles communiquent avec le serveur en utilisant du XML encapsulé dans du HTTP(S). 07/11/2002 © P. Itey - INRIA 38 Clients sans fil Les clients sans fil sont basés sur la technologie Mobile Information Device Profile (MIDP), en conjonction avec Connected Limited Device Configuration (CLDC) qui fournissent un environnement J2ME complet pour les dispositifs sans fil. 07/11/2002 © P. Itey - INRIA 39 Les composants Web Un composant Web est une entité logicielle qui fournit une réponse à une requête. Les composants Web génèrent habituellement l'interface utilisateur d'une application Web. La plate-forme J2EE définit 2 types de composants Web : – les servlets et – les JavaServer Pages (JSP). 07/11/2002 © P. Itey - INRIA 40 Les Servlets Une servlet est un composant qui étend les fonctionnalités d'un serveur Web de manière portable et efficace. Un serveur Web héberge des classes Java servlets qui sont exécutées à l'intérieur du container Web. Le serveur Web associe une ou plusieurs URLs à chaque servlet et lorsque ces URLs sont appelées via une requête HTTP de l'utilisateur, la servlet est déclenchée. 07/11/2002 © P. Itey - INRIA 41 Les Servlets (suite) Quand la servlet reçoit une requête du client, elle génère une réponse, éventuellement en utilisant la logique métier contenue dans des EJBs ou en interrogeant directement une base de données. Elle retourne alors une réponse HTML ou XML au demandeur. 07/11/2002 © P. Itey - INRIA 42 Les JSP (Java Server Pages) La technologie Java Server Pages (JSP) fournit un moyen simple et extensible pour générer du contenu dynamique pour le client Web. Une page JSP est un document texte qui décrit comment traiter la requête d'un client et comment créer une réponse. 07/11/2002 © P. Itey - INRIA 43 Les JSP (suite) Une page JSP contient : – Des informations de formatage (modèle) du document Web, habituellement en HTML ou XML. • Les concepteurs Web peuvent modifier cette partie de la page sans affecter les parties dynamiques. Cette approche permet de séparer la présentation du contenu dynamique. 07/11/2002 © P. Itey - INRIA 44 Les JSP (suite) Une page JSP contient (suite) : – Des éléments JSP et de script pour générer le contenu dynamique du document Web. • La plupart des pages JSP utilisent aussi des JavaBeans et/ou des Enterprise JavaBeans pour réaliser les opérations complexes de l'application. Les JSP permettent en standard d'instancier des beans, de modifier ou lire leurs attributs et de télécharger des applets. 07/11/2002 © P. Itey - INRIA 45 Les JSP (suite) La technologie JSP est extensible en utilisant des balises personnalisées qui peuvent être encapsulées dans des bibliothèques de balises personnalisées (taglibs) 07/11/2002 © P. Itey - INRIA 46 Conteneurs de composants Web Les composants Web sont hébergés dans des conteneurs de servlets, conteneurs de JSP et conteneurs Web. En sus des fonctionnalités normales d'un conteneur de composants, un conteneur de servlets (servlets container) fournit les services réseaux par lesquels les requêtes et réponses sont émises. Il décode également les requêtes et formate les réponses dans le format approprié. 07/11/2002 © P. Itey - INRIA 47 Conteneurs de composants Web Tous les conteneurs de servlets doivent supporter le protocole HTTP et peuvent aussi supporter le protocole HTTPS. Un conteneur de JSP (JSP container) fournit les mêmes services qu'un conteneur de servlets. Ces conteneurs sont généralement appelés conteneurs Web (Web containers). 07/11/2002 © P. Itey - INRIA 48 Topologies d'une application J2EE 07/11/2002 © P. Itey - INRIA 49 Application multitiers 07/11/2002 © P. Itey - INRIA 50 Client autonome 07/11/2002 © P. Itey - INRIA 51 Client autonome "EJB-centric" 07/11/2002 © P. Itey - INRIA 52 Application Web 07/11/2002 © P. Itey - INRIA 53 Détails de l'application Web 07/11/2002 © P. Itey - INRIA 54 Application Business-to-business 07/11/2002 © P. Itey - INRIA 55 Technologies J2EE La plate-forme J2EE, comme la plate-forme J2SE, inclue un grand nombre de bibliothèques de code (API) prédéfinies pour les fonctions de base d'une application. 07/11/2002 © P. Itey - INRIA 56 Technologies J2EE (suite) 07/11/2002 © P. Itey - INRIA 57 Technologies J2EE (suite) Les technologies mises en œuvre : – L'architecture J2EE Connector est l'infrastructure pour interagir avec une grande variété de systèmes d'information d'entreprise tels que des ERPs, des CRM, et autres progiciels. – L'API JDBC est utilisée pour accéder à des données relationnelles à partir de programmes Java 07/11/2002 © P. Itey - INRIA 58 Technologies J2EE (suite) Les technologies mises en œuvre (suite) : – La Java Transaction API (JTA) est utilisée pour gérer et coordonner les transactions entre un ensemble hétérogène de systèmes d'information d'entreprise. – L'API Java Naming and Directory Interface (JNDI) est utilisée pour accéder aux services de nommage et d'annuaire de l'entreprise. 07/11/2002 © P. Itey - INRIA 59 Technologies J2EE (suite) Les technologies mises en œuvre (suite) : – L'API Java Message Service (JMS) est utilisée pour émettre et recevoir des messages via les systèmes de messagerie d'entreprise comme IBM MQ Series ou TIBCO Rendezvous. Dans l'architecture J2EE, les Message Driven Beans fournissent une approche à base de composant pour encapsuler les fonctionnalités de messagerie. 07/11/2002 © P. Itey - INRIA 60 Technologies J2EE (suite) Les technologies mises en œuvre (suite) : – La JavaMail API est utilisée pour émettre et recevoir des mails. – Java IDL est utilisée pour appeler des services CORBA – L'API Java pour XML (JAXP) est utilisée pour l'intégration avec les systèmes et applications existants et pour implémenter les Web services dans la plate-forme J2EE. 07/11/2002 © P. Itey - INRIA 61 JNDI Java Naming and Directory Interface La technologie JNDI est utilisée dans J2EE pour localiser les objets sur un serveur et accéder aux objets externes à partir des composants J2EE. Chaque conteneur stocke une référence aux objets qu’il peut créer et instancie ces objets à la demande des clients ou des applications qui fonctionnent sur le serveur. 07/11/2002 © P. Itey - INRIA 62 JNDI (suite) Le conteneur met aussi à la disposition des composants un jeu de ressources JNDI initial, issu de la configuration du serveur et/ou des applications Web (via les descripteurs de déploiement). Un objet InitialContext est crée par le conteneur lorsqu'une Web application est déployée. 07/11/2002 © P. Itey - INRIA 63 JNDI (suite) Cet objet est accessible par les composants, en lecture seulement. L'API JNDI est définie dans le package javax.naming. L'autre rôle de JNDI dans une application J2EE est la localisation des interfaces distantes des beans. 07/11/2002 © P. Itey - INRIA 64 Exemple d'utilisation de JNDI // // // // // Dans Tomcat, les ressources JDNI initiales sont accessibles dans l'espace de nommage java:comp/env. Exemple d'accès à une ressource JDBC par JNDI : Obtain our environment naming context Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup("java:comp/env"); // Look up our data source DataSource ds = (DataSource)envCtx.lookup("jdbc/EmployeeDB"); // Allocate and use a connection from the pool Connection conn = ds.getConnection(); // ...use this connection to access the database conn.close(); 07/11/2002 © P. Itey - INRIA 65 Le Web-Tier dans J2EE 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. 07/11/2002 © P. Itey - INRIA 66 Topologie(s) du Web-Tier 07/11/2002 © P. Itey - INRIA 67 Topologie(s) du Web-Tier (2) 07/11/2002 © P. Itey - INRIA 68 Topologie(s) du Web-Tier (3) 07/11/2002 © P. Itey - INRIA 69 Rôles du serveur Web 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. 07/11/2002 © P. Itey - INRIA 70 Rôles du serveur Web (suite) 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. 07/11/2002 © P. Itey - INRIA 71 Fonctions du serveur Web mise à disposition de la logique métier sur le Web: le serveur 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,… 07/11/2002 © P. Itey - INRIA 72 Fonctions du serveur Web (suite) 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 07/11/2002 © P. Itey - INRIA 73 Fonctions du serveur Web (suite) 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 07/11/2002 © P. Itey - INRIA 74 Technologies utilisées sur le Web Technologies “traditionnelles” 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. 07/11/2002 © P. Itey - INRIA 75 Technologies "traditionnelles" 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 CGI ont ensuite été palliées en utilisant des extensions propres à chaque serveur Web. 07/11/2002 © P. Itey - INRIA 76 Technologies "traditionnelles" On parle de NSAPI (pour les serveurs Netscape), de modules d’extension (pour le serveur Apache), et d’ISAPI (pour Microsoft Internet Information Server). L’inconvénient de ces techniques étant qu’elles sont spécifiques à chaque serveur et donc non-portables. 07/11/2002 © P. Itey - INRIA 77 Technologies Web pour J2EE Les technologies Web utilisées sur un serveur J2EE présentent l’avantage d’être des solutions 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. 07/11/2002 © P. Itey - INRIA 78 Techno Web pour J2EE (suite) L’environnement d’exécution d’une application Web est appelé de conteneur Web (Web container). Tous les fichiers d’une application Web sont contenus dans un fichier Web Application Archive (WAR) qui contient également un fichier de description de déploiement rédigé en XML. 07/11/2002 © P. Itey - INRIA 79 Techno Web pour J2EE (suite) Les spécifications de la plate-forme J2EE définissent un contrat en 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. Les spécifications J2EE définissent 2 types de composants Web : – les Servlets Java (“servlets”) – et les Java Server Pages (pages JSP) 07/11/2002 © P. Itey - INRIA 80 PLAN - Les composants Web Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 81 Les Travaux dirigés http://www-sop.inria.fr/semir/personnel/Patrick.Itey/cours/j2ee/ TP0 : Une simple servlet Installation du server J2EE, utilisation du serveur de déploiement J2E Ecriture / compilation / déploiement / exécution d'une servlet TP1 : Une page JSP Ecriture / déploiement / exécution d'une page JSP pour remplace la servlet TP2 : Intégrer Servlet / JSP et JavaBean dans une architecture MVC de J2EE TP3 : Utiliser des taglibs XML dans une JSP 07/11/2002 © P. Itey - INRIA 82 Servlet : qu'est ce que c'est ? Avec JSP, c'est un des composants logiciels Web de l'architecture J2EE C'est une classe Java compilée (.class) qui s'exécute dans un conteneur de Servlets (moteur), hébergé par le serveur Web (côté serveur) Permet d'étendre les fonctionnalités du serveur Web de manière portable et efficace 07/11/2002 © P. Itey - INRIA 83 Servlet : qu'est ce que c'est ? Ecrit en Java : technologie indépendante de la plate-forme et du serveur S'apparente aux technologies traditionnelles CGI (PERL) mais : – plus efficaces – plus pratiques – plus puissantes – portables et gratuites 07/11/2002 © P. Itey - INRIA 84 Servlet : à quoi ça sert ? Créer des pages dynamiques (HTML/XML) à "la volée" Effectuer des tâches de type CGI (traitements applicatifs) côté serveur Ecrire une application en Java dont l'interface utilisateur (en HTML) se situe dans le Browser, côté client 07/11/2002 © P. Itey - INRIA 85 Servlet : comment ça marche ? Le serveur Web associe une ou plusieurs URLs à chaque servlet Lorsque ces URLs sont appelées via une requête HTTP de l'utilisateur, côté client, le conteneur de servlet (moteur) déclenche la servlet qui s'exécute côté serveur La servlet génère une réponse HTML/XML vers le client en utilisant la logique métier d'EJB ou en interrogeant directement la BD (via API JDBC) © P. Itey - INRIA 07/11/2002 86 Architecture WEB : principe Client Serveur WEB Serveur EJB JSP Servlet Conteneur Conteneur web EJB Navigateur Web Tier Web 07/11/2002 © P. Itey - INRIA Tier EJB 87 Architecture Servlets Serveur WEB Client Requête (http) Réponse XML H T T P Navigateur Web JVM Tier Web Servlet maServlet.class Conteneur web http://host/servlets/maServlet © P. Itey - INRIA 07/11/2002 88 API Servlet Les classes et les interfaces pour les Servlets sont définies dans 2 packages : – javax.servlet • package générique indépendant des protocoles – javax.servlet.http • spécifique à HTTP • permet la gestion des sessions Où les trouver : JSWDK – java.sun.com/products/servlets 07/11/2002 © P. Itey - INRIA 89 Les classes de l'API 2 classes abstraites : – javax.servlet.GenericServlet – javax.servlet.http.HttpServlet qui implémentent 2 interfaces abstraites : – javax.servlet.Servlet – javax.servlet.ServletConfig © P. Itey - INRIA 07/11/2002 90 Les classes de l'API abstract interface abstract interface Servlet ServletConfig void service() abstract class GenericServlet abstract void service() abstract class HttpServlet void service() void doXXX() 07/11/2002 © P. Itey - INRIA 91 La classe GenericServlet javax.servlet.GenericServlet – définit une servlet indépendante des protocoles – une classe abstraite qui fournit une implémentation de base de l'interface Servlet La méthode service() est le principal point d'entrée – c'est une méthode abstraite qui doit être implémentée par une classe dérivée 07/11/2002 © P. Itey - INRIA 92 Structure de base d'une servlet import javax.servlet.*; public class first extends GenericServlet { public void init(ServletConfig config) throws ServletException {…} public void service( ServletRequest req, ServletResponse rep) throws ServletException, IOException {…} public void destroy() {…} } 07/11/2002 © P. Itey - INRIA 93 Communiquer avec le client 2 arguments pour service() : – javax.servlet.ServletRequest • encapsule la requête du client • contient le flot d'entrée dans lequel lire les données en provenance du client – javax.servlet.ServletResponse • contient le flot de sortie pour répondre au client 07/11/2002 © P. Itey - INRIA 94 Développer des HttpServlet javax.servlet.http.HttpServlet – dérive de GenericServlet et fournit une implémentation spécifique à HTTP de l'interface Servlet 07/11/2002 © P. Itey - INRIA 95 La méthode service() de HttpServlet HttpServlet surcharge la méthode service() – lit la méthode HTTP à partir de la requête – transmet la requête à une méthode appropriée, destinée à la traiter Chaque méthode a une méthode "handler" associée, définie dans une méthode HttpServlet:doXXX() 07/11/2002 © P. Itey - INRIA 96 Méthodes de HttpServlet Une servlet est une sous-classe de HttpServlet dans laquelle on surcharge la ou les méthodes doXXX() appropriées : – requête GET, HEAD : doGet() – requête POST : doPost() –… public void doXXX(HttpServletRequest req, HttpServletResponse rep) 07/11/2002 © P. Itey - INRIA 97 Squelette d’une servlet Http import javax.servlet.*; import javax.servlet.http.*; public class SimpleServlet extends HttpServlet { public void init(ServletConfig c) throws ServletException {…} public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {…} public void destroy() {…} public String getServletInfo() {…} } © P. Itey - INRIA 07/11/2002 98 Structure de base public class SimpleServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { // Lire la requête du client // La traiter // Répondre } } 07/11/2002 © P. Itey - INRIA 99 Lire la requête du client HttpServletRequest hérite de ServletRequest : – encapsule la requête HTTP et fournit des méthodes pour accéder à toutes les informations – contient les informations sur l'environnement du serveur 07/11/2002 © P. Itey - INRIA 100 Les méthodes de HttpServletRequest String getMethod() – retourne la méthode HTTP String getHeader(String name) – retourne le paramètre name de l'entête HTTP de la requête String getRemoteHost() – retourne le nom d'hôte du client String getRemoteAddr() – retourne l'adresse IP du client 07/11/2002 © P. Itey - INRIA 101 Les méthodes de HttpServletRequest String getParameter(String name) – retourne la valeur d'un champ de formulaire HTML String getServerName() – retourne le nom du serveur String getServerPort() – le port sur lequel le serveur écoute 07/11/2002 © P. Itey - INRIA 102 Répondre au serveur HttpServletResponse hérite de ServletResponse : – utilisé pour construire un message de réponse HTTP renvoyé au navigateur client – contient les méthodes nécessaires pour définir : type de contenu, en-tête et code de retour – contient un flot de sortie pour envoyer des données (HTML ou autre) au navigateur 07/11/2002 © P. Itey - INRIA 103 Les méthodes de HttpServletResponse void setStatus(int statusCode) – définit le code de retour de la réponse void setHeader(String name, String value) – définit la valeur de l'en-tête name void setContentType(String type) – définit le type de contenu MIME 07/11/2002 © P. Itey - INRIA 104 Les méthodes de HttpServletResponse PrintWriter getWriter() – pour envoyer des données texte au client ServletOutputStream getOutputStream() – flot pour envoyer des données binaires void sendRedirect(String url) – redirige le navigateur vers l'URL 07/11/2002 © P. Itey - INRIA 105 Un exemple simple ... 07/11/2002 © P. Itey - INRIA 106 Un exemple simple ... package hall; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWorld extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getWriter(); out.println("Hello World");out.flush(); } } 07/11/2002 © P. Itey - INRIA 107 Un autre exemple ... 07/11/2002 © P. Itey - INRIA 108 Un autre exemple ... package hall; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWWW extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " + "Transitional//EN\">\n" + "<HTML>\n" + "<HEAD><TITLE>Hello WWW</TITLE></HEAD>\n" + "<BODY><H1>Hello WWW</H1>\n" +"</BODY></HTML>");}} 07/11/2002 © P. Itey - INRIA 109 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 110 Méthodes du cycle de vie La classe javax.servlet.Servlet définit les méthodes qui permettent de contrôler le cycle de vie d'une servlet : – void init() – void service() – void destroy() Elles sont héritées par la servlet et doivent être redéfinies 07/11/2002 © P. Itey - INRIA 111 Les méthodes du cycle de vie import javax.servlet.*; import javax.servlet.http.*; public class SimpleServlet extends HttpServlet { public void init(ServletConfig c) throws ServletException {…} public void doXXX(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {…} public void destroy() {…} } 07/11/2002 © P. Itey - INRIA 112 Les méthodes du cycle de vie void init() : – une fois créée, la servlet est initialisée avec cette méthode : elle n'est appelée qu'une seule fois par le serveur au chargement initial. – Similaire à un constructeur – on peut y placer (par exemple) des connexions réseaux ou à une BD 07/11/2002 © P. Itey - INRIA 113 Les méthodes du cycle de vie void service() : – appelée automatiquement par le serveur à chaque requête cliente void destroy() : – appelée qu'une seule fois quand la servlet est déchargée par le serveur et lorsque le serveur est arrêté. – on y place la fermeture de connexions réseaux ou BD (souvent allouées par init() ) © P. Itey - INRIA 07/11/2002 114 Gestion des servlets par le moteur Moteur de Servlets Créer un pool de threads Thread Thread Instancier la servlet Servlet Appeler la méthode init() Initialisation Requête HTTP 1 Requête HTTP 2 Affecter une requête à un thread Appeler la méthode service() Affecter une requête à un thread Appeler la méthode service() Réponse HTTP 1 Exécution service Exécution service Réponse HTTP 2 Terminer le pool de threads Appeler la méthode destroy() 07/11/2002 © P. Itey - INRIA 115 Servlets et concurrence Une seule servlet gère les requêtes de plusieurs clients Un thread est généré à chaque requête du client – conséquences : les attributs de la servlet sont partagés, les variables des méthodes sont locales Pour des portions de code critique, utiliser synchronized 07/11/2002 © P. Itey - INRIA 116 Implémenter SingleThreadModel javax.servlet.SingleThreadModel – interface vide, ne contient aucune méthode Le moteur de servlet crée un pool d'objet servlet et passe les requêtes à un des objets libres public class HelloWWW extends HttpServlet implements SingleThreadModel {…} 07/11/2002 © P. Itey - INRIA 117 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 118 Les formulaires HTML Permettent aux utilisateurs de saisir des données dans une interface graphique dans le Navigateur Mécanisme intégré pour envoyer des données au serveur WEB 07/11/2002 © P. Itey - INRIA 119 Rappel : les balises de formulaire <FORM> : pour définir un formulaire <INPUT> : pour définir une interface : – text, password, checkbox, radio, submit, reset <TEXTAREA> : zone de texte sur plusieurs lignes <SELECT> : liste déroulante 07/11/2002 © P. Itey - INRIA 120 Envoyer les données du formulaire Attributs de la balise <FORM> – ACTION : l'URL où envoyer les données – METHOD : la méthode HTTP (GET / POST) Les données sont envoyées quand l'utilisateur clique sur un bouton de type submit 07/11/2002 © P. Itey - INRIA 121 Exemple de formulaire <FORM METHOD="POST" ACTION="http://host/servlet/demandeServlet" > Nom : <INPUT type="text" name="Nom" /> <BR> <INPUT type="submit" value="Envoyer" /> </FORM> 07/11/2002 © P. Itey - INRIA 122 Les méthodes GET et POST GET : les champs du formulaire sont ajoutés à l'URL de l'attribut ACTION sous une forme nom=valeur URL?nom1=val1&nom2=val2&... POST : les données sont passées dans le corps du message HTTP – convient pour l'envoi de données binaires 07/11/2002 © P. Itey - INRIA 123 Lire les données dans une servlet La méthode de HttpServletRequest : public String getParameter(String name) Dans le formulaire : <INPUT type="text" name="nom" /> Dans la méthode doXXX() : String n = req.getParameter("nom") 07/11/2002 © P. Itey - INRIA 124 Lire les données dans une servlet public class ShowParameters extends HttpServlet { public void doGet(HttpServletRequest req,...) { out.println(req.getParameter(“param1”)); Enumeration paramNames = req.getParameterNames(); String[] paramValues = req.getParameterValues(paramNames); } } 07/11/2002 © P. Itey - INRIA 125 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 126 HTTP : protocole sans états HTTP gère les paires requête/réponse – ouverture, requête, réponse, fermeture HTTP : protocole sans états – aucun historique des différentes requêtes n'est conservé – les requêtes sont totalement indépendantes les unes des autres 07/11/2002 © P. Itey - INRIA 127 Introduction : la gestion des états Une application WEB a besoin de savoir : – quel utilisateur a émis la requête courante – les requêtes déjà émises par l'utilisateur – l'état général de l'application : • nombre de visites, nombres de produits vendus, – Il faut rajouter à HTTP un mécanisme de gestion des états 07/11/2002 © P. Itey - INRIA 128 Qu'est ce qu'un cookie ? Petit fragment d'information textuelle échangé entre le serveur WEB et le Navigateur – collection de paires nom/valeur – chargés dans la mémoire du Navigateur – les cookies permanents sont aussi sauvegardés dans un fichier texte sur le client – Ils font partie de l'en-tête HTTP 07/11/2002 © P. Itey - INRIA 129 Qu'est ce qu'un cookie ? Crées à l'origine par Netscape – maintenant RFC 2109 Utilisés couramment pour mémoriser les préférences de l'utilisateur ou même pour l'identifier 07/11/2002 © P. Itey - INRIA 130 Anatomie d'un cookie Partie Description Name Value Domain Path Max Age Secure Identité du cookie Valeur du cookie Nom du domaine qui l'a défini Information sur le chemin Temps d'expiration du cookie Vrai si cookie transmis avec SSL 07/11/2002 © P. Itey - INRIA 131 Où les cookies sont-ils stockés ? Netscape les stocke dans 1 seul fichier : – cookies.txt Server:8080 FALSE /servlet FALSE 975685981 Sport Foot domaine script chemin SSl ? Date nom valeur client I.E. les stocke dans 1 fichier séparé par site – dans c:\Winnt\Profiles\username\Cookies 07/11/2002 © P. Itey - INRIA 132 Cookie et sécurité ? Jamais interprété ou exécuté : pas de virus Un cookie est limité à 4KB et les navigateurs se limitent à 300 cookies (20 par site) : pas de surcharge de disque Bien pour rendre privées des données non sensibles – nom, adresse, … mais pas No CB ! … mais ne constitue pas un traitement sérieux de la sécurité 07/11/2002 © P. Itey - INRIA 133 Utiliser des cookies Depuis API 2.1, pris en charge par : javax.servlet.http.Cookie Cette classe construit des cookies avec des paires nom/valeur : public Cookie(String name, String value) 07/11/2002 © P. Itey - INRIA 134 Méthodes de Cookie Pour les fixer des attributs supplémentaires void setValue(String val) définit la valeur du cookie void setMaxAge(int expSec) nombre de secondes depuis le 01/01/70 par défaut -1 (expire quand on ferme le navigateur) 0 supprime le cookie 07/11/2002 © P. Itey - INRIA 135 Méthodes de Cookie (suite) void setPath(String path) définit le chemin void setSecure(boolean flag) true si SSL, false par défaut void setDomain(String domaine) définit le domaine 07/11/2002 © P. Itey - INRIA 136 Envoi des cookies Méthode addCookie() de la classe HttpServletResponse public void doGet(HttpServletRequest req, HttpServletResponse rep) { Cookie c = new Cookie ("nom", "toto"); c.setMaxAge(365*24*60*60); // 1 an rep.addCookie( c ); rep.setContentType("text/html"); … } 07/11/2002 © P. Itey - INRIA 137 Lecture des cookies Le navigateur envoie automatiquement les cookies qui correspondent à domain et path Une servlet peut récupérer les cookies envoyés précédemment au navigateur – méthode getCookies() de HttpServletRequest public Cookie[] getCookies() 07/11/2002 © P. Itey - INRIA 138 Lecture des cookies Cookie [] cookies = request.getCookies(); String nom = getCookieValue(cookies, "nom", "non trouvé"); ... public static String getCookieValue( Cookie [] cookies, String cookieName, String defaultValue) { for(int i=0; i < cookies.length; i++) { Cookie cookie = cookies[i]; if(cookieName.equals(cookie.getName()) return(cookie.getValue()); } return(defaultValue); } 07/11/2002 © P. Itey - INRIA 139 Les sessions Une session peut se définir : – une série d'interactions reliées entre un navigateur et un serveur WEB – englobe plusieurs requêtes HTTP sur une période donnée Utilisées pour mémoriser les actions (requêtes HTTP) d'un utilisateur unique au cours du temps – exple : opérations bancaires 07/11/2002 © P. Itey - INRIA 140 Techniques de mémorisation Pour échanger les données d'identification de la session dans chaque requête : – réécriture d'URL – champ de formulaire caché ("hidden") – cookies – utilisation des sessions avec les HttpSession 07/11/2002 © P. Itey - INRIA 141 Réécriture d'URL Principe : – ajouter dans la chaîne de requête de la servlet des informations supplémentaires identifiant la session <a href="http://leo.inria.fr/servlet/foo?uid=itey">Ac heter</a> – l'ID utilisateur est transmis en même temps que la requête; il est accédé par chaque servlet mentionnée qui récupère les informations persistantes (BD, fichiers) à partir de cet ID 07/11/2002 © P. Itey - INRIA 142 Réécriture d'URL Limitations : – données volumineuses, – caractères autorisés, – longueur URL, – données visibles (sécurité) 07/11/2002 © P. Itey - INRIA 143 Champs de formulaires cachés Principe : – on cache les données de session dans des champs "hidden" : <INPUT TYPE="HIDDEN" NAME="uid" VALUE=itey"> Limitations : – idem la "réécriture d'URL" sauf pour la sécurité (utilisation de POST) 07/11/2002 © P. Itey - INRIA 144 L'interface HttpSession Les objets HttpSession mémorisent les données de chaque utilisateur fonctionne comme une table de "hachage" stockée sur le serveur A chaque ID de session est associé, via la table de hachage, l'ensemble des informations 07/11/2002 © P. Itey - INRIA 145 Identification des sessions 2 façons possibles d'échanger l'ID de session : – par défaut : les cookies (de session : non permanents) – ajouter l'ID de session à l'URL (réécriture d'URL) L'implémentation est dépendante du moteur de Servlets 07/11/2002 © P. Itey - INRIA 146 Identification des session Pseudo-algorithme : – si GET : regarder la requête – si POST : regarder dans l'en-tête HTTP – Sinon, rechercher un cookie "sessionid" – Vérifier l'existence de la session – si oui, retourner la session – sinon : nouvel ID = tps courant + nb aléatoire 07/11/2002 © P. Itey - INRIA 147 Identification des session Pseudo-algorithme (suite) : – Si le navigateur accepte les cookies, en ajouter 1 à la réponse sinon dans l'URL – Enregistrer la session avec le nouvel ID 07/11/2002 © P. Itey - INRIA 148 Utiliser HttpSession 2 étapes pour la mémorisation des sessions – 1- obtenir l'objet de session de l'utilisateur – 2- mémoriser / extraire les informations dans / de la session de l'utilisateur 07/11/2002 © P. Itey - INRIA 149 Obtenir l'objet de session 2 méthodes de HttpServletRequest : – HttpSession getSession() : retourne la session courante, si elle n'existe pas, elle est créée – HttpSession getSession(boolean create) : idem sauf que la session n'est créée que si create = true, sinon retourne null 07/11/2002 © P. Itey - INRIA 150 Mémoriser et extraire les données Une fois la session obtenue, on peut mémoriser et extraire les données grâce aux méthodes de HttpSession : void putValue(String name, Object Val) Object getValue(String name) 07/11/2002 © P. Itey - INRIA 151 Mémoriser et extraire les données HttpSession session = request.getSession(); session.putValue( "table", newArrayList()); ArrayList tab = (ArrayList)session.getValue("table"); 07/11/2002 © P. Itey - INRIA 152 Autres méthodes de HttpSession boolean isNew() : retourne true si nouvelle session void invalidate() : invalide la session et supprime les associations nom / valeur 07/11/2002 © P. Itey - INRIA 153 Autres méthodes de HttpSession Les moteurs de servlets gèrent un timeout de durée de vie des sessions : int getMaxInactiveInterval() : retourne l'intervalle maximal d'inactivité en secondes void setMaxInactiveInterval : définit l'intervalle maximal d'inactivité en secondes 07/11/2002 © P. Itey - INRIA 154 Autres méthodes de HttpRequest String getRequestedSessionId() : retourne l'ID de session boolean isRequestedSessionIdFromCookie() retourne true si l'ID de session a été passé dans un cookie boolean isRequestedSessionIdFromURL() retourne true si l'ID des session a été passé dans l'URL 07/11/2002 © P. Itey - INRIA 155 Utiliser HttpSession sans cookies L'implémentation par défaut de HttpSession utilise les cookies – si les cookies ne sont pas autorisés par le navigateur, la mémorisation des sessions ne fonctionne pas Autre solution : la réécriture d'URL – ajouter l'ID de session à la fin de l'URL – la réécriture d'URL doit être activée sur le serveur 07/11/2002 © P. Itey - INRIA 156 Réécriture d'URL Méthodes de HttpServletRequest : String encodeURL(String url) encode l'URL en ajoutant l'ID de session si les cookies sont désactivés String encodeRedirectURL(String url) encode l'URL avant de rediriger le Navigateur 07/11/2002 © P. Itey - INRIA 157 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 158 JSP : Java Server Page La plupart des applications Web produisent des pages HTML dynamiquement en modifiant uniquement les champs de données et pas la structure de base de la page. Les JSP sont la technologie la plus appropriée pour ce type de contenu. 07/11/2002 © P. Itey - INRIA 159 JSP : Java Server Page (suite) 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. 07/11/2002 © P. Itey - INRIA 160 JSP : Java Server Page Une JSP est un fichier texte ( .jsp ) contenant du code HTML et des fragments de code Java contenus dans des balises spécifiques, exécutés sur le serveur WEB Versions 1.0 et maintenant 1.2 En fait, le fichier JSP est traduit en servlet qui est compilée, puis instanciée lors de son invocation via une URL 07/11/2002 © P. Itey - INRIA 161 Principe de fonctionnement Requête client OUI La JSP demandée est-elle chargée NON Traduire le code en servlet source OUI Le fichier .jsp a-t-il été modifié depuis la dernière traduction Compiler et charger la servlet Réponse JSP 07/11/2002 NON Exécuter la servlet © P. Itey - INRIA 162 Les balises JSP 3 types : – des directives : 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 (scriptlets) : blocs d’instructions Java inclus dans la page JSP entre des délimiteurs <% et %>. 07/11/2002 © P. Itey - INRIA 163 Les balises JSP (suite) – 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. 07/11/2002 © P. Itey - INRIA 164 Un exemple simple de JSP <html><head><title>Un exemple de page JSP</title></head><body> <!-- définit les informations globales a la page --> <%@page language="java" %> <!-- Déclare la variable c --> <%! char c = 0; %> <!-- Scriplet (code java) %> <% for(int i = 0; i < 26; i++){ for(int j = 0; j < 26; j++){ c = (char)(0x41 + (26 - i + j)%26); %> <%= c %> <% } %> <br> <% } %> </body></html> 07/11/2002 © P. Itey - INRIA 165 4 types d'éléments dans une JSP Nom Directives Tag Traduction Servlet <%@ … %> pour l'ensemble page de la page include Déclarations <%! … %> en dehors de service() Scriptlets <% … %> méthodes et variables de la servlet dans service() Expressions <%= … %> dans service() 07/11/2002 © P. Itey - INRIA 166 Les scriptlets : <% … %> Contient du code JAVA – tout code JAVA valide – Objet out pour produire de la sortie HTML, objets request et response Se transforme dans la méthode _jspService() de la servlet – les variables sont locales à la méthode – les blocs de code s'insèrent dans la servlet 07/11/2002 © P. Itey - INRIA 167 Les scriptlets : exemple <% String[] noms = {"titi", "toto"}; for(int i = 0; i < noms.length; i++){ out.println(noms[i]); } %> 07/11/2002 © P. Itey - INRIA 168 Les expressions : <%= … %> Pour évaluer une expression ou un objet Java et renvoyer sa valeur : – retourne une version String de l'expression – raccourci pour <% out.println(…); %> Se transforme en out.println(…) dans la méthode _jspService(…) de la servlet 07/11/2002 © P. Itey - INRIA 169 Les expressions : exemple <% String[] noms = {"titi", "toto"}; for(int i = 0; i < noms.length; i++){ %> Le nom <%= i %> ième nom est <%= noms[i] %> <% } %> 07/11/2002 © P. Itey - INRIA 170 Les déclarations : <%! … %> Pour déclarer des méthodes à l'échelle de la page (méthodes de la servlet générée) – les méthodes ne sont exécutées que si elles sont appelées explicitement – on peut aussi déclarer des attributs Se transforme en déclarations de champs et méthodes au niveau de la servlet 07/11/2002 © P. Itey - INRIA 171 Les déclarations : exemple <%! private int accessCount = 0; private int incrementCount() {return accessCount++;} %> … <H2>Nombre et liste des articles</H2> Nombre d'articles : <%= incrementCount() %> 07/11/2002 © P. Itey - INRIA 172 Directives <%@ directive attribut1="valeur" attribut2="valeur"... %> 2 directives possibles (jsp1.1) : – page : informations relatives à la page – include : fichiers à inclure littéralement 07/11/2002 © P. Itey - INRIA 173 La directive : <%@page … %> Valeurs possibles : – <%@ page language="java" – <%@ page import="java.util.*, java.net.*" %> – <%@ page contentType="text/plain" %> – <%@ page session="true|false " %> – <%@ page errorPage="pathToErrorPage" %> – <%@ page isErrorPage="true|false" %> – <%@ page … 07/11/2002 © P. Itey - INRIA 174 La directive : <%@include … %> Valeurs possibles : – <%@ include file="chemin relatif du fichier" %> – pour se référer au home dir du serveur Web : <%@ include file="/toto.html" %> Interprété littéralement, le fichier peut être – HTML, scripting elements, directives, actions, ... L'insertion se fait au moment de la traduction de la page... 07/11/2002 © P. Itey - INRIA 175 Technique de gestion des erreurs Une exception Java peut être déclenchée et gérée par la JSP On peut ainsi spécifier une page d'erreur séparée pour la JSP – placer une directive de page pour errorPage au début du fichier – <%@page errorPage="err.jsp" %> – permet d'ôter le code d'erreur de la JSP – un objet Exception est passé à la page d'erreur 07/11/2002 © P. Itey - INRIA 176 Développer la page d'erreur Elle est identifiée par une directive de page en début de fichier : <@page isErrorPage="true" %> 07/11/2002 © P. Itey - INRIA 177 la page d'erreur : exemple <%@page isErrorPage="true" %> <html><body> Information d'exception : <strong> <%= exception %> </strong> <pre> <% java.io.PrintWriter monWriter = new java.io.PrintWriter(out); exception.printStackTrace(monWriter); %> </pre></body></html> 07/11/2002 © P. Itey - INRIA 178 Variables prédéfinies Ou "objets implicites", ils sont accessibles dans les balises JSP : – request : le HttpServletRequest – response : le HttpServletResponse – session : le HttpSession – out : flot de sortie (idem response.getWriter()) – application : le ServletContext (idem getServletConfig().getContext() ) – config, pageContext, page... : peu utiles 07/11/2002 © P. Itey - INRIA 179 Gestion des sessions avec les JSP Cookies et Sessions fonctionnent de la même façon que dans l'API Servlet Cookie : <% Cookie c = new Cookie("Sport", "Foot"); response.addCookie(c); %> 07/11/2002 © P. Itey - INRIA 180 Gestion des sessions avec les JSP Sessions : – toutes les pages JSP disposent automatiquement d'un objet session <% String val = (String)session.getValue("Sport"); %> 07/11/2002 © P. Itey - INRIA 181 Actions Syntaxe XML Permettent de faire des actions au moment où la page est demandée par un client : – inclure dynamiquement un fichier – utiliser des beans – rediriger vers une autre page – etc... 07/11/2002 © P. Itey - INRIA 182 Action : <jsp:include … /> <jsp:include page="url" /> Pour inclure des éléments standards comme des en-têtes et des pieds de page On peut inclure n'importe quoi qui s'intégrera correctement dans le flot de la page inclusion au moment où la page est servie, pas au moment où elle est traduite en servlet. 07/11/2002 © P. Itey - INRIA 183 Action : <jsp:forward … /> <jsp:forward page="/unAutreURI" /> redirige vers un autre URI/URL 07/11/2002 © P. Itey - INRIA 184 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 185 Objectifs des JSP Les JSP DOIVENT servir à la conception de l'IHM en HTML dans le Navigateur La logique de traitement (logique applicative) DOIT venir de composants auxquels accède la JSP 07/11/2002 © P. Itey - INRIA 186 Objectifs des JSP (suite) Avantages de l'utilisation de composants : – lisibilité accrue de la JSP – dissociation de la présentation et des traitements – Réutilisation des composants 07/11/2002 © P. Itey - INRIA 187 Qu'est-ce qu'un JavaBean ? C'est une classe Java publique qui : – possède un constructeur public sans argument – implémente des méthodes getXXX() et setXXX() pour chacun de ses attributs XXX : public PropertyType getPropertyName() public void setPropertyNamePropertyType val) En option, il implémente l'interface java.io.Serializable 07/11/2002 © P. Itey - INRIA 188 Utiliser un Bean dans une JSP ? La balise <jsp:useBean … /> <jsp:useBean id="nom de l'instance du Bean" class="nom qualifié de la classe du Bean" scope="request | session | application | page" /> 07/11/2002 © P. Itey - INRIA 189 La balise <jsp:useBean … > L'attribut "scope" (portée) : – request : le Bean est valide pour la requête, il est détruit à la fin – page : (défaut), idem request sauf que le Bean ne peut pas être transmis 07/11/2002 © P. Itey - INRIA 190 La balise <jsp:useBean … > (suite) L'attribut "scope" : – session : il est stocké dans la session de l'utilisateur et il dure autant que la session – application : le Bean est valide pour l'application courante. Il est crée une fois et est partagé par tous les clients de l'application 07/11/2002 © P. Itey - INRIA 191 Définir les propriétés du Bean La balise <jsp:setProperty … /> <jsp:useBean id="monObjet" class="maClasse" scope="request" /> <jsp:setProperty name="monObjet" property="Sport" value="Foot" /> <jsp:setProperty name="monObjet" property="email" value="addr_email" /> 07/11/2002 © P. Itey - INRIA 192 Lire les propriétés du Bean La balise <jsp:getProperty ...> <jsp:useBean id="monObjet" class="maClasse" scope="request" /> <jsp:getProperty name="monObjet" property="Sport" /> <jsp:setProperty name="monObjet" property="email" /> 07/11/2002 © P. Itey - INRIA 193 Exemple d'utilisation d'un Bean La page JSP : <html> ... <jsp:usebean id="test" class="inria.SimpleBean"/> <jsp:setProperty name="test" property="message" value="Hello !!" /> <h1>Le message est : <i> <jsp:getProperty name="test" property="message"/> </i></h1>… </html> 07/11/2002 © P. Itey - INRIA 194 Exemple d'utilisation d'un Bean Le code source Java du Bean : package inria; public class SimpleBean { private String message = "no message"; public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } } 07/11/2002 © P. Itey - INRIA 195 Résumé sur les JSP 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,…. 07/11/2002 © P. Itey - INRIA 196 Résumé (suite) Les pages JSP sont plus faciles à écrire que les servlets car elles ressemblent à des documents structurés classiques et sont manipulables 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. 07/11/2002 © P. Itey - INRIA 197 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 198 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. 07/11/2002 © P. Itey - INRIA 199 Syntaxe XML pour les JSP (suite) 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. 07/11/2002 © P. Itey - INRIA 200 Syntaxe XML pour les JSP (suite) <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:prefix1="URI-for-taglib1" xmlns:prefix2="URI-for-taglib2" ...version="1.2"> <jsp:text> <html> <head> <title> Simple JSP Document </title> </head> <body> <h1>Hello World</h1> </body> </html> </jsp:text> </jsp:root> 07/11/2002 © P. Itey - INRIA 201 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 202 Balises JSP personnalisées 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. 07/11/2002 © P. Itey - INRIA 203 Balises JSP personnalisées (suite) Le programmeur définit la syntaxe pour chaque balise 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. © P. Itey - INRIA 07/11/2002 204 Avantages Les balises personnalisées : – sont réutilisables – permettent de définir des services de haut niveau et sont portables – facilitent la maintenance d'une application • pas de répétition du code de pages en pages • Modification du code en un seul endroit 07/11/2002 © P. Itey - INRIA 205 Avantages (suite) – facilitent la lecture et la manipulation des pages • plus simples à lire que des bouts de scripts – fournissent un moyen simple pour utiliser la logique métier 07/11/2002 © P. Itey - INRIA 206 Avantages (suite) – permettent une séparation claire entre présentation des données et logique métier • maintenance plus simple • montre plus clairement l'utilité de chaque composant • permet aux programmeurs et auteurs de pages de travailler plus indépendamment 07/11/2002 © P. Itey - INRIA 207 Bibliothèques de balises standards Les bibliothèques de balises standards sont des jeux de balises qui fournissent un jeu de fonctionnalités basiques pour les pages JSP : – – – – – – – – 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. 07/11/2002 © P. Itey - INRIA 208 Standard tag libraries (suite) Certaines sociétés 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. Exemple : Apache Taglibs (bibliothèque Open source de balises personnalisées). 07/11/2002 © P. Itey - INRIA 209 Standard tag libraries (suite) 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. 07/11/2002 © P. Itey - INRIA 210 Standard tag libraries (suite) Les librairies standards 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 standards de haute qualité permet ainsi de gagner un précieux temps en développement. 07/11/2002 © P. Itey - INRIA 211 PLAN Les Servlets Cycle de vie d'une servlet Traitement des données de formulaires Gestion de l'état avec cookies et sessions Introduction aux JSP Intégrer JSP, Servlets et JavaBeans Les JSP en XML Les balises JSP personnalisées Règles de conception 07/11/2002 © P. Itey - INRIA 212 Quand utiliser des servlets ? Elles sont la plupart du temps utilisées pour : – implémenter la logique de l'application – générer des données binaires – implémenter des services Les servlets ne sont pas habituellement des composants visuels, à l'exception de certaines qui génèrent du contenu binaire. Elles sont surtout utilisées comme un service d'accès aux informations de l'application. 07/11/2002 © P. Itey - INRIA 213 Quand utiliser des servlets ? 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 elle peut être assimilée à un service, un filtre de servlets peut être assimilé à une extension ou une personnalisation du service fourni par la servlet. 07/11/2002 © P. Itey - INRIA 214 Servlets contrôleurs (dispatcher) 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. 07/11/2002 © P. Itey - INRIA 215 Servlets contrôleurs (dispatcher) 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. 07/11/2002 © P. Itey - INRIA 216 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); } } 07/11/2002 © P. Itey - INRIA 217 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 écrit ses données binaires dans un objet OutputStream récupéré à partir de l'objet ServletRequest , comme montré dans l'exemple de code suivant. 07/11/2002 © P. Itey - INRIA 218 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... } } 07/11/2002 © P. Itey - INRIA 219 Eviter de génèrer 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. 07/11/2002 © P. Itey - INRIA 220 Mauvais exemple de Servlet utilisée 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>");}} 07/11/2002 © P. Itey - INRIA 221 Mauvais exemple (suite) 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. 07/11/2002 © P. Itey - INRIA 222 Bon exemple de Servlet utilisée pour générer du texte PopulateServlet.java: public class PopulateServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ...{ ... if (dbConnectionClosed){ ServletContext ctx = getServletContext(); RequestDispatcher rd = ctx.getRequestDispatcher("/db_failed.jsp"); rd.forward(req,res); }} 07/11/2002 © P. Itey - INRIA 223 Bon exemple de Servlet (suite) db_failed.jsp: <html> <body> <br><font color="red">Unable to Connect</font> <br>Confirm that your database is running </body> </html> 07/11/2002 © P. Itey - INRIA 224 Redirections et inclusions Une servlet peut utiliser 2 méthodes de l'objet RequestDispatcher, pour créer une réponse en faisant appel à d'autres composants : – void forward(…) – void include(...) 07/11/2002 © P. Itey - INRIA 225 Redirections et inclusions (suite) Ces 2 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 07/11/2002 © P. Itey - INRIA 226 Le patron de conception M-V-C Le patron de conception (Design pattern) Modèle-Vue-Contrôleur est recommandé car il permet de créer des applications réutilisables, et d’ajouter de nouveaux types de clients, processus et vues facilement. 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. 07/11/2002 © P. Itey - INRIA 227 Le modèle MVC avec Servlet et JSP Utilisation conjointe des servlets et JSP : – JSP fournit la vue – les servlets contrôlent et dispatchent – les composants servent à accéder aux données du modèle 07/11/2002 © P. Itey - INRIA 228 Principe de MVC Servlet JSP files 07/11/2002 © P. Itey - INRIA 229 Quand 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). 07/11/2002 © P. Itey - INRIA 230 Utiliser les JSP pour la présentation des données 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. 07/11/2002 © P. Itey - INRIA 231 Utiliser les JSP pour la présentation des données (suite) 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 peuvent être placés à divers endroits des données statiques et sont substitués à l'exécution par du contenu dynamique. 07/11/2002 © P. Itey - INRIA 232 Utiliser les JSP pour la présentation des données (suite) 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 (servlet dispatcher) Les pages JSP peuvent accéder facilement à la logique métier d'une application, en incluant des beans par exemple. 07/11/2002 © P. Itey - INRIA 233 Générer du XML JSP : bonne technologie pour générer du XML avec une structure fixe. 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'attributs ou les données brutes varient entre les appels à la page. 07/11/2002 © P. Itey - INRIA 234 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. 07/11/2002 © P. Itey - INRIA 235 Encodage des pages JSP Les JSP 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 binaire à partir d'une JSP. 07/11/2002 © P. Itey - INRIA 236 Eviter d'utiliser trop de balises logiques Les bibliothèques de balises standards 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. 07/11/2002 © P. Itey - INRIA 237 Eviter d'utiliser trop de balises logiques (suite) A la place, il vaut mieux implémenter la logique dans une balise personnalisée qui fait appel à un entreprise bean. Ainsi une fine couche de code (le gestionnaire de balises ou tag handler) lie la balise personnalisée à un bean 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. 07/11/2002 © P. Itey - INRIA 238 Bien utiliser les directives et balises d'inclusion JSP La directive <%@include … %> des JSP et la balise <jsp:include … /> ont la même syntaxe mais des buts différents. 07/11/2002 © P. Itey - INRIA 239 La directive JSP <%@include … %> Une directive d'inclusion inclue 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" %> 07/11/2002 © P. Itey - INRIA 240 La balise JSP <jsp:include … /> La balise JSP <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 : <jsp:include page="/servlets/currentUserInfoServlet"/> 07/11/2002 © P. Itey - INRIA 241 Bien utiliser les directives et balises d'inclusion JSP (suite) 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 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). 07/11/2002 © P. Itey - INRIA 242 Bien utiliser les directives et balises d'inclusion JSP (suite) A chaque fois qu'une page JSP est demandée dans le cas d'une inclusion par la balise JSP include : – les pages liées sont recompilées. – les composants utilisés (JavaBeans ou autres objets fournis par le conteneur) doivent être redéclarés dans les pages inclues et partagés entre les pages, via l'utilisation de l'objet HttpSession. 07/11/2002 © P. Itey - INRIA 243 Utiliser des balises personnalisées … pour éviter les éléments de script car : – le code scriptlet 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> (!!) 07/11/2002 © P. Itey - INRIA 244 Utiliser des balises personnalisées – le code scriptlet est plus difficile à lire et à maintenir que des balises personnalisées – les informations de déboggage 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 scriptlet est plus difficile à tester; avec des balises personnalisées, on dispose de composants personnalisés prêt à subir des tests unitaires 07/11/2002 © P. Itey - INRIA 245 (Mauvais) exemple de JSP contrôleur Eviter de rediriger des requêtes à partir de pages JSP Quand une page JSP appelle RequestDispatcher.forward(), elle se comporte comme un contrôleur. 07/11/2002 © P. Itey - INRIA 246 (Mauvais) exemple de JSP contrôleur Les contrôleurs sont, de préférence, implémentés dans des servlets, pas dans des composants de présentation. <% 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"/> <%}%> 07/11/2002 © P. Itey - INRIA 247 Résumé (1/4) Le serveur Web d’une application J2EE rend disponible les applications sur le Web Les pages JSP et servlets sont des composants Web qui succèdent aux anciennes technologies côté serveur telles que les CGIs et qui assurent la portabilité. 07/11/2002 © P. Itey - INRIA 248 Résumé (2/4) 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. 07/11/2002 © P. Itey - INRIA 249 Résumé (3/4) 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. Les servlets sont principalement utilisées pour générer des données binaires et contrôler l’application (modèle Servlet Dispatcher) Les pages JSP sont principalement utilisées pour créer du contenu textuel et des références à des données externes. 07/11/2002 © P. Itey - INRIA 250 Résumé (4/4) Pour les JSP, l’utilisation de bibliothèques de balises personnalisées améliore la qualité du code source et facilite la maintenance des applications J2EE. 07/11/2002 © P. Itey - INRIA 251
