Vous êtes sur la page 1sur 81

CLIENT/SERVEUR

CLIENT/SERVEUR

Partie 1 : Prsentation du modle client-serveur

Un peu d'histoire.
Le client serveur est l'tat actuel de l'volution
des architectures informatiques :
Avant les Annes 80 : Systme Centralis
(ordinateur central avec des terminaux passifs
de type texte).
Les Annes 80 : Dveloppement du
transactionnel et apparition des SGBD nonpropritaires (indpendants des
constructeurs) - SGBD relationnel + SQL

Un peu d'histoire.
Les Annes 80 : Paralllement dveloppement
des micros-ordinateurs avec leur puissance de
calcul dcentralise et leurs interfaces
graphiques conviviales.
Le maintien des gros et moyens systmes avec
les micros-ordinateurs ont rendu les
communications difficiles et ont cr des
dsordres dans les systmes d'informations
(redondance,etc.)

Un peu d'histoire.
Les Annes 90 : Dveloppement des rseaux.
L'efficacit et le partage des systmes
d'informations doivent tre optimum
(concurrence conomique, etc.).
Le client-serveur se situe dans ce besoin de
centralisation (information cohrente, non
redondante et accessible) et de
dcentralisation (conserver la puissance et
l'interface des micros-ordinateurs)

Le modle Multi-Utilisateur centralis


E
C
R
A
N

CLIENT

INTELLIGENCE
SERVEUR

Serveur = Ordinateur central qui effectue tous


les traitements
Client = Terminal sans puissance locale de
traitement

Le modle rseau local traditionnel


E
C
R
A
N

CLIENT
INTELLIGENCE

SERVEUR

Serveur = Gre le rseau et stocke les bases de


donnes sans les gres.
Client = Les stations effectuent tous les
traitements

Le modle Client-Serveur
E
C
R
A
N

CLIENT
INTELLIGENCE

INTELLIGENCE
SERVEUR

Rpartition judicieuse de la puissance de


traitement entre le serveur et les diffrentes
stations interconnectes.

Pourquoi le Client-Serveur ?
Contraintes sur l'entreprise
Contraintes externes : comptitivit, exigence de
la clientle, produire mieux et plus vite, etc.
Contraintes internes : Compression des budgets
(limitation des ressources), manque de temps,
absorption des technologies nouvelles

Mieux matriser le systme d'information


Une architecture ouverte C/S btie autour d'un
moteur relationnel amliore cette matrise :
prsentation naturelle des donnes, meilleure
productivit des dveloppeurs avec le SQL

Pourquoi le Client-Serveur ?
Prise en compte des volutions technologiques
Aspect ouvert et modulaire du Client-serveur.

Mais.
Rduire les cots ?
L'architecture C/S cote plus cher qu'une
architecture centralise :
Postes de travail
Rseau local
Formation des dveloppeurs (SGBD, Middleware,
l'objet et les interfaces graphiques)
Techniciens de maintenance rseau et PC

Client/Serveur : dfinition
Est conforme au modle clientserveur tout processus utilisant
des services offerts par un autre
processus, et communiquant avec
lui laide de messages.

Client/Serveur : dfinition
CLIENT
REQUTE

REPONSE
SERVEUR

Approche Puriste
E
C
R
A
N

CLIENT
REQUTE

Approche Pragmatique

REPONSE
SERVEUR

Client/Serveur : dfinition
La prsence d'un rseau n'est pas
obligatoire dans la dfinition. On peut
nanmoins considrer qu'une architecture
C/S ne se construit qu'autour d'un rseau.
Le terme SERVEUR fait rfrence tout
processus qui reoit une demande de
service (requte) venant d'un client via un
rseau, traite cette demande et renvoie le
rsultat (rponse) au demandeur (le
CLIENT).

Client-Serveur : dfinition
CLIENT
Processus qui demande l'excution d'une
opration par l'envoi d'une demande.

SERVEUR
Processus qui excute la demande du client et
qui transmet la rponse.

REQUTE (Request)
Message transmis par le client.

REPONSE (Reply)
Message transmis par le serveur.

Les 4 principes de base du C/S


Principe 1 :
Rendre l'architecture matrielle transparente
vis vis des dveloppeurs et des utilisateurs
finals.
Principe 2 :
Rendre le niveau physique (et logique dans une
moindre mesure) des bases de donnes
transparent pour les dveloppeurs et les
utilisateurs.

Les 4 principes de base du C/S


Principe 3 :
Utiliser au niveau de chaque station (cliente ou
serveur) l'ensemble matriel/logiciel le plus
adapt.
Chaque machine est adapte des besoins prcis
(implique l'htrognit des matriels).
Optimisation de l'outil.
Diversit des services offerts l'utilisateur.
Minimisation des cots (le sophistiqu l o il es
ncessaire.

Les 4 principes de base du C/S


Principe 4 :
Permettre une sparation physique entre les
actions d'un programme lies l'interaction
avec les utilisateurs et les autres actions.
Gestion du dialogue par le client (interface)
Gestion des donnes par le serveur

Il s'agit d'un modle de traitement coopratif.

Dcoupage des applications


client-serveur
On reconnat traditionnellement dans une application
3 modules :
DONNEES

TRAITEMENT

PRESENTATION

Dcoupage des applications


client-serveur
La rpartition de ces 3 modules variera entre le client
et le serveur et sera fonction :
Des types darchitecture retenus
De la capacit des machines
De la capacit du rseau
Le Gartner Group a propos les cas de figure suivants :

Le schma du Gartner Group

Le schma du Gartner Group


Client/Serveur de prsentation
Type 1 : Reprsente un systme Serveur/terminal
classique. Ce dernier prsente un cran
"calcul" par le serveur. Le type 1 n'est pas un
systme client/serveur.
Type 2 : L'affichage effectu par le client se fait
la suite d'un change de requtes avec le serveur
(type de fentre sa taille, son titre, etc.)
X-Windows est le systme reprsentatif du type 2

Le schma du Gartner Group


Client/Serveur de Traitements (Type 3)
Les donnes restent centralises mais les
traitements sont rpartis entre le client et le
serveur (cf. Le dialogue RPC).
Les applications Web rentrent dans cette
catgorie avec :
du ct client les scripts intgrs dans les pages
HTML, les plug-in et/ou les composants.
du ct serveur les divers programmes (accs
aux bases de donnes,) qui transmettent
leurs rsultats aux clients

Le schma du Gartner Group


Client/Serveur de donnes
Systme popularis par les SGBDR associs au
SQL. Dans ce contexte le serveur gre les
donnes, leur intgrit, la scurit, etc. Il envoie
seulement les donnes correspondant la
requte (opposition avec le serveur de fichiers).
Le client traite ces donnes pour ventuellement,
en retour, mettre jour la base.
Un partie de la base de donnes pour tre sur le
client -type 5- (cf. rpartition des bases de
donnes)

Conclusion (partie 1)
Modle client/serveur se caractrise donc
par :
Des ressources indpendantes,
L'importance du dialogue entre le
client et le serveur,
La place centrale du rseau.

Ressources indpendantes
Hbergement
Toute plate-forme matrielle peut devenir serveur
Tout systme dexploitation peut hberger un
service
Toutes configurations matrielles ou logicielles
envisageables

Localisation
Les ressources peuvent tre nimporte o sur le
rseau
Architecture plus modulaire
Administration plus complexe

Ressources indpendantes
Utilisation
Les ressources ne sont pas ddies une
utilisation particulire
Partage des ressources facilit

Importance du Dialogue
Importance accrue des communications
Le rseau devient le centre de gravit du SI
Le rseau devient la cl de vote du modle
client-serveur

Complexification du dialogue
Dialogue entre systmes htrognes
Dialogue distance

Ncessit de couches intermdiaires


Pour grer la complexit
Pour rendre transparent le dialogue

Les protocoles
L'importance du rseau les placent au premier
plan :
Dfinissent le fonctionnement des rseaux
Couvrent 3 types de services
les services dapplication
les services de transport
les services de liaison

Respectent le modle OSI (interconnexion des


systmes ouverts) dfini par lISO

CLIENT/SERVEUR

Partie 2 : Le MIDDLEWARE

Dfinition
Georges GARDARIN dfinit le middleware
comme :
"L'ensemble des services logiciels construits audessus d'un protocole de transport afin de
permettre l'change de requtes et des
rponses associes entre client et serveur de
manire transparente."
D'autres auteurs intgrent les couches rseaux
dans le middleware.

Dfinition
Application(s)

Serveur(s)

MIDDLEWARE
RESEAU

Une triple transparence :


Transparence aux rseaux. Tous les types de rseaux
doivent tre supports.
Transparence aux serveurs. Tous le SGBD (avec leur
SQL souvent diffrents) doivent tre accessibles.
Transparence aux langages. Les fonctions appeles
doivent tre aussi indpendantes que possible des
langages.

Pourquoi le Middleware ?
La complexit du dialogue client/serveur est
l'origine du middleware. Complexit due la
prsence :
Des Systmes htrognes
Des Systmes propritaires
Du dialogue distance

Le Middleware : quoi a sert ?


Avantages
Offre des services de haut niveau aux applications
Rend portable les applications (avec certaines
limites)
Prend en charge les protocoles de conversion de
caractres et dtablissement de sessions entre
clients et serveurs htrognes

Cest la glue qui rend possible le clientserveur


Cest la bote outils pour le dveloppement des
applications.

L'architecture type du Middleware


L'IPC (Inter Processus Communication) est
l'autre nom du middleware.
L'IPC se compose :
L'interface API (Application Programming
Interface) - Interface de programmation au
niveau applicatif.
Interface entre un programme et le systme
qui propose un ensemble de fonctions
standards pour accder un service local ou
distant.

L'architecture type du Middleware


L'interface FAP (Format And Protocols) Protocoles de communication et format des
donnes.
Ce module assure :
la synchronisation entre client et serveur,
la reconnaissance du format des donnes
changes
l'appel aux fonctions de transport du
rseau.

L'architecture type du Middleware

Client serveur et modle OSI


Couche 7 - Application
Couche 6 - Prsentation
Couche 5 - Session
Couche 4 - Transport
Couche 3 - Rseau
Couche 2 - Liaison
Couche 1 - Physique

API
FAP
Par Ex : TCP
Par Ex : IP
Par Ex : CSMA/CD
Par Ex : Paire torsade

Client serveur et modle OSI


couches

Le dialogue avec session


Client

Rseau

Application
Demande de connexion
Requte
Rsultats
Synchronisation
Requte
Rsultats

Serveur

Prise en compte de demande


et cration d'un contexte
Excution des requtes
et gestion de la
synchronisation

Synchronisation
Dconnexion

Fin du contexte

Le dialogue avec session


Dans les dialogues avec session (ou avec
connexion). Les changes dinformations
sont subordonns louverture dune
session par le client vers le serveur.
IPC avec connexion :
Protocole APPC de larchitecture rseau
SNA dIBM (Application Programm to
Progamm Application)
Protocole RDA, bas sur SQL dfini par
lISO (Remote Data Access)

Le dialogue avec session


Si le serveur accepte la connexion, il cre un
contexte propre chaque application cliente
connecte.
Client et serveur s'changent des requtes, des
rponses et des points de synchronisation.
Le client a la responsabilit de conduire les
phases successives de l'change
Le serveur a la responsabilit de garantir le
contexte peru par le client.

Le dialogue avec session


Les ordres SQL "COMMIT" ou "ROLL
BACK" sont des exemples de points de
synchronisation.
A la suite d'une requte le :
COMMIT confirmera la transaction,
ROLL BACK l'annulera.

Le serveur mettra rellement jour la base


de donnes qu' la suite de ces ordres de
synchronisation (avant cela les transactions
s'appliquent dans le "contexte")

Le dialogue sans connexion : les RPC


Client
Application

Rseau

Requte

Appel de la procdure
distante
Rponse
Rception du rsultat
poursuite de l'excution

Serveur

Prise en compte
de la demande

Excution de la
procdure

Le dialogue sans connexion : les RPC


Les dialogues sans connexion avec appels de
procdures distantes (RPC - Remote
Procedure Call).
Le processus client invoque une procdure
distante situe sur le serveur.
La requte contient tous les lments ncessaires
au serveur (nom de la procdure, paramtres,
identit du processus).
Le message en retour contient toute la rponse.

Loffre Middleware
Les offres Middleware sont varies :
Offres propritaires,
Offres d'accs universel aux bases,
Offres pour des accs multibases

Les offres propritaires aux SGBDR :


ORACLE avec Sql*Net
SYBASE avec Db-lib

Loffre Middleware
Les offres multi-clients, multi-serveurs. Elles
permettent aux clients d'accder en toute
transparence plusieurs bases htrognes,
situes ventuellement sur des serveurs
diffrents.
SEQUELINK : Techgnosis propose une API sur
presque toutes les architectures clientes ou serveurs
EDA/SQL : Information Builders propose
daccder tout type de bases de donnes partir
de plates-formes htrognes

Loffre Middleware
DRDA (Distributed Relational Database
Architecture) d'IBM pour fdrer les bases IBM
(DB2) et non IBM.
IDAPI (Integrated Database Application
Programming Interface) de Borland en
collaboration avec Novell et IBM.

Note : videmment l'accs multibases permet galement l'accs


monobase.

Loffre Middleware
Laccs universel aux donnes pour les
clients
ODBC de Microsoft : accs standardis aux
principales bases de donnes du march
(drivers)
IDAPI de Borland et Novell

Le Standard ODBC
ODBC (Open DataBase Connectectivity) est
prsent en 1992 par Microsoft comme une
interface universelle aux bases de donnes.
Il ne s'agit pas d'un middleware
proprement parl mais d'une API que l'on
utilise en lieu et place des API des diteurs de
SGBDR

Le Standard ODBC
Exemple : De Sybase ODBC
Application

Application

API : db-lib
(li au SE db-lib pour OS2,
pour Windows, etc)

API : ODBC
DataBase Driver

FAP : net-lib
(li au SE et au
rseau)

FAP : net-lib
(li au SE et au
rseau)

Rseau

Rseau

Le Standard ODBC

CLIENT/SERVEUR

Partie 3 : La Rpartition des Bases de donnes

Dfinitions
Base de donnes rpartie
Ensemble de bases de donnes gres par des
sites diffrents et apparaissant l'utilisateur
comme une base unique.
SGBD Rparti (ambigut de SGBDR)
Systme qui gre des collections de BD
logiquement relies, distribues sur un rseau,
en fournissant un mcanisme d'accs qui rend
la rpartition transparente aux utilisateurs

Dfinitions
On parlera ainsi de :
Client de SGBD Rpartie
Application qui accde aux informations
distribues par les interfaces du SGBD Rparti.
Serveur de SGBD Rpartie
SGBD grant une base de donnes locale intgre
dans une base de donnes rpartie
D'une faon gnrale on parlera de SITE (client
ou serveur)
Dfinitions de G. GARDARIN

Pourquoi rpartir les donnes ?


La performance daccs aux bases est limite
Par le nombre daccs disques ncessaires
Par le volume de donnes transmis (dbit du
rseau)
Par le nombre daccs concurrents

Les performances peuvent se dgrader


rapidement
Au-del de 30 postes clients
Pour des consultations trs frquentes ou trs
importantes
Dans le cadre daccs distance (rseau tendu)

Conception des BdD Rparties


Il existe deux types de conception :
Conception descendante
Conception d'un schma global
Distribution des objets de ce schma sur les
diffrents sites pour obtenir des schma locaux
Base de donnes Globale

Base de donnes
locale 1

Base de donnes
locale 2

Base de donnes
locale 3

Conception des BdD Rparties


Conception ascendante
Dans ce cas une base de donnes globale fdre
des base de donnes locales afin de crer un
ou plusieurs schmas globaux.
(Le plus souvent il y refonte des schmas locaux)
Base de donnes Globale

Base de donnes
locale 1

Base de donnes
locale 2

Base de donnes
locale 3

Conception des BdD Rparties


Les deux cas reviennent partager,
fragmenter la base de donnes globale entre
plusieurs sites.
Fragment
Un fragment est une sous-table obtenue par
slection de lignes et de colonnes partir
d'une table globale, localise sur un site
unique.
(peut correspondre galement la table entire)

Conception des BdD Rparties


2 Types de fragmentation :
Fragmentation Horizontale
Dcoupage d'une table en slectionnant des
lignes (Il s'agit d'une slection SQL ).
Exemple : Table VENDEUR fragmente selon
les rgions d'affectation des reprsentants
Lignes de la rgion 1
Autres rgions

Conception des BdD Rparties


Fragmentation Verticale
Dcoupage d'une table en slectionnant des
colonnes (Il s'agit d'une projection SQL ).
Exemple : Table PRODUIT fragmente selon les
fonctions commerciale et production
( Pour la production projection sur : Ref, Desig et cout
(Pour le commercial projection sur : Ref, Desig, Prix et
Conditionnement )
Production

Commercial

Conception des BdD Rparties


Fragmentation Mixte
Rsultat d'un fragmentation horizontale et
verticale.
La recomposition de la table originale doit
toujours tre possible par :
L'union des fragments horizontaux,
La jointure des fragments verticaux.

Conception des BdD Rparties


Allocation des fragments (*)
Les fragments peuvent tre :
Dupliqus sur les sites
Les fragments apparaissent plusieurs fois.
Placs (rpartis) sur les sites
Les fragments n'apparaissent que sur un
seul site.

(*) Rappel : Le fragment peut correspondre une table.

La Gestion des Transactions


Proprits des transactions
ATOMICITE : Une transaction doit effectuer
toutes ses mises jour ou ne rien faire.
COHERENCE : La transaction doit faire passer
la base de donnes d'un tat cohrent un autre.
ISOLATION : Les rsultats d'une transaction ne
doivent tre visibles aux autres transactions
qu'une fois la transaction valide.
DURABILITE : Ds qu'une transaction valide ses
modifications, le systme doit garantir que ces
modifications seront conserves en cas de panne.

La Gestion des Transactions


Validation en deux phases
Cette validation est base sur un principe
centralis.
L'excution de la transaction est contrle par un
site coordinateur, rle jou par le client.
Les autres sites intresss par la transaction sont
des participants, rle jou par les sites serveurs.

La Gestion des Transactions


Validation en deux phases
Le client coordinateur demande aux autres sites
(serveurs) s'ils sont prts mettre jour leur base
(ordre PREPARE).
Si tous les participants rpondent positivement
(ordre OK) alors le site coordinateur envoie
l'ordre COMMIT. Les serveurs envoient un
acquittement au coordinateur (ordre ACK).
Si l'un des participant rpond ngativement
(ordre KO) alors le site coordinateur envoie
l'ordre d'annulation (ordre ABORT).

La Gestion des Transactions


Serveur 1

Client Coordinateur

PREPARE

Serveur 2
PREPARE

OK

OK
COMMIT

COMMIT
ACK

ACK

Validation en deux tapes avec succs

La Gestion des Transactions


Serveur 1

Client Coordinateur

PREPARE

Serveur 2
PREPARE

OK

KO

ABORT

ABORT
ACK

ACK

Validation en deux tapes avec panne totale d'un participant

La Gestion des Transactions


Commentaires :
Une non-rponse est assimile un refus
(time out).
Le serveur 2 annule la transaction car il ne l'a
pas accept (PREPARE mais pas de OK).

La Gestion des Transactions


Serveur 1

Client Coordinateur

PREPARE

Serveur 2

PREPARE
OK

OK

COMMIT

COMMIT
ACK

STATUS
COMMIT
ACK

Validation en deux tapes avec panne partielle d'un participant

La Gestion des Transactions


Commentaires :
Le serveur 2 a accept la transaction (OK) puis
tombe en panne. COMMIT n'est pas reu.
A la reprise, le serveur qui a effectu la
sauvegarde sur disque analyse son journal et
demande l'tat de la transaction qui entre
temps a pu tre annule (ordre STATUS).
Dans cet exemple la reprise est faite avec un
ordre COMMIT.

La Gestion des Transactions


Validation en deux phases distribu
Dans le cadre d'un rseau local, le message OK
est en fait reu par toutes les stations.
Chacune peut donc compter le nombre de OK
et valider la transaction
OK

PREPARE

Les Base de donnes Dupliques


La rplication entrane la cration de copies
multiples d'une base de donnes sur plusieurs
sites. La duplication peut concerner la base
entire, une ou plusieurs tables ou des
fragments.
A la suite de transactions les copies peuvent
diverger un instant donn mais doivent
converger vers un tat identique et cohrent
terme.

Les Base de donnes Dupliques


Les bases de donnes dupliques (ou rpliques)
posent donc un problme particulier celui de
la MISE A JOUR des bases pour obtenir cette
convergence.
Les avantages de la duplication
Amliorer les performances : L'utilisation de
la base la plus proche permet de limiter les
transferts et de rpartir la charge de travail.

Les Base de donnes Dupliques


Augmenter la disponibilit :En cas de panne en
particulier.
Utiliser des serveurs plus petits et moins chers.
Les inconvnients de la duplication
Il faut assurer la convergence des copies.
Il faut assurer la transparence aux utilisateurs
qui ne doivent percevoir qu'une seule copie.

Les Base de donnes Dupliques


Deux types de mise jour :
Mise jour SYNCHRONE
Toute transaction entrane la mise jour en
temps rel de toutes les copies de la base.
Avantage : convergence immdiate
Inconvnient : Coteux en ressources et
complexit du systme (gestion des reprises
sur panne)
Technique parfois obligatoire : Base des taux de
change par exemple.

Les Base de donnes Dupliques


Mise jour ASYNCHRONE
On prfre le plus souvent le mode asynchrone
(ou mode diffr). Les mises jour sont
effectues ds que possible ou des instants
fixs.

Les Base de donnes Dupliques


Le synchronisme se combine au concept de
symtrie qui permet de crer une hirarchie
dans les bases.
Dans la rplication SYMETRIQE toutes les
bases ont le mme degr hirarchique.
Dans la rplication ASYMETRIQUE on
distingue un site primaire charg de
centraliser les mises jour.

Les Base de donnes Dupliques


Exemple de mise jour asymtrique
asynchrone (Consolidation dinformations)
Les donnes comptables tenues jour dans les
agences sont dupliques en lecture seulement vers
le sige pour consolidation.
Mise jour en fin de
journe par exemple
Dpts
&
Retraits

Agence

Sige Social

Agence

Agence

Les Base de donnes Dupliques


Exemple de mise jour asymtrique
synchrone (Diffusion dinformations
centralises)
Les informations appartiennent au site primaire,
qui a le monopole des mises jour
Les donnes sont diffuses automatiquement vers
les sites qui ont un droit de lecture seulement
Copie PRIMAIRE

Sige Social

Cours des devises

Copies SECONDAIRES
Agence

Agence

Agence

Les Base de donnes Dupliques


Exemple de mise jour symtrique asynchrone
Chaque dpartement met rgulirement jour les
donnes des autres dpartements.
Commercial

Copie Matre

Temps diffr
Financier

Stocks

Copie Matre

Copie Matre

Les Base de donnes Dupliques


Exemple de mise jour symtrique synchrone
Chaque site modifie la donne PRIX puis diffuse
immdiatement la modification.
Modification du
PRIX

Produit

Copie Matre

Temps rel
Produit

Produit

Copie Matre

Copie Matre