Vous êtes sur la page 1sur 30

Le modèle

Client/Serveur
Principe de base :
 La possibilité de répartir la charge du traitement
 Les machines clientes gèrent l'interface avec les
utilisateurs et les serveurs gèrent les données et les
fichiers.
 C'est un réseau qui repose sur des nœuds intelligents
plutôt que des terminaux passifs.
 Les applications clientes font appel à des services
distants au travers d'un échange de requêtes plutôt
que par un échange de fichiers.
Principe de base
Découpage de l'application

Une application informatique se compose de 3 niveaux


principaux :
 L'interface avec l'utilisateur
 Les traitements
 Les données
Ces trois niveaux sont aussi composés de différentes
couches :
Interface Gestion de l'affichage
Logique de l'affichage
Traitement Logique fonctionnelle
Exécution des procédures

données Intégrité des données


Gestion des données
Découpage de l'application

 Gestion de l'affichage : Fonction de fenêtrage


 Logique de l'affichage : Description des éléments de
présentation
 Logique fonctionnelle : L'arborescence algorithmique
de l'application.
 Exécution des procédures : Le cœur des traitements
de l'application.
 Intégrité des données : Garantit le respect de la règle
CRUDE pour les objets de la base.
 CRUDE = Colonne Référence Utilisateur Domaine
Entité
 Gestion des données : La sélection et les mise à jour
des données ( Prises en compte par le SGBD)
Dialogue entre le client et le
serveur :

Le dialogue s'effectue au travers le réseau et il concerne


deux processus :
L'IPC ( Inter Process Communication )
Le processus qui permet l'établissement et le maintien
du dialogue. Ce dialogue inter-processus s'appuie de
part et d'autre ( c à d pour le programme client que
pour le programme serveur) sur deux interfaces de
niveau système.
Ces deux interfaces assurent le lien entre les
programmes clients et serveur d'une part et le réseau
d'autre part. Il s'agit des API et des FAP ( Format And
Protocols ) c'est l'articulation entre API et FAP qui
constitue l'IPC.
IPC
MiddleWare

On appelle Middleware l'ensemble des


couches logicielles qui s'interposent entre
l'application et le réseau , ces couches
prennent en compte les requêtes de
l'application cliente et les transmet à
travers le réseau en pratiquant les
conversions de protocoles appropriés puis
en retournant les données ou les codes de
contrôles de l'application clientes.
MiddleWare

Les logiciels réseau qui entre dans la catégorie du


MiddleWare sont basés sur deux approches de la
communication inter-processus (IPC) les RPC ( Remote
Procedural Call ) et les messages.
Mécanismes utilisés par les IPC
Dialogue sans connexion : Les RPC
Dialogue avec session A.P.P.C. ou
R.D.A.

 A.P.P.C. : Application Program to Program


Communication.
Elément de l'architecture SNA d'IBM
 R.D.A. : Remote Data Access
Norme de l'I.S.O. pour l'accès distant aux
bases de données.
 Les IPC basés sur un échange de messages
( comme APPC ou RDA) permettent des
dialogues asynchrones. De plus il est
possible d'implémenter un mécanisme de
RPC sur un IPC orienté message mais pas
l'inverse.
Dialogue avec session A.P.P.C. ou
R.D.A
La demande de connexion émise par le programme client
représente le point de départ du dialogue, cette
demande est généralement accompagnée des
éléments d'identification de l'utilisateur de
l'application cliente.
Si le serveur accepte la connexion cette acceptation est
suivie de la création d'un contexte sur le serveur qui
est propre à chaque programme client connecté.
Durant toute la conversation, client et serveur vont
s'échanger trois types de messages :
 Requêtes
 Résultats
 Point de synchronisation
Dialogue avec session A.P.P.C. ou
R.D.A
Dialogue avec session A.P.P.C. ou
R.D.A
Un exemple de messages de synchronisation est donné
par les ordres Commit ou Rollback .
Begin Transaction est un point de synchronisation.
N.B. La gestion des transactions est plus facile à mettre en
œuvre avec un dialogue en mode connecté qu'avec des
RPC car le mode connecté est plus coûteux en ressources
que les RPC pour les raisons suivantes :
La communication entre le client et le serveur est maintenue
tout au long de l'échange.
Le serveur crée et conserve un contexte propre à chaque
client jusqu'à la fin du dialogue.
Dialogue avec session A.P.P.C. ou
R.D.A
Différents types de Client/Serveur
Différents types de Client/Serveur

 Type 1: Présentation distribuée , correspond au


REVAMPING. Ce n'est pas du Client Serveur.

 Type 2 : Présentation distante, correspond au


fonctionnement de type X-Window appelé Client Serveur
de présentation.

 Type 3 : Traitement distribuée , appelé Client Serveur de


procédures.

 Type 4 : Gestion des données distantes , appelé Client


Serveur de données le plus connu et le plus répandu .

 Type 5 : Base de données distribuées, une simple


variante du type 4.
Client Serveur de Présentation

La mise en œuvre du Client Serveur de présentation suppose de


pouvoir séparer la gestion de l'affichage de la logique de
l'affichage.
Environnement graphique basé sur un Window Manager ( Motif
et Open Look sont des exemples typiques qui s'appuient sur
un gestionnaire de fenêtre X-Window en l'occurrence.
Avec X-Window on peut déporter la gestion de l'affichage sur un
serveur spécialisé ( qu'on appelle un serveur d'affichage ou
serveur X).
Le client serveur de présentation est un cas particulier du
modèle Client Serveur dans la mesure où il impose une
(apparente) inversion de terminologie : La machine que
l'utilisateur a devant lui, ce n'est pas le client mais le
serveur ! cette inversion n'est en réalité qu'apparente, en
effet puisque le système qui gère l'affichage est en effet un
service de présentation, donc un serveur.
Client Serveur de Présentation

Dans le dialogue établi entre la logique de l'affichage et la gestion


de l'affichage, il n'ya que des requêtes décrivant les objets à
afficher (de la logique vers la gestion de l'affichage) et les actions
significatives de l'utilisateur ( de la gestion vers la logique de
l'affichage).
Client Serveur de Présentation
Client Serveur de Présentation

L'application cliente n'envoie que des


requêtes de demande d'affichage
d'objets et ces requêtes contiennent
des paramètres tels que les
caractéristiques de l'objet à afficher
(type de fenêtre, libelle de la barre de
titre, etc.....), ses dimensions et son
emplacement initial. Le serveur traite
ces requêtes, construit et affiche les
objets selon les paramètres reçus.
Client Serveur de Données

 Le client Serveur de données est certainement


actuellement l'exemple le plus répandu, le serveur qui
abrite les données est appelé serveur de données. Les
stations clientes n'ont pas de SGBD en local pour
gérer les données utilisées par les applications, mais
que ces dernières utilisent le SGBD résidant sur le
serveur de données en passant leurs requêtes par le
réseau après une "mise en forme" via les IPC.
 Les SGBDR modernes proposent des mécanismes
permettant de déclencher des traitements de contrôle
afin de s'assurer de la validité des mises à jour des
bases de données d'où les applications n'ont pas
besoin d'émettre des requêtes de contrôle avant
d'envoyer les requêtes de mise à jour, et cela réduit
le trafic sur le réseau.
Client Serveur de Données
Client Serveur de Données

 Etape1 : L'action de l'utilisateur est transformée en requête


par l'application.
 Etape2 : L'application cliente transmet la requête au
SGBD en utilisant l'IPC qui lui même s'appuie sur le réseau.
 Etape3 : Le SGBD reçoit la requête et la traite .
 Etape4 : La table en question est balayée par le SGBD et
les lignes concernées sont identifiées.
 Etape5 : Les lignes concernées sont envoyées à
l'application cliente comme réponse à sa requête.
 Etape6 : L'application cliente reçoit le résultat et prend
en charge sa mise en forme pour que l(utilisateur puisse le
consulter )
Client Serveur de Données

Le Client Serveur de données est très


répandu, quasiment tous les éditeurs de
SGBDR propose ce mode de
fonctionnement et commercialisent donc un
IPC permettant à des outils ou des
applications d'accéder à leur produit à
travers le réseau.
Oracle, Sybase, Ingres, Informix, Microsoft,
etc.. tous ont à leur offre un produit client
serveur ( SQL*Net pour Oracle, Informix
Net pour Informix, Sql Server pour
Microsoft ,etc...).
Client Serveur de Procédures

Le Client Serveur de procédures correspond


aux traitements distribués , bien qu'il
représente la mise en œuvre la plus
efficace, il est loin d'être le plus répandu,
cela est dû en grande partie au fait que le
client serveur de procédures requiert le
plus de savoir-faire pour sa mise en œuvre.
Client Serveur de Procédures
Client Serveur de Procédures

Le Client Serveur de procédures peut être mis en œuvre


en utilisant un mécanisme de type RPC entre Client et
Serveur. Le module Logique fonctionnelle de l'applicatif
Client envoie des appels de procédures au Serveur qui les
exécutent et envoie les résultats ( ces résultats peuvent
être aussi bien des codes de retour ou des données) .
Point sensibles des
développements Client Serveur
 Le développement d'applications reposant sur le modèle
Client Serveur pose des problèmes spécifiques.
 Répartition des traitements, gestion de la localisation des
données et/ou des traitements.
Gestion de la localisation :
 Avec les serveurs passifs, le problème de la répartition ne
se posait pas, la quasi-intégralité des traitements reposait
sur les stations clientes.
 Avec les serveurs programmables (Client Serveur de
procédures) il est possible et même souhaitable faire une
répartition plus équilibrée, les traitements exclusifs à
certaines applications restent sur les stations clientes alors
que les traitements communs qui seraient définis sous
forme de procédures auxquelles l'application ferait appel par
le biais de mécanisme de type RPC vont évidement sur le
serveur.
Gestion de la localisation
Gestion des données :

 Il est logique de rapprocher les traitements visant à


préserver l'intégrité des données au plus près de ces
dernières.
 Il existe deux types de mécanismes qui permettent de
vérifier "l'innocuité" des requêtes mises à jour avant
d'autoriser leur impact sur la base de données, il
s'agit des déclencheurs ( Triggers) et des contraintes.
 Les triggers agissent comme des filtres logiques de
type oui ou non entre les requêtes traitées par le
SGBDR et les objets dans lesquels sont stockées les
données.
 Les triggers sont compatibles à des procédures qui
s'exécutent de façon implicite.