Introduction : pourquoi le Client-Serveur ?
Architectures Client-Serveur
Evolution des organisations :
Bernard ESPINASSE
1980-1990
1985-1995
1995-2000
Professeur l'Universit d'Aix-Marseille
2011
Introduction : pourquoi le C/S, les enjeux
Dcoupage d'une application
Dialogue entre client et serveur : le middleware (IPC = API+FAP)
Types de Middleware : RPC, APPC / RDA, Message queuing
Le schma du Gartner Group : C/S de prsentation, de donnes,
de traitements
L'offre en middlewares
Les performances du Client-Serveur
Bernard ESPINASSE - Architecture Client-Serveur
hirarchique
hirarchique
rparti
et centralis
et dcentralis
(entreprise virtuelle)
Bernard ESPINASSE - Architecture Client-Serveur
Pourquoi le Client-Serveur ?
Pourquoi le Client-Serveur ?
Inversion de la pyramide :
volution des besoins : production, informationnel, communication
volution des techniques : micro-informatique + rseaux locaux
PILOTAGE PAR LE CENTRAL
contraintes des architectures hierachiques : rseau centralis, htrognit des
postes de travail, rigidit des applications, ...
serveur
central
central
serveur
dept.
! le client-serveur :
gestion
rseau
principes gnraux :
poste de travail multi-fonction
possibilit d'accs multi-serveur
localisation des donnes
rpartition des traitements
pilotage par l'utilisateur
consquences :
serveur
local
Dept.
Dept.
Dept.
gestion
rseau
poste de
travail
dfinition de relation Client - Fournisseur
transformation des mtiers
volution des responsabilits
une mutation dlicate
PILOTAGE PAR L'UTILISATEUR
Bernard ESPINASSE - Architecture Client-Serveur
Bernard ESPINASSE - Architecture Client-Serveur
Enjeux stratgiques du Client-Serveur ?
Dcoupage d'une application: 3 niveaux
Enjeux stratgiques :
gestion de la
prsentation
productivit individuelle (micro)
performance collective : communication, disponibilit du patrimoine
d'information personnalisable
ractivit : rduction des dlais, flexibilit des applications
Prsentation
logique de la
prsentation
coeur de l'application
Enjeux organisationnels :
logique des
traitelents
souplesse organisationnelle par banalisation du couple "homme-machine"
et "polyvalence" du personnel
fluidit de l'information
communication inter-services et inter-personnes
Traitements
gestion des
traitements
Enjeux humains :
logique des
donnes
usage intuitif, appropriation de l'outil, enrichissement des tches,
initiative, moindre rsistance au changement, communication,...
Donnes
gestion des
donnes
Enjeux techniques :
cohrence technique : libres changes des applications et des
informations,
dfinition d'architectures modulaires : serveurs, poste de travail,
dification de normes et standards : chartes, guides, rgles d'hygine ,
Bernard ESPINASSE - Architecture Client-Serveur
l'interface avec l'utilisateur
1 la gestion de l'affichage : concerne le fentrage (li un
env. graphique d'exploitation (Window, XWindow,...))
2 la logique de l'affichage : transmet la gestion de
l'affichage la description des lments de prsentation
les traitements
3 la logique des traitements : contient l'arborescence
algorithmique de l'application ( ! lancement des procdures
de la couche 4)
4 la gestion des traitements : procdures de traitements
contenant des requtes SQL de manipulation de donnes)
les donnes
5 la logique des donnes : garantit le respect de la rgle
CRUDE pour les objets de la BD mis jour par les
procdures
6 la gestion des donnes : slections ou mises jour des
enregistrements (gnralement pris en charge par le SGBD)
Modules 2 et 3 insparables : coeur de l'application !!!
5
Dcoupages d'une application
Bernard ESPINASSE - Architecture Client-Serveur
Dialogue entre client et serveur
1 application en traitements coopratifs :
permettre l'change de la demande et du rsultat cette demande
! module de logique de traitement :
s'effectue travers le rseau qui relie les 2 machines :
! dialogue interprocessus : Inter Process Communication (IPC) qui
s'appuie ct client et ct serveur sur :
clat sur plusieurs processeurs
rsidant sur plusieurs machines
API : Application Programming Interfaces (interface de
programmation au niveau applicatif)
2 application en client/serveur :
FAP : Format And Protocols (protocoles de communication et
formats de donnes)
! un ou plusieurs modules sont dports sur un serveur :
IPC = Middleware = ensemble des couches logicielles qui s'interposent
entre l'application et le rseau
Ex: le module de gestion des donnes est transform en
service et hberg par un serveur (serveur de donnes)
Bernard ESPINASSE - Architecture Client-Serveur
Bernard ESPINASSE - Architecture Client-Serveur
Inter Process Communication (IPC) ou
Middleware
Exemple de dialogue C/S
SELECT libell, date, sujet FROM dossiers WHERE responsable = mon_user
application
interface de programmation (API)
l'application construit la requte et fait appel des fonctions de l'API pour
l'envoyer au serveur :
Middleware
fonction 1: remise zro de la zone tampon
protocoles de communication et formats (FAP)
fonction 2: criture du message de requte, premire partie
fonction 3: criture du message de requte, seconde partie mettre la suite du prcdent
fonction 4: fermeture de la zone tampon, le message est complet
Protocoles de transports (lis au rseau)
fonction 5: vrification de la syntaxe de la requte (analyse du message par l'API (phrase en ASCII))
FAP (Format And Protocols) pilote les changes travers le rseau :
si OK : fonction 6: passer la main au FAP pour envoi du message au serveur. L'application se met en
attente de la rponse ou effectue une autre tche en attendant de consulter l'API pour rcuprer le
rsultat
synchronisation des changes selon un protocole de communication
mise en forme des donnes changes selon un format connu de part et d'autre
l'API passe la main au FAP :
formatage du message : encapsulation du message dans une trame rseau (valise)
API (Application Programming Interfaces) :
les fonctions encapsules dans l'API permettent l'application de faire appel aux
services proposs par le serveur
Bernard ESPINASSE - Architecture Client-Serveur
envoi du message format au serveur : selon le protocole de communication
son arriv, le rsultat subit le mme l'opration inverse
10
Bernard ESPINASSE - Architecture Client-Serveur
Types de Middleware
RPC : dialogue synchrone sans cession
caractrise la nature du dialogue :
le client fait une RPC et reste "suspendu" en attendant la rponse du serveur
conversation synchrone trs simple :
le message d'appel contient tous les lments ncessaires au serveur (nom de la
synchrone / asynchrone : obligation (/ou non) pour le client d'attendre la
rponse du serveur aprs chaque envoi
avec connexion / sans connexion (ou avec session): ncessit (/ou non)
d'tablir une connexion entre le client et le serveur
procdure et paramtres associs, donnes d'identification de l'appelant (pour vrifier
autorisation))
le message en retour, en un seul flot, contient toute la rponse attendue par le
programme client
client
Dialogue ...
sans session
avec session
synchrone
RPC
APPC ou RDA
asynchrone
message queuing
APPC ou RDA
serveur
programme client
appel de la procdure distante
message d'appel
prise en compte
de la demande
rveil du serveur
rception du rsultat et
poursuite de l'excution
RPC : Remote Procedure Call ou appels de procdure distance (ex: DCE =
IPC bas sur RPC)
APPC : Application Program to Communication (l'APPC = lment de SNA
d'IBM)
RDA : Remote Data Access : norme de l'ISO pour l'accs distant aux BdD
Bernard ESPINASSE - Architecture Client-Serveur
rseau
11
message de rponse
excution procdure
! Inconvnients :
synchrone
fiabilit mdiocre (si l'mission initiale choue, le client n'est pas averti et pas de
mcanisme de reprise interne au protocole sous-jacent),
pas de resynchronisation possible entre C et S
pas de gestion de flux de retour (tjs un seul flot)
Bernard ESPINASSE - Architecture Client-Serveur
12
APPC/RDA : dialogue asynchrone avec session
APPC/RDA : dialogue asynchrone avec session
la demande de connexion mise par le programme client
l'change de points de synchronisation (principalement C!S) permet de garantir un
tat stable au contexte du client
si le serveur accepte la connexion ! cration d'un contexte propre au programme
client sur le serveur
durant toute la conversation asynchrone, client et serveur vont changer 3 types de
messages : requtes, rsultats, points de synchronisation
client
serveur
rseau
programme client
message d'appel
demande de connexion
l'applicatif client dfini et pilote les phases successives de l'change
serveur garantit le contexte tel qu'il est peru par le client
un ordre Commit ou Rollback du client conduira un point de synchronisation
un dbut ou une fin de transaction client conduira un point de synchronisation
prise en compte de la demande et
cration d'un contexte
Avantages:
mission de requtes
rception des rsultats
point de synchronisation
mission de requtes
! gestion de l'change plus facile mettre en oeuvre qu'avec les RPC
excution des
requtes et
gestion de la
synchronisation
Inconvnients :
! plus coteux en ressources que les RPC car tout au long de l'change :
rception des rsultats
- communication C/S maintenue
point de synchronisation
dconnexion
- le serveur cre et conserve le contexte
fin du contexte
13
Bernard ESPINASSE - Architecture Client-Serveur
APPC/RDA : dialogue asynchrone avec session
change Client-Serveur utilisant IPC fournit par un diteur de SGBDR (typiquement APISQL et FAP RDA) :
Application cliente
14
Bernard ESPINASSE - Architecture Client-Serveur
Message queuing : dialogue asynchrone et
sans session
Echanges fondamentalement asynchrones :
le client envoie un message un destinataire (le service) dsign par un nom (plutt
qu'une adresse ou une localisation) sans se soucier de sa disponibilit
Processeur serveur (SGBDR)
application cliente
l'application veut adresser une requte SQL de type
SELECT
tablissement de la connexion
cration du curseur (notion de contexte propre au client
connect)
mission de la requte
compilation de la requte
IN
OUT
service
IN
OUT
excution de la requte, message de bonne fin
demande de la structure du rsultat
envoi du descriptif de la structure du rsultat
demande des n premires lignes composant le rsultat
envoi des n premires lignes
demande des n lignes suivantes composant le rsultat
envoi des n lignes suivantes composant le rsultat
demande des n lignes suivantes composant le rsultat
rponse : plus de lignes envoyer
fin de connexion
destruction du curseur
Bernard ESPINASSE - Architecture Client-Serveur
15
Avantages :
grande simplicit car l'API repose sur les 2 verbes {envoyer, recevoir}
la technique "stocker et propager" (store and forward) garantit, quels que
soit les vnements, que le service appel sera effectu une et une seule
fois (utile dans applications financires)
Inconvnients :
manque de contrle sur le dlai d'obtention d'une rponse
Bernard ESPINASSE - Architecture Client-Serveur
16
Exemples d'IPC possibles
Le schma du Gartner Group
APPLICATION
SQL
CPI-C
RPC
SQL
RPC
interface de programmation
RDA
APPC
DCE
RDA
APPC
protocole de communication
IPX
SNA
TCP-IP
TCP-IP
Netbios
exemple 3
exemple 4
exemple 5
exemple 1
exemple 2
exemple 1
protocoles de com. et formats des
donnes changes aussi
(s'inspire souvent de la norme
RDA (ISO))
protocole IPX pour accder au
serveur disposant d'un mme IPC
FAP
protocole de transport
Gestion
distante des
donnes
Bases de
donnes
distribues
Revamping
X-Window
procdures
catalogues
R.D.A
R.D.A
distribu
Donnes
Donnes
Donnes
Traitements
API : CPI-C (Common
Programming Interface
Communication - ISO (origine
IBM))
l'application a recours des appels
de procdures distance
protocole APPC (Application
Program to Program
Communication)
DCE (Distributed Computing Env.
quasi standard)
Traitements
API : de type RPC
RDA avec un transport TCP-IP
Prsentation
17
Client-Serveur de prsentation
ne peut tre
considr comme
C/S
Donnes
Prsentation
terminal X
SNA (protocole de transport LU6.2)
C/S de
prsentation
Traitements
Traitements
Traitements
Prsentation
Prsentation
Prsentation
C/S de
traitement
suppose de pouvoir sparer la gestion de l'affichage de la
logique de l'affichage
X-Window
le C/S de prsentation ncessite un gestionnaire de
fentres
! interface ne s'appuyant pas sur un gestionnaire de fentres et reposant
sur le systme d'exploitation : par exemple Windows de Microsoft
gestion de
l'affichage
terminal X
poste client
Bernard ESPINASSE - Architecture Client-Serveur
18
logique de l'affichage
logique de
l'affichage
donnes
serveur d'application
et de donnes
gestion de l'affichage
rception et excution de la requte, mission d'un accus
de rception
l'utilisateur dplace et redimentionne la fentre
l'utilisateur clique sur un des boutons de la fentre
mission : vnements de type "click" sur l'objet "bouton_1"
rception du message, prise en compte de l'vnement,
prparation de la requte suivante
mission : affichage d'un dialogue...
Window A
Client 1
serveur X
C/S de
donnes
distribues
mission : affichage d'une fentre avec telles dimensions,
telles caractristiques et tel emplacement initial
X-Window = C/S de prsentation en mode natif = serveur
d'affichage ou "serveur X"
client
le plus connu et le
plus rpandu
Bernard ESPINASSE - Architecture Client-Serveur
poste client
! interface s'appuyant sur un gestionnaire de fentres (Window Manager) :
par exemple Motif sous Unix s'appuie sur le gestionnaire de fentre XWindow
Window B
Client 2
C/S de donnes
Client-Serveur de prsentation
serveur
Prsentation
Donnes
Prsentation
exemple 3
Bernard ESPINASSE - Architecture Client-Serveur
Traitements
Traitement
distribu
Traitements
! attention : toutes les combinaisons ne sont pas toujours possibles et toutes celles
qui sont possibles n'ont pas ncessairement une implmentation disponible ...
Donnes
Prsentation
dporte
Donnes
exemple 2
API : type SQL fournies par les
diteurs de SGBD (Oracle,
Sybase, ...)
API
Prsentation
distribue
Appli A
Appli B
X Client 1
X Client 2
! avantages : indpendance entre logique de prsentation et l'interface graphique
utilise (les standards X11 et NFS)
! inconvnients : trafic rseau gnr par le protocole X11 important, X11 pas une
norme, stabilit?
serveur d'application
19
Bernard ESPINASSE - Architecture Client-Serveur
20
Client-Serveur de donnes
serveur
R.D.A
Client-Serveur de donnes
le serveur abrite la gestion des donnes
trs tt les SGBDR ont propos des IPC pour accder leurs
donnes (Oracle, Ingres, ...1985)
1 - requte utilisateur
6 - affichage des rsultats
appli
cliente
3 - recherche
tuples.
2 - requte
SGBDR
5 - rsultats
le serveur assure aussi l'intgrit des donnes
Donnes
poste client
les SGBD modernes proposent des mcanismes permettant de
dclencher des traitements de contrle :
client 1
application
IPC
Dos+LAN
s'assurant de la validit des mises jour des BD,
client 2
application
IPC
Dos+LAN
4 - tuples
serveur
Serveur
SGBD
B.D
LAN + OS + IPC
indpendamment des applications
incontournables
Traitements
Prsentation
Avantages :
! prservation de la cohrence des donnes
facile mettre en oeuvre,
largement disponible,
bien adapt aux utilisateurs de type consultation/dcision
! plus d'efficacit
! moins de maintenance
client
Inconvnients :
! plus de scurit
pas compltement normalis,
inadapt aux exigences du transactionnel intensif
21
Bernard ESPINASSE - Architecture Client-Serveur
Client-Serveur de traitements
Client-Serveur de traitements
serveur
procdures
catalogues
Donnes
Traitements
meilleure rpartition des traitements sur le client et le serveur
! charge plus faible sur le rseau
ncessite un dcoupage fin du noyau de l'application,
demande beaucoup de savoir-faire pour sa mise en oeuvre !
encore peu rpandu
logique
fonctionnelle
et affichage
poste client
Traitements
Prsentation
client
logique des
traitements
Rpartition du processus :
Charge sur le rseau
(trafic sur le rseau : nb et volu me de messages changs)
serveur de fichiers
C/S de prsentation
(X-Window)
donnes
C/S de donnes
serveur d'application
et de donnes
le module "logique fonctionnelle" de l'application client envoie
des requtes SQL mais aussi des appels de procdures
(procdures catalogues) au serveur qui les excute et
renvoie les rsultats
sur le serveur, le module d'excution des procdures n'est pas
obligatoirement associ aux modules d'intgrit et de gestion
des donnes
peut tre mis en oeuvre avec un mcanisme de type RCP entre
client et serveur
Bernard ESPINASSE - Architecture Client-Serveur
22
Bernard ESPINASSE - Architecture Client-Serveur
23
C/S de traitements
poste client
serveur
Avantages :
meilleures performances,
trafic rseau rduit
Inconvnients :
ncessite un dveloppement ct serveur,
ne convient pas pour les applications "haddock" type infocentre
Bernard ESPINASSE - Architecture Client-Serveur
24
C.- S. : a r c h i t e c t u r e s c e n t r a l i s e s ( d s 1 9 7 0 )
C.- S. : architectures centralises (ds 1980)
Client serveur de Premire Gnration
Client serveur de Deuxime Gnration
LAN
Serveur
WAN
Base de
donnes
Ordinateur
hote
Rseau
propritaire
Base de
donnes
Serveur
LAN
Routeur
Serveur
Base de
donnes
terminaux passifs pas ergonomiques
Client : gestion prsentation
Serveur : ralisation
25
Bernard ESPINASSE - Architecture Client-Serveur
C.- S.: architectures centralises (ds 1990)
Base de
donnes
terminaux ergonomiques
LAN : Large Area Network - WAN : Wide Area Network
Client : gestion prsentation + Portage traitements applicatifs
Serveur : gestion accs BD
26
Bernard ESPINASSE - Architecture Client-Serveur
Le middleware en dtail
Client serveur de Troisime Gnration
application
serveur
middleware
Intranet
Base de
donnes
Serveur
rseau
Firewall
Serveur Web
Serveur
middleware (=IPC) = intelligence du rseau
permet d'unifier pour les applications l'accs et la manipulation de l'ensemble des
services disponibles sur le rseau
Client Internet
Clients
Base de
donnes
Base de
donnes
application
Internet
Firewall
interface de programmation (API)
Middleware
protocoles de communication et formats (FAP)
Clients (Unix, Windows, ) : gestion prsentation
Serveur applicatif : lien entre client et plusieur serveurs de BD
Serveur de donnes : gestion accs BD
Protocoles de transports (lis au rseau)
! middleware = cl de l'interoprabilit : largir les fonctionnalits et aller vers les
standards
Bernard ESPINASSE - Architecture Client-Serveur
27
Bernard ESPINASSE - Architecture Client-Serveur
28
Le middleware en dtail
Couche
API
Les types de middlewares
Fonction
interface de programmation
Exemple
Fonctions assures :
Elmentaire
point d'entre unique pour les applications
gre l'ordonnancement de l'change : ouvrir
une connexion, envoyer une requte,
rcuprer rsultats, crer les messages ->
transport
FAP
transport
protocole de transport
insre les messages et les insre dans une
trame qui circulera sur le rseau
mthode d'accs au
mdia
protocole d'accs au mdia
TCP-IP
Netbios
...
Ethernet
TokenRing
Middleware et couche ISO :
couche 7 : application
couche 6 : reprsentation
couche 5 : session
couche 4 : transport
couche 3 : rseau
couche 2 : liaison
couche 1 : physique
Intermdiaire
gestion du protocole de
communication
transfert des requtes et
des rsultats
transmission des codes
d'erreurs et de statut
protocole de communication
API
catalogue complet des
donnes
pas de catalogue des
support total des appels de
donnes
fonctions
support limit des appels
transparences de la
de fonctions
localisation des donnes
administration restreinte du administration complte
ou des serveurs
des serveurs et des
services associs
scurit tendue
(d'aprs A. Lefebvre)
Marketing :
proposs par les diteurs de serveurs (SGBD (oracle, ...))
proposs par les diteurs de middleware (ex: Sequelink,...)
proposs par les constructeurs (DRDA/IBM, DDA/Bull, ...)
FAP
ex : TCP-IP
ex : accs mdia
ex : coaxial
29
Bernard ESPINASSE - Architecture Client-Serveur
Les performances
Sequelink (indpendant) :
(Source : tude Dipro )
serveur
client
application
SGBDR
API Sequelink
Interface SGBDR
Noyau Sequelink
Noyau Sequelink
Interface rseau
Interface rseau
protocole de transport rseau
(application : C sous Windows; requte SQL lecture; SGBD Ingres sur HP9000 (unix):
dcisionnel
transactionnel
50
45
40
35
30
Sybase (propritaire) : Open Client & Open Server
25
20
CLIENTS
OpenClient
OpenClient
30
Bernard ESPINASSE - Architecture Client-Serveur
L'offre en Middlewares
OpenClient
Etendue
passerelles vers SGBD
15
10
5
SQLserver
SQLserver
(sous VM ou MPE)
OpenServer (net gateway)
serveur
transport
IPC
application
! le serveur consomme la plupart du temps ncessaire
l'excution complte d'une requte (simple ou complexe)
(sous Unix ou Netware)
SERVEURS
DB2 & CICS
Bernard ESPINASSE - Architecture Client-Serveur
31
Bernard ESPINASSE - Architecture Client-Serveur
32
Les performances
Performances d!une application cliente dpendent de 3 critres :
le dbit : (rseau: de SNA, DSA = 9,6 kb/s; ...64 kb/s...) doubler le dbit des
liaison amliore les temps de rponse de 30%
l'affichage : performance de l'environnement graphique
l'excution procdurale : vitesse d'excution du langage
Importance relative des critres :
procdural
(5%)
affichage
(30%)
dbit
(65%)
Nb d'utilisateurs :
temps de rponse en secondes
35
30
25
20
15
10
5
3 utilisateurs
2 utilisateurs
1 utilisateur
9,6Kb/s
Bernard ESPINASSE - Architecture Client-Serveur
16 Kb/s
38,4Kb/s
64Kb/s
33
