Client Serveur

CLIENT/SERVEUR
CLIENT/SERVEUR
Partie 1 : Présentation du modèle client-serveur
Un peu d'histoire…….
Le client serveur est l'état actuel de l'évolution
des architectures informatiques :
• Avant les Années 80 : Système Centralisé
(ordinateur central avec des terminaux passifs
de type texte).
• Les Années 80 : Développement du
transactionnel et apparition des SGBD nonpropriétaires (indépendants des
constructeurs) - SGBD relationnel + SQL
Un peu d'histoire…….
• Les Années 80 : Parallèlement développement
des micros-ordinateurs avec leur puissance de
calcul décentralisée et leurs interfaces
graphiques conviviales.
Le maintien des gros et moyens systèmes avec
les micros-ordinateurs ont rendu les
communications difficiles et ont créé des
désordres dans les systèmes d'informations
(redondance,etc.)
Un peu d'histoire…….
• Les Années 90 : Développement des réseaux.
L'efficacité et le partage des systèmes
d'informations doivent être optimum
(concurrence économique, etc.).
Le client-serveur se situe dans ce besoin de
centralisation (information cohérente, non
redondante et accessible) et de
décentralisation (conserver la puissance et
l'interface des micros-ordinateurs)
Le modèle 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 modèle réseau local traditionnel
E
C
R
A
N
CLIENT
INTELLIGENCE
SERVEUR
Serveur = Gère le réseau et stocke les bases de
données sans les gérées.
Client = Les stations effectuent tous les
traitements
Le modèle Client-Serveur
E
C
R
A
N
CLIENT
INTELLIGENCE
INTELLIGENCE
SERVEUR
Répartition judicieuse de la puissance de
traitement entre le serveur et les différentes
stations interconnectées.
Pourquoi le Client-Serveur ?
• Contraintes sur l'entreprise
– Contraintes externes : compétitivité, exigence de
la clientèle, produire mieux et plus vite, etc.
– Contraintes internes : Compression des budgets
(limitation des ressources), manque de temps,
absorption des technologies nouvelles
• Mieux maîtriser le système d'information
– Une architecture ouverte C/S bâtie autour d'un
moteur relationnel améliore cette maîtrise :
présentation naturelle des données, meilleure
productivité des développeurs avec le SQL
Pourquoi le Client-Serveur ?
• Prise en compte des évolutions technologiques
Aspect ouvert et modulaire du Client-serveur.
Mais….
• Réduire les coûts ?
L'architecture C/S coûte plus cher qu'une
architecture centralisée :
• Postes de travail
• Réseau local
• Formation des développeurs (SGBD, Middleware,
l'objet et les interfaces graphiques)
• Techniciens de maintenance réseau et PC
Client/Serveur : définition
Est conforme au modèle clientserveur tout processus utilisant
des services offerts par un autre
processus, et communiquant
avec lui à l’aide de messages.
Client/Serveur : définition
CLIENT
REPONSE
REQUÊTE
SERVEUR
Approche Puriste
E
C
R
A
N
CLIENT
REPONSE
REQUÊTE
Approche Pragmatique
SERVEUR
Client/Serveur : définition
• La présence d'un réseau n'est pas
obligatoire dans la définition. On peut
néanmoins considérer qu'une architecture
C/S ne se construit qu'autour d'un réseau.
• Le terme SERVEUR fait référence à tout
processus qui reçoit une demande de
service (requête) venant d'un client via un
réseau, traite cette demande et renvoie le
résultat (réponse) au demandeur (le
CLIENT).
Client-Serveur : définition
• CLIENT
Processus qui demande l'exécution d'une
opération par l'envoi d'une demande.
• SERVEUR
Processus qui exécute la demande du client et
qui transmet la réponse.
• REQUÊTE (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 matérielle transparente
vis à vis des développeurs et des utilisateurs
finals.
• Principe 2 :
Rendre le niveau physique (et logique dans une
moindre mesure) des bases de données
transparent pour les développeurs et les
utilisateurs.
Les 4 principes de base du C/S
• Principe 3 :
Utiliser au niveau de chaque station (cliente ou
serveur) l'ensemble matériel/logiciel le plus
adapté.
– Chaque machine est adaptée à des besoins précis
(implique l'hétérogénéité des matériels).
– Optimisation de l'outil.
– Diversité des services offerts à l'utilisateur.
– Minimisation des coûts (le sophistiqué là où il es
nécessaire.
Les 4 principes de base du C/S
• Principe 4 :
Permettre une séparation physique entre les
actions d'un programme liées à l'interaction
avec les utilisateurs et les autres actions.
– Gestion du dialogue par le client (interface)
– Gestion des données par le serveur
Il s'agit d'un modèle de traitement coopératif.
Découpage des applications
client-serveur
On reconnaît traditionnellement dans une application
3 modules :
DONNEES
TRAITEMENT
PRESENTATION
Découpage des applications
client-serveur
La répartition de ces 3 modules variera entre le client
et le serveur et sera fonction :
– Des types d’architecture retenus
– De la capacité des machines
– De la capacité du réseau
Le Gartner Group a proposé les cas de figure suivants :
Le schéma du Gartner Group
Le schéma du Gartner Group
• Client/Serveur de présentation
– Type 1 : Représente un système Serveur/terminal
classique. Ce dernier présente un écran
"calculé" par le serveur. Le type 1 n'est pas un
système client/serveur.
– Type 2 : L'affichage effectué par le client se fait à
la suite d'un échange de requêtes avec le serveur
(type de fenêtre sa taille, son titre, etc.)
X-Windows est le système représentatif du type 2
Le schéma du Gartner Group
• Client/Serveur de Traitements (Type 3)
– Les données restent centralisées mais les
traitements sont répartis entre le client et le
serveur (cf. Le dialogue RPC).
Les applications Web rentrent dans cette
catégorie avec :
• du côté client les scripts intégrés dans les pages
HTML, les plug-in et/ou les composants.
• du côté serveur les divers programmes (accès
aux bases de données,…) qui transmettent
leurs résultats aux clients
Le schéma du Gartner Group
• Client/Serveur de données
Système popularisé par les SGBDR associés au
SQL. Dans ce contexte le serveur gère les
données, leur intégrité, la sécurité, etc. Il envoie
seulement les données correspondant à la
requête (opposition avec le serveur de fichiers).
Le client traite ces données pour éventuellement,
en retour, mettre à jour la base.
Un partie de la base de données pour être sur le
client -type 5- (cf. répartition des bases de
données)
Conclusion (partie 1)
Modèle client/serveur se caractérise donc
par :
– Des ressources indépendantes,
– L'importance du dialogue entre le
client et le serveur,
– La place centrale du réseau.
Ressources indépendantes
• Hébergement
– Toute plate-forme matérielle peut devenir
serveur
– Tout système d’exploitation peut héberger un
service
– Toutes configurations matérielles ou logicielles
envisageables
• Localisation
– Les ressources peuvent être n’importe où sur le
réseau
– Architecture plus modulaire
– Administration plus complexe
Ressources indépendantes
• Utilisation
– Les ressources ne sont pas dédiées à une
utilisation particulière
– Partage des ressources facilité
Importance du Dialogue
• Importance accrue des communications
– Le réseau devient «le centre de gravité du SI»
– Le réseau devient «la clé de voûte» du modèle
client-serveur
• Complexification du dialogue
– Dialogue entre systèmes hétérogènes
– Dialogue à distance
• Nécessité de couches intermédiaires
– Pour gérer la complexité
– Pour rendre «transparent» le dialogue
Les protocoles
L'importance du réseau les placent au premier
plan :
• Définissent le fonctionnement des réseaux
• Couvrent 3 types de services
– les services d’application
– les services de transport
– les services de liaison
• Respectent le modèle OSI (interconnexion des
systèmes ouverts) défini par l’ISO
CLIENT/SERVEUR
Partie 2 : Le MIDDLEWARE
Définition
• Georges GARDARIN définit le middleware
comme :
"L'ensemble des services logiciels construits audessus d'un protocole de transport afin de
permettre l'échange de requêtes et des
réponses associées entre client et serveur de
manière transparente."
• D'autres auteurs intègrent les couches réseaux
dans le middleware.
Définition
Application(s)
Serveur(s)
MIDDLEWARE
RESEAU
• Une triple transparence :
– Transparence aux réseaux. Tous les types de
réseaux doivent être supportés.
– Transparence aux serveurs. Tous le SGBD (avec
leur SQL souvent différents) doivent être
accessibles.
– Transparence aux langages. Les fonctions
appelées doivent être aussi indépendantes que
possible des langages.
Pourquoi le Middleware ?
La complexité du dialogue client/serveur est à
l'origine du middleware. Complexité due à la
présence :
– Des Systèmes hétérogènes
– Des Systèmes propriétaires
– 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
caractères et d’établissement de sessions entre
clients et serveurs hétérogènes
• C’est la «glue» qui rend possible le clientserveur
• C’est la boîte à outils pour le développement
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 système
qui propose un ensemble de fonctions
standards pour accéder à un service local ou
distant.
L'architecture type du Middleware
– L'interface FAP (Format And Protocols) Protocoles de communication et format des
données.
Ce module assure :
• la synchronisation entre client et serveur,
• la reconnaissance du format des données
échangées
• l'appel aux fonctions de transport du
réseau.
L'architecture type du Middleware
Client serveur et modèle OSI
Couche 7 - Application
API
Couche 6 - Présentation
FAP
Couche 5 - Session
Couche 4 - Transport
Par Ex : TCP
Couche 3 - Réseau
Par Ex : IP
Couche 2 - Liaison
Par Ex : CSMA/CD
Couche 1 - Physique
Par Ex : Paire torsadée
Client serveur et modèle OSI
couches
Le dialogue avec session
Client
Réseau
Application
Demande de connexion
Requête
Résultats
Synchronisation
Requête
Résultats
Serveur
Prise en compte de demande
et création d'un contexte
Exécution des requêtes
et gestion de la
synchronisation
Synchronisation
Déconnexion
Fin du contexte
Le dialogue avec session
• Dans les dialogues avec session (ou avec
connexion). Les échanges d’informations
sont subordonnés à l’ouverture d’une
«session» par le client vers le serveur.
• IPC avec connexion :
– Protocole APPC de l’architecture réseau
SNA d’IBM (Application Programm to
Progamm Application)
– Protocole RDA, basé sur SQL défini par
l’ISO (Remote Data Access)
Le dialogue avec session
• Si le serveur accepte la connexion, il crée un
contexte propre à chaque application cliente
connectée.
• Client et serveur s'échangent des requêtes, des
réponses 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 perçu 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 requête le :
– COMMIT confirmera la transaction,
– ROLL BACK l'annulera.
• Le serveur mettra réellement à jour la base
de données qu'à la suite de ces ordres de
synchronisation (avant cela les transactions
s'appliquent dans le "contexte")
Le dialogue sans connexion : les RPC
Client
Réseau
Serveur
Application
Requête
Prise en compte
de la demande
Appel de la procédure
distante
Réponse
Réception du résultat
poursuite de l'exécution
Exécution de la
procédure
Le dialogue sans connexion : les RPC
• Les dialogues sans connexion avec appels de
procédures distantes (RPC - Remote
Procedure Call).
Le processus client invoque une procédure
distante située sur le serveur.
La requête contient tous les éléments nécessaires
au serveur (nom de la procédure, paramètres,
identité du processus).
Le message en retour contient toute la réponse.
L’offre Middleware»
Les offres Middleware sont variées :
– Offres propriétaires,
– Offres d'accès universel aux bases,
– Offres pour des accès multibases
• Les offres propriétaires aux SGBDR :
– ORACLE avec Sql*Net
– SYBASE avec Db-lib
L’offre Middleware»
• Les offres multi-clients, multi-serveurs. Elles
permettent aux clients d'accéder en toute
transparence à plusieurs bases hétérogènes,
situées éventuellement sur des serveurs
différents.
– SEQUELINK : Techgnosis propose une API sur
presque toutes les architectures clientes ou
serveurs
– EDA/SQL : Information Builders propose
d’accéder à tout type de bases de données à partir
de plates-formes hétérogènes
L’offre Middleware»
– DRDA (Distributed Relational Database
Architecture) d'IBM pour fédérer les bases IBM
(DB2) et non IBM.
– IDAPI (Integrated Database Application
Programming Interface) de Borland en
collaboration avec Novell et IBM.
Note : Évidemment l'accès multibases permet également l'accès
monobase.
L’offre Middleware»
• L’accès universel aux données pour les
clients
– ODBC de Microsoft : accès standardisé aux
principales bases de données du marché
(drivers)
– IDAPI de Borland et Novell
Le Standard ODBC
• ODBC (Open DataBase Connectectivity) est
présenté en 1992 par Microsoft comme une
interface universelle aux bases de données.
• 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
réseau)
FAP : net-lib
(lié au SE et au
réseau)
Réseau
Réseau
Le Standard ODBC
CLIENT/SERVEUR
Partie 3 : La Répartition des Bases de données
Définitions
• Base de données répartie
Ensemble de bases de données gérées par des
sites différents et apparaissant à l'utilisateur
comme une base unique.
• SGBD Réparti (ambiguïté de SGBDR)
Système qui gère des collections de BD
logiquement reliées, distribuées sur un réseau,
en fournissant un mécanisme d'accès qui rend
la répartition transparente aux utilisateurs
Définitions
On parlera ainsi de :
• Client de SGBD Répartie
Application qui accède aux informations
distribuées par les interfaces du SGBD
Réparti.
• Serveur de SGBD Répartie
SGBD gérant une base de données locale
intégrée dans une base de données répartie
• D'une façon générale on parlera de SITE
(client ou serveur)
Définitions de G. GARDARIN
Pourquoi répartir les données ?
• La performance d’accès aux bases est limitée
– Par le nombre d’accès disques nécessaires
– Par le volume de données transmis (débit du
réseau)
– Par le nombre d’accès concurrents
• Les performances peuvent se dégrader
rapidement
– Au-delà de 30 postes clients
– Pour des consultations très fréquentes ou très
importantes
– Dans le cadre d’accès à distance (réseau étendu)
Conception des BdD Réparties
Il existe deux types de conception :
• Conception descendante
– Conception d'un schéma global
– Distribution des objets de ce schéma sur les
différents sites pour obtenir des schéma locaux
Base de données Globale
Base de données
locale 1
Base de données
locale 2
Base de données
locale 3
Conception des BdD Réparties
• Conception ascendante
Dans ce cas une base de données globale fédère
des base de données locales afin de créer un
ou plusieurs schémas globaux.
(Le plus souvent il y refonte des schémas locaux)
Base de données Globale
Base de données
locale 1
Base de données
locale 2
Base de données
locale 3
Conception des BdD Réparties
Les deux cas reviennent à partager, fragmenter
la base de données globale entre plusieurs
sites.
• Fragment
Un fragment est une sous-table obtenue par
sélection de lignes et de colonnes à partir
d'une table globale, localisée sur un site
unique.
(peut correspondre également à la table entière)
Conception des BdD Réparties
2 Types de fragmentation :
• Fragmentation Horizontale
Découpage d'une table en sélectionnant des
lignes (Il s'agit d'une sélection SQL ).
Exemple : Table VENDEUR fragmentée selon
les régions d'affectation des représentants
Lignes de la région 1
Autres régions
Conception des BdD Réparties
• Fragmentation Verticale
Découpage d'une table en sélectionnant des
colonnes (Il s'agit d'une projection SQL ).
Exemple : Table PRODUIT fragmentée 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 Réparties
• Fragmentation Mixte
Résultat 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 Réparties
• Allocation des fragments (*)
Les fragments peuvent être :
– Dupliqués sur les sites
Les fragments apparaissent plusieurs fois.
– Placés (répartis) sur les sites
Les fragments n'apparaissent que sur un
seul site.
(*) Rappel : Le fragment peut correspondre à une table.
La Gestion des Transactions
• Propriétés des transactions
– ATOMICITE : Une transaction doit effectuer
toutes ses mises à jour ou ne rien faire.
– COHERENCE : La transaction doit faire passer
la base de données d'un état cohérent à un autre.
– ISOLATION : Les résultats d'une transaction ne
doivent être visibles aux autres transactions
qu'une fois la transaction validée.
– DURABILITE : Dés qu'une transaction valide ses
modifications, le système doit garantir que ces
modifications seront conservées en cas de panne.
La Gestion des Transactions
• Validation en deux phases
Cette validation est basée sur un principe
centralisé.
L'exécution de la transaction est contrôlée par
un site coordinateur, rôle joué par le client.
Les autres sites intéressés par la transaction sont
des participants, rôle joué par les sites
serveurs.
La Gestion des Transactions
• Validation en deux phases
– Le client coordinateur demande aux autres sites
(serveurs) s'ils sont prêts à mettre à jour leur base
(ordre PREPARE).
– Si tous les participants répondent 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 répond négativement
(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 succès
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-réponse est assimilée à 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
STATUS
ACK
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
reçu.
• 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 annulée (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 réseau local, le message OK
est en fait reçu par toutes les stations.
Chacune peut donc compter le nombre de OK
et valider la transaction
OK
PREPARE
Les Base de données Dupliquées
La réplication entraîne la création de copies
multiples d'une base de données sur plusieurs
sites. La duplication peut concerner la base
entière, 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 cohérent à
terme.
Les Base de données Dupliquées
Les bases de données dupliquées (ou répliquées)
posent donc un problème particulier celui de
la MISE A JOUR des bases pour obtenir cette
convergence.
Les avantages de la duplication
• Améliorer les performances : L'utilisation de
la base la plus proche permet de limiter les
transferts et de répartir la charge de travail.
Les Base de données Dupliquées
• Augmenter la disponibilité :En cas de panne en
particulier.
• Utiliser des serveurs plus petits et moins chers.
Les inconvénients 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 données Dupliquées
Deux types de mise à jour :
• Mise à jour SYNCHRONE
Toute transaction entraîne la mise à jour en
temps réel de toutes les copies de la base.
Avantage : convergence immédiate
Inconvénient : Coûteux en ressources et
complexité du système (gestion des reprises
sur panne)
Technique parfois obligatoire : Base des taux de
change par exemple.
Les Base de données Dupliquées
• Mise à jour ASYNCHRONE
On préfère le plus souvent le mode asynchrone
(ou mode différé). Les mises à jour sont
effectuées dès que possible ou à des instants
fixés.
Les Base de données Dupliquées
Le synchronisme se combine au concept de
symétrie qui permet de créer une hiérarchie
dans les bases.
• Dans la réplication SYMETRIQE toutes les
bases ont le même degré hiérarchique.
• Dans la réplication ASYMETRIQUE on
distingue un site primaire chargé de
centraliser les mises à jour.
Les Base de données Dupliquées
• Exemple de mise à jour asymétrique
asynchrone (Consolidation d’informations)
Les données comptables tenues à jour dans les
agences sont dupliquées en lecture seulement vers
le siège pour consolidation.
Mise à jour en fin de
journée par exemple
Dépôts
&
Retraits
Agence
Siège Social
Agence
Agence
Les Base de données Dupliquées
• Exemple de mise à jour asymétrique
synchrone (Diffusion d’informations
centralisées)
– Les informations appartiennent au site primaire,
qui a le monopole des mises à jour
– Les données sont diffusées automatiquement vers
les sites qui ont un droit de lecture seulement
Copie PRIMAIRE
Siège Social
Cours des devises
Copies SECONDAIRES
Agence
Agence
Agence
Les Base de données Dupliquées
• Exemple de mise à jour symétrique asynchrone
Chaque département met régulièrement à jour les
données des autres départements.
Commercial
Copie Maître
Temps différé
Financier
Stocks
Copie Maître
Copie Maître
Les Base de données Dupliquées
• Exemple de mise à jour symétrique synchrone
Chaque site modifie la donnée PRIX puis diffuse
immédiatement la modification.
Modification du
PRIX
Produit
Copie Maître
Temps réel
Produit
Produit
Copie Maître
Copie Maître