CLIENT/SERVEUR

1
CLIENT/SERVEUR
2
CLIENT/SERVEUR

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

3
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

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

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

6
Le modèle Multi-Utilisateur centralisé

• Serveur Ordinateur central qui effectue tous
  les traitements
• Client Terminal sans puissance locale de
  traitement

7
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

8
Le modèle Client-Serveur

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

9
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

10
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

11
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 à
  laide de messages.

12
Client/Serveur définition
13
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).

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

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

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

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

18
Découpage des applications client-serveur

• On reconnaît traditionnellement dans une
  application 3 modules

19
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 darchitecture retenus
• De la capacité des machines
• De la capacité du réseau
• Le Gartner Group a proposé les cas de figure
  suivants

20
Le schéma du Gartner Group
21
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

22
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

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

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

25
Ressources indépendantes

• Hébergement
• Toute plate-forme matérielle peut devenir serveur
• Tout système dexploitation peut héberger un
  service
• Toutes configurations matérielles ou logicielles
  envisageables
• Localisation
• Les ressources peuvent être nimporte où sur le
  réseau
• Architecture plus modulaire
• Administration plus complexe

26
Ressources indépendantes

• Utilisation
• Les ressources ne sont pas dédiées à une
  utilisation particulière
• Partage des ressources facilité

27
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

28
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 dapplication
• les services de transport
• les services de liaison
• Respectent le modèle OSI (interconnexion des
  systèmes ouverts) défini par lISO

29
CLIENT/SERVEUR

• Partie 2 Le MIDDLEWARE

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

31
Définition

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

32
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

33
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
• Cest la glue qui rend possible le
  client-serveur
• Cest la boîte à outils pour le développement des
  applications.

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

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

36
L'architecture type du Middleware
37
Client serveur et modèle OSI
38
Client serveur et modèle OSI
couches
39
Le dialogue avec session
40
Le dialogue avec session

• Dans les dialogues avec session (ou avec
  connexion). Les échanges dinformations sont
  subordonnés à louverture dune session par le
  client vers le serveur.
• IPC avec connexion
• Protocole APPC de larchitecture réseau SNA dIBM
  (Application Programm to Progamm Application)
• Protocole RDA, basé sur SQL défini par lISO
  (Remote Data Access)

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

42
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")

43
Le dialogue sans connexion les RPC
44
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.

45
Loffre 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 SqlNet
• SYBASE avec Db-lib

46
Loffre 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 daccéder
  à tout type de bases de données à partir de
  plates-formes hétérogènes

47
Loffre 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.

48
Loffre Middleware

• Laccè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

49
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

50
Le Standard ODBC

• Exemple De Sybase à ODBC

51
Le Standard ODBC
52
CLIENT/SERVEUR

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

53
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

54
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

55
Pourquoi répartir les données ?

• La performance daccès aux bases est limitée
• Par le nombre daccès disques nécessaires
• Par le volume de données transmis (débit du
  réseau)
• Par le nombre daccè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 daccès à distance (réseau étendu)

56
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

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

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

59
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

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

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

62
Conception des BdD Réparties

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

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

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

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

66
La Gestion des Transactions
67
La Gestion des Transactions
Validation en deux étapes avec panne totale d'un
participant
68
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).

69
La Gestion des Transactions
Validation en deux étapes avec panne partielle
d'un participant
70
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.

71
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

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

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

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

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

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

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

78
Les Base de données Dupliquées

• Exemple de mise à jour asymétrique asynchrone
  (Consolidation dinformations)
• Les données comptables tenues à jour dans les
  agences sont dupliquées en lecture seulement vers
  le siège pour consolidation.

Siège Social
Mise à jour en fin de journée par exemple
Dépôts Retraits
Agence
Agence
Agence
79
Les Base de données Dupliquées

• Exemple de mise à jour asymétrique synchrone
  (Diffusion dinformations 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

Copies SECONDAIRES
80
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.

Temps différé
81
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.