Vous êtes sur la page 1sur 18

Module : Architectures n/3 et orientées

services
Architecture 2-tiers

Olfa Bouchaala Charfeddine


E-mail : olfa.bouchaala@isimg.com
Année universitaire : 2020 - 2021
Niveau auditoire : LFSIM3
Rappel : Architecture 1-tiers
2

gestion Interface
Architecture centralisée utilisateur en
1-tier sur des données mode
Fiabilité de caractère
site central
l’application

Architecture Interface Gestion


1-tier utilisateur des donnée
déployée moderne n’est pas
fiables
Rappel : Architecture 1-tiers
3

gestion Interface
centralisée utilisateur
des en mode
données caractère
Solution Naissance du concept
Client/Serveur
Gestion Gestion
locale de des donnée
l’interface n’est pas
utilisateur fiables
Types de C/S
4
(Schéma du Gartner Group)
Architecture 2-tier : définition
5

 Architecture 2-tiers ou C/S de 1ère génération ou


C/S de données
 Le client s’occupe de la présentation et la logique
applicative
 Le serveur s’occupe de la gestion des données
Architecture 2-tiers : Exemple
6

 Application
de gestion de stock fonctionnant sur
Windows et exploitant un SGBD (oracle) centralisé
Architecture 2-tiers: dialogue
7

 Echange de messages à travers le réseau reliant les


deux machines
 Mécanismes de communication complexes pris en
charge par un middleware de base de données
Architecture 2-tiers: Middleware
8

 Quoi?
 élément du milieu = interface de communication
universelle entre processus
 L’ensemble des couches réseau et services logiciel qui
permettent le dialogue entre les différents composants
d'une application répartie.
 Pourquoi?
 Assurer échanges données entre C et S en masquant les
différents problèmes potentiels liés à:
 répartition des données et traitements (accès distant, baisse
performances)
 hétérogénéité des matériels et des logiciels en opération.
Architecture 2-tiers : Middleware
9

 Envoyer des requêtes d'accès à des données (type


SQL) d'un client vers un serveur et recevoir les
résultats
 Ouvrir une connexion entre entités
 Envoi de requêtes SQL vers le serveur
 Conversion des formats de requêtes
 Envoi des résultats
 Conversion des résultats
 (Gestion des erreurs)
 Fermeture de connexion.
Architecture 2-tiers : Middleware
10

EXEMPLES
 SQL*NET : Interface permettant de faire dialoguer

une application cliente avec une base de données


Oracle.
 Middleware propriétaire
 Passage requête SQL, Appel procédures

 indépendance vis a vis du réseau (topologie, protocole)


et des OS
Architecture 2-tiers : Middleware
11

EXEMPLES
 ODBC : Interface standardisée isolant le client du

serveur de données.
 Middleware indépendant
 C'est l'implémentation par Microsoft du CLI (Call

Level Interface) du SQL Access Group


 Elle se compose de :

 gestionnaire de driver standardisé,


 API s'interfaçant avec l'application cliente
Architecture 2-tiers : Middleware
12

EXEMPLES
 JDBC : Fournit un ensemble de classes et

d’interfaces permettant l’utilisation sur le réseau


d’un ou plusieurs SGBD à partir d’un programme
Java
 Middleware indépendant
 Avantages liés à Java

 Portabilité
sur de nombreux OS et sur de nombreux
SGBDR (Orale, Informix, Sybase,…)
 Middleware portable
Architecture 2-tiers : Avantages
13
Architectures 2-tiers : Limitations
14

 Poste client supporte la grande majorité des


traitements applicatifs
 Client lourd ou fat client
Architectures 2-tiers : Limitations
15

 Leposte client est fortement sollicité


 devient de plus en plus complexe

 nécessite des mises à jour régulières


Architectures 2-tiers : Limitations
16

Il est difficile de modifier l’architecture initiale


 Les applications supportent mal les fortes
montées en charge
Architecture 2-tiers : Limitations
17

 La conversation entre C et S est assez bruyante et


s’adapte mal à des bandes passantes étroites
 Ce type d’architecture est souvent réservé au réseau
local de l’entreprise
Solution…
18

 Ce type d’architecture est grandement rigidifié par les


coûts et la complexité des maintenances
 Solution: architecture plus évoluée facilitant les forts
déploiements à moindre coût architectures distribuées