J2EE Web Tier

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

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

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

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

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
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
– 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 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
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
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

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
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

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
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

– 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
– 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.http.*;
public class SimpleServlet extends HttpServlet {
public void init(ServletConfig c)

public void doGet(HttpServletRequest req,

HttpServletResponse res)
public String getServletInfo() {…}

}
07/11/2002 © P. Itey - INRIA 98
Structure de base

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.*;
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.*;
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
Les JSP en XML
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
public void init(ServletConfig c)

public void doXXX(HttpServletRequest req,


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

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
Les JSP en XML
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
Les JSP en XML
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
Les JSP en XML
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>

<%@page language="java" %>


<%! 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
Les JSP en XML
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
Les JSP en XML
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
Les JSP en XML
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

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
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
Les JSP en XML
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 {
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,
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

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

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

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

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

J2EE Web Tier

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

J2EE Web Tier

Hochgeladen von

Copyright:

Verfügbare Formate

Architecture J2EE

Composants Web Servlets / JSP et

Patrick Itey (Patrick.Itey@sophia.inria.fr) - INRIA

 Rappels sur l'architecture J2EE :

Rappels : Architectures distribuées

 Ce sont des applications dont les fonctions

 Dans une architecture distribuée type, les

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

 Chaque système contient une partie de

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

Rappels : architectures distribuées

– 2- fonctions applicatives / orientées métier :

 sur la couche présentation, une application

– browsers web (http/HTML),

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

Rappels : fonction applicative

 sur la couche application, un serveur

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

 sur la couche données, les serveurs du

– bases de données relationnelles ou objets,

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

Motivation pour les serveurs

 Plus grande séparation entre les 3 couches

 Le développeur peut se concentrer sur la

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

– Fournir des services standards pour :

– Mise sur le marché des applications

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

Motivation pour les serveurs

 Intégration avec l’existant :

– mettre à la disposition des développeurs des

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

– mettre en place des mécanismes standards

– mais peu de possibilités pour mettre en

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

Motivation pour les serveurs

– mécanismes et technologies standards pour la

• utilisation de ses propres composants pour les

 Réponse adaptée à la demande :

– les applications supportent la montée en

– mécanismes simples pour répartir la charge

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

Programmation par composants

– plus adaptée à la programmation de “petits

– tout est à la charge du programmeur :

• construction de objets utilisées sur les

– la structure de l’application est peu visible et

– l’évolution de l’application est difficile : ajout

– le développement, la génération des

Programmation par composants

– motivée par la réutilisation des logiciels déjà

– concept du “programming in the large” où

– la description des interactions entre

Architecture à base de composants

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

 Un composant est un module logiciel

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

 Les composants sont les briques de bases

 Parmi les différentes technologies de

 Un conteneur encapsule les composants et

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

– Servent de médiateur entre les conteneurs

– Peuvent prendre en charge le

– La Java Virtual Machine est la structure

Rappels sur l'architecture J2EE :

Ce sont des applications dont les fonctions

Dans une architecture distribuée type, les

Chaque système contient une partie de

sur la couche présentation, une application

sur la couche application, un serveur

sur la couche données, les serveurs du

Plus grande séparation entre les 3 couches

Le développeur peut se concentrer sur la

Intégration avec l’existant :

Réponse adaptée à la demande :

Un composant est un module logiciel

Les composants sont les briques de bases

Parmi les différentes technologies de

Un conteneur encapsule les composants et

Rappels sur l'architecture J2EE :

L’architecture J2EE est une architecture

Elle identifie et donne les spécifications des

Les conteneurs isolent les beans du client et

Les beans sont installés dans la partie serveur

Les conteneurs et serveurs implémentent les

Les spécifications J2EE s’intéressent aux

C'est une unité logicielle de niveau applicatif.

En plus des JavaBeans, qui font partie du

Les applets et applications clientes sont

Les composants EJB, Web fonctionnent sur le

Les concepteurs et développeurs d'applications

Tous les composants J2EE dépendent à

Les conteneurs fournissent aux composants

Comme c'est le conteneur qui gère ces

La plate-forme J2EE prévoit plusieurs types de

Ce sont des clients Java qui s'exécutent dans

Les applications J2EE les utilisent pour avoir

Les applets communiquent avec le serveur par

S'exécutent dans leur propre conteneur client.

Le conteneur client est un jeu de librairies et

Les applications clientes ont des interfaces

Les clients ont un accès complet aux services

Le conteneur client gère l'accès à ces services

Ce sont des applications autonomes reposant

Elles peuvent être installées par le web,

Elles communiquent avec le serveur en

Les clients sans fil sont basés sur la

Un composant Web est une entité logicielle qui

Les composants Web génèrent habituellement

La plate-forme J2EE définit 2 types de

Une servlet est un composant qui étend les

Un serveur Web héberge des classes Java

Quand la servlet reçoit une requête du client,

La technologie Java Server Pages (JSP) fournit

Une page JSP est un document texte qui décrit

Une page JSP contient :