81
CLIENT/SERVEUR

CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Embed Size (px)

Citation preview

Page 1: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

CLIENT/SERVEUR

Page 2: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Partie 1 : Présentation du modèle client-serveur

CLIENT/SERVEUR

Page 3: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur 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 non-propriétaires (indépendants des constructeurs) - SGBD relationnel + SQL

Page 4: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.)

Page 5: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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)

Page 6: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le modèle Multi-Utilisateur centralisé

Serveur = Ordinateur central qui effectue tous les traitements

Client = Terminal sans puissance locale de traitement

CLIENTECRAN SERVEUR

INTELLIGENCE

Page 7: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le modèle réseau local traditionnel

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

CLIENTECRAN SERVEUR

INTELLIGENCE

Page 8: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le modèle Client-Serveur

Répartition judicieuse de la puissance de traitement entre le serveur et les différentes stations interconnectées.

ECRAN SERVEUR

CLIENT

INTELLIGENCE

INTELLIGENCE

Page 9: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 10: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 11: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Client/Serveur : définition

Est conforme au modèle client-serveur tout processus utilisant des services offerts par un autre processus, et communiquant avec lui à l’aide de messages.

Page 12: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Client/Serveur : définition

Approche Puriste

SERVEUR

CLIENT

REQUÊTE

REPONSE

Approche Pragmatique

ECRAN SERVEUR

CLIENT

REQUÊTE

REPONSE

Page 13: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/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).

Page 14: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• CLIENTProcessus qui demande l'exécution d'une

opération par l'envoi d'une demande.

• SERVEURProcessus 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.

Client-Serveur : définition

Page 15: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/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.

Page 16: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 17: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 18: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Découpage des applications client-serveur

On reconnaît traditionnellement dans une application 3 modules :

DONNEES

TRAITEMENT

PRESENTATION

Page 19: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur 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 :

Découpage des applications client-serveur

Page 20: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le schéma du Gartner Group

Page 21: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

Page 22: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

Page 23: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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)

Le schéma du Gartner Group

Page 24: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 25: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 26: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Ressources indépendantes

• Utilisation– Les ressources ne sont pas dédiées à une

utilisation particulière– Partage des ressources facilité

Page 27: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 28: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 29: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Partie 2 : Le MIDDLEWARE

CLIENT/SERVEUR

Page 30: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Définition

• Georges GARDARIN définit le middleware comme :

"L'ensemble des services logiciels construits au-dessus 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.

Page 31: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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.

DéfinitionApplication(s) Serveur(s)

MIDDLEWARERESEAU

Page 32: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 33: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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 client-serveur

• C’est la boîte à outils pour le développement des applications.

Page 34: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 35: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

– 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

Page 36: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

L'architecture type du Middleware

Page 37: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Client serveur et modèle OSI

Couche 6 - Présentation

Couche 7 - Application

Couche 5 - Session

Couche 4 - Transport

Couche 3 - Réseau

Couche 2 - Liaison

Couche 1 - Physique

Par Ex : TCP

Par Ex : IP

Par Ex : Paire torsadée

Par Ex : CSMA/CD

API

FAP

Page 38: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

couches

Client serveur et modèle OSI

Page 39: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le dialogue avec session

Application

ServeurRéseauClient

Demande de connexionRequête

Résultats

SynchronisationRequête

Résultats

Synchronisation

Déconnexion

Prise en compte de demandeet création d'un contexte

Fin du contexte

Exécution des requêteset gestion de lasynchronisation

Page 40: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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)

Page 41: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

Page 42: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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 avec session

Page 43: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le dialogue sans connexion : les RPC

Application

ServeurRéseauClient

Appel de la procéduredistante

RequêtePrise en comptede la demande

Exécution de laprocédure

RéponseRéception du résultat

poursuite de l'exécution

Page 44: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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.

Le dialogue sans connexion : les RPC

Page 45: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 46: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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»

Page 47: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

– 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»

Page 48: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

L’offre Middleware»

Page 49: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

Page 50: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Exemple : De Sybase à ODBC

Le Standard ODBC

Application

API : db-lib(lié au SE -

db-lib pour OS2, pour Windows, etc)

FAP : net-lib(lié au SE et au

réseau)

Réseau

Application

FAP : net-lib(lié au SE et au

réseau)

Réseau

API : ODBC

DataBase Driver

Page 51: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Le Standard ODBC

Page 52: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Partie 3 : La Répartition des Bases de données

CLIENT/SERVEUR

Page 53: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 54: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Définitions

On parlera ainsi de :• Client de SGBD RépartieApplication qui accède aux informations

distribuées par les interfaces du SGBD Réparti.

• Serveur de SGBD RépartieSGBD 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

Page 55: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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)

Page 56: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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éeslocale 1

Base de donnéeslocale 2

Base de donnéeslocale 3

Page 57: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• Conception ascendanteDans 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)

Conception des BdD Réparties

Base de données Globale

Base de donnéeslocale 1

Base de donnéeslocale 2

Base de donnéeslocale 3

Page 58: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 59: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

2 Types de fragmentation :• Fragmentation HorizontaleDé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

Conception des BdD Réparties

Lignes de la région 1

Autres régions

Page 60: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• Fragmentation VerticaleDé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 )

Conception des BdD Réparties

CommercialProduction

Page 61: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

Page 62: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• Allocation des fragments (*)

Les fragments peuvent être :

– Dupliqués sur les sitesLes fragments apparaissent plusieurs fois.

– Placés (répartis) sur les sitesLes fragments n'apparaissent que sur un seul site.

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

Conception des BdD Réparties

Page 63: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 64: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 65: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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).

Page 66: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

La Gestion des TransactionsClient CoordinateurServeur 1 Serveur 2

PREPARE PREPARE

OK OK

COMMIT COMMIT

ACK ACK

Validation en deux étapes avec succès

Page 67: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

La Gestion des Transactions

Validation en deux étapes avec panne totale d'un participant

Client CoordinateurServeur 1 Serveur 2

PREPARE PREPARE

OK KO

ABORT ABORT

ACK ACK

Page 68: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 69: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

La Gestion des Transactions

Validation en deux étapes avec panne partielle d'un participant

Client CoordinateurServeur 1 Serveur 2

PREPARE PREPAREOK OK

COMMIT COMMIT

ACK

ACK

STATUS

COMMIT

Page 70: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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

Page 71: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

La Gestion des Transactions

PREPARE

OK

Page 72: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 73: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 74: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 75: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

Les Base de données Dupliquées

Deux types de mise à jour :• Mise à jour SYNCHRONEToute transaction entraîne la mise à jour en

temps réel de toutes les copies de la base.Avantage : convergence immédiateInconvé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.

Page 76: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 77: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Page 78: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

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.

Siège Social

Agence Agence AgenceDépôts

&Retraits

Mise à jour en fin dejournée par exemple

Page 79: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• 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

Les Base de données Dupliquées

Siège Social

Agence Agence Agence

Cours des devisesCopie PRIMAIRE

Copies SECONDAIRES

Page 80: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• Exemple de mise à jour symétrique asynchroneChaque département met régulièrement à jour les

données des autres départements.

Les Base de données Dupliquées

Commercial

Financier Stocks

Copie Maître

Copie Maître Copie Maître

Temps différé

Page 81: CLIENT/SERVEUR. Partie 1 : Présentation du modèle client-serveur CLIENT/SERVEUR

• Exemple de mise à jour symétrique synchroneChaque site modifie la donnée PRIX puis diffuse

immédiatement la modification.

Les Base de données Dupliquées

Produit

Produit Produit

Copie Maître

Copie Maître Copie Maître

Modification du PRIX

Temps réel