Les 

architectures Web

1. Les types d’architectures

Dans les applications Web, la communication entre le client et le serveur est réalisée selon le protocole TCP/IP qui est 
chargé du routage des données. Le transit des informations s’effectue selon le protocole HTTP pour le Web, les données 
sont alors transmises entre le client et le serveur via TCP/IP. On distingue alors deux types de clients : 

l Le  client  léger  :  il  est  aussi  appelé  client  Web  car  le  module  d’exécution  est  alors  un  navigateur.  Les  applications  clientes 
sont composées de pages HTML/XHTML voire DHTML avec l’utilisation du langage client JavaScript . 

l Le client lourd : il s’agit  d’une application composée d’une interface graphique évoluée ou en mode console. Dans l’idéal, les 
clients lourds communiquants ne contiennent que la logique présentation (affichage des données). Tous les traitements sont 
délégués à des composants métier distants. 

Il existe actuellement un grand nombre d’architectures utilisées pour le Web. 

L’architecture 2­tiers  est composée de deux éléments, un client et un serveur. Cette architecture physique simple peut 
être représentée de cette façon : 

Cette  architecture  peut  aussi  être  représentée  avec  un  serveur  de  base  de  données  (SGBD),  le  schéma  est  alors  le 
suivant : 

Dans  ce  type  d’architecture,  le  client  assume  les  tâches  de  présentation  et  communique  uniquement  avec  le  serveur 
d’applications.  Le  client  est  dit  ’’lourd’’.  Ce  type  d’architecture  peut  être  développé  très  rapidement  en  fonction  de  la 
complexité du projet. Il existe un très grand nombre d’outils de développement et de langages pour les architectures 2­
tiers. 

Du  point  de  vue  des  inconvénients,  le  problème  d’évolutivité,  de  maintenance  et  la  mise  en  place  lors  de  projets 
complexes peuvent être cités. 

Dans l’architecture  3­tiers , le client est constitué d’un simple navigateur Internet et communique avec le serveur. Cette 

architecture est composée de trois éléments ou trois couches. La couche présentation ou affichage est le client ’’léger’’ 
dans la mesure où il ne fait aucun traitement. La couche fonctionnelle ou métier est en général un serveur Web. Et enfin, 
la couche de données est liée au serveur de bases de données (SGBD). 

© Editions ENI – Tous droits réservés – Copie personnelle de Yasmine MINA SYLLA - 1-
  

l La couche présentation (de premier niveau) souvent appelée IHM (Interface Homme Machine) correspond à la partie visible et 
interactive. Cette partie est réalisée pour le Web en HTML en général avec JavaScript, Flash... 

l La  couche  métier  (de  second  niveau)  correspond  à  la  partie  fonctionnelle  de  l’application.  Les  opérations  à  réaliser,  les 
fonctions  d’accès  aux  données  et  les  traitements  sont  mis  à  la  disposition  des  utilisateurs  et  invoqués  par  leurs  requêtes. 
Pour  fournir  ces  services,  elle  s’appuie  parfois  sur  la  couche  accès  aux  données  et  en  retour  renvoie  à  la  couche 
présentation les résultats qu’elle a calculés. 

l La dernière couche (de troisième niveau) gère l’accès aux données du système. Ces données peuvent être stockées sur le 
même  système  (fichiers,  fichiers  XML,  base  de  données,  images...)  ou  sur  d’autres  systèmes.  L’accès  aux  données  est 
transparent pour la couche métier et correspond uniquement à la préoccupation de la couche accès aux données. 

D’une  manière  générale  cette  abstraction  améliore  la  maintenance  du  système.  Parmi  les  avantages  de  cette 
architecture,  la  flexibilité  de  l’ensemble  peut  être  citée.  La  partie  client  est  composée  uniquement  d’affichage  (pas  de 
programmation, de requêtes SQL...). De fait, des modifications peuvent être réalisées au niveau du SGBD sans que cela 
apporte un impact sur la couche client. De même, par la suite toute nouvelle technologie peut être introduite sans tout 
remettre en question. Du point de vue développement, la séparation entre le client, le serveur et le SGBD permet une 
spécialisation des développeurs et une meilleure répartition des tâches et fonctions (développeur de modèle/designer, 
programmeur, administrateur de bases de données...). 

Le gros inconvénient de ce modèle (et le principal), est l’expertise qu’il est nécessaire d’avoir et qui est assez longue à 
obtenir pour bien maîtriser chaque tiers et interconnexions. Les coûts de développement d’une architecture 3­tiers sont 
plus élevés que pour du 2­tiers. 

L’architecture  n­tiers   a  été  pensée  pour  pallier  les  limitations  des  architectures  3­tiers  et  concevoir  des  applications 
puissantes et simples à maintenir. D’un point de vue théorique, cette architecture permet de solutionner les problèmes 
suivants : 

l Elle permet l’utilisation de clients riches. 

l Elle sépare nettement tous les niveaux de l’application. 

l Elle facilite la gestion des sessions. 

l Elle offre de grandes capacités d’extension. 

Une définition possible de ce type d’architecture est : une architecture 3­tiers dans laquelle le traitement des données 
(couche accès aux données ou middleware) contient lui­même plusieurs couches multipliant ainsi les tiers. 

Les types d’architectures en Java EE

Dans  ce  cas,  l’application  cliente  peut  être  développée  avec  des  composants  graphiques  (Swing  par  exemple)  et  faire 
appel à des règles métier EJB qui accèdent à une base de données. 

- 2- © Editions ENI – Tous droits réservés – Copie personnelle de Yasmine MINA SYLLA
  

Il est aussi possible de trouver des applications clientes avec JSP, EJB et base de données. Le client est un navigateur 
Web. Les pages JSP accèdent aux règles métier et construisent le contenu HTML fourni au navigateur. 

Un  dérivé  de  l’architecture  précédente  est  une  Applet  cliente  avec  JSP  et  base  de  données.  Dans  ce  cas,  le  client  est 
encore un navigateur mais une Applet permet d’obtenir une interface utilisateur plus complexe (mais aussi plus lourde) 
et  plus  interactive.  Cette  Applet  peut  accéder  au  contenu  produit  par  des  JSP.  Celles­ci  obtiennent  des  données 
nécessaires grâce à JDBC. 

Une  autre  version  de  l’architecture  précédente  est  JWS  (Java  Web  Start)  avec  JSP  et  base  de  données.  C’est 
pratiquement le même cas que l’architecture avec Applet si ce n’est que le client est une application téléchargeable et 
utilisable de manière autonome (sans navigateur) mais uniquement avec une connexion réseau. 

© Editions ENI – Tous droits réservés – Copie personnelle de Yasmine MINA SYLLA - 3-
  

Le  dernier  type  d’architecture  repose  sur  l’intégration  de  services  Web.  Une  application  cliente  accède  aux  données 
grâce à un service Web programmé en Java. 

Les  architectures  proposées  par  Java  EE  reposent  sur  le  découpage  des  applications  en  plusieurs  tiers  aux 
responsabilités  clairement  séparées.  Les  programmeurs  vont  développer  des  composants  qui  seront  hébergés  par  un 
serveur  d’application  Java  EE  (Tomcat,  JBoss...).  Les  applications  distribuées  (réalisées  sous  forme  de  composants 
distincts) permettent de diviser le logiciel en plusieurs couches appelées tiers (chaque couche représente un tiers). Le 
modèle  le  plus  courant  étant  l’architecture  3­tiers/n­tiers.  Cette  division  facilite  la  maintenance  et  l’adaptabilité  du 
produit. 

2. L’architecture MVC (Model View Controller)

L’architecture MVC proposée par Sun est la solution de développement Web côté serveur qui permet de séparer la partie 
logique/métier  de  la  partie  présentation  dans  une  application  Web.  C’est  un  point  essentiel  du  développement  de 
projets  car  cela  permet  à  toute  l’équipe  de  travailler  séparément  (chacun  possède  ses  fichiers,  ses  logiciels  de 
développement et ses composants). 

- 4- © Editions ENI – Tous droits réservés – Copie personnelle de Yasmine MINA SYLLA
Cette architecture trouve son origine dans le langage SmallTalk au début des années 1980, ce n’est donc pas un modèle 
(design  pattern  )  nouveau  uniquement  lié  à  Java  EE.  L’objectif  principal  est  de  diviser  l’application  en  trois  parties 
distinctes : le modèle , la vue  et le contrôleur . 

Dans l’architecture MVC, nous retrouvons : 

l Le  modèle qui est représenté par les EJB et/ou JavaBeans et/ou systèmes de persistances (Hibernate, objets sérialisés en 
XML, stockage de données par le biais de JDBC...). 

l La vue qui est représentée par les JSP. 

l Le contrôleur qui est représenté par les Servlets. 

Principe de fonctionnement de l’architecture MVC

l 1. Le client envoie une requête HTTP au serveur. C’est en général une Servlet (ou un programme exécutable côté serveur) 
qui traite la demande. 

l 2. La Servlet récupère les informations transmises par le client et délègue le traitement à un composant métier adapté. 

l 3.  Les  composants  du  modèle  manipulent  ou  non  des  données  du  système  d’information  (lecture,  écriture,  mise  à  jour, 
suppression). 

l 4.  Une  fois  les  traitements  terminés,  les  composants  rendent  la  main  à  la  Servlet  en  lui  retournant  un  résultat.  La  Servlet 
stocke alors le résultat dans un contexte adapté (session, requête, réponse...). 

l 5. La Servlet appelle la JSP adéquate qui peut accéder au résultat. 

l 6. La JSP s’exécute, utilise les données transmises par la Servlet et génère la réponse au client. 

Les composants sont bien sûr plus nombreux mais également plus simples . Leurs spécificités font qu’ils pourront être 
développés  par  des  spécialistes :  les  Servlets  et  EJB  par  des  développeurs  Java,  les  JSP  par  des  développeurs  et 
Webdesigner, les accès aux données par des spécialistes SQL... Ce découpage permet également une maintenance plus 
aisée du système. Ainsi, le changement de la charte graphique sera opéré facilement en utilisant les vues sans toucher 
au modèle et au contrôleur. 

Afin  de  faciliter  l’utilisation  du  modèle  MVC  dans  les  architectures  Java  EE,  des  frameworks  (outils  composés  de 
spécifications,  librairies,  outils...)  de  développement  entièrement  basés  sur  ce  modèle  ont  été  développés  (Apache 
Struts/Spring).  Le  schéma  complexe  ci­dessous reprend un exemple de mise en place d’une  telle  architecture  dans  un 
projet d’entreprise. 

© Editions ENI – Tous droits réservés – Copie personnelle de Yasmine MINA SYLLA - 5-
  

3. Les différents modules Java EE

Comme  indiqué  précédemment,  les  architectures  Java  EE  offrent  de  multiples  possibilités.  Il  est  donc  nécessaire 
d’organiser les différents éléments d’une application en fonction de leur rôle. 

Module Web

Le  module  Web  contient  les  éléments  d’une application Java EE qui vont permettre l’utilisation  de  cette  application  au 
travers d’un navigateur Web et de toute application utilisant le protocole HTTP. Les éléments regroupés dans ce module 
Web  sont  les  Servlets,  les  JSP  et  les  ressources  statiques  de  l’application  Internet  (images,  JavaScripts,  fichiers 
statiques...). Il y a également des bibliothèques dynamiques développées en Java fournies sous forme de fichiers  .jar et 
qui  sont  utilisées  par  les  Servlets  et/ou  JSP  (manipulation  d’images,  de  fichiers...).  Les  modules  Web  possèdent  un 
descripteur  de  déploiement,  le  fichier  web.xml.  L’ensemble  des  fichiers  est  regroupé  dans  un  fichier  d’extension  .war 
signifiant WebARchive. 

Module EJB/composants métier

Les  composants  EJB  sont  constitués  de  fichiers  de  code  Java.  Il  y  a  aussi  dans  ce  module  des  bibliothèques  au 
format .jar. Les modules sont ensuite assemblés en archive d’extension .jar. 

Module Client

Il est possible d’utiliser un client riche avec une interface graphique développée en utilisant les API de programmation 
Java  comme  Swing  et/ou  AWT.  Un  module  client  permet  un  assemblage  en  classes  et  fournit  un  descripteur  de 
déploiement. Le module client est un fichier d’archive portant l’extension .jar. 

- 6- © Editions ENI – Tous droits réservés – Copie personnelle de Yasmine MINA SYLLA