Vous êtes sur la page 1sur 126

Architecture J2EE

Etude du Web-tier

Composants Web Servlets / JSP et


JavaBeans

Patrick Itey (Patrick.Itey@sophia.inria.fr) - 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

07/11/2002 © P. Itey - INRIA 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)

07/11/2002 © P. Itey - INRIA 86

Architecture WEB : principe

Serveur WEB Serveur EJB


Client
JSP
Servlet

Conteneur Conteneur
web EJB

Navigateur Web

Tier Web Tier EJB

07/11/2002 © P. Itey - INRIA 87


Architecture Servlets

Serveur WEB

Client
Requête (http) H JVM
Tier Web
T
Réponse XML
T Servlet

P
maServlet.class
Navigateur Web
Conteneur
web

http://host/servlets/maServlet
07/11/2002 © P. Itey - INRIA 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

07/11/2002 © P. Itey - INRIA 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() {…}


}

07/11/2002 © P. Itey - INRIA 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() )

07/11/2002 © P. Itey - INRIA 114

Gestion des servlets par le moteur


Moteur de
Servlets
Créer un pool Thread
de threads Thread
Instancier la servlet
Servlet
Appeler la méthode init()

Initialisation
Affecter une requête à un thread Appeler la méthode service()
Requête HTTP 1
Exécution
Affecter une requête à un thread Appeler la méthode service() service
Requête HTTP 2

Réponse HTTP 1 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 Identité du cookie


Value Valeur du cookie
Domain Nom du domaine qui l'a défini
Path Information sur le chemin
Max Age Temps d'expiration du cookie
Secure 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

La JSP demandée OUI


Requête client
est-elle chargée

NON OUI Le fichier .jsp


Traduire le code a-t-il été modifié
en servlet source depuis la dernière
traduction

Compiler et charger NON


la servlet

Réponse JSP Exécuter la servlet

07/11/2002 © 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 Tag Traduction
Servlet
Directives <%@ … %> pour l'ensemble page
de la page include

Déclarations <%! … %> en dehors de méthodes et


service() variables de
la servlet
Scriptlets <% … %> 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.

07/11/2002 © P. Itey - INRIA 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

Vous aimerez peut-être aussi