REPUBLIQUE TUNISIENNE MINISTERE DE L’ENSEIGNEMENT SUPERIEUR, DE LA RECHERCHE SCIENTIFIQUE ET DES TECHNOLOGIES DE L'INFORMATION ET DE LA COMMUNICATION
DIRECTION GENERALE DES ETUDES TECHNOLOGIQUES INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE KASSERINE
SUPPORT DE COURS & TRAVAUX DIRIGES Programmation N-TIERS Adressé aux étudiants en troisième année de Licence Appliquée en Technologies de l’Informatique Parcours Multimédia et Développement Web
Elaboré par : Fatma zahra BOUZIDI
Assistante technologue
Contact :
[email protected]
Année Universitaire 2013/2014
Avant-propos Cet ouvrage « PROGRAMMATION
N-TIERS
» est à l’intention des étudiants
de troisième année en Licence appliquée en technologies de l’informatique à l’Institut Supérieur des Etudes Technologique de Kasserine, parcours Multimédia et Développement Web . L’étudiant trouvera dans cet ouvrage une initiation à la programmation Ntiers en prenant comme exemple la plateforme JavaEE, il s’agit
de
préparer l’étudiant à apprendre les compétences théoriques nécessaires pour programmer une application
faisant la distinction entre la
présentation, le traitement et les données en imbriquant quelques API de javaEE . Après avoir compris les différentes architectures et la plateforme JavaEE, l’étudiant sera capable à la fin de cet ouvrage de créer une application simple selon le modèle MVC et de s’approfondir sur la programmation NTiers. Ce cours nécessite des prérequis: des notions en développement Java et des notions en langages HTML sont nécessaires. L’ouvrage est divisé en cinq chapitres : Le premier chapitre décrit les niveaux d’abstraction d’une application. Le découpage de ces niveaux en couches définit son architecture. Ce chapitre présente rapidement différent architectures applicatifs ainsi que leurs inconvénients et avantages. Le deuxième chapitre présente la plateforme JavaEE, ses API, son architecture, et son environnement d’exécution : l’étudiant sera capable
de distinguer entre les différentes couches d’une architecture JavaEE et les API qui les composent ainsi que le mode d’assemblage et de déploiement de chaque module d’une application JavaEE. Le troisième chapitre introduit les API Servlet et JSP en présentant les concepts nécessaires pour comprendre chaque composant : définition, radiographie, cycle de vie. Le quatrième chapitre représente le noyeau de ce cours en décrivant une implémentation simple d’une architecture MVC imbriquant les API servlet, Jsp et un objet Java : l’étudiant sera capable de collaborer entre une servlet et une Jsp, de savoir transmettre des données issues d’un client et des
données
issus
d’un
serveur
et
de
comprendre
un
exemple
implémentant le modèle MVC. Le
dernier chapitre
introduit l’API
javaBean et
présente une
implémentation de modèle MVC imbriquant les composants JSP, Servlet et javaBean.
Domaine de Formation : Sciences et Technologies
Mention TI
Mention : Technologies de l’Informatique (TI)
Spécialité MDW
Parcours : Multimédia et Développement Web
Semestre S5
UNITÉ D’ENSEIGNEMENT (UE) : PROGRAMMATION N-
Crédits : 5
Coef : 5
TIERS
Volume Horaire par Semestre : 90
Semaine : 6
Fiche Matière Élément Constitutif (ECUE)
PROGRAMMATION N-TIERS Ventilation / Semaine
Vol. Horaire / Semestre Cours 11.2 5 0.75
TD 11.2 22.5 5 0.75 1.5
Coeffici ent
Crédit s
TP 0 0
1.5
1.5
Évaluati on
Contrôle continu
Objectif(s) Génér(al)/(aux) Le cours vise à donner à l’apprenant les compétences théoriques nécessaires pour programmer des applications faisant la distinction entre l'aspect métier et les aspects non fonctionnels.
Objectifs Spécifiques - Comprendre l’architecture client serveur. - Comprendre l'architecture N-Tiers: Tiers présentation, tiers métier, tiers données. -Comprendre l’architecture MVC - Comprendre La plate-forme Java: J2EE -savoir programmer des servlets -savoir programmaer des jsps -savoir programmer des javabeans -Etre capable de mettre en œuvre une architecture MVC
Mots-Clés Client, Serveur, Métier, Plate-forme, Architecture, J2EE, MVC, N-Tiers, JSP, Servlet, JavaBean etc.
Pré-requis UE : Développement Web 1.
Éléments de Contenu
-
Architecture Client Serveur. Architecture N-Tiers. Architecture MVC Plate-forme J2EE JSP,Servlet,JavaBean Implémentation de MVC
Moyens et Outils Pédagogiques -
Cours, Travaux dirigés, mini-projet
Table des matières Chapitre I Présentation générale............................................................................. 1 1
Les trois niveaux d'abstraction d'une application.........................................2
2
L'architecture 1-tiers..................................................................................... 2
3
4
5
6
2.1
Présentation........................................................................................... 2
2.2
Limitations.............................................................................................. 3
L'architecture 2-tiers..................................................................................... 4 3.1
Présentation........................................................................................... 4
3.2
Avantages et inconvénients de l'architecture 2-tiers.............................4
L'architecture 3-tiers..................................................................................... 5 4.1
Présentation........................................................................................... 5
4.2
Avantages et inconvénients de l'architecture 3-tiers..............................6
Les architectures N-tiers...............................................................................7 5.1
Présentation........................................................................................... 7
5.2
Avantages et inconvénients de l'architecture N-tiers :..........................8
L’architecture Modèle-Vue- Contrôleur (MVC) :............................................8 6.1
Présentation........................................................................................... 8
6.2
Avantages et inconvénients..................................................................10
6.3
Différence avec l’architecture 3-tiers....................................................10
Chapitre II Présentation de la plateforme Java EE...............................................12 1
La présentation de Java EE.........................................................................13
2
Les API de Java EE....................................................................................... 13
3
Architectures en Java EE............................................................................. 14 3.1
Les composants clients ou tiers Client..................................................15
3.2
Les composants Web ou tiers Web.......................................................17
3.3
Les composants métier ou tiers Métier.................................................17
3.4
Enterprise Information System Tier......................................................18
4
Les conteneurs Java EE............................................................................... 18
5
L'assemblage et le déploiement d'applications J2EE...................................20
Chapitre III Introduction aux Servlets et pages JSP..............................................22 1
Introduction aux Servlets............................................................................23 1.1
Qu’est-ce qu'une servlet.......................................................................23
2
1.2
Cycle de vie d’une servlet....................................................................23
1.3
Radiographie d’une première servlet....................................................27
Introduction aux JSP.................................................................................... 30 2.1
Pourquoi une JSP?.................................................................................30
2.2
C’est quoi une JSP?...............................................................................30
2.3
Cycle de vie d'une JSP..........................................................................31
2.4
Radiographie d’un Script JSP................................................................33
2.5
Les Balises JSP...................................................................................... 35
2.6
Les variables prédéfinis :......................................................................39
Chapitre IV Implémentation de MVC....................................................................40 1
MVC et Java EE............................................................................................ 41
2
Collaboration entre JSP et servlets : l’interface requestdispatcher.............41
3
Transmission de données: les paramètres et les attributs..........................43
4
3.1
Différence entre paramètres et attributs..............................................43
3.2
Transmission des attributs : méthodes setAttribute() et getAttribute() 44
3.3
Transmission des paramètres : méthode getParameter().....................45
Exemples d’applications du design pattern MVC :.....................................46 4.1
Exemple1 :............................................................................................ 46
4.2
Exemple 2 :........................................................................................... 55
Chapitre V JavaBeans et Scope...........................................................................60 1
JavaBeans................................................................................................... 61 1.1
C’est quoi un Javabean.........................................................................61
1.2
Structure d’un Javabean.......................................................................61
1.3
Comment utiliser des beans ?..............................................................61
2
Implémentation du MVC (avec les JavaBeans)............................................62
3
Les Scopes d’un bean................................................................................. 66 3.1
Partage de données sur requête...........................................................66
3.2
Partage de données sur session...........................................................67
3.3
Partage de données sur application (Rare)...........................................68
Travaux dirigées................................................................................................... 70 TD N°1 : Les bases................................................................................................. 71 Correction TD N°1 : Les bases..................................................................................73 TD N°2 : Introduction aux Servlets et pages JSP.............................................................79 Correction TD N°2 : Introduction aux Servlets et pages JSP...............................................81 TD N°3: Implémentation de MVC..............................................................................95 Correction TDN°3 : Implémentation de MVC..............................................................100
DEVOIR SURVEILLE............................................................................................. 109 EXAMEN.................................................................................................................. 1 REFERENCES.......................................................................................................... 1
Liste des figures Figure I-1 : Schéma explicatif du modèle MVC.....................................................11 Figure II-1 Architecture Java EE standard..............................................................17 Figure II-2 : Tier client, Tier web et Tier métier.....................................................18 Figure II-3 : Tiers Web et Tiers Métier Java EE.......................................................20 Figure II-4 : Serveur Java EE et conteneurs...........................................................21 Figure III-1 : L’interface Servlet............................................................................. 26 Figure III-2 : cycle de vie d’une Servlet.................................................................27 Figure III-3 : cycle de vie détaillé d’une servlet....................................................29 Figure III-4 : traitement de deux requêtes par le serveur.....................................30 Figure III-5 : recherche de la Ssevlet dans le fichier web.xml...............................33 Figure III-6 : CorrespondanceJSP/Servlet...............................................................34 Figure III-7 : Cycle de vie d’une JSP......................................................................36 Figure IV-1 : Collaboration entre JSP et servlets...................................................45 Figure IV-2 : Liste des promos.............................................................................. 51 Figure IV-3 : Étape 1 du modèle MVC...................................................................51 Figure IV-4 : Étape 2 du modèle MVC...................................................................53 Figure IV-5 : Étape 3 du modèle MVC...................................................................54 Figure IV-6 : Étape 4 du modèle MVC...................................................................56 Figure IV-7 : Étape 5 du modèle MVC..................................................................57 Figure IV-8 : Liste des promos.............................................................................. 58 Figure IV-9 : Formulaire HTML............................................................................... 59 Figure IV-10 : pages d'affichage des données de formulaire................................59 Figure V-1 : implémentation du MVC....................................................................67
Liste des tableaux Tableau II-1 : Les différents types d'archives........................................................23
CHAPITRE I : PRESENTATION GENERALE
Chapitre I Présentation générale OBJECTIFS
L’objectif de ce chapitre est de :
1
Comprendre le découpage en couches d’une application ; Comprendre l’architecture Client/serveur ; Connaitre les architectures 1-Tiers, 2-Tiers, 3-Tiers et N-Tiers ; Comprendre l’architecture MVC.
Les trois niveaux d'abstraction d'une application
En général, une application informatique peut être découpée en trois niveaux d'abstraction distincts : La présentation, encore appelée IHM permet l'interaction de l'application avec l'utilisateur. Cette couche gère les saisies au clavier, à la souris et la présentation des informations à l'écran. Dans la mesure du possible, elle doit être conviviale et ergonomique. La logique applicative, les traitements, décrivant les travaux à réaliser par l'application. Ils peuvent être découpés en deux familles : Les traitements locaux, regroupant les contrôles effectués au niveau du dialogue avec l'IHM, visant essentiellement le contrôle et l'aide à la saisie, Les traitements globaux, constituant l'application elle-même. Cette couche, appelée Business Logic ou couche métier, contient les règles internes qui régissent une entreprise donnée. Les données, ou plus exactement l'accès aux données, regroupant l'ensemble des mécanismes permettant la gestion des informations stockées par l'application. 1
CHAPITRE I : PRESENTATION GENERALE
Ces trois niveaux peuvent être imbriqués ou répartis de différentes manières entre plusieurs machines physiques. Le découpage et la répartition de ces niveaux permettent de distinguer les architectures applicatives suivantes : 2
l'architecture 1-tiers ; l'architecture 2-tiers ; l'architecture 3-tiers ; les architectures n-tiers. L'architecture 1-tiers
2.1 Présentation Dans une application 1-tiers, les trois couches applicatives sont fortement liées et s'exécutent sur le même ordinateur. On ne parle pas ici d'architecture client-serveur, mais d'informatique centralisée. Dans un contexte multi-utilisateurs, on trouve les applications sur site central : les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs se comportant en esclaves. C'est le serveur central qui prend en charge l'intégralité des traitements, y compris l'affichage qui est simplement déporté sur des terminaux passifs.
Figure I-1 Architecture 1-tiers 2
CHAPITRE I : PRESENTATION GENERALE
2.2 Limitations Les applications sur site central souffrent d'une interface utilisateur en mode caractères et la cohabitation d'applications micro exploitant des données communes n'est pas fiable au delà d'un certain nombre d'utilisateurs. Il a donc fallu trouver une solution conciliant les avantages des deux premières :
La fiabilité des solutions sur site central, qui gèrent les données de
façon centralisée, l'interface utilisateur moderne des applications sur micro-ordinateurs.
Pour obtenir cette synthèse, il a fallu scinder les applications en plusieurs parties distinctes et coopérantes :
gestion centralisée des données ; gestion locale de l'interface utilisateur ;
Ainsi est né le concept du client-serveur; 3
L'architecture 2-tiers
3.1 Présentation Dans une architecture 2-tiers, encore appelée client-serveur de première génération ou client-serveur de données, le poste client se contente de déléguer la gestion des données à un service spécialisé. Ce type d'application permet de fournir à l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent gérées de façon centralisée. La gestion des données est prise en charge par un SGBD centralisé, s'exécutant le plus souvent sur un serveur dédié. Ce dernier est interrogé en utilisant un langage de requête qui, le plus souvent, est SQL.
3
CHAPITRE I : PRESENTATION GENERALE
Figure I-2 : Architecture 2-tiers
3.2 Avantages et inconvénients de l'architecture 2-tiers Avantages L’architecture 2-tiers présente de nombreux avantages :
elle permet l'utilisation d'une interface utilisateur riche ; elle a permis l'appropriation des applications par l'utilisateur ; elle a introduit la notion d'interopérabilité.
Inconvénients : Le client lourd L'expérience a démontré qu'il était coûteux et contraignant de vouloir faire porter l'ensemble des traitements applicatifs par le poste client. On en arrive aujourd'hui à ce que l'on appelle le client lourd, ou fat client. L'architecture client-serveur de première génération s'est heurtée à ce constat à l'heure des premiers bilans :
on ne peut pas soulager la charge du poste client, qui supporte la
grande majorité des traitements applicatif ; le poste client est fortement sollicité, il devient de plus en plus complexe et doit être mis à jour régulièrement pour répondre aux besoins des utilisateurs ; 4
CHAPITRE I : PRESENTATION GENERALE
la relation étroite qui existe entre le programme client et l'organisation de la partie serveur complique les évolutions de cette dernière.
Pour résoudre les limitations du client-serveur 2-tiers tout en conservant ses avantages, on a cherché une architecture plus évoluée, facilitant les forts déploiements à moindre coût. La réponse est apportée par les architectures distribuées 4
L'architecture 3-tiers
4.1 Présentation Les limites de l'architecture 2-tiers proviennent en grande partie de la nature du client utilisé, la solution résiderait donc dans l'utilisation d'un poste client simple communicant avec le serveur par le biais d'un protocole standard. Dans ce but, l'architecture 3-tiers, encore appelée client-serveur de deuxième génération ou client-serveur distribué, sépare l'application en trois niveaux de service distincts :
premier niveau : l'affichage et les traitements locaux (contrôles de saisie, mise en forme de données...) sont pris en charge par le poste
client ; deuxième niveau : les traitements applicatifs globaux sont pris en
charge par le service applicatif ; troisième niveau : les services de base de données sont pris en charge par un SGBD.
Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes.
5
CHAPITRE I : PRESENTATION GENERALE
Figure I-3 : Architecture 3-tiers
4.2 Avantages et inconvénients de l'architecture 3-tiers Avantages : Le client léger Dans l'architecture 3-tiers, le poste client est communément appelé client léger ou Thin Client, par opposition au client lourd des architectures 2tiers. Il ne prend en charge que la présentation de l'application avec, éventuellement, une partie de logique applicative permettant une vérification immédiate de la saisie et la mise en forme des données. Il est souvent constitué d'un simple navigateur Internet. Le poste client ne dispose d'aucune connaissance des traitements applicatifs ou de la structure des données exploitées. Les évolutions de l'application sont donc possibles sans nécessiter de modification de la partie cliente.
Inconvénients L'architecture 3-tiers a corrigé les excès du client lourd en centralisant une grande partie de la logique applicative sur un serveur HTTP. Le poste client, qui ne prend à sa charge que la présentation et les contrôles de saisie, s'est trouvé ainsi soulagé et plus simple à gérer. Par contre, le serveur HTTP se trouve souvent fortement sollicité et il est difficile de répartir la charge entre client et serveur.
6
CHAPITRE I : PRESENTATION GENERALE
Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures 2-tiers : le client est soulagé, mais le serveur est fortement sollicité. Le juste équilibrage de la charge entre client et serveur semble atteint avec la génération suivante : les architectures n-tiers. 5
Les architectures N-tiers
5.1 Présentation L'architecture N-tiers a été pensée pour pallier aux limitations des architectures 3-tiers et concevoir des applications puissantes et simples à maintenir. L'appellation N-tiers pourrait faire penser que cette architecture met en oeuvre un nombre indéterminé de niveaux d'application, alors que ces derniers sont au maximum trois (pour rappel : la couche IHM – la couche applicative – la couche d’accès aux données). En fait, l'architecture N-tiers qualifie la distribution de la couche applicative entre de multiples services et non la multiplication des couches. Les composants ‘‘métiers'' de la couche applicative sont spécialisés et indépendants. Ils communiquent entre eux et peuvent donc coopérer en étant implantés sur des machines distinctes. Ce
type
d'architecture
permet
de
distribuer
librement
la
logique
applicative, ce qui facilite la répartition de la charge entre tous les niveaux.
7
CHAPITRE I : PRESENTATION GENERALE
Figure I-4 : Architecture N-tiers
5.2 Avantages et inconvénients
de l'architecture N-
tiers : Avantages : Théoriquement, ce type d'architecture supprime tous les inconvénient s des architectures précédentes :
Elle permet l'utilisation d'interfaces utilisateurs riches ; Elle sépare nettement tous les niveaux de l'application ; Elle offre de grandes capacités d'extension ; facilite la gestion des sessions.
Inconvénient : 6
Nécessite des ressources matérielles importantes L’architecture Modèle-Vue- Contrôleur (MVC) :
6.1 Présentation L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une application. Elle consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'application. Dans l'architecture MVC, les rôles des trois entités sont les suivants. 8
CHAPITRE I : PRESENTATION GENERALE
La vue : Ce qu'on nomme la vue est en fait une IHM. Celle-ci est en fait ce qu'a l'utilisateur sous les yeux. La vue peut donc être :
Une
C#...) ; une page web Un terminal Linux ou une console Windows...
application
graphique swing, awt, swt pour
Java
(Form pour
Le modèle : Il décrit les données manipulées par l'application .Le modèle représente le cœur de l'application : traitements des données, interactions avec la base de données, etc.. Il regroupe la gestion de ces données et est responsable de leur intégrité. Le modèle comporte des méthodes standards pour mettre à jour ces données (insertion, suppression, changement de valeur).
Le contrôleur Contrôleur: son rôle est de traiter les événements en provenance de l’interface utilisateur et les transmet au modèle pour le faire évoluer ou à la vue pour modifier son aspect visuel (pas de modification des données affichées mais des modifications de présentation (couleur de fond, affichage ou non de la légende d’un graphique, …)). Le contrôleur ‘connaît’ la (les) vues qu’il contrôle ainsi que le modèle.
Le contrôleur pourra
appeler des méthodes du modèle pour réagir à des événements (demande d’ajout d’un client par exemple), il pourra faire modifier à la vue son aspect visuel.
Il pourra aussi instancier
de nouvelles
vues (demande
d’affichage de telle ou telle info). Pour faire cela, le contrôleur sera à l'écoute d'événements survenant sur les vues.
Interactions Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le schéma de la figure suivante.
9
CHAPITRE I : PRESENTATION GENERALE
Figure I-5 : Schéma explicatif du modèle MVC
6.2 Avantages et inconvénients Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En
effet, la
modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base
de données de type SQL à XML en changeant
simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectées. Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web,
bâties à partir de serveurs d'applications. Des
couches supplémentaires sont alors introduites ainsi que les mécanismes de dépendance.
6.3 Diférence avec l’architecture 3-tiers L'architecture 3-tiers est un modèle en couches, c'est-à-dire, que chaque couche communique seulement avec ses couches adjacentes (supérieures 10
CHAPITRE I : PRESENTATION GENERALE
et inférieures) et
les couches supérieures contrôlent les couches
inférieures, c'est-à-dire, que les couches supérieures sont toujours sources d'interaction (clients) alors que les couches inférieures ne font que répondre à des requêtes (serveurs). Dans le modèle MVC, il est généralement admis que la vue puisse consulter directement le modèle (lecture) sans passer par le contrôleur. Par contre, elle doit nécessairement passer par le contrôleur pour effectuer une modification (écriture). Le contrôleur peut envoyer des requêtes à toutes les vues de manière à ce qu'elles se mettent à jour. Dans l'architecture 3-tiers, si une vue modifie les données, toutes les vues concernées par la modification doivent être mises à jour, d'où l'utilité de l'utilisation du MVC au niveau de la couche de présentation. De
plus,La
différence
fondamentale
se
trouve
dans
le
fait
que
l'architecture 3-tiers sépare la couche Buisness logic (couche métier) de la couche Data access (accèsaux données).Pour qu'une application MVC soit une vraie application 3-tiers il faut lui ajouter une couche d'abstraction d'accès aux données. Inversement pour qu'une application 3-tiers respecte MVC il faut lui ajouter une couche de contrôle entreUser interface et Buisness logic. Loin d'être antagonistes, ces deux pratiques se combinent et sont la fondation de la plupart des frameworks de création d'applications Web.
En résumé : Ce chapitre a présenté brièvement les architectures 1-tiers, 2-tiers, 3-tiers, N-tiers et MVC, ainsi que
leurs avantages et
inconvénients. Dans les
chapitres suivant on étudiera la distinction entre les aspects présentation, métier, et données en utilisant la technologie java EE.
11
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
Chapitre II
Présentation de la plateforme
Java EE OBJECTIFS L’objectif de ce chapitre est de :
Comprendre la plateforme java EE ; Connaître les différentes couches d’une application java EE multi-
tiers et leur distribution sur les machines ; Savoir les différents APIs de la plateforme qui composent chaque
couche ; Connaitre les différents éléments qui constituent l’environnement
d’exécution des applications java EE multi-tiers ; Connaitre le mode d’assemblage et de déploiement des applications java EE multi-tiers.
1
La présentation de Java EE
J2EE est l'acronyme de Java 2 Entreprise Edition. Cette édition proposé par Sun Microsystems, désormais Oracle Corporation,
est dédiée à la
réalisation d'applications pour entreprises. J2EE est basé sur J2SE (Java 2 Standard Edition) qui contient les API de base de Java. Depuis sa version 5, J2EE est renommé Java EE (Enterprise Edition). La plate-forme J2EE offre un environnement de développement et déploiement en langage Java pour les applications distribuées à plusieurs niveaux. Elle est composée de deux parties essentielles :
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent les composants écrits en Java : un tel environnement se
nomme serveur d'application ; un ensemble d'API qui peut être obtenu et utilisé séparément.
L'utilisation
de
J2EE
pour
développer
et
exécuter
une application
propose plusieurs avantages :
une architecture d'application basée sur les composants qui permet un découpage de l'application et donc une séparation des rôles lors du
développement ; la possibilité de s'interfacer avec le système d'information existant
grâce à de nombreuses API : JDBC, JNDI, JMS, JCA ... la possibilité de choisir les outils de développement et le ou les serveurs d'applications utilisés qu'ils soient commerciaux ou libres
2
Les API de Java EE
Une API (Application Programming Interface) est une interface de programmation. C’est un ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle, un système d’exploitation ou un service. Les API de Java EE peuvent se répartir en trois grandes catégories :
Les composants. On distingue habituellement deux familles de composants : o Les composants web : Servlets et JSP (Java Server Pages). Il s'agit de la partie Chargée de l'interface avec l'utilisateur (on parle de logique de présentation) ; o Les composants métier : EJB (Enterprise Java Beans). Il s'agit de composants Spécifiques chargés des traitements des données propres à un secteur d'activité (on parle de logique métier ou de logique applicative) et de l'interfaçage avec les bases de
données. Les services, pouvant être classés par catégories : o Les services d'infrastructures : il en existe un grand nombre, définis ci-dessous :
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
-
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 et aux annuaires d'entreprises tels que
-
DNS, LDAP, etc..; JTA/JTS (Java Transaction API/Java Transaction Services) est une
-
API de gestion des transactions ; J2EE Connector est une API qui facilite les connexions aux plates-
-
formes autres que J2EE ; JMX (Java Management
Extension)
fournit
des
extensions
permettant de développer des applications web de supervision d'applications. o 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. ; JMS (Java Message Service) Permet à 2 composants d'applications
-
J2EE de créer, envoyer et recevoir des messages ; RMI-IIOP est une API permettant la communication synchrone entre objets.
3
Architectures en Java EE
J2EE permet une grande flexibilité dans le choix de l'architecture de l'application en combinant les différents composants. Ce choix dépend des besoins auxquels doit répondre l'application mais aussi des compétences dans les différentes API de J2EE. D'après le schéma ci-après, la spécification Java EE définit les composants suivants :
Les composants Clients (ou tier Client) s'exécutent sur la machine des
utilisateurs ; Les composants Web(ou tiersWeb) s'exécutent sur le serveur J2EE ; Les composants métier ou ( tier Métier) s'exécutent sur le serveur Java
EE ; La partie stockage des données, nommée tiers Enterprise Information System (EIS), s'exécute sur le serveur de base de données.
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
Figure II-6 Architecture Java EE standard Une application Java EE multi-tiers correspond à un ensemble de couches. Elle est distribuée de manière physique sur trois machines :
La machine des clients ; Le serveur d'applications Java EE ; Le serveur de base de données ou de stockages.
3.1 Les composants clients ou tiers Client La plate-forme Java EE propose trois types de clients : les clients Web, les Applets et les applications clientes riches type Java SE.
3.1.1 Les clients Web Un client Web consiste en des pages Web de différents types (HTML, XHTML, XML, JavaScript ou autres) générées à partir de composants exécutés côté serveur dans un conteneur Web.
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
Un client Web se compose de deux parties: des pages web de différents types (HTML, XML, etc) générées à partir de composants Web exécutés côté serveur, et d'un navigateur Web, ce qui permet d’afficher les pages reçues du serveur. Un client Web est parfois appelé un client léger.
3.1.2 Les clients Applets Une page Web reçu de la couche web peut inclure une applet intégrée. Une applet est une petite application cliente écrite en langage de programmation Java qui s'exécute dans la machine virtuelle Java installée dans le navigateur. Cependant cette technique est plus contraignante à maintenir, requiert des accès et des droits pour la sécurité et nécessite un plug-in pour les navigateurs. Les clients Web sont donc préférables pour la création du tiers Client.
3.1.3 Les applications clientes Une application de type client est un logiciel riche, qui s'exécute sur la machine du client et fournit un ensemble de services aux utilisateurs par l'intermédiaire
d'une
interface
graphique
évoluée
encore
appelée
Graphical User Interface (GUI). Ces applications riches sont développées avec les composants SWING en général, exécutées Application Client Container (ACC).
Figure II-7 : Tiers client, Tiers web et Tiers métier
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
La figure ci-dessus montre les différents types de clients utilisés dans une plate-forme Java EE. Les clients riches de type application communiquent directement avec le tiers Métier alors que les clients de type navigateur Internet communiquent à travers le tiers Web par l'intermédiaire de pages exécutées sur le serveur et générées par des Servlets, JSP ou JSF.
3.2 Les composants Web ou tiers Web Les composants Web Java EE sont des Servlets et/ou des pages web ( JavaServer Pages et/ou des JavaServer Faces). Les Servlets sont des classes Java, capables d'intercepter et de gérer les requêtes du protocole HTTP. Les pages JSP sont des documents textuels exécutés comme des Servlets apportant une solution simplifiée pour la programmation de pages Web. La technologie JavaServer Faces est construite à partir de Servlets et fournit un framework de développement pour accélérer la création d'applications Web.
3.3 Les composants métier ou tiers Métier Les composants métier ou tiers Métier représentent la couche business, avec les données du système, et sont de deux types : Les entités beans (entity bean ou bean entity) peuvent être exécutées par un conteneur léger (pas forcément un serveur Java EE) Les Enterprise JavaBeans offrent des possibilités plus riches comme la gestion des transactions, les accès directs par clients riches ou encore la gestion automatique des sessions utilisateur, mais sont exécutés sur un conteneur lourd, c'est-à-dire compatible Java EE.
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
Figure II-8 : Tiers Web et Tiers Métier Java EE
3.4 Enterprise Information System Tier La partie stockage des données, nommée Enterprise Information System (EIS) Tier est directement liée au tiers Métier et correspond dans la majorité des cas, aux systèmes de gestion de bases de données (Derby, MySQL, PostgreSQL, Oracle ou autres) ou n'importe quel système de stockage évolué. 4
Les conteneurs Java EE
Les serveurs Java EE proposent plusieurs types de conteneurs (containers) pour chaque type de composant. Chaque conteneur a un rôle bien défini et offre un ensemble de services pour les développeurs. Les conteneurs assurent la gestion du cycle de vie des composants qui s'exécutent en eux et fournissent des services qui peuvent être utilisés par les applications lors de leur exécution.
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
Une application Java EE de type Web nécessite un conteneur Web pour son exécution alors qu’une application utilisant les EJB nécessite un conteneur EJB pour son exécution. Chaque conteneur propose un ensemble de services avec ses avantages et ses contraintes. Les serveurs d’applications peuvent fournir un conteneur web uniquement (exemple : Tomcat) ou un conteneur d'EJB uniquement (exemple : JBoss, Jonas, ...) ou les deux (exemple : Websphere, Weblogic, ...).
Figure II-9 : Serveur Java EE et conteneurs Le serveur Java EE est composé de deux types de conteneurs :
Web Container ou conteneur Web, capable d’exécuter des pages JSP, Servlets et programmes JSF (implémentation JSF nécessaire). Ces composants s’exécutent avec le conteneur serveur Java EE. Ce conteneur supporte les protocoles HTTP et HTTPS et dialogue avec différents types de clients (navigateur, application) ;
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
EJB Container ou conteneur EJB, responsable de la couche métier et de l’exécution des EJB. Ce conteneur fournit le mécanisme de gestion des EJB et la gestion de leur cycle de vie ;
5
L'assemblage et le déploiement d'applications J2EE
Pour déployer une application dans un conteneur, il faut lui fournir deux éléments :
l'application
avec
tous
les
composants
(classes
compilées,
ressources ...) regroupée dans une archive ou module. Chaque
conteneur possède son propre format d'archive. un fichier descripteur de déploiement contenu dans le module qui précise au conteneur des options pour exécuter l'application
Il existe différents types d'archives : Descript Archive
/
module
Contenu
Extensi eur on
de
déploie ment
application client
Regroupe les ressources nécessaires à
applicatio
leur exécution (classes, bibliothèques, jar
n-
images, ...)
client.xml
Regroupe les servlets et les JSP ainsi Web
que les ressources nécessaires à leur exécution (classes, bibliothèques de
war
web.xml
balises, images, ...) EJB
Regroupe les EJB et leurs composants (classes)
jar
ejbjar.xml
Tableau II-1 : Les diférents types d'archives
Une application J2EE peut regrouper différents modules : modules web,
CHAPITRE II : PRESENTATION DE LA PLATEFORME JAVA EE
modules EJB ... Chacun de ces modules possède son propre mode de packaging. J2EE propose de regrouper ces différents modules dans un module unique sous la forme d'un fichier EAR (Entreprise Archive). Le format de cette archive est très semblable à celui des autres archives :
un contenu : les différents modules qui composent l'application
(module web, EJB, fichier RAR, ...) ; un fichier descripteur de déploiement nommé application.xml.
En résumé Ce chapitre a donné un aperçu sur la plateforme JavaEE et les différentes API qui la composent, il a décrit les différents éléments qui composent l'environnement d'exécution des applications JavaEE et leurs modes d'assemblage et de déploiement. Dans le chapitre qui suit nous allons découvrir les servlets et les jsp qui seront utilisés pour implémenter le modèle MVC.
Chapitre III : Introduction aux Servlets et pages JSP
Chapitre III
Introduction aux Servlets et
pages JSP OBJECTIFS L’objectif de ce chapitre est de :
1
Comprendre le cycle de vie d’une servlet ; Savoir programmer une servlet ; Comprendre le cycle de vie d’une jsp ; Savoir programmer une jsp.
Introduction aux Servlets
1.1 Qu’est-ce qu'une servlet Une Servlet est un composant web conçu sous la forme d’une classe java qui existe au sein d’une application web et dont la mise en œuvre est géré par un conteneur web (exemple Tomcat ). une Servlet interagit avec un client web par l’intermédiaire du protocole http, via un mécanisme de requête/réponse. Une servlet s'exécute dynamiquement sur le serveur web et permet l'extension des fonctions de ce dernier. Typiquement : accès à des bases de données, transactions d'e-commerce, etc. Une servlet peut être chargée automatiquement lors du démarrage du serveur web ou lors de la première requête du client. Une fois chargées, les servlets restent actives dans l'attente d'autres requêtes du client.
1.2 Cycle de vie d’une servlet Une servlet est un objet qui peut être manipulé par le conteneur via l’interface suivante:
Chapitre III : Introduction aux Servlets et pages JSP
Figure III-10 : L’interface Servlet Lorsque le conteneur reçoit une requête, il la transmet au servlet qui correspond à l’URL pour que la requête soit traitée effectivement. Le cycles de vie d’une servlet se résume comme suit : 1. Chargement de la classe 2. Instanciation du servlet (constructeur par défaut) 3. Appel de init() 4. Appel(s) de service()(1 thread par requête) 5. Appel de destroy()
Chapitre III : Introduction aux Servlets et pages JSP
Figure III-11 : cycle de vie d’une Servlet
Les servlets ne sont pas des objets instanciés à chaque requête HTTP, Il n'existe qu'une et une seule instance d'une servlet dans le
conteneur. Ce qu'il se passe c'est que pour chaque requête HTTP, un thread est créé pour satisfaire la requête et proposer une réponse :
Si on reprend la vie de notre servlet partant du principe que la servlet est initialisée, voici ce que ça donnerait :
La servlet reçoit une requête HTTP ; Elle crée les deux objets : o Un objet HttpServletRequest contenant les informations de la requête HTTP ; o Un objet HttpServletResponse, servant à fournir la réponse attendue.
Une fois ceci fait, il va utiliser la servlet correspondant à la requête demandée
et
va
invoquer
la
méthode
adéquate,
ici
doGet(HttpServletRequest request, HttpServletResponse response)
Elle alloue un nouveau thread à cette requête ; Elle invoque la méthode service (HttpServletRequest
request,
HttpServletResponse response) en passant les deux objets en paramètres ;
Chapitre III : Introduction aux Servlets et pages JSP
Ladite méthode invoque la bonne méthode de traitement (doGet, doPost, doHead, doDelete, doPut,...) ; il y existe une méthode pour chaque type de requête HTTP, les plus utilisées sont o GET : méthode doGet() , c' est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet ; o POST : méthode doPost() , cette méthode doit être utilisée lorsqu'une requête modifie la ressource ;
Figure III-12 : Type de requête HTTP Le schéma ci-dessous explique la différence entre les requêtes de type Get et Post:
Le traitement se fait ; La réponse est renvoyée au client.
Voici un schéma illustrant le cycle de vie d’une servlet (partant du principe que la servlet est initialisée)
Chapitre III : Introduction aux Servlets et pages JSP
Figure III-13 : cycle de vie détaillé d’une servlet A chaque fois que le conteneur reçoit une requête HTTP, il crée les objets requête et réponse puis, il crée un thread afin d'invoquer la méthode service (HttpServletRequest req, HttpServletREsponse rep)… Voici petit schéma résumant ce qu'il se passe lorsque deux personnes envoient une requête vers la même ressource sur le serveur :
Chapitre III : Introduction aux Servlets et pages JSP
Figure III-14 : traitement de deux requêtes par le serveur
1.3 Radiographie d’une première servlet Nous examinons l'exemple ci-dessus : La servlet Test.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class Test extends HttpServlet { public
void
doGet(HttpServletRequest
request,
response) throws IOException,ServletException{ response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("
Hello World
"); }
HttpServletResponse
Chapitre III : Introduction aux Servlets et pages JSP
} Le fichier web.xml est le suivant :
Test firstServlet firstServlet /Serv1 /
La servlet : On notera les points suivants :
la servlet HTTP hérite de la classe abstraite HttpServlet ; La méthode déclarée dans notre servlet contient le nom du type de
requête http envoyée : requête de type GET - méthode doGet. la méthode doGet de notre servlet prend deux objets en paramètres et ceux-ci ont des noms qui ressemblent beaucoup à requête HTTP et
réponse HTTP. Ensuite, le contenu de la servlet est très simple : o response.setContentType("text/html") : définit le type de réponse, ici, on retourne une page HTML ; o PrintWriter out = response.getWriter() : on récupère un objet permettant d'écrire dans la future page HTML ; o out.println("....") : écrit dans la page.
Chapitre III : Introduction aux Servlets et pages JSP
Le fichier descripteur web.xml Chaque application sur le serveur a une structure et cette structure est définie dans le fichier web.xml. Il existe Un seul fichier web.xml par application.Ce fichier est utilisé par le conteneur pour faire une relation entre une requête HTTP et une servlet (mapping des servlets). On dit aussi que le fichier sert à définir le contexte de l’ application. , ceci est tout simplement une sorte d'annuaire pour Tomcat : la définition des applications sur le serveur ainsi que la structure de celles-ci. On note les ponts suivants :
Le contenu est englobé par une balise
et La servlet est tout d'abord définie dans l'application via l'élément
. Deux éléments dans ce dernier : o
: code réel de la servlet ; o
: nom interne à l'application. Ensuite, on trouve
contenant les informations de paramétrage client : o
: nom interne à l'application ; o
: nom qui apparaît côté client. Voici un petit récapitulatif de ce qu'il se passe. 1/
Tomcat,
à
son
lancement,
prend
connaissance
des
données
mentionnées dans le fichier de configuration. 2/ Il reçoit une requête HTTP demandant "/", dans notre cas bien sûr. 3/ Il sait que ce nom est associé au nom de servlet "FirstServlet" qui, lui, correspond à la servlet com.servlet.test.DoIt. 4/ Celle-ci est instanciée et la méthode adéquate est invoquée. 5/ La réponse est récupérée par Tomcat qui renvoie cette dernière au client. Voici un petit schéma récapitulatif (les instanciations des objets requêtes et réponses sont tacites) :
Chapitre III : Introduction aux Servlets et pages JSP
Figure III-15 : recherche de la Ssevlet dans le fichier web.xml
2
Introduction aux JSP
2.1 Pourquoi une JSP? La technologie servlet est trop difficile d'accès et ne convient pas à la génération du code de présentation : écrire une page web en langage Java est horriblement pénible. Il est nécessaire de disposer d'une technologie qui joue le rôle de simplification de l'API servlet : les pages JSP sont en quelque sorte une abstraction "haut niveau" de la technologie servlet.
2.2 C’est quoi une JSP? Les pages JSP sont une des technologies de la plate-forme Java EE les plus puissantes, simples à utiliser et à mettre en place. Elles se présentent sous la forme d’une page HTML dans laquelle on peut ajouter du code Java (même principe qu„avec PHP). Pour que le serveur puisse différencier le code HTML du code JSP, il est nécessaire d’entourer les instructions JSP par des éléments de script spécifiques, appelés étiquettes ou encore balises JSP. Ecrire un script JSP demande donc d’acquérir une bonne connaissance du code HTML et d’apprendre à programmer en Java.
Chapitre III : Introduction aux Servlets et pages JSP
Exemple d’une portion de page JSP :
Aujourd’hui, nous sommes le:
<%= (new java.util.Date()) %> IL existe deux syntaxes pour les Jsps : –Standard (JSP 1.2) –XML (JSP 2.0) On ne peut pas mixer les deux versions dans une même page. Il faut utiliser XML pou la page entière si on utilise la deuxième syntaxe.
2.3 Cycle de vie d'une JSP les
JSP
ont
un
cycle
de
vie
un
peu
plus
compliqué
que
les
servlets..Cependant, aussi complexe soit ce cycle de vie, toutes nos JSP sortiront de leurs chrysalides afin de se transformer en servlets et être utilisées par le conteneur.
Figure III-16 : CorrespondanceJSP/Servlet Exemple : CorrespondanceJSP/Servlet JSP d‟origine
Time on server
<%= new java.util.Date() %>
<% baz(); %> <%! private int accessCount = 0; %> Servlet généré parTomcat
Chapitre III : Introduction aux Servlets et pages JSP
public final class XXX_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent{ public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException{ response.setContentType("text/html"); JspWriter out = response.getWriter(); out.write("
Time on server
\r\n"); out.write("
"); out.print( new java.util.Date() ); out.write("
\r\n"); baz(); } private int accessCount = 0 ; }
Le e cycle
de vie d’une jsp ressemble très fortement à celui de la vie
d'une servlet standard. Le schéma suivant représente le cycle de vie d'une JSP :
Chapitre III : Introduction aux Servlets et pages JSP
Figure III-17 : Cycle de vie d’une JSP Examinons un peu ce schéma : 1. Quelqu'un appelle une page JSP, via une URL ou en cliquant sur un lien. 2. La requête est dirigée vers le serveur de notre application. 3. Tomcat prend en charge la requête et s'aperçoit qu'une page JSP est demandée. 4. Il trouve ladite page et la convertit en fichier source java, en servlet pour être exact. 5. Ladite servlet est compilée et mise en mémoire, enfin prête à l'utilisation. 6. La méthode _jspInit() est invoquée. 7. Tomcat crée un nouveau thread pour traiter la demande et invoque dans ce thread la méthode _jspService(). 8. Le résultat, une page entièrement constituée de code HTML, est retournée par Tomcat au demandeur de départ, le client
2.4 Radiographie d’un Script JSP Considérons un exemple de code source d’un premier programme JSP qui affiche la liste suivante des réalisateurs et des films : L. Besson, le grand bleu; F. Truffaut, Jules et Jim; J.-J. Annaud, la guerre du feu; J,-J. Beinex, 37°2 le matin.
Chapitre III : Introduction aux Servlets et pages JSP
Cette liste doit s’afficher sous la forme d’un tableau à deux colonnes, la première pour les réalisateurs, la seconde pour les films réalisés par ces auteurs.
<% @ page contentType="test/html" %> <%-- déclaration de variables -- %> <%! String lFilm [] = {"le grand bleu", "Jules et Jim", "La guerre du feu", "37°2 le matin"}; String lRealisateur [] = {"L. Besson", "F. Truffaut", "J.-J. Annaud", "J.-J. Beineix" }; String lAffiche=""; int i; %> <% lAffiche = "
"; lAffcihe+= " +Réalisateur | Film |
";
Chapitre III : Introduction aux Servlets et pages JSP
for (i=0; i< 4; i++) { lAffcihe+= ""+lRealisateur[i]+" | "; lAffcihe+= ""+lFilm[i]+" |
"; } lAffcihe+= "
"; %> <%= lAffiche %>