projet application web mvc2 avec architecture 3 niveaux - e

IUT Vélzy Université de Versailles Saint Quentin
PROJET APPLICATION WEB MVC2
AVEC ARCHITECTURE 3 NIVEAUX
Licence SIL JJLC
Introduction.
Ce projet est par nature multidimensionnel. Il doit permettre aux étudiants de mettre en œuvre les
concepts vus dans les deux cours. Tout d'abord dans une phase d'étude et de modélisation puis dans
une phase d'implémentation et enfin dans une phase de déploiement et de test.
Le projet est suffisamment dense pour que son développement soit abordé par petites itérations. Les
thématiques d'architecture, de structuration, de protocole, etc, doivent jalonner la réalisation du
projet.
Application WEB 3 tiers ou 3 niveaux.
Une application WEB trois niveaux est divisée comme son nom l'indique en trois parties. Chacune
pouvant être implémentée avec une technologie différente dans une entité qui lui est propre.
Sur ce sujet, la littérature confond assez souvent l'approche en couches et la vision en niveaux. Pour
rappel l'approche en couches de l'architecture distingue : les couches présentation, adaptation,
service, médiation, métier, accès aux données et stockage des données.
La vision en niveaux est liée au nombre d'entités qui composent l'architecture. Cependant chaque
1/22 Licence SIL JJLC
présentation
adapatation
service médiation
métier accès aux données stockage

niveau implémente une ou plusieurs des couches décrites ci-dessus.
Le premier niveau est appelé client. Il a pour rôle d'interagir avec les humains utilisateurs. Il
implémente la couche présentation. Dans le cadre d'une application WEB, il est représenté
physiquement par une machine (PC, tablette, téléphone portable intelligent, télévision, etc) qui
héberge un navigateur capable d'afficher un flux HTML, voire d'exécuter du javascript. Ce
dispositif empile peu de couches logiciels, le terme de client léger est souvent utilisé pour le décrire.
C'est pourquoi il peut être présent sur les périphériques mobiles.
Le second niveau est composite, il implémente les couches de service, de métier, d'accès aux
données, voire de médiation. L'ensemble peut être résumé par le terme de niveau logique de
domaine. Il est déployé dans une entité elle-même logique appelée serveur WEB ou serveur
d'application WEB hébergée sur un serveur qui peut être une entité physique ou virtuelle (machine
virtuelle).
Le dernier niveau représente les données persistantes de l'application le plus souvent stockées dans
une base de données, elle-même déployée sur un serveur physique ou virtuelle (machine virtuelle).
Il implémente la couche de stockage des données.
L'ensemble représente une application client-serveur où le serveur WEB joue à la fois le rôle de
serveur et de client. Serveur pour le navigateur distant de l'utilisateur et client vis à vis du serveur de
base de données. Il s'agit donc bien d'une infrastructure en réseau dont le protocole est HTTP entre
le client et le serveur d'application et un driver au dessus de TCP/IP (ou encore HTTP avec la
technologie RESTful par exemple) entre le serveur d'application et le serveur de la base de données.
Patron de structuration MVC2.
Chaque application logicielle peut être vue comme la composition de trois aspects, de trois
orientations. Le premier aspect, la vue (le « V » de MVC2) est représenté par la partie de
l'application réalisée avec une technologie qui permet d'interagir avec le monde extérieur afin de
présenter de l'information. Cela peut-être une simple interface de programmation (API) mais dans le
cadre d'une application WEB, il s'agit de l'ensemble des pages ou flux de présentation qui sont
affichés par le navigateur HTML du client. Ces pages génèrent des événements lorsque l'utilisateur
manipule leurs composants graphiques (logique événementielle).
Le second aspect, le modèle (le « M » de MVC2) représente l'ensemble du code de l'application qui
structure les données. Le modèle est une représentation des concepts métier mis en œuvre par
l'application. Avec les langages orientés objet, le modèle est encapsulé dans des classes métier sous
la forme de données membres privées. La richesse sémantique du modèle est également exprimé
par les relations qu'entretiennent ces classes entre elles. Le modèle est persistant et permet, côté
serveur, de générer des pages au contenu dynamique (mélange de données statiques et de données
provenant du modèle). Le modèle envoie une notification au contrôleur à chaque fois qu'un
événement extérieur à l'application modifie son état.
Le dernier aspect concerne le code de l'application qui contrôle la logique applicative. Il s'agit du
2/22 Licence SIL JJLC
< réponse SQL
SGBDR
(données)
3
internet
internet
requête HTTP >
Client léger
(navigateur)
1
Serveur web
(application)
2
requête SQL >
< réponse HTTP

contrôleur (le « C » de MVC2). C'est lui qui ordonnance les tâches à accomplir en fonction des
événements qui proviennent soit de la vue soit du modèle. Les événements qui proviennent de la
vue peuvent avoir un impact sur le modèle résumé par l'acronyme CRUD (Create, Read, Update,
Delete). Les événements qui proviennent du modèle, quant à eux, peuvent nécessiter de notifier
l'utilisateur par un rafraîchissement de la vue par exemple.
Le « 2 » de l'acronyme MVC2 signifie qu'il s'agit d'une structuration respectant le patron de
conception Modèle-Vue-Contrôleur mais adapté aux applications WEB. Dans le cadre de ce
type d'application, la responsabilité du seul contrôleur est de faire correspondre une requête
HTTP entrante, provenant d'une page WEB d'un client distant, à un objet côté serveur afin de
traiter cette requête. Cette opération de correspondance est appelée mappage (mapping en
anglais).
Processus de mappage.
Le navigateur WEB du client distant encode une requête HTTP en utilisant l'URL du serveur
d'application WEB. L'URL représente une adresse composite : type du protocole utilisé (HTTP ou
HTTPS), adresse TCP/IP, nom de machine ou nom de domaine puis port TCP suivi du nom de
l'application et d'un nom de cible (endpoint).
Exemples d'URL :
http://172.17.0.3/nom-application/nom/de/cible (port 80 par défaut)
http://192.168.0.128:8080/nom-application/nom/de/cible (port explicite : 8080)
https://www.lapie.com/nom-application/nom/de/cible (port 443 par défaut)
L'adresse représente un ensemble de domaines hiérarchiques. Le nom de l'application et le nom de
la cible représentent un chemin jusqu'à la ressource sollicitée.
C'est grâce à ce système de nommage que la requête est envoyée au serveur WEB puis que le
serveur WEB est capable de « router » la requête jusqu'à la ressource applicative de destination, la
cible.
Les encodages de requêtes HTTP1 les plus utilisés sont la méthode GET et la méthode POST. La
première permet d'envoyer une requête de demande d'informations au serveur WEB, la seconde
d'envoyer une requête porteuse d'informations (par exemple celles contenues dans un formulaire).
La ressource cible côté serveur doit être prévue pour traiter chaque requête selon son type
d'encodage.
1 HTTP: hypertext transfer protocol (RFC 7230 à 7237)
3/22 Licence SIL JJLC
ressource cible
protocole adresse, nom de
machine ou de
domaine
nom de
l'application

La technologie JAVA pour développer des applications WEB.
La distribution JAVA pour développer ce type d'application est celle qui est appelée Enterprise
Edition2 (JAVA EE). Cette distribution est composée de nombreuses technologies qui permettent de
développer des applications d'entreprise.
JAVA EE propose deux solutions, une basée sur des composants simples et une autre sur un
framework très évolué qui a pour nom JSF (Java Server Faces). Les deux solutions respectent le
patron de structuration MVC2 vu plus haut.
Avec la solution basée sur des composants simples, le rôle du modèle est tenu par les classes JAVA
POJO (Plain Old Java Object), la vue par les pages WEB JSP (Java Server Pages) et le
contrôleur par les composants de type SERVLET.
Une SERVLET est un composant qui une fois déployée dans un serveur d'application approprié
(serveur d'application JAVA EE WEB) est capable de répondre à des requêtes HTTP. C'est un
composant multi-thread dont une seule instance est présente durant tout le cycle de vie de
l'application. Cette solution fournit une grande capacité à monter en charge (scalability) et offre par
la même de très bonnes performances.
L'implémentation d'une SERVLET se réalise par héritage. Il faut que la classe SERVLET spécialise
la classe abstraite HttpServlet car c'est elle qui implémente l'API du protocole HTTP.
Exemple de SERVLET :
@WebServlet(urlPatterns="/formulaire")
public class Controleur extend HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse rep) {
…
}
}
Le composant ci-dessus est capable de répondre à une requête HTTP de type GET. La méthode
doGet est invoquée lorsqu'une requête HTTP GET est routée par le serveur grâce à l'URL vers ce
composant. La méthode prend deux arguments. Le premier représente la requête entrante, le second
la réponse du composant au client. L'annotation @WebServlet doit décorer le composant.
Une page JSP (Java Server Page) est une page WEB qui contient des éléments statiques comme
une simple page HTML et des éléments dynamiques exprimés en langage JSP, XML, EL ou JAVA.
Ce type de composant est toujours exécuté au sein du serveur d'application JAVA EE ce qui a
pour conséquence de générer (notion de rendered) un flux HTML vers le navigateur distant. Les
pages JSP sont les composants de la technologie JAVA EE WEB conçues pour implémenter les vues
de l'architecture MVC2.
Exemple de page JSP :
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Exemple de page JSP</title>
</head>
<body>
<%= new java.util.Date()%>
</body>
</html>
2 Pour rappel, il y a trois distributions JAVA : JAVA SE (Standard Edition), JAVA ME (Micro Edition) et JAVA EE
(Enterprise Edition).
4/22 Licence SIL JJLC

serveur JAVA EE
exécution
La page ci-dessus une fois exécutée par le serveur JAVA EE génère un flux HTML vers le
navigateur du client distant. Celui-ci présente ce flux sous la forme d'une page WEB dans laquelle
est affichée la date du serveur.
Présentation de la page WEB
flux HTML
Les classes qui représentent le modèle sont des classes JAVA de type POJO (Plain Old Java
Object). C'est à dire des classes JAVA classiques. Elles représentent les concepts du système
d'information pris en charge par l'application. Ces classes ont vocation à être persistantes. Elles
doivent respecter le standard JavaBean. C'est à dire avoir leurs données membres privées, leurs
accesseurs publics et au moins un constructeur sans argument.
Présentation du projet.
Le projet est archétypique des petites applications WEB. Il s'agit d'une application qui permet à des
internautes de s'abonner à une newsletter. Cette inscription est rendue possible par le biais d'un
formulaire qui une fois soumis à l'application permet de représenter l'abonné sous la forme d'un
objet métier puis de le rendre persistant dans une base de données relationnelle. Une page de
confirmation est retournée à l'internaute une fois l'inscription effectuée.
Contraintes fonctionnelles.
Le scénario du cas d'utilisation (use case) est donc très simple. Cas nominal : l'internaute
désireux de s'abonner remplit les champs du formulaire puis soumet sa saisie au système. Les
champs sont le nom, le prénom et le courriel. Le système enregistre ce nouvel abonné et retourne à
l'internaute une confirmation d'inscription.
Les champs du formulaire sont : le nom, le prénom et l'adresse de courrier électronique du futur
abonné. Tous les champs sont obligatoires. Les informations saisies dans le formulaire sont
dépouillées côté serveur et l'abonné est représenté sous la forme d'un objet de type Abonne.
5/22 Licence SIL JJLC
navigateur
Page JSP
internaute
s'abonner à la newsletter