Architecture N-Tiers
Chapitre 1: Conception architecturale
Dr. Ghada Besbes
Syst mes dinformation
" Un syst me dinformation est constitu dun ensemble
doutils destin s g rer, stocker et traiter des flux
dinformation.
" Un Post-it laiss par une secr taire sur le bureau de son
directeur pour lui transmettre un message est consid r
comme un syst me dinformation.
" Linformatique nest quun outil mis disposition des
organisations afin de compl ter dam liorer le syst me
dinformation d j en place.
2
Syst mes dinformation
" Linformatique tend au fur et mesure des ann es devenir le
principal outil incontournable dun syst me dinformation.
" Les applications et programmes informatiques voluent
d sormais dans plusieurs domaines dactivit : comptabilit ,
administration, chaine de montage, etc...
" Progressivement, les applications mises en place se
regroupent au sein dapplications de plus en plus importantes.
" Lobjectif tant terme dobtenir une seule et m me
application qui g re lensemble du syst me dinformations
dans lensemble des secteurs dactivit dune entreprise ou
organisation.
3
Syst mes dinformation
" Avec l volution des technologies, les applications ont
progressivement volu , les attentes des utilisateurs et des
clients galement.
" Autrefois, les entreprises privil giaient le fonctionnel
lesth tique, la popularit du syst me monolithique
(Mainframe) AS/400 en est un tr s bel exemple.
" Cet outil la fois simple et extr mement complet dun point de
vue fonctionnel ne doit pas sa renomm e son interface
graphique (texte blanc sur fond noir avec des menus uniquement
textuels).
" Il serait aujourdhui impensable de mettre en place un outil
semblable lAS/400 au coeur dun syst me dinformation.
4
D finition Architecture
" & la structure des composants dun programme/syst me, leurs
interrelations et les principes et lignes directrices gouvernant leur
conception et leur volution au fil du temps.
La d finition de larchitecture logicielle consiste :
" D crire lorganisation g n rale dun syst me et sa d composition en
sous-syst mes ou composants
" D terminer les interfaces entre les sous-syst mes
" D crire les interactions et le contr le entre les sous syst mes
" D crire les composants utilis s pour implanter les fonctionnalit s
des sous-syst mes
" Les propri t s de ces composants
" Leur contenu (e.g., classes, autres composants)
" Les machines ou dispositifs mat riels sur lesquels ces modules seront
d ploy s
5
D finition Architecture
" Pourquoi d velopper une architecture logicielle ?
" Pour permettre tous de mieux comprendre le syst me
" Pour permettre aux d veloppeurs de travailler sur des parties
individuelles du syst me en isolation
" Pour pr parer les extensions du syst me
" Pour faciliter la r utilisation
6
Niveaux dabstraction
" Traditionnellement une application informatique est un
programme ex cutable sur une machine qui repr sente la
logique de traitement des donn es manipul es par
lapplication.
" Ces donn es peuvent tre saisies interactivement via
linterface ou lues depuis un disque.
" Lapplication met un r sultat sous forme de donn es qui
sont, soit affich es, soit enregistr es sur un disque.
" Dans ce sch ma, les traitements, les donn es dentr es, les
7
donn es de sortie sont sur une seule machine.
Niveaux dabstraction
" Une application informatique peut tre d coup e en trois
niveaux d'abstraction distincts :
" Pr sentation
" Logique applicative
" Donn es
8
Niveaux dabstraction
1.
2.
La couche interface homme machine (IHM) ou pr sentation:
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 couche de traitement ou la logique applicative: d crit les
travaux r aliser par l'application. Ils peuvent tre d coup s en
deux familles:
" Les traitements locaux, qui sont les contr les effectu s au niveau du
dialogue avec l'IHM. Ils assurent la coh rence des informations entre
la couche pr sentation et les traitements globaux.
" 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 application donn e.
9
Niveaux dabstraction
3.
La couche de gestion des 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.
" Fonctions classiques dun SGBD :
" D finition de donn es
" Manipulation de donn es
" S curit de donn es
" Gestion de transactions
" etc. ..
" Et toute application poss de ces trois parties ou niveaux
d'abstraction distincts
" Le d coupage et la r partition d'une application en diff rentes
parties permettent de distinguer les architectures applicatives
diff rentes.
10
Syst mes r partis
" Dans un syst me reparti, l'application est divis e en plusieurs
morceaux o chacun effectue un traitement donn e.
" Possibilit de dupliquer un morceau pour offrir une meilleure
robustesse (fiabilit ) du syst me
" Chaque morceau de l'application repartie peut tre d velopp
dans un langage de programmation diff rent et tre ex cut
depuis un syst me d'exploitation diff rent.
11
Evolution des syst mes
dinformation
" Les applications compos es dun ex cutable lancer ont
progressivement laiss la place des applications accessibles
partir dun r seau par linterm diaire dun navigateur Web.
" Cette volution est due en partie aux volutions
technologiques mais aussi gr ce la simplicit de de mise
jour de lapplication :
" Il est plus simple de mettre jour un serveur unique avec une
interface Web que de compiler un programme et de le d ployer
sur lensemble des postes du r seau.
" Chaque utilisateur peut acc der lapplication partir de
nimporte quel PC connect au r seau dot dun navigateur Web
alors quil aurait t n cessaire autrefois davoir un poste de
travail configur avec lapplication pr alablement install e.
12
Publicité
Vision : historique des
architectures
" Architecture 1 tiers
" Architectures Client-Serveur
" 2- tiers
" 3- tiers
" N-tiers
" Architectures Base de Composants
" Architectures Orient es Services
13
ARCHITECTURE 1-TIERS
14
Architecture 1 tiers
" Jusquau ann es 90, ces trois couches taient la plupart du
temps sur la m me machine.
" Dans une application un tiers, les trois couches applicatives
sont intimement li es et s'ex cutent sur le m me ordinateur.
" Lapplication utilisait les disques de la machine pour lire les
donn es a traiter et stocker les donn es r sultantes du
traitement .
15
Architecture 1 tiers
" Dans un contexte multi-utilisateurs, on peut rencontrer deux types
d'architecture mettant en Suvre des applications un tiers :
" des applications sur site central,
" des applications r parties sur des machines ind pendantes
communiquant par partage de fichiers.
Les solutions sur site central (mainframe)
1.
" Historiquement, les applications sur site central sont les premi res
proposer un acc s multiutilisateurs.
" Dans ce contexte, les utilisateurs se connectent aux applications
ex cut es par le serveur central (le mainframe) l'aide de
terminaux passifs se comportant en esclaves et neffectuent la
moindre t che.
" 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.
16
Architecture 1 tiers
17
Architecture 1 tiers
Les applications un tiers r parties
2.
" Avec l'arriv e dans l'entreprise des premiers PC en r seau, il
est devenu possible de d ployer une application un tiers sur
plusieurs ordinateurs ind pendants.
" Ce type d'application peut tre tr s satisfaisant pour r pondre
aux besoins d'un utilisateur isol et sa mise en oeuvre dans un
environnement multi-utilisateur est envisageable:
" Plusieurs utilisateurs se partagent des fichiers de donn es stock s
sur un serveur commun.
" Le moteur de base de donn es est ex cut ind pendamment sur
chaque poste client.
" La gestion des conflits d'acc s aux donn es doit tre prise en
charge par chaque programme de fa on ind pendante, ce qui
n'est pas toujours vident.
18
Architecture 1 tiers
Les applications un tiers r parties
2.
" Dans ce contexte, plusieurs utilisateurs se partagent des fichiers de
donn es stock s sur un serveur commun. Le moteur de base de
donn es est ex cut ind pendamment sur chaque poste client.
" Lors de l'ex cution d'une requ te, l'int gralit des donn es
n cessaires doit transiter sur le r seau
saturation du r seau.
" La cohabitation de plusieurs moteurs de base de donn es
ind pendants manipulant les m mes donn es peut devenir instable:
" Possibilit davoir des conflits lors de la consultation ou de la
modification simultan e d'un m me enregistrement par plusieurs
utilisateurs.
" Les conflits peuvent alt rer l'int grit des donn es.
" Il est difficile d'assurer la confidentialit des donn es.
19
Architecture 1 tiers
Architecture d'une application sur site central
20
Architecture 1 tiers
" Avantages:
" Grande facilit d'administration
" Haute disponibilit .
" La centralisation de la puissance sur une seule et m me machine
permet une utilisation optimale des ressources
21
Architecture 1 tiers
" Inconv nients
" Laugmentation du nombre dutilisateurs pose des probl mes de
gestion des conflits d'acc s aux donn es ou la modification
simultan e d'un m me enregistrement par plusieurs utilisateurs.
Ces conflits peuvent alt rer l'int grit des donn es
" Lexplosion de la volum trie des donn es rend leur gestion
difficile
" il est difficile d'assurer la confidentialit des donn es
" En regroupant tous les traitements on groupe galement toutes
les sources d'erreur
" Ce type de solution est donc r server des applications non
critiques exploit es par de petits groupes de travail (une
dizaine de personnes au maximum).
22
Architecture 1 tiers
" Solution
" Trouver une solution regroupant :
" La fiabilit de lapplication sur site central, qui g rent les donn es
de fa on centralis e,
" L'interface utilisateur moderne des applications sur diff rents
ordinateurs.
" Il est n cessaire de scinder lapplication en plusieurs
parties distinctes et coop rantes :
" Gestion centralis e des donn es
" Gestion locale de l'interface utilisateur
Naissance du concept du client/serveur.
23
ARCHITECTURES CLIENT-SERVEUR
24
Architecture client-serveur
" Dans le cas d'un syst me reparti, l'application est divis e en
plusieurs morceaux o chaque morceau joue un r le diff rent
pour les traitements du SI.
" L'environnement client-serveur d signe un mode de
communication travers un r seau entre
plusieurs programmes ou logiciels : l'un, qualifi de client,
envoie des requ tes ; l'autre ou les autres, qualifi s
de serveurs, attendent les requ tes des clients et y r pondent.
25
Architecture client-serveur
" Le mod le client-serveur met en oeuvre une conversation
entre deux programmes que l'on peut opposer l' change
fig ma tre-esclave qu'entretiennent les applications sur
site central avec leurs terminaux passifs.
" Dans une conversation client-serveur, on distingue donc les
deux parties suivantes :
" Le client, c'est le programme qui provoque le dialogue,
" Le serveur, c'est le programme qui se contente de r pondre au
client.
26
Types de clients
" Client lourd (fat client): d signe une application cliente
graphique ex cut e sur le syst me d'exploitation de
l'utilisateur. Un client lourd poss de g n ralement des
capacit s de traitement volu es et peut poss der une
interface graphique sophistiqu e. N anmoins, ceci demande
un effort de d veloppement et tend m ler la logique de
pr sentation (l'interface graphique) avec la logique applicative
Publicité
(les traitements).
" Client leger (thin client): 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 web.
27
Types de clients
" Les clients lourds sont des logiciels destin s tre install s
localement sur une machine en opposition aux clients l gers
qui s'ex cutent par exemple dans un navigateur internet, mais
n cessitent un serveur.
" titre indicatif, Google Maps constitue un client l ger
puisque tout sex cute sur un serveur et est affich dans votre
navigateur internet.
" Google Earth est pour sa part un client lourd puisquune
version doit tre install e manuellement sur votre ordinateur.
28
Couplage
" Le couplage est une m trique indiquant le niveau d'interaction
et de d pendance entre deux ou plusieurs composants
logiciels (fonctions, modules, objets ou applications).
" Deux composants sont dits coupl s s'ils changent de
l'information et sont d pendants lun de lautre.
" Couplage fort: si les composants changent beaucoup
d'information.
" On ne peut pas d terminer le qui, le quoi et le comment dune
modification de donn es donc a pose des probl mes lors du
d veloppement et la maintenance. A viter autant que possible
" Exemple: Architecture peer-to-peer (tous les processus ont le
m me r le)
29
Couplage
" Couplage faible: si les composants changent peu
d'information.
" Pas dinter-d pendance entre les composants de lapplication
" Permet de ma triser la complexit de larchitecture pour le
d veloppement, le test et la maintenance
" Exemples: Architectures 3-tiers, n-tiers
" Couplage tr s faible: Les composants sont rempla ables,
con us en ind pendance, avec des technologies diverses
" Un composant est facilement rempla able par un autre rendant
les m mes services
" La construction par assemblage permet de faciliter la
maintenance
" Exemple: architecture orient e services
30
Architecture client-serveur
" Le mod le client-serveur mono-serveur
" les clients demandent des services en mode message
" le serveur connect offre le service demand . Si le service
demand nest pas local, le serveur demande son tour le service
en question en mode message . Dans ce cas, le serveur
devient un client.
31
Architecture client-serveur
" Le mod le client-serveur multi-serveur
" les clients demandent un service en mode message
" un service est assur par un serveur ou par multi-serveurs
32
Architecture client-serveur
" Le client est le programme qui demande lutilisation des
ressources dun serveur
" Par extension, le client d signe galement l'ordinateur sur
lequel est ex cut le logiciel client, et le serveur, l'ordinateur
sur lequel est ex cut le logiciel serveur.
" En g n ral:
" Les serveurs sont des ordinateurs d di s au logiciel serveur qu'ils
abritent, et dot s de capacit s sup rieures celles des ordinateurs
personnels en ce qui concerne la puissance de calcul, les entr es-
sorties et les connexions r seau.
" Les clients sont souvent des ordinateurs personnels ou des appareils
individuels (t l phone, tablette), mais pas syst matiquement. Un
serveur peut r pondre aux requ tes d'un grand nombre de clients.
33
Architecture client-serveur
" Il existe une grande vari t de logiciels serveurs et de logiciels
clients en fonction des besoins servir :
" un serveur web publie des pages web demand es par
des navigateurs web
" un serveur de messagerie lectronique envoie des mails des clients
de messagerie
" un serveur de fichiers permet de stocker et consulter des fichiers sur
le r seau
" Le client et le serveur doivent bien s r utiliser le m me protocole de
communication au niveau de la couche transport du mod le OSI. Un
serveur est g n ralement capable de servir plusieurs clients
simultan ment.
34
Middleware
" D finition
" Le dialogue entre le client et le serveur seffectue laide dun
ensemble de m canismes assurant la communication
" On appelle intergiciel ou middleware, litt ralement l ment
du milieu , un logiciel servant d'interm diaire de
communication entre plusieurs applications, g n ralement
complexes ou distribu es sur un r seau informatique.
" Les composants logiciels du middleware assurent la
communication entre les applications quels que soient les
ordinateurs impliqu s et quelles que soient les
caract ristiques mat rielles et logicielles des r seaux
informatiques, des protocoles r seau, des syst mes
d'exploitation impliqu s.
35
Middleware
" Pour former une application part enti re les tiers doivent
tre reli s entre eux. Les diff rents serveurs sont regroup s
par un r seau. Afin d'effectuer la liaison entre les diff rentes
parties du logiciel tout en rendant le r seau et les syst mes
dexploitation des diff rents machines transparents aux
utilisateurs, on utilise un middleware.
" Le terme middleware est utilis pour d crire des logiciels qui
servent de colle entre les deux applications.
" Il peut tre ressembl la plomberie parce qu'il relie deux
c t s d'une application et transmet les donn es entre elles.
36
Middleware
" Objectif:
" Unifier, pour les applications, l'acc s et la manipulation de
l'ensemble des services disponibles sur le r seau, afin de rendre
l'utilisation de ces derniers transparente
" Offre des API (Application Programming Interface) de haut niveau
" Permettant de masquer la complexit des changes inter-
applications
" Facilite le d veloppement d'une application client-serveur
37
Middleware
Services
" Un middleware rend les services suivants:
" Conversion : Service utilis pour la communication entre machines
mettant en oeuvre des formats de donn es diff rents
" Adressage : Permet d'identifier la machine serveur sur laquelle est
localis le service demand afin d'en d duire le chemin d'acc s.
" S curit : Permet de garantir la confidentialit et la s curit des
donn es l'aide de m canismes d'authentification et de cryptage
des informations.
" Communication : Permet la transmission des messages entre les
deux syst mes sans alt ration. Ce service doit g rer la connexion au
serveur, la pr paration de l'ex cution des requ tes, la r cup ration
des r sultats et la d connexion de l'utilisateur.
" Le middleware masque la complexit des changes inter-
applications. Sans ce m canisme, la programmation d'une
application client-serveur serait extr mement complexe et rigide.
38
Publicité
Middleware
Exemples de middleware
" Les middleware qui lient un syst me de base de donn es un
serveur Web. Cela permet aux utilisateurs de demander les donn es
de la base de donn es en utilisant des formulaires affich es sur un
navigateur Web.
" Le middleware permet au serveur Web de retourner des pages Web
dynamiques bas es sur les demandes et le profil de l'utilisateur:
" SQL*Net : Interface propri taire permettant de faire dialoguer une
application cliente avec une base de donn es Oracle. Ce dialogue
peut aussi bien tre le passage de requ tes SQL que l'appel de
proc dures stock es.
" ODBC (Open DataBase Connectivity): Ind pendant d un SGBD.
Interface standardis e isolant lapplication informatique du serveur
de donn es. Il est mis en Suvre par Microsoft pour les syst mes
d'exploitation Windows, Unix et la plateforme Java.
" API JDBC: de Java avec des drivers crits en Java
39
Middleware
Exemples de middleware
" Le middleware joue un grand r le dans la structuration du
syst me d'information.
" Les middleware propos s par les fournisseurs de SGBD sont
tr s performants et permettent de tirer profit de l'ensemble
des fonctionnalit s du serveur de donn es pour lequel ils ont
t con us. Par contre, ils ne permettent pas, le plus souvent,
l'acc s d'autres sources de donn es.
40
Middleware
Types de middleware
" On distingue en g n ral trois types de middleware diff rents:
" Les middlewares orient s message ou MOM
" Les middlewares orient transaction ou MOT
" Les middlewares orient s objet ou MOO
41
Middleware
" Le MOM
" Il permet d' changer des messages entre un client et un
serveur au moyen dune file d'attente de messages. Les
applications communiquent sur le r seau en disposant et en
retirant des messages dans des files d'attentes.
" C'est un middleware qui fait abstraction de la couche
communication. Il autorise des ex cutions d synchronis es
des applications et n'impose pas de connexions instantan e
entre elles. Une file d'attente re oit le message de
l'application mettrice et le stocke jusqu' ce que l'application
r ceptrice vienne lire le message.
" Ce type de middleware est particuli rement adapt s aux
situations o une connexion entre client et serveur n'est pas
souhaitable pour des raisons de s curit s ou d'efficacit .
42
Middleware
" Le MOM
" Ils offrent deux modes de communications:
1.
2.
Le mod le point point: une application produit des messages et
une application les consomme. Les messages ne sont lus que par
un seul consommateur. Une fois qu'un message est lu, il est retir
de la file d'attente.
Le mod le Publish & Subscribe: un sujet est associ chaque
message. Lemetteur transmet le message un agent
interm diaire. Les serveurs sont abonn es aupr s de cet agent en
fonction des sujets qui les int resse. L'agent transmet le message
tous les serveurs "int ress s" par le sujet.
" Avec ce type de middleware les applications transmettent les
messages des destinations, qui sont des files d'attente. Elles n'ont
pas connaissance de la localisation physique de ces destinations ni
des noms des applications. Un message peut tre transmis
plusieurs destinataires.
" Plusieurs MOM existent sur le march comme MQSeries d'IBM ou
MessageQ de BEA.
43
Middleware
" Le MOT
" On appelle transaction ou unit de travail une suite d'actions
qui changent l' tat dun syst me dune mani re contr l e. Il
n'y a pas de demi-mesure, soit le travail a t effectu soit
non. Si pour une raison quelconque la transaction n'a pu se
terminer, on replace le syst me dans son tat de d part. Une
transaction a un d but et une fin que l'on doit obligatoirement
atteindre pour que les modifications soient valid es.
" Un MOT prend en charge lex cution d'une application et la
v rification de son bon fonctionnement en int grant des
m canismes transactionnels.
44
Middleware
" Le MOT
" Les MOT permettent au programmeur de ne pas s'occuper des
probl mes de simultan it s d'acc s, de d faillance du
syst me, de ruptures de connexions. Ils fournissent le moteur
pour faire tourner les applications au dessus des syst mes
dexploitation et du mat riel. Ils assurent une coh rence
transactionnelles et facilitent le d coupage des applications en
services.
" Il existe diff rents moniteurs transactionnels comme Tuxedo
de BEA ou CIS d'IBM
45
Middleware
" Le MOO
" Pour permettre diff rentes applications de communiquer
entre elles, il faut des r gles et des formats communs d'appels
de services: ils sont assur s par les MOO.
" Les MOO permettent aux diff rents objets de communiquer
entre eux car les composants peuvent tre de nature
diff rentes, sur des machines diff rentes, ayant des syst mes
dexploitation diff rents. Ils peuvent aussi avoir t con u dans
des langages diff rents.
" Ils existe trois mod les de composants objets qui sont
compl mentaires et interop rable. Il s'agit du mod le CORBA,
des composant Java EJB et enfin de DCOM de Microsoft.
46
Le mod le de Gartner Group
Fig. Les diff rents types de client-serveur selon la classification du Gartner Group
- Le trait horizontal repr sente le r seau
47
Le mod le de Gartner Group
" Pr sentation distribu e : Partie pr sentation
est partag e par le client et le serveur. Tout le
reste est attribu au serveur.
" La classification client-serveur de ce type
est souvent jug e abusive, du fait que
l'int gralit des traitements originaux est
conserv e et que le poste client conserve une
position d'esclave par rapport au serveur.
48
Le mod le de Gartner Group
" Pr sentation distante : Encore appel e
client-serveur de pr sentation. L'ensemble
des traitements est ex cut par le serveur,
le client ne prend en charge que
l'affichage.
" Ce type d'application pr sentait jusqu'
pr sent l'inconv nient de ne permettre
aucune r partition de la charge entre
client et serveur.
49
Le mod le de Gartner Group
" Gestion distante des donn es : Correspond
au client-serveur de donn es, sans doute le
type de client-serveur le plus r pandu.
" L'application fonctionne dans sa totalit sur le
client, la gestion des donn es et le contr le
de leur int grit sont assur s par un SGBD
Publicité
centralis .
" Cette architecture, de part sa souplesse,
s'adapte tr s bien aux applications
interrogeant souvent la base de donn es. Il ne
soulage pas norm ment le poste client, qui
r alise encore la grande majorit des
traitements.
50
Le mod le de Gartner Group
" Traitement distribu : Correspond au client-
serveur de traitements. Les traitements sont
distribu s entre le client et le serveur.
" Il s'appuie sur un m canisme d'appel de
proc dure distante, et la notion de proc dure
stock e propos e par les principaux SGBD du
march .
" Cette architecture permet d'optimiser la
r partition de la charge de traitement entre
machines et limite le trafic r seau.
" Par contre il n'offre pas la m me souplesse que
le client/serveur de donn es puisque les
traitements doivent tre connus du serveur
l'avance.
51
Le mod le de Gartner Group
" Bases de donn es distribu es : Il s'agit d'une
variante du client-serveur de donn es dans
laquelle une partie de donn es est prise en
charge par le client.
" Ce mod le est int ressant si l'application doit
g rer de gros volumes de donn es, si l'on
souhaite disposer de temps d'acc s tr s
rapides sur certaines donn es ou pour
r pondre de fortes contraintes de
confidentialit .
" Ce mod le est aussi puissant que complexe
mettre en Suvre.
52
Le mod le de Gartner Group
" Donn es et traitements distribu s: r partir
la charge des donn es et des traitements
entre le client et le serveur.
" Ce mod le est tr s puissant et tire partie de
la notion de composants r utilisables et
distribuables pour r partir au mieux la
charge entre client et serveur.
" C'est, bien entendu, l'architecture la plus
complexe mettre en Suvre.
53
Le mod le de Gartner Group
" Les solutions que nous venons de d tailler sont
ind pendantes les unes des autres
" Prises individuellement, on peut dire que les deux premi res
solutions propos es ne correspondent pas des applications
client-serveur. (Les traitements et la gestion des donn es sont
r alis es par le serveur)
" En effet, la pr sentation distribu e ne consid re pas le client
en tant que tel et ce dernier reste dans une position d'esclave
par rapport au serveur.
" La premi re solution mettre en Suvre une relation client-
serveur se retrouve au troisi me niveau et correspond au
client-serveur de donn es.
" Ce type d'application, encore appel client-serveur de
premi re g n ration, met en Suvre une architecture 2-tiers.
54
Architecture 2 tiers
" Dans une architecture deux 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 .
" Le cas typique de cette architecture est l'application de
gestion fonctionnant sous Ms-Windows et exploitant un SGBD
centralis s'ex cutant le plus souvent sur un serveur d di
pour la gestion des donn es
55
Architecture 2 tiers
56
Architecture 2 tiers
" Ce dernier est interrog en utilisant un langage de requ te
qui, le plus souvent, est SQL. Le dialogue entre client et
serveur se r sume donc l'envoi de requ tes et au retour des
donn es correspondant aux requ tes. Ce dialogue n cessite
l'instauration d'une communication entre client et serveur.
" Ce type d'application permet de tirer profit de la puissance
des ordinateurs d ploy s en r seau pour 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.
57
Architecture 2 tiers
" Le client provoque l' tablissement d'une conversation afin de
d'obtenir des donn es ou un r sultat de la part du serveur.
" Cet change de messages transite travers le r seau reliant
les deux machines. Il met en Suvre des m canismes
relativement complexes qui sont, en g n ral, pris en charge
par un middleware.
58
Architecture 2 tiers
Avantages:
" Maintenance et administration du serveur simplifi es
" Souplesse : possibilit dajouter/suprimer dynamiquement des
clients sans perturber le fonctionnement de lapplication
" Les ressources sont centralis es sur le serveur
" S curisation simple des donn es : un seul point dentr e
" Pas de probl me dint grit /coh rence des donn es
Limitations:
" On ne peut pas soulager la charge du poste client, qui
supporte la grande majorit des traitements applicatifs (client
lourd)
" Co t lev : le serveur doit tre tr s performant pour honorer
tous les clients
59
Architecture 2 tiers
" Exemples d applications du syst me client-serveur
" Op ration transactionnelle par OLTP (On Line Transaction
Processing): Elle permet deffectuer une transaction, une
transaction bancaire par exemple. Les principales composants
sont des acc s la base de donn es, des traitements et des
modifications et des affichages en mode graphique.
" Aide la d cision par DS (Decision Support), la gestion des
lignes Air France, par exemple. Les principales composants
sont des acc s BD, des traitements de synth se et de
d cision et des affichages.
" &.
60
Architecture 2-tiers
" Les limites de l'architecture deux tiers proviennent en grande
partie de la nature du client utilis : le frontal est complexe et
non standard (m me s'il s'agit presque toujours d'un PC sous
Windows),
" 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 trois tiers applique les principes
suivants :
" la pr sentation est toujours prise en charge par le poste client,
" la logique applicative est prise en charge par un serveur
interm diaire.
" les donn es sont toujours g r es de fa on centralis e,
61