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