Plan

 Introduction

 Architecture Java EE

 Le conteneur web
Java EE
Java Enterprise Edition  Le conteneur EJB
Ghada Feki
2 LTIC IoT
 La persistance des données en Java (JPA)

2 Ghada Feki

Web Dynamique
Confiance

Echange entre
applications
Introduction
Java Enterprise Edition Etat /
Architecture logicielle Banque /
Ghada Feki MVC Entreprise
…
4 Ghada Feki

1
 Applications
Desktop

Concurrents

Applications
Bibliothèques Web

5 Ghada Feki 6 Ghada Feki

JEE n’impose pas un

style de rangement !

Eviter les problèmes

Ref : openclassrooms.com
Architecture interne MVC
7 Ghada Feki 8 Ghada Feki

2
 MVC
Modèle
Vue
Contrôleur
HTML + Java
Ref : openclassrooms.com
Code

9 Ghada Feki 10 Ghada Feki

Framework Java EE
Architecture Java EE
Java EE
Ghada Feki

11 Ghada Feki

3
Plan Architecture des applications (3-tiers)

 Architecture des applications (3-tiers)

Présentation Services Métiers Persistance

 Java EE : Architecture 4-tiers (Client léger web)

Machine Client Serveur d’applications Serveur de données

 Plateforme Java EE  Présentation : Interface utilisateur pour interagir avec

l’application.
 Java EE : Technologies intégrées / Objectifs  Applicatif / Services métiers : Intègre la logique
métier / services offerts aux utilisateurs.
 Persistance : Enregistrement sur un support physique
des données de l’application.
13 Ghada Feki 14 Ghada Feki

Java EE / Architecture 4-tiers (Client léger :

navigateur web)
 Présentation
 Interaction avec la partie applicative sur le serveur Conteneur Web
• Via JSP/Servlet (s’occupe de la logique présentation)
Navigateur Web Logique de présentation
Servlet/JSP
 Logique applicative
• Réalisée par composants EJB
• Communication via Hibernate ou JDBC pour
interroger BD distante Logique métier Composants
EJB
 Persistance
Conteneur EJB SGBD

Serveur Java EE Serveur données

15 Ghada Feki 16 Ghada Feki

4
Plateforme Java EE
 Plateforme : base générique fournissant un ensemble de
fonctionnalités utiles pour une majorité d’applications.
 Plateforme Java EE est un ensemble constitué de services
(API) offerts et de l'infrastructure d'exécution.
17 Ghada Feki
Les outils de la plateforme Java EE
• Les composants
o Les composants web : JSP (Java Server Pages) et
Servlets
o Les composants métier : EJB (Enterprise Java Beans)
• Les services
o Les Services d'infrastructure
o Les services de communication
19 Ghada Feki
 JavaEE comprend notamment :
• Les spécifications du serveur d'application
• Des services, au travers d'API (Application
Programming Interface : Interface de programmation
d’applications , contenant un ensemble de fonctions
courantes de « bas niveau » permettant des
applications de « haut niveau »)
18 Ghada Feki
Les Services d'infrastructure
 JDBC (Java DataBase Connectivity) est une API
d'accès aux bases de données relationnelles
 JNDI (Java Naming and Directory Interface) est
une API d'accès aux services de nommage, aux annuaires
d'entreprises et aux serveur de noms des références sur
des objets distants.
 JTA/JTS (Java Transaction API/Java Transaction
Services) est un API définissant des interfaces standard
avec un gestionnaire de transactions.
20 Ghada Feki
5

 JCA (JavaEE Connector Architecture) est une API
de connexion au système d'information de l'entreprise,
tels que les ERP
 JMX (Java Management Extension) fournit des
extensions permettant de développer des applications
web de supervision d'applications
21 Ghada Feki
 JMS (Java Message Service) fournit des fonctionnalités
de communication asynchrone (appelées MOM pour
Middleware Object Message) entre applications.
 RMI (Remote Method Invocation) est une API
permettant la communication entre objets distants.
23 Ghada Feki
Les services de communication
 JAAS (Java Authentication and Authorization
Service) est une API de gestion de l'authentification et
des droits d'accès.
 JavaMail est une API permettant l'envoi de courrier
électronique.
22 Ghada Feki
Java EE / Technologies intégrées
 Composants logiciels: EJB
 Applications orientées Web : JSP, servlet
 Communication à distance : Java RMI, IIOP, JMS
 Gestion données distantes : JDBC, JPA
 Gestion d’annuaires (type LDAP) : JNDI
 Transactions : JTA
24 Ghada Feki
6
Java EE / Objectifs
 Faciliter le développement de nouvelles applications à
base de composants Conteneur Web JDBC
 Intégration avec les systèmes d’information existants HTTP
Navigateur Web JMS
 Support pour les applications « critiques » de l’entreprise Servlet/JSP
JTA
 Disponibilité, tolérance aux pannes, montée en charge,
RMI JAAS
securité ...
Composants JNDI
EJB
RMI
Application Java Conteneur EJB SGBD
Services / API

Serveur Java EE Serveur données

25 Ghada Feki 26 Ghada Feki

Plan

 Les Servlet

 Les pages JSP

Conteneur Web  Les JavaBeans

Java EE
 Les Expressions Language EL et la librairie JSTL
Ghada Feki

28 Ghada Feki

7
Les Servlets
 Une servlet est un programme qui s’exécute coté serveur
en tant qu’extension du serveur.
 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. La servlet est invoquée lorsque des requêtes
HTTP utilisateur sont soumises au serveur.
 Une servlet est une classe Java qui permet de créer
dynamiquement des données au sein d'un serveur HTTP.
Ces données sont présentées au format JSP.
Création d'une Servlet
 Les servlets sont des classes java qui jouent le rôle
d'aiguilleurs dans une application (Contrôleur).
 une servlet HTTP doit hériter de la classe
abstraite HttpServlet ;
 une servlet doit implémenter au moins une des
méthodes doXXX(), afin d'être capable de traiter une
requête entrante.

29 Ghada Feki 30 Ghada Feki

Récupérer une
ressource web du
GET serveur via une URL doGet() HttpServletRequest contient la requête HTTP, et donne accès à
toutes ses informations, telles que les en-
têtes (headers) et le corps de la requête.
Soumettre au
serveur des données
POST de tailles variables
doPost() HttpServletResponse initialise la réponse HTTP qui sera
(volumineuses)
renvoyée au client, et permet de la
personnaliser, en initialisant par exemple
Identique à la
méthode GET mais
HEAD elle renvoie doHead() les en-têtes et le corps.
seulement les en-
têtes HTTP

31 Ghada Feki 32 Ghada Feki

8
Déclaration de Sevlet dans web.xml
 La déclaration de Sevlet dans le fichier web.xml (WEB-
INF) est cruciale (définir l'identité).
<servlet-name> permet de donner un nom à une
servlet. C'est ensuite via ce nom qu'on
fera référence à la servlet en question.
<servlet-class> sert à préciser le chemin de la classe
de la servlet dans votre application.
33 Ghada Feki
<servlet-name> permet de préciser le nom de la servlet à
laquelle faire référence. Cette information
doit correspondre avec le nom défini dans
la précédente déclaration de la servlet.
<url-pattern> permet de préciser la ou les URL
relatives au travers desquelles la servlet
sera accessible.
35 Ghada Feki
Mapping de Servlet dans web.xml
 L'étape suivante est de faire correspondre la servlet
déclarée à une URL, afin qu'elle soit joignable par les
clients.
 Le rôle primordial du fichier web.xml est de configurer
l'application en associant une Servlet à une URL. Ainsi
lorsque le client la saisira, la requête HTTP sera
automatiquement aiguillée par le conteneur de servlets
vers la bonne servlet (celle qui est en charge de répondre
à cette requête).
34 Ghada Feki
Les Pages JSP
 En Java EE, la technologie utilisée pour réaliser une vue
est JSP (Java Server Pages). En fait, c'est du HTML
amélioré (HTML+java).
 Il faut placer les JSP dans /WEB-INF. En fait, /WEB-INF
cache automatiquement les ressources qu'il contient. Une
page présente sous ce répertoire n'est plus accessible
directement par une URL côté client.
 Les inclusions de JSP
Dans le but d'éviter la redondance du code, on utilise les
inclusions de JSP comme dans le cas d'ajouter un menu.
Exemple :
<%@ include file="menu.jsp" %>
36 Ghada Feki
9
Stratégie de conception:
Limiter le code Java dans les JSP Versions JSP
 Deux options  Extensions de fichiers
• Ecrire 25 lignes de code directement dans une JSP
•*.jsp, page JSP standard
• Ecrire ces 25 lignes dans une classe Java à part et 1 ligne
•*.jspf, fragment de page JSP
dans une JSP pour l’invoquer
 Pourquoi la deuxième option est vraiment meilleure? •*.jspx, page JSP compatible XML
• Développement. Ecriture de la Classe dans un  Deux syntaxes
environnement Java et pas HTML •Standard (JSP 1.2)
• Debogage. S’il y a des erreurs, elles sont visible à la
compilation •XML (JSP 2.0)

• Test. L’accès à la classe Java facilite le test (ex: boucle de  Depuis la 2.0 : Extensible à travers des librairies de tag
test de100000itérations sur un serveur…) (fichier .tld) importés ou personnels.
• Réutilisation. Utilisation de la même classe dans
différentes pages JSP
37 Ghada Feki 38 Ghada Feki

Variables prédéfinies Tags / JSP

 Request – Instance de HttpServletRequest (1argument de
service/doGet)
 Response – Instance de HttpServletResponse (2
Les Tags permettent de différencier les fragments JSP du code HTML :
 Tag de directive : <%@ une_directive %>
Sert à contrôler comment le serveur Web génère la Servlet.
 Tag de commentaire: <%--un_commentaire --%>

argument de service/doGet) Le commentaire JSP n’est pas envoyéau client ni compilé dans la Servlet.
 Tag de déclaration:<%! une_déclaration %>
 Out – Instance de JspWriter (une version bufferisée de Sert à insérer du code Java.
Writer) utilisée pour envoyer des donnés sur la sortie  Tag de scriplet :<% un_scriptlet %>

vers leclient Un scriplet est un bloc de code Java.

 Session –Instance de HttpSession associée la requête
 Application – Instance de Servlet Context (pour partager
des données) telle que obtenue via getServletContext()
 Tag d’expression:<%= une_expression %>
Sert à évaluer une expression et à renvoyer sa valeur.
Les bibliothèques de tags («tag libraries») : collections de tags (au format xml)
utilisables dans les pages JSP.
Exemple JSTL/Core <c:out value="EL" />

39 Ghada Feki 40 Ghada Feki

10
JavaBeans
 Les JavaBeans forment la partie modèle.
 But: Gérer les structures de données.
 Recommandations pour un objet java (JavaBean):
• être une classe publique;
• avoir au moins un constructeur par défaut, public et sans
paramètres;
• ne doit pas avoir de champs publics ;
• peut définir des propriétés (des champs non publics), qui
doivent être accessibles via des méthodes publiques getter
et setter, suivant des règles de nommage.
 Ces objets java peuvent implémenter l'interface Serializable, ils
deviennent ainsi persistants et leurs états peuvent être
sauvegardés;
41 Ghada Feki
 Cependant, dans une JSP, l'utilisation des balise de
scriptlets n'est pas très « propre », on utilisera plutôt
l'une des manière suivantes :
• balises JSP (JSP 1.2) : <jsp:useBean>,
<jsp:getProperty>, <jsp:setProperty>
• utilisation des EL (JSP 2.0) : ${...}
43 Ghada Feki
Comment utiliser des beans ?
 Une fois la classe créée, les beans sont des objets Java sur
lesquels on peut faire ces actions :
• instanciation d'un nouveau bean
• récupération de la valeur d'une propriété du bean
• affectation/modification de la valeur d'une propriété
du bean
 Pour faire cela dans une Servlet, le bean est traité comme
un objet Java standard.
42 Ghada Feki
Implémentation du MVC
1. Définir les beans pour représenter les données
2. Utiliser une servlet pour gérer les requêtes : La servlet lit
les paramètres de requêtes, vérifie les données
manquantes ou malformées, appelle le code métier, etc.
3. Créer les beans : La servlet invoque le code métier
(spécifique à l’application) ou accède à une base de
données pour obtenir les résultats. Les résultats sont
dans les beans définis à l’étape 1
4. Placer le bean dans le bon scope : La servlet appelle
setAttribute sur la requête, la session, ou la servlet
context pour garder une référence sur les beans qui
représentent le résultat de la requête
44 Ghada Feki
11
Implémentation du MVC avec
RequestDispatcher
5. Transmettre la requête à la JSP (forward) : La servlet
détermine quelle JSP est appropriée à la situation et
utilise la méthode forward du RequestDispatcher pour
transférer le contrôle à la JSP
Exemple :
this.getServletContext().getRequestDispatcher( "/WEB-
INF/accueil.jsp" ).forward( request, response );
45 Ghada Feki
6. Extraire les données des beans
• JSP 1.2 : la JSP accède aux beans avec jsp:useBean et un
scope correspondant au choix de l’étape 4. La JSP utilise
ensuite jsp:getProperty pour afficher les propriétés des
beans
• JSP 2.0: la JSP utilise ${nameFromServlet.property} pour
afficher les propriétés des beans
47 Ghada Feki
getServletContext() retourne un objet ServletContext, qui fait référence
au contexte commun à toute l'application : celui-ci
contient un ensemble de méthodes qui permettent à
une servlet de communiquer avec le conteneur de
servlet ;
getRequestDispatcher() Permet de manipuler une ressource. Elle retourne
un objet RequestDispatcher, qui agit comme une
enveloppe autour de la page JSP. Il est impératif d'y
préciser le chemin complet vers la JSP.
forward() réexpédier la paire requête/réponse HTTP vers la
page JSP.
46 Ghada Feki
L'EL permet de récupérer l'information sur un bean (s'il a
été mis préalablement dans un scope par une servlet avec
un setAttribute):
${nomBean.property}
- nomBean est celui défini lors du setAttribute fait par la servlet
- property est le nom de la propriété que l'on veut accéder
48 Ghada Feki
12
Un Scope
Un scope peut être vu comme un conteneur de beans stocké du  Application : ce scope est créé automatiquement au
côté du serveur (le client ne peut avoir aucune connaissance sur lancement du projet JEE sur le serveur. Les beans qu'il
ces beans).
contient sont partagés par tous les clients et ne sont
Il existe 4 types de Scopes, que l'on distingue par la durée de vie
des beans qui y sont stockés : détruit que lors de l'arrêt/rechargement du projet JEE sur
 Requête : ce scope est créé à chaque requête du client, les
le serveur.
beans qu'il contient sont détruit lorsque le serveur à envoyé la  Page : ce scope restreint la durée de vie des beans aux
réponse au client requêtes POST effectuées sur une page donnée, dès
 Session : ce scope est créé automatiquement par le qu'on en sort, les beans sont détruit.(Ce scope n'est
conteneur JEE pour chaque client qui se connecte au serveur. quasiment pas utilisé)
Les beans qu'il contient ne sont visible que par le client
détenant la session, et sont détruit lorsque la session du client
se termine (géré par un timeout du côté du serveur)

49 Ghada Feki 50 Ghada Feki

Partage de données sur requête:

Partage de données sur requête exemple simple

51 Ghada Feki 52 Ghada Feki

13
Partage de données sur session
53 Ghada Feki
Manipulation d'objets (JavaBeans) dans
les JSP
 Les JavaBeans forment la partie modèle.
 But: Gérer les structures de données.
 Recommandations pour un objet java (JavaBean):
 être une classe publique;
 avoir au moins un constructeur par défaut, public et sans
paramètres;
 ne doit pas avoir de champs publics ;
 peut définir des propriétés (des champs non publics), qui
doivent être accessibles via des méthodes publiques getter et
setter, suivant des règles de nommage.
 Ces objets java peuvent implémenter l'interface Serializable, ils
deviennent ainsi persistants et leurs états peuvent être
sauvegardés;
55 Ghada Feki
Expression Language (EL)
 Syntaxe
 Limiter la présence du langage Java (non spécialiste)
 Meilleure lisibilité, le code se limite au nom des beans et de ses propriétés
 Les Expressions Languages (EL) permettent de manipuler les données d’une page
JSP (essentiellement les Beans)
 Une EL permet d’accéder simplement aux beans des différents scopes de
l’application (page, request , session et application)
 Utilisation optimale des JSP (facile, court, simple et concis).
 Forme : ${ expression }
 Opérateurs :
 Arithmétiques, applicables à des nombres : +, -, *, /, % ;
 Logiques, applicables à des booléens : &&, ||, ! ;
 Relationnels, basés sur l'utilisation des méthodes equals() et compareTo() des objets
comparés : == ou eq, != ou ne, < ou lt, > ou gt, <= ou le, >= ou ge.
 Condition: test ? si oui : sinon ;
 Vérification si vide (null) : opérateur empty.
54 Ghada Feki
Java Standard Tag Library (JSTL)
 La JSTL est une bibliothèque, une collection regroupant
des balises implémentant des fonctionnalités à des fins
générales, communes aux applications web. Citons par
exemple la mise en place de boucles, de tests
conditionnels, le formatage des données ou encore la
manipulation de données XML. Son objectif est de
permettre au développeur d'éviter l'utilisation de code
Java dans les pages JSP, et ainsi de respecter au mieux le
découpage en couches recommandé par le modèle MVC.
 Le but de la JSTL est de simplifier le travail des auteurs
de JSP, c’est-à-dire les acteurs responsables de la couche
présentation.
56 Ghada Feki
14

 La JSTL permet de développer des pages JSP en utilisant
des balises XML sans connaissances du langage Java.
 Sun a proposé une spécification pour la Java Standard Tag
Library voir adresse java.sun.com/ jsp/ jstl.
 L’implémentation proposée vient du projet Jakarta JSTL
1.1 disponible à l’adresse jakarta.apache.org/ taglibs.
 Avantage: Rend le code plus facile à lire, à réutiliser et à
maintenir.
 La dernière version est JSTL 1.2.
 C’est un ensemble de balises personnalisées qui propose
des fonctionnalités souvent rencontrées dans les page JSP.
 Utilisation conjointe avec les Expressions Languages (EL).
57 Ghada Feki
La librairie Core
 Cette bibliothèque « core » comporte les actions de base
pour la gestion des variables de scope d’une application
web :
 Affichage de variable, création, modification et
suppression de variables de scope et de gestion des
exceptions;
 Actions conditionnelles et boucles;
 Manipulation d’URL et redirection.
58 Ghada Feki

 Elle propose les tags suivants répartis dans trois  Mise en place
catégories :
Catégorie Tag  Configurer Tomcat : mettre JSTL 1.2 (fichier jar dans lib
set de WEB-INF)
out
Utilisation de EL
remove  Configurer Eclipse pour qu'il connaisse les balises JSTL :
catch ajouter la directive taglib à la JSP.
if <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"
choose
Gestion du flux (condition et itération)
forEach %>
forTokens
import
Gestion des URL url
redirect
59 Ghada Feki 60 Ghada Feki

15
Syntaxe Core - Tag out
 Le tag out permet d'envoyer dans le flux de sortie de la  L'attribut default permet de définir une valeur par défaut
JSP le résultat de l'évaluation de l'expression fournie dans si le résultat de l'évaluation de la valeur est null. Si la
le paramètre " value ". valeur est null et que l'attribut default n'est pas utilisé
alors c'est une chaîne vide qui est envoyée dans le flux de
sortie.
Attribut Rôle <c:out value="${personne.nom}" default="Inconnu" />
value valeur à afficher (obligatoire)
default définir une valeur par défaut si la valeur est null  Le tag out est particulièrement utile pour générer le code
escape booléen qui précise si les caractères particuliers (< > & ...) dans un formulaire en remplaçant avantageusement les
Xml doivent être convertis en leurs équivalents HTML (&lt; &gt; scriplets.
&amp ; ...)
<input type="text" name="nom" value="<c:out
value="${param.nom}"/>" />

61 Ghada Feki 62 Ghada Feki

Syntaxe Core - Tag if

 Ce tag permet d'évaluer le contenu de son corps si la <c:if test="${empty personne.nom}" >Inconnu</c:if>
condition qui lui est fournie est vraie. Il possède plusieurs  Le tag peut ne pas avoir de corps s'il est simplement
attributs : utilisé pour stocker le résultat de l'évaluation de la
condition dans une variable.
Attribut Rôle <c:if test="${empty personne.nom}" var="resultat" />
test condition à évaluer  Le tag if est particulièrement utile pour générer le code
var nom de la variable qui contiendra le résultat de dans un formulaire en remplaçant avantageusement les
l'évaluation scriplets.
scope portée de la variable qui contiendra le résultat

63 Ghada Feki 64 Ghada Feki

16
Syntaxe Core - Tag choose
 Ce tag permet de traiter différents cas mutuellement <c:choose>
<c:when test="${personne.civilite == 'Mr'}">
exclusifs dans un même tag. Le tag choose ne possède pas
Bonjour Monsieur
d'attribut. Il doit cependant posséder un ou plusieurs tags </c:when>
fils « when ». <c:when test="${personne. civilite == 'Mme'}">
 Le tag when possède l'attribut test qui permet de Bonjour Madame
préciser la condition à évaluer. Si la condition est vraie </c:when>
<c:when test="${personne. civilite == 'Mlle'}">
alors le corps du tag when est évalué et le résultat est
Bonjour Mademoiselle
envoyé dans le flux de sortie de la JSP </c:when>
 Le tag otherwise permet de définir un cas qui ne <c:otherwise>
correspond à aucun des autres cas inclus dans le tag. Ce Bonjour
tag ne possède aucun attribut. </c:otherwise>
</c:choose>

65 Ghada Feki 66 Ghada Feki

Syntaxe Core - Tag forEach

 Ce tag permet de parcourir les différents éléments d'une  A chaque itération, la valeur de la variable dont le nom
collection et ainsi d'exécuter de façon répétitive le est précisé par la propriété var change pour contenir
contenu de son corps. Il possède plusieurs attributs : l'élément de la collection en cours de traitement.
Attribut Rôle  Pour les attributs, la seule obligation est d'avoir défini soit
var nom de la variable qui contient l'élément en cours de l'attribut items, soit les attributs begin et end.
traitement
items collection à traiter
 Le tag forEach peut aussi réaliser des itérations sur les
varStatus nom d'une variable qui va contenir des informations sur nombres et non sur des éléments d'une collection. Dans
l'itération en cours de traitement ce cas, il ne faut pas utiliser l'attribut items mais
begin numéro du premier élément à traiter (le premier possède
le numéro 0)
uniquement utiliser les attributs begin et end pour fournir
end numéro du dernier élément à traiter les bornes inférieures et supérieures de l'itération.
step pas des éléments à traiter (par défaut 1)

67 Ghada Feki 68 Ghada Feki

17
 Syntaxe Core - Tag forTokens
<c:forEach begin="1" end="4" var="i">  Ce tag permet de découper une chaîne selon un ou
<c:out value="${i}"/><br> plusieurs séparateurs donnés et ainsi d'exécuter de façon
</c:forEach> répétitive le contenu de son corps autant de fois qu'il y a
d'occurrences trouvées.
 Il possède plusieurs attributs :
 L'attribut step permet de préciser le pas de l'itération.
Attribut Rôle
var variable qui contient l'occurrence en cours de traitement
(obligatoire)
<c:forEach begin="1" end="12" var="i" step="3"> items la chaîne de caractères à traiter (obligatoire)
<c:out value="${i}"/><br> delims précise le ou les séparateurs
varStatus nom d'une variable qui va contenir des informations sur l'itération
</c:forEach> en cours de traitement
begin numéro du premier élément à traiter (le premier possède le
numéro 0)
end numéro du dernier élément à traiter
69 Ghada Feki 70 Ghada Feki
step pas des éléments à traiter (par défaut 1)

 L'attribut delims peut avoir comme valeur une chaîne de caractères ne
contenant qu'un seul caractère (délimiteur unique) ou un ensemble de
caractères (délimiteurs multiples).
<c:forTokens var="token" items="chaine 1;chaine 2;chaine 3" delims=";">
<c:out value="${token}" /><br>
</c:forTokens>
 Dans le cas où il y a plusieurs délimiteurs, chacun peut servir de séparateur.
<c:forTokens var="token" items="chaine 1;chaine 2,chaine 3" delims=";,">
<c:out value="${token}" /><br>
</c:forTokens>
 Il n'y a pas d'occurrence vide. Dans le cas où deux séparateurs sont
juxtaposés dans la chaîne à traiter, ceux-ci sont considérés comme
un seul séparateur. Si la chaîne commence ou se termine par un
séparateur, ceux-ci sont ignorés.
<c:forTokens var="token" items="chaine 1;;chaine 2;;;chaine 3"
delims=";">
<c:out value="${token}" /><br>
</c:forTokens>
 Il est possible de ne traiter qu'un sous-ensemble des occurrences de
la collection. JSTL attribut à chaque occurrence un numéro
incrémenté à partir de 0.
 Les attributs begin et end permettent de préciser une plage
d'occurrences à traiter.


71 Ghada Feki 72 Ghada Feki

18
 Contrôle d'un formulaire par une Servlet
<c:forTokens var="token" items="chaine 1;chaine 2;chaine 3"  La balise form annonce le début d'un formulaire.
delims=";" begin="1" end="1" >
 Attribut method de la balise form peut avoir ces deux
<c:out value="${token}" /><br>
valeurs :
</c:forTokens>
 GET: correspond à l'appel d'une page par le navigateur
 Résultat: chaine 2
(barre d'adresse ou lien)
 Transmet les paramètres dans l'URL :
 Il est possible de n'utiliser que l'attribut begin ou l'attribut end.  http://localhost:8080/servlet/test?param=value
Si seul l'attribut begin est précisé alors les dernières  POST: plus adapté au transfert de données depuis un
occurrences seront traitées. Si seul l'attribut end est précisé
alors seules les premières occurrences seront traitées. formulaire
 Les attributs varStatus et step ont le même rôle que ceux du
tag forEach.
73 Ghada Feki 74 Ghada Feki

Le contrôle un formulaire par une sevlet se fait

principalement en deux phases :
 Au niveau de la servlet :
Liaison Sevlet-JSPformulaireInit par doGet.
Liaison Sevlet-JSPformulaireResultat par doPost.
 Au niveau de la JSP formulaireInit :
Mentionner la servlet comme action dans le formulaire avec Conteneur EJB
method=post. Java EE
Ghada Feki

75 Ghada Feki

19
Plan La logique métier
 La logique métier
 La logique métier sera implémentée dans les EJB qui sont
 Le conteneur EJB des composants transactionnels côté serveur et
accessibles à distance par leurs clients.
 Les EJB (Enterprise JavaBeans)
 Les EJB s’exécutent dans des serveurs Java EE
 Interfaces des Enterprise JavaBeans fonctionnant comme des serveurs intermédiaires dans un
système client/serveur.
 Les objets distribués

 Les Middlewares

77 Ghada Feki 78 Ghada Feki

 Deux types de conteneurs sont utilisés dans
l’architecture Java EE : le conteneur Web et le conteneur
EJB.
• Le conteneur Web est un environnement d’exécution
pour les pages JSP et les servlets qui constituent une
passerelle entre l’interface utilisateur et les EJB
implémentant la logique métier.
• Le conteneur EJB est un environnement d’exécution
pour les EJBs. Le conteneur EJB contient les
composants métiers et leur fournit des services.
Le conteneur EJB
 Du côté serveur, l’accès aux différentes ressources s’avère
complexe.
 Avec les EJB, la plupart des tâches se font par déclaration,
évitant ainsi d’écrire du code spécifique pour gérer les
transactions ou la persistance.
 Il s’agit de se concentrer sur le développement des
composants en déléguant au conteneur EJB l’implantation
des services techniques et la fourniture de ces services
durant l’exécution.

79 Ghada Feki 80 Ghada Feki

20
 À un composant est associé un descripteur de
déploiement, pour signifier par exemple qu’un bean soit
persistant, sécurisé et accessible par plusieurs clients en
même temps.
 Le serveur est responsable du traitement de ce
descripteur et assure l’exécution de ces services.
81 Ghada Feki
 La gestion de la persistance : les composants persistants
peuvent choisir de déléguer leur persistance sur le
support de persistance au conteneur.
 La gestion des transactions : les composants persistants
peuvent choisir de déléguer la gestion de leurs
transactions au conteneur, qui implémente les
mécanismes transactionnels nécessaires à la réalisation de
la logique transactionnelle décrite par les beans.
83 Ghada Feki
Les principales fonctionnalités fournies par un conteneur
d’EJB sont :
 La connectivité entre les clients et les EJB :
• le conteneur gère les communications entre les clients
et les EJB ;
• après le déploiement d’un EJB dans un serveur
d’applications, le client peut invoquer les méthodes de
cet EJB comme si elles étaient situées dans la même
machine virtuelle ;
• les communications sont assurées par le Middleware
sous-jacent de manière transparente.
82 Ghada Feki
 La gestion de la sécurité :
• politiques de sécurité déclarées mais non codées par
le développeur,
• support de la sécurité basé sur l’API sécurité de Java,
• méthodes liées à la sécurité implémentées par le
conteneur,
• utilisation des attributs de sécurité définis dans le
descripteur de bean utilisé lors de la phase de
déploiement.
84 Ghada Feki
21

 La gestion de la concurrence : Les composants peuvent
être invoqués par un seul client ou par plusieurs clients
simultanément.
 La gestion du cycle de vie des composants : création et la
destruction des instances des composants.
 La gestion du pool de connexions :
• connexion à une BD = coûteuse en termes de
ressources,
• nombre de connexions limité par le nombre de licences,
• solution : le conteneur gère un pool de connexions.
85 Ghada Feki
 Un composant EJB est constitué d’une collection de
classes Java et d’un fichier XML, fusionnés en une entité
unique.
 Le conteneur prend en charge tout ce qui concerne le
système. Cette séparation des tâches est le concept
fondamental de cette technologie.
 Un composant EJB est conçu comme un ensemble
réutilisable de logiques métiers et fonctionne avec tous
les types de clients : servlets, JSP, application Java/RMI,...
87 Ghada Feki
Les EJB (Enterprise JavaBeans)
 Le développement de logiciel a vu apparaître dans les
années 90 la notion de composant comme des morceaux
de code standards, préconstruits, réutilisables et
encapsulant de la logique métier.
 Les composants EJB sont conçus pour encapsuler la
logique métier et éviter au développeur d’applications de
se préoccuper de : transaction, sécurité, concurrence,
communication, persistance, gestion d’erreurs...
86 Ghada Feki
 La spécification Enterprise JavaBeans 1.1 définit 2 types de
beans : bean entité et bean session.
 La spécification Enterprise JavaBeans 2.0 introduit un
troisième bean : le bean message.
 Il existe donc 3 types de beans :
•les beans sessions,
•les beans entités,
•les beans messages.
88 Ghada Feki
22
 Les beans sessions
 Un bean session représente un processus. C’est une
Avec état extension du processus du client dans le serveur
Session d’applications Java EE.
Sans état
 On distingue 2 types de beans sessions : les beans
Logique métier Composants
Composants sessions sans état (stateless session) et les beans sessions
CMP
EJB
EJB
Entité avec état (stateful session).
Conteneur EJB BMP
Message  Un bean session ne peut avoir qu’un client à un moment
donné.

89 Ghada Feki 90 Ghada Feki

 Pour un bean session sans état, plusieurs clients peuvent
être associés au même bean successivement.
 Pour un bean session avec état, c’est le même client qui
réalise toutes les invocations.
 Un bean session sans état représente un traitement
fonctionnel.
 Un bean session avec état possède un état
conversationnel, c’est à dire un état résultant des
interactions avec un même client.
 L’état représenté par un bean session est privé et
conversationnel . Le bean est accessible par un client
unique.

 Exemple d’un bean session sans état : le calcul d’un

itinéraire entre 2 points ou la demande d’un virement
entre 2 comptes.

91 Ghada Feki 92 Ghada Feki

23

Exemple de bean session avec état :
 un panier sur un site de commerce électronique
possédant deux attributs : un pour le nom du client et un
pour les articles sélectionnés par ce client.
 Ce bean peut posséder une méthode telle que
ajouterArticle() que le client va invoquer pour ajouter un
nouvel article dans le panier.
93 Ghada Feki
 Un bean entité peut être utilisé par plusieurs clients
simultanément.
 L’état représenté par un bean entité est partagé et
transactionnel. Le bean constitue le point d’accès unique à
ces données par différents clients.
 La persistance d’un bean entité peut être gérée par le
bean lui-même ou bien par le conteneur.
95 Ghada Feki
Les beans entités
 Un bean entité représente un objet métier persistant.
 Par exemple, un bean entité représente une commande,
un article, un compte bancaire.
 Les attributs d’un bean entité peuvent être stockés dans
une base de données ou tout autre support de
persistance.
94 Ghada Feki
• Dans le premier cas (gérée par le bean lui-même) : les
opérations de lecture et d’écriture sur le support de
persistance doivent être codées dans le bean (par
exemple du code SQL pour une BDR).
⇒ on parle de bean BMP (Bean Managed Persistence).
96 Ghada Feki
24

• Dans le second cas (gérée par le conteneur) : la
persistance est gérée par le conteneur et seules les
fonctionnalités de recherches avancées doivent être
codées dans le bean, les autres opérations de lecture et
d’écriture sur le support de persistance sont effectués
automatiquement par le conteneur.
⇒ on parle de bean CMP (Container Managed Persistence).
97 Ghada Feki
Interfaces des Enterprise JavaBeans
 Les composants EJB possèdent des interfaces exposant
leurs services disponibles aux clients.
 Les clients utilisent ces interfaces pour exécuter la
logique encapsulée dans le bean.
 Il existent 2 sortes d’interfaces : les interfaces distantes et
les interfaces locales.
 Ces interfaces permettent de préciser quelles seront les
méthodes métiers des Beans qui seront accessibles
depuis l’intérieur ou l’extérieur d’un serveur
d’application.
99 Ghada Feki
Les beans messages
 Les beans sessions et entités sont des composants
distribués invoqués par des clients de manière synchrone,
c’est-à-dire par invocation de méthodes
 Les beans messages sont des beans qui consomment des
messages de manière asynchrone, par l’intermédiaire de
Java Messaging Service (JMS).
 Exécution sur réception d’un message JMS
(Appel à d’autres beans par exemple).
98 Ghada Feki
Les objets distribués - base des EJB
 Les objets distribués sont forts utiles puisqu’ils
permettent de distribuer une application sur un réseau.
 Cependant, des exigences telles que les transactions et la
sécurité deviennent indispensables dans des applications
d’entreprise.
100 Ghada Feki
25

 Un objet distribué est un objet qui peut être appelé
depuis un système distant, notamment :
• depuis un client faisant partie du processus contenant
l’objet (in-process),
• depuis un client en dehors de ce processus (out-of-
process)
• depuis un client situé n’importe où sur le réseau.
 Différentes technologies permettent d’utiliser des objets
distribués telles que CORBA de OMG, DCOM de
Microsoft et Java RMI-IIOP de Sun
101 Ghada Feki
 De manière transparente pour le développeur : sans qu’il
ait besoin de coder des mécanismes pour assurer ces
services.
⇒ Ce type d’infrastructure est appelée Middleware.
 D’autres services sont nécessaires :
• optimisation des accès aux ressources (pool de
connexions...),
• mécanisme d’activation/désactivation des objets,
• mécanisme de répartition de charge et de tolérance
aux pannes.
103 Ghada Feki
Les Middlewares
 Les objets distribués nécessitent une infrastructure
technique permettant d’assurer la communication entre
ces objets.
 Cette infrastructure doit fournir aux objets un accès aux
services transversaux comme les services de nommage,
de gestion des transactions, de gestion de persistance, de
gestion de sécurité...
102 Ghada Feki
Exemple d’application Java EE
 Un exemple type d’application basée sur l’architecture
Java EE est celui d’une application de e-commerce :
 Le client se connecte sur le site Web d’un magasin,
consulte un catalogue des articles disponibles, en choisit
certains qu’il met dans un panier électronique et règle ses
achats.
Modéliser le besoin avec les différents types de beans.
104 Ghada Feki
26
 Du côté du serveur Web, les pages JSP et servlets
utilisent:
 des beans entités qui correspondent aux objets métiers
comme les articles, clients, commandes, factures;
 des beans sessions avec état représentant les paniers des
clients;
 des beans sessions sans état qui peuvent implémenter des La persistance des données en Java (JPA)
traitements comme la navigation dans un catalogue ou la Java EE
demande d’un devis pour le contenu d’un panier.
Ghada Feki

105 Ghada Feki

JPA Limites de JDBC

 JPA : Java Persistence API  Java avec stockage des données dans une BDD
 Framework de persistance en Java relationnelle
 ORM : Object-Relationnal Mapping  Nécessite des requêtes SQL
 API définie sur la base d'Hibernate, ORM de référence dans le monde  Utilisation d'un framework dédié : JDBC
Java
 Sort du format « standard » de représentation Java des
 Peut fonctionner avec d'autres moteurs de persistance
données (classes et objets)
 Principes  Une requête de type SELECT retourne un ResultSet
 On définit la correspondance entre la structure des classes objet et le  C'est à dire un ensemble de ligne de plusieurs colonnes
schéma relationnel de la BDD
 On accède aux éléments du ResultSet en naviguant selon les lignes et
 On manipule directement des objets dans le code les colonnes, case par case
 Le framework fait la lecture/enregistrement du contenu des objets sur le  Peu pratique mais difficile de faire autrement vu ce que retourne de
support physique manière native les requêtes SQL
 Plus besoin de coder des requêtes SQL  Sauf à passer par des SGBD objet-relationnel

107 Ghada Feki 108 Ghada Feki

27

 Java avec stockage BDD et accès via JDBC
 Au delà de l'accès à faire à distance
 Qui complexifie forcément les choses mais ne peut pas y
couper
 Représentation des données très différentes
 Coté BDD
 Structure en table avec langage de requête dédié
 Récupère toujours une « sous-table » via le résultat de
l'exécution d'une requête de type SELECT
 Coté Java
 Structure des données définies par les classes que l'on
instancie
109 Ghada Feki
Fonctionnement général de JPA
 Définition de correspondances entre classes et tables
 On ne manipulera que des objets métier coté Java
 API de JPA offre des fonctionnalités pour
 Récupérer des objets à partir de leur contenu en BDD
 Usage au besoin d'un langage de requête ressemblant à SQL mais se
basant sur la structure des classes
 Rendre des objets créés persistants
 Leur contenu est inséré dans la BDD
 Faire toute opération de création / modification /
suppression sur des objets avec persistance en BDD
 Se fait en mode transactionnel
 JPA est une API qui nécessite un moteur l'implémentant
 Hibernate, EclipseLink …
111 Ghada Feki
De JDBC à JPA
 Avec un framework ORM comme JPA
 Définition des correspondances classes / tables
 Avec des classes Java classiques (POJO : Plain Old Java Object)
 Gére ensuite tout seul la cohérence objet / contenu base
 JDBC
 Très simple d'exécuter des requêtes SQL
 Mais ensuite le programmeur doit tout gérer à la main
 JPA
 Framework assez complexe mais très puissant
 Qui supprime une très grande partie du code nécessaire avec
JDBC
110 Ghada Feki
Mappings : entités Java– tables SQL
 Indépendance de définition des structures de données
 On modélise d'un coté le métier et de l'autre la BDD en s'attachant à faire
les meilleures implémentations / conceptions selon le domaine
 Coté métier : structure métier et facilité de manipulation des données
 Coté BDD : optimiser la gestion des données et performance d'accès
 On définira ensuite les mappings requis entre les classes et tables
 Une classe Java est mappée vers une table dite primaire
 La plupart des attributs de la classe ont une correspondance avec les
colonnes de la table
 Pourra utiliser d'autres tables dites secondaires pour la correspon- dance
d'autres attributs
 Via des jointures réalisées automatiquement par JPA
 Une classe pourra fusionner le contenu de deux (ou plus) tables
 Pourra gérer tout type de jointures entre tables /associations entre classes
112 Ghada Feki
28
Entité Annotations
 Classe Java qui a vocation à avoir le contenu de ses  Les mappings classes / tables sont définis par des
objets rendu persistant en BDD  annotation Java dans les classes des entités
 Ou dans des fichiers XML mais moins pratique
 Classe standard : un POJO (Plain Old Java Object)  Annotations Java : méta-données
 Définit des attributs de tout type  Données sur des données
 Et éventuellement des méthodes métier  S'appliquent sur des éléments du code
 Précise qu'un élément joue un certain rôle, a certaines
 Peu de contraintes à respecter (programmation classique) caractéristiques, informer de quelque chose …
 Constructeurs dont un sans paramètre  Une annotation peut contenir des paramètres (nommés s'il y en a
 Getters et setters pour les attributs plusieurs)
 Un attribut jouera un rôle d'identifiant  Une annotation commence par @
 Exemple : @Override pour préciser que c'est la rédéfinition d'une
 Implémente java.io.Serializable méthode de la classe mère
 Rédéfinir equals() et hashcode() pour gestion des collections  Une annotation est définie par une classe Java dédiée

113 Ghada Feki 114 Ghada Feki

Annotations des entités Annotation basique d'attributs

 Annotations JPA définies dans le package javax.persistence
 @Entity
 Définit une classe comme étant une entité EJB dont les instances
pourront être rendues persistantes
 Paramètre name=''nomEntite''
 Nom optionnel de l'entité : par défaut le nom de la classe
 A utiliser si deux classes de même nom dans 2 packages différents
 @Table(name = "compte")
 Définit la table primaire mappée sur la classe
 Paramètres
 name : nom de la table, optionnel si la classe a le même nom
 schema, catalog : optionnel, si utile à préciser, sinon valeurs par défaut
 uniqueConstraints : optionnel, contraintes d'unicité sur des colonnes
115 Ghada Feki
 Cas où le contenu d'une colonne mappe directement le contenu d'un attribut
de type simple (pas de collection)
 @Basic : mapping colonne/attribut
 Optionnel, s'applique par défaut : pour préciser des options
 fetch : FetchType (voir plus loin)
 optional : boolean, si remplir l'attribut est obligatoire ou pas
 @Id : si l'attribut est un identifiant d'objet (aucun paramètre)
 @Column : optionnel, précision de paramètres
 Application implicite par défaut sur la base de même nom entre un attribut
et une colonne
 Plusieurs paramètres optionnels dont
 name : String, par défaut égal au nom de la propriété
 table : String, si colonne vient d'une autre table que la primaire
 unique : boolean, si unicité des valeurs de la colonne
116 Ghada Feki

29
Manipulation d'entités persistantes
 Configuration d'une unité de persistance  <persistence-unit ...>
 Fichier XML définissant la liste des classes correspondant à  Définit le nom de l'unité de persistance et le type de transaction utilisée
des entités, la connexion au SGBD, divers paramètres …  <provider>
 Dans l'application Java  Le moteur de persistance utilisé par JPA
 Récupère un « entity manager »  <class>
 A partir de ce gestionnaire, on manipulera les entités  Définit qu'une classe Java sera une entité dont les instances seront
persistantes en base de données
 Récupération d'instances d'entités en base, rendre
persistant de nouvelles instances, modifier des entités …  <properties>
 Ensemble de propriétés de configuration
 Les modifications se font via une transaction
 Ici on retrouve les paramètres de connexion à la base via JDBC
 Avec Jave EE, on peut utiliser d'autres fonctionnalités  URL, driver, utilisateur et mot de passe
comme JTA pour les transactions ou JNDI pour les
annuaires
117 Ghada Feki 118 Ghada Feki

Langage de requête JPQL

 JPA définit un langage de requête similaire à SQL
 Mais travaillant sur la structure des classes directement
 Requêtes statiques
@NamedQuery, @NamedNativeQuery
 Requêtes dynamiques
définition de la requête à l’exécution
 EntityManager permet de créer et exécuter les requêtes
createNamedQuery, createQuery, createNativeQuery
 Recherche par identifiant
find et getReference permettent de retrouver une entité en
donnant son Id
Elles ont deux paramètres
Class<T> pour indiquer le type de l’entité recherchée
Object pour indiquer la clé primaire
Exemple :
public void supprimeCommande(Long commandeId) {
Commande cmde = entityManager.find(Commande.class,
commandeId); entityManager.remove(cmde);
}

119 Ghada Feki 120 Ghada Feki

30
 Requêtes statiques
Paramétrage
Définition @NamedQuery( name=“clientParNom”,
@NamedQuery(name=“clientParCodePostal”, query = “SELECT c FROM Client c
WHERE c.adresse.codePostal = :cp”) queryString=“SELECT c FROM Client c ” + “WHERE c.nom LIKE :nomClient”
@Entity public class Client { )
…
}
@PersistenceContext public EntityManager em; List clients =
Utilisation em.createNamedQuery(“clientParNom”)
public List rechercheClientParCodePostal(int cp) { return .setParameter(“nomClient”,“Marchand”)
em.createNamedQuery(“clientCodePostal”)
.setParameter(“cp”, cp) .getResultList();
.setMaxResults(20)
.get
}

121 Ghada Feki 122 Ghada Feki

 Requêtes dynamiques  Update, delete

public List rechercheAvecNom (String nom) { return em.CreateQuery ( UPDATE Employe e

“SELECT c FROM Client c ” + “WHERE c.nom LIKE :nomClient”) SET e.salaire = e.salaire * 1.1
.setParameter(“nomClient”, nom) WHERE e.departement.nom = ‘Informatique’
.setMaxResults(10)
.getResultList(); DELETE
} FROM Client c
WHERE c.status = ‘inactif’ AND c.commandes IS EMPTY AND c.solde = 0

123 Ghada Feki 124 Ghada Feki

31
 Entity Manager  persist()
C’est lui qui est chargé de gérer le cycle de vie des entités public Commande creerCommande(Client c) { Commande cmde =
Équivalent de Hibernate Session ou JDO PersistenceManager 4 new Commande(c);
opérations principales // Après l’appel à persist(), l’état de l’entité passe
• persist() // transient à managed.
• insère une entité dans la base // Au prochain commit, l’instance sera insérée dans la
• remove() // base de données entityManager.persist(cmde); return cmde;
• supprime une entité de la base }
• merge()
 merge()
• synchronise l’état des entités détachées
la méthode merge() retourne une copie gérée (managed) de l’entité
• refresh()
(préalablement détachée)
• recharge l’état des entités à partir de la base les modifications sur l’état persistant sont appliquées à l’instance gérée

125 Ghada Feki 126 Ghada Feki

Références
Livres :
 Designing Entreprise Applications (Auteur : Nicholas
Kassem and the Entreprise Team / Editeur : Sun
Microsystems )
 Java Servlet Programming (Auteur : Jason Hunter et
William Crawford / Editeur : OREILLY / ISBN : 1-56592- Merci de votre attention
391-X)
 Supports de cours :
 Java EE (Servlets / JSP) (Auteur : Fabien Romeo)
 Les Entreprise JavaBeans(EJB) (Auteur : Jean-Marc
Farinone)
 Les Entreprise JavaBeans (Auteur : Claue Duallet)

127 Ghada Feki 128 Ghada Feki

32