Présentations des architectures 3-tiers

1. ARCHITECTURES 3-
TIERS
heithem.abbes@gmail.com2014-2015

2. De l’arch. 2-tiers aux 3-tiers
2
 Limites des arch. 2-tiers
 Charge importante du poste client qui réalise
l'ensemble des traitements applicatifs
 Maintenance et mises à jour difficiles à gérer
 Conversation entre client et serveur est assez
bruyante
 Ces limites proviennent de type du client : client
lourd
 Frontal complexe et non standard (Windows, Linux,
Mac,…)
 Middleware entre client et serveur n'est pas standard
Solution : utilisation d'un poste client simple
communicant avec le serveur par le biais d'un
protocole standard

3. Présentation de l’arch. 3-tiers
3
 L'arch. 3-tiers, ou C/S de 2ème génération,
sépare l'application en 3 niveaux
 Niveau 1 : l'affichage et les traitements locaux
(contrôles de saisie, mise en forme de données... )
sont pris en charge par le poste client
 Niveau 2 : les traitements applicatifs globaux sont
pris en charge par le service applicatif : serveur
d’application
 Niveau 3 : les services de base de données sont
pris en charge le serveur de données
Traitements
globaux
Présentati
on
Traitemen
ts locaux
Données
Niveau 1 Niveau 2 Niveau 3

4. Exemple
4
Présentation
Traitements
locaux
Traitements
globaux
Données

5. Fonctionnement
5

6. Client léger
6
 Dans l’arch 3-tiers le client est léger, prend en
charge
 présentation de l'application
 traitements locaux permettant une vérification
immédiate de la saisie et la mise en forme des données
 Les évolutions de l'application ne nécessitent pas la
modification de la partie cliente
 Éviter l'installation des applications sur le poste
utilisateur
 Utiliser un navigateur web
 Communiquer avec le serveur d’application via une
façade web

7. Niveau web dans l’arch. 3-tiers
11
 Le poste client prend la forme d'un navigateur Web
 Le serveur d’application nécessite une couche web, appelé
serveur web, pour communiquer avec le navigateur
 Fonctionnement
 Le serveur web transmet au client, lui ayant fait une demande HTTP
via URL , les fichiers statiques présents sur son disque dur (pages
HTML , images, fichiers CSS,...)
 Lorsque le client demande un traitement, page dynamique, le
serveur web aiguille cette demande vers la couche applicative dans
le serveur d'application
 Une fois le traitement effectué, le serveur d'application renvoie la
page HTML au serveur web qui se charge de la router vers le client
 Remarque : Le marché des serveurs web est dominé par
Apache

8. Niveau web dans l’arch. 3-tiers
12

9. Les technologies web

10. Les technologies web : coté
client14
 Javascript
 Langage Interprété, orienté objet
 Code s’insère dans le code HTML
 Gère les évènements principaux de la souris et la saisie au
clavier
 Code envoyé au client, puis interprété
 Applets
 Langage java
 Ensemble de fichiers .class
 Le code est exécuté dans une JVM
 ActiveX
 Composants Microsoft
 Fichiers stockés sur disque dur (.VBX, .OCX, .DLL, .EXE)
 Créés avec Visual basic, Delphi ou C++

11.  CGI (Common Gateway Interface)
 Technologie la plus ancienne
 Tout langage possible
 Langage Perl le plus utilisé
 C, C++, Fortran, etc...
 Servlets
 Classes Java
 Exécutés par un moteur de servlet (Tomcat ou
Jetty)
 La classe doit générer tout le code html
Les technologies web : coté
serveur

12.  JSP (Java Server Pages)
 Technologie Java
 Langage de scripts
 Fichier .jsp remplaçant les fichiers .html
 Combine l’utilisation d’html et de java
 ASP (Active Server Pages)
 Technologie Microsoft
 Même principe que JSP
 PHP
 Langage de scripts
 Orienté Objet
 S’intègre au code HTML
Les technologies web : coté
serveur

13. Synthèse
17
 Avantages
 Déploiement immédiat
 Evolutions transparentes pour l'utilisateur
 Caractéristiques du poste client libres
 Limites
 Le serveur d’application réalise la majorité des
traitements
 Problème de gestion de la montée en charge