Architecture Client-Serveur PDF

ARCHITECTURE CLIENT/SERVEUR
SOMMAIRE
SOMMAIRE ..........................................................................................................................1
LISTE DES FIGURES ...........................................................................................................3
RESUME ...............................................................................................................................4
ABSTRACT ...........................................................................................................................5
INTRODUCTION GENERALE.............................................................................................6
I. ORIGINE ........................................................................................................................7
II. PROBLEMATIQUE .......................................................................................................7
III. ETAT DE L’ART ........................................................................................................8
1. Définitions ...................................................................................................................8
1.1. Client ....................................................................................................................8
1.2. Le serveur .............................................................................................................9
2. Architecture Client/serveur ........................................................................................ 10
2.1. Définitions ..........................................................................................................10
2.2. Les principes généraux de l’architecture client/serveur ........................................ 11
2.3. Les différents modèles de client serveur .............................................................. 11
2.4. Schéma du GARTNER Group ............................................................................ 13
2.5. Les différentes Architectures............................................................................... 15
3. Principes de Fonctionnement ..................................................................................... 19
3.1. Coté serveur ...........................................................................................................19
3.1.1. Gestion des processus ...................................................................................... 19
3.1.2. Gestion d’états................................................................................................. 20
3.2. Mode de communication client/serveur .................................................................. 21
3.2.1. Modes .............................................................................................................21
3.2.2. Notion de connexion ....................................................................................... 22
4. Le Middleware ...........................................................................................................26
4.1. Définitions ..........................................................................................................26
4.2. Fonctions du Middleware .................................................................................... 27
4.3. Les services du Middleware ................................................................................ 28
4.4. Exemples de Middleware .................................................................................... 28
IV. EXEMPLE DE CLIENT/SERVEUR ......................................................................... 29
CONCLUSION .................................................................................................................... 31
BIBLIOGRAPHIE ............................................................................................................... 32
1
WEBOGRAPHIE ................................................................................................................. 32
TABLES DES MATIERES .................................................................................................. 33
2
LISTE DES FIGURES

Figure 1: communication client/serveur ................................................................................ 10
Figure 2: modèle client/serveur ............................................................................................. 12
Figure 3: Schéma du GARTNER Group ............................................................................... 13
Figure 4: Architecture peer to peer........................................................................................ 15
Figure 5: Architectures 1-tiers .............................................................................................. 16
Figure 8: Architectures n-tiers .............................................................................................. 19
Figure 9: Modes de Communication ..................................................................................... 21
Figure 10: API Socket ..........................................................................................................22
Figure 11: Principes de Fonctionnement ............................................................................... 23
Figure 12 : communication Mode Connecté ..........................................................................25
Figure 13: mode non connecté .............................................................................................. 26
Figure 14 : Middleware ........................................................................................................ 27
3
RESUME
L’architecture client/serveur désigne un mode de communication entre plusieurs

composants d’un réseau. L'environnement client–serveur désigne un mode de transaction
(souvent à travers un réseau) entre plusieurs programmes : l'un, qualifié de client, envoie des
requêtes ; l'autre, qualifié de serveur, attend les requêtes des clients et y répond. Le serveur offre
ici un service au client. Par extension, le client désigne souvent l'ordinateur sur lequel est
exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur. Les
machines serveurs sont généralement dotées de capacités supérieures à celles des ordinateurs
personnels en ce qui concerne la puissance de calcul, les entrées-sorties et les connexions
réseau. Les clients sont souvent des ordinateurs personnels ou des appareils individuels
(téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux requêtes de
plusieurs clients. Parfois le client et le serveur peuvent être sur la même machine. Un serveur
peut être spécialisé en serveur d’applications, de fichiers, de terminaux, ou encore de
messagerie électronique. Le client et le serveur doivent bien sûr utiliser le même protocole de
communication au niveau de la couche transport du modèle OSI.
4
ABSTRACT
Client / Server architecture refers to a mode of communication between several

components of a network. The client – server environment designates a mode of transaction
(often through a network) between several programs : one, known as the client, sends requests;
the other, called a server, waits for and responds to client requests. The server here offers a
service to the client. By extension, the client often refers to the computer on which the client
software is executed, and the server, the computer on which the server software is executed.
Server machines typically have higher capacities than personal computers in computing power,
input-output, and network connections. Clients are often personal computers or individual
devices (phone, tablet), but not always. A server can respond to requests from multiple clients.
Sometimes the client and the server can be on the same machine. A server can be specialized
in application, file, terminal, or even electronic mail server. The client and the server must of
course use the same communication protocol at the transport layer of the OSI model.
5
INTRODUCTION GENERALE
Un effort de recherche et de production industriel a été effectué au niveau mondial. La

mutation permanente des concepts, des techniques et des organisations associées aux
applications informatiques, ont vues une évolution majeure des systèmes d’information à savoir
le passage d’une architecture centralisée à travers de grosses machines (des mainframes) vers
une architecture distribuée basée sur l’utilisation de serveurs et de postes clients grâce à
l’utilisation des PC et des réseaux. L’architecture client/serveur désigne un mode de
communication entre plusieurs composants d’un réseau. Cette évolution a été possible
essentiellement grâce à 2 facteurs qui sont : la baisse des prix de l’informatique personnelle et
le développement des réseaux. Dans la suite de notre projet, il sera question de définir
précisément ce qu’est une architecture client/serveur, puis de préciser ce qu’est dans ce contexte
quel est son fonctionnement et enfin comment il dialogue avec les clients.
6
I. ORIGINE
En 1987 le principe du client-serveur, dans lequel une application informatique est
scindée en 2 processus qui peuvent être exécutés par deux ordinateurs différents, intéresse les
fournisseurs de logiciels pour les bases de données. Ashton-
Tate, Microsoft et Sybase travaillent ensemble au développement d'un système de gestion de
base de données selon le principe du client-serveur, en même temps que IBM et Oracle
Corporation mettent sur le marché de tels produits.
Depuis 1990, les systèmes informatiques, en client-serveur, ont connu une croissance
explosive ; le client-serveur était une nouveauté à la mode et le mot était considéré comme
un buzzword. Contrairement aux systèmes informatiques précédents qui étaient alors équipés
d'un mainframe manipulé depuis des terminaux, un système informatique en client-serveur
demandait un matériel moins spécifique et moins coûteux. De plus les systèmes client-serveur
utilisaient des produits ouverts, basés sur des standards industriels évitant à l'acheteur de devoir
acquérir la totalité de son système informatique auprès du même fabricant. Ces avantages sont
à l'origine du downsizing : le remplacement progressif des mainframes coûteux et volumineux
par des serveurs plus petits, meilleur marché et qui travaillent de concert avec des micro-
ordinateurs.
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 micro-
ordinateurs)
II. PROBLEMATIQUE
Les Systèmes informatiques précédents étaient équipés de Mainframe (gros Unité
Central qu’on manipule via des terminaux aux faibles capacités). Ceux-ci étaient très couteux,
très volumineux et peu fiable. C’est au regard de cela que Ces vingt dernières années ont vues
une évolution majeure des systèmes d’informations, à savoir le passage d’une architecture
centralisée à travers de grosses machines (des mainframes) vers une architecture distribuée
basée sur l’utilisation de serveurs et de postes clients grâce à l’utilisation des PC et des réseaux.
Cette architecture est mise en place pour répondre aux besoins des utilisateurs rapidement et
progressivement à travers la gestion de la cohérence des données, la baisse des prix de
l’informatique personnelle, le développement des réseaux et la centralisation des données.
7
III. ETAT DE L’ART

1. Définitions
1.1. Client
Client : processus demandant l’exécution d’une opération à un autre processus par envoi
de message contenant le descriptif de l’opération à exécuter et attendant la réponse de cette
opération par un message en retour.
Caractéristiques d'un programme client :
• Il établit la connexion au serveur à destination d'un ou plusieurs ports réseaux ;
• Lorsque la connexion est acceptée par le serveur, il communique comme le
prévoit la couche application du modèle OSI.
Les clients applicatifs, sont des logiciels qui tournent sur les machines ou terminaux
des utilisateurs. Il est possible de distinguer 3 types de clients applicatifs majeurs :
Un client léger
Un client léger est une application où le traitement des requêtes du client est entièrement
effectué par le serveur, le client se contente de recevoir et mettre en forme pour afficher les
réponses calculées et envoyées par le serveur. Quelques avantages :
• Peu de puissance de calcul est nécessaire au niveau du client ;
• La mise à jour de l'application s'effectue uniquement sur le serveur, excepté
l'éventuelle mise à jour du client Web ;
• Un travail de développement concentré sur le serveur.
Un client lourd
Un client lourd est une application (applications de bureau, applications mobile) où les
traitements sont principalement effectués sur la machine locale dite cliente. Le serveur se
contentant principalement de répondre aux demandes de données du client. Quelques avantages
:
• Le client peut parfois fonctionner même en cas de déconnexion du serveur ;
• Une partie des traitements est réalisé par le client, ce qui soulage les ressources
du serveur ;
• Plus grande indépendance vis à vis des temps de réponse réseau et serveur.
Un client riche
8
Un client riche est une application où le traitement des requêtes du client (applications
Web utilisant beaucoup de JavaScript côté client) est effectué majoritairement par le serveur,
le client recevant les réponses « semi-finies » et les finalisant. C'est un client léger plus évolué
permettant de mettre en œuvre des fonctionnalités comparables à celles d'un client lourd. C'est
un compromis entre les clients légers et lourds.
1.2. Le serveur
Serveur : processus accomplissant une opération sur demande d’un client, et lui
transmettant le résultat.
Caractéristiques d'un programme serveur :
• Il attend une connexion entrante sur un ou plusieurs ports réseaux locaux ;
• A la connexion d'un client sur le port en écoute, il ouvre un socket local
au système d'exploitation ;
• A la suite de la connexion, le processus serveur communique avec le client
suivant le protocole prévu par la couche application du modèle OSI.
NB : un programme serveur tourne en permanence, attendant des requêtes ; il peut
répondre à plusieurs clients en même temps.
Comme type de serveur nous avons :
Serveur lourd
• On effectue plus de traitements sur le serveur : transactions, Groupware, etc ;
• Déploiement plus aisé
Serveurs multi-clients
Comme les serveurs Web/http qui sont capables de traiter plusieurs clients en même
temps. Il existe aussi des serveurs « non connectés », dans ce cas il n’y a pas de connexion ou
de déconnexion.
Exemple de serveur : il existe une grande variété de serveurs et de clients en fonction
des besoins ou services à fournir :
Un serveur Web publie des pages Web demandées par des navigateurs Web ;
Un serveur de messagerie électronique transmet les courriels à des clients de
messagerie ;
9
Un serveur de fichiers permet de partager des fichiers sur un réseau aux machines qui
le sollicitent ;
Un serveur de base de données permet aux clients de récupérer des données stockées
dans une base de données, etc.
2. Architecture Client/serveur
2.1. Définitions
Le modèle client-serveur est en fait un principe d’architecture informatique hiérarchisé
en réseaux, interne avec TCP/IP ou externe sur Internet. Un ordinateur, ou un groupe
d'ordinateurs, dénommé serveur, stocke la totalité des ressources partageables telles que
données et traitements. Il agit comme un fournisseur de services.
L’architecture client-serveur est un modèle de fonctionnement logiciel qui peut se
réaliser sur tout type d’architecture matérielle (petites ou grosses machines), à partir du moment
où ces architectures peuvent être interconnectées.
On parle de fonctionnement logiciel dans la mesure où cette architecture est basée sur
l’utilisation de deux types de logiciels, à savoir un logiciel serveur et un logiciel client
s’exécutant normalement sur 2 machines différentes. L’élément important dans cette
architecture est l’utilisation de mécanismes de communication entre les 2 applications.
Le dialogue entre les applications peut se résumer par :
- Un client demande un service au serveur
- Le serveur réalise ce service et renvoie le résultat au client
- Client et serveur sont généralement localisés sur deux machines distinctes
Figure 1: communication client/serveur
Un des principes fondamentaux est que le serveur réalise un traitement pour le client.
10
2.2. Les principes généraux de l’architecture client/serveur

Il y’a pas véritablement de définition exhaustive de la notion de client-serveur,
néanmoins des principes régissent ce que l’on entend par client-serveur :
✓ Service : Le serveur est fournisseur de services. Le client est consommateur de
services.
✓ Protocole : C’est toujours le client qui déclenche la demande de service. Le
serveur attend passivement les requêtes des clients.
✓ Partage des ressources : Un serveur traite plusieurs clients en même temps et
contrôle leurs accès aux ressources.
✓ Localisation : Le logiciel client-serveur masque aux clients la localisation du
serveur.
✓ Hétérogénéité : Le logiciel client-serveur est indépendant des plateformes
matérielles et logicielles.
✓ Redimensionnement : Il est possible d'ajouter et de retirer des stations clientes. Il
est possible de faire évoluer les serveurs.
✓ Intégrité : Les données du serveur sont gérées sur le serveur de façon centralisée.
Les clients restent individuels et indépendants.
✓ Souplesse et adaptabilité : On peut modifier le module serveur sans toucher au
module client. La réciproque est vraie. Si une station est remplacée par un modèle
plus récent, on modifie le module client (en améliorant l'interface, par exemple) sans
modifier le module serveur.
2.3. Les différents modèles de client serveur

Dans l’architecture client-serveur, une application est constituée de trois parties :
➢ L’interface utilisateur
➢ La logique des traitements
➢ La gestion des données
Le client n’exécute que l’interface utilisateur (souvent une interface graphique) ainsi
que la logique des traitements (formuler la requête), laissant au serveur de bases de données la
gestion complète des manipulations de données.
11
Figure 2: modèle client/serveur
Dans le modèle client-serveur on distingue trois couches :

➢ Couche présentation (l’interface) est chargée d’organiser le dialogue entre la
machine et l’utilisateur ;
➢ Couche applicative (les traitements) réalise les tâches pour produire les résultats ;
➢ Couche données : la gestion des données.
En fait, les différences sont essentiellement liées aux services qui sont assurés par le
serveur. On distingue :
a. Le client-serveur de présentation
Dans ce cas la présentation des pages affichées par le client est intégralement prise en
charge par le serveur. Cette organisation présente l’inconvénient de générer un fort trafic
réseau.
b. Le client-serveur de traitement
Dans ce cas, le serveur effectue des traitements à la demande du client. Il peut s'agir de
traitement particulier sur des données, de vérification de formulaires de saisie, de traitements
d'alarmes …
Ces traitements peuvent être réalisés par des programmes installé sur des serveurs mais
également intégrés dans des bases de données, dans ce cas, la partie donnée et traitement sont
intégrés.
12
c. Le client-serveur de données
Dans ce cas, le serveur assure des tâches de gestion, stockage et de traitement de
données. C’est le cas le plus connu de client-serveur est qui est utilisé par tous les
grands SGBD :
➢ La base de données avec tous ses outils (maintenance, sauvegarde …) est installée
sur un poste serveur ;
➢ Sur les clients, un logiciel d'accès est installé permettant d'accéder à la base de
données du serveur ;
➢ Tous les traitements sur les données sont effectués sur le serveur qui renvoie les
informations demandées (souvent à travers une requête SQL) par le client.
2.4. Schéma du GARTNER Group
Un groupe d’étude composé d’acteurs du marché a défini 6 types d’architectures

client/serveur, qui représente les différents modèles ainsi que la répartition des tâches entre
serveur et client.
Figure 3: Schéma du GARTNER Group
Sur ce schéma, le trait horizontal représente le réseau et les flèches entre client et
serveur, le trafic réseau généré par la conversation entre client et serveur.
13
Le Gartner Group distingue les types de client-serveur suivants, en fonction du type de

service déporté du cœur de l’application :
Présentation distribuée : habillage graphique de l'affichage en mode
caractères d’applications fonctionnant sur site central ; le Poste client conserve une
position d’esclave / serveur
Présentation distante : Encore appelée client-serveur de présentation.
L'ensemble des traitements est exécuté par le serveur, le client ne prend en charge que
l'affichage. Inconvénients : il génère un fort trafic réseau et ne permet aucune répartition
de la charge entre client et serveur.
Gestion distante des données : correspond au client-serveur de données,
sans doute le type de client-serveur le plus répandu. L’application fonctionne dans sa
totalité sur le client, la gestion des données et le contrôle de leur intégrité sont assurés
par un SGBD centralisé. Inconvénients : le trafic réseau assez important et ne soulage
pas le poste client, qui réalise encore la grande majorité des traitements.
Traitement distribué : Correspond au client-serveur de traitements. Le
découpage de l'application se fait ici au plus près de son noyau et les traitements sont
distribués entre le client et le(s) serveur(s). Le client-serveur de traitements s'appuie,
soit un mécanisme d'appel de procédure distante, soit sur la notion de procédure stockée
proposée par les principaux SGBD du marché. Cette architecture permet d'optimiser la
répartition de la charge de traitement entre machines et limite le trafic réseau.
Inconvénients : client et serveur doivent à l’avance connaître et implémenter les
procédures à accomplir.
Base de données distribuées : Il s'agit d'une variante du client-serveur
de données dans laquelle une partie de données est prise en charge par le client. Ce
modèle est intéressant si l'application doit gérer de gros volumes de données, si l'on
souhaite disposer de temps d'accès très rapides sur certaines données ou pour répondre
à de fortes contraintes de confidentialité.
Données et traitements distribués : Ce modèle est très puissant et tire
parti de la notion de composants réutilisables et distribuables pour répartir au mieux la
charge entre client et serveur. C'est, bien entendu, l'architecture la plus complexe à
mettre en œuvre.
14
2.5. Les différentes Architectures

2.5.1. Architecture peer to peer
Le pair-à-pair (P2P : peer-to-peer) est un réseau informatique dans lequel chaque client
du réseau est également serveur. L'information est répartie sur l'ensemble des machines qui
composent le réseau P2P.
Les systèmes pair-à-pair permettent à plusieurs ordinateurs de communiquer via un

réseau, de partager simplement des fichiers le plus souvent, mais également des flux
multimédias ou encore un service (comme la téléphonie avec Skype par exemple).
Les serveurs pair-à-pair fonctionnent dans la quasi-totalité des cas en mode synchrone :
le transfert d'information est limité aux éléments connectés en même temps au réseau. Ils
peuvent utiliser le protocole TCP comme couche de transport des données (il fonctionne en
duplex, la réception des données est donc confirmée et leur intégrité est assurée).
Figure 4: Architecture peer to peer
Avantage du Pair à pair :
- Plus il y a d'utilisateur plus les performances du réseau grandissent.

- Un coût réduit
- Simplicité d'installation
- Rapidité d'installation
- Si une source est en pannes le réseau fonctionne toujours
Inconvénients du Pair à Pair :
- Problème de sécurité
- Maintenance plus difficile
- Nécessite plusieurs machines pour que le réseau soit performant
15
2.5.2. Architectures centralisées

a. Architectures 1-tiers
✓ Les 3 couches applicatives s'exécutent sur la même machine
✓ On parle d'informatique centralisée :
✓ Contextes multi-utilisateurs dans le cadre d'un site central (mainframe)
Figure 5: Architectures 1-tiers
b. Architectures 2-tiers client serveur

De base la relation entre un client en un serveur se fait entre deux processus, deux
logiciels ou deux machines. On peut parler d'une architecture à deux niveaux ou
une architecture deux tiers (two-tier architecture en anglais). Dans ce cas, le client demande
une ressource au serveur qui la fournit directement à partir de ses propres ressources, sans
solliciter d'autres machines.
Ce type d'application permet de tirer parti de la puissance des ordinateurs déployés en
réseau pour fournir à l'utilisateur une interface riche5.1, tout en garantissant la cohérence des
données, qui restent gérées de façon centralisée.
La gestion des données est prise en charge par un SGBD centralisé, s'exécutant le plus
souvent sur un serveur dédié. Ce dernier est interrogé en utilisant un langage de requête qui, le
plus souvent, est SQL.
16
Avantages de l'architecture client/serveur

Le modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant
un grand niveau de fiabilité, ses principaux atouts sont :
• Des ressources centralisées
Étant donné que le serveur est au centre du réseau, il peut gérer des ressources
communes à tous les utilisateurs, comme par exemple une base de données centralisée, afin
d'éviter les problèmes de redondance et de contradiction
• Une meilleure sécurité
Car le nombre de points d'entrée permettant l'accès aux données est moins important
• Une administration au niveau serveur
Les clients ayant peu d'importance dans ce modèle, ils ont moins besoin d'être
administrés
• Un réseau évolutif
Grâce à cette architecture on peu supprimer ou rajouter des clients sans perturber le
fonctionnement du réseau et sans modifications majeures
Limites du modèle client/serveur
- Contrairement au réseau Pair-à-Pair si trop de clients se connecte au serveur celui-ci
peut saturer ;
- Si le serveur tombe en panne plus rien ne fonctionne ;
- Les coûts de mise en place et de maintenance sont élevés ;
- Les clients ne peuvent pas communiquer entre eux ;
- Le middleware entre client et serveur n’est pas standard (dépend de la plateforme, du
SGBD).
17
2.5.3. Architectures Distribuées

a. Architecture 3-tiers
Une architecture à trois niveaux ou une architecture trois tiers (three-tier
architecture en anglais) ajoute un niveau supplémentaire à l'architecture à 2 niveaux, permettant
de spécialiser les serveurs dans une tâche précise, ce qui donne un avantage de flexibilité, de
sécurité et de performance :
• Un client qui demande une ressource via une interface utilisateur (généralement un
navigateur web) chargée de la présentation de la ressource ;
• Un serveur d'application (appelé middleware) qui fournit la ressource, mais en faisant
appel aux ressources d'un autre serveur ;
• Un serveur de données qui fournit au serveur d'application les ressources requises pour
répondre au client.
La présentation est sur le client
✓ Les traitements sont pris par un serveur intermédiaire
✓ Les données sont sur un serveur de données
✓ Contexte multiutilisateur internet
b. Architecture n-tiers
L’architecture n-tiers a été pensée pour pallier aux limitations de architectures trois tiers
et concevoir des applications puissantes et simples à maintenir. Ce type d’architecture permet
de distribuer plus librement la logique applicative, ce qui facilite la répartition de la charge entre
tous les niveaux. Cette évolution des architectures3-tiers met en œuvre une approche objet pour
offrir une plus grande souplesse d’implémentations et faciliter la réutilisation des
développements. Théoriquement, ce type d’architecture supprime tous les inconvénients des
architectures précédentes :
18
• Elle permet l’utilisation d’interfaces utilisateurs riches ;

• Elle sépare nettement tous les niveaux de l’application ;
• Elle offre de grandes capacités d’extension ;
• Elle facilite la gestion des sessions.
Une architecture à N niveaux ou architecture N tiers (N-tier architecture en anglais)

n'ajoute pas encore des niveaux supplémentaires à l'architecture à 3 niveaux, mais introduit la
notion des objets qui offre la possibilité de distribuer les services entre les 3 niveaux selon N
couches, permettant ainsi de spécialiser les serveurs davantage.
✓ La présentation est sur le client

✓ Les traitements sont pris par un serveur intermédiaire
✓ Les données sont sur un serveur de données
✓ Contexte multi-utilisateurs internet
Figure 8: Architectures n-tiers
3. Principes de Fonctionnement
3.1. Coté serveur
3.1.1. Gestion des processus
Le client et le serveur exécutent des processus distincts :
- Le client est suspendu lors de l’exécution de la requête (appel synchrone)

- Plusieurs requêtes peuvent être traitées par le serveur :
Comme mode de gestion des requêtes nous avons :
• Itératif : le processus serveur traite les requêtes les unes après les autres ; adapté
aux requêtes qui peuvent s'exécuter rapidement ; souvent utilisé en mode non
connecté (recherche de la performance)
19
• Concurrent : le serveur accepte les requêtes puis les "délègue" à un processus fils
(traitement de plusieurs clients) ; adapté aux requêtes qui demandent un certain
traitement (le coût du traitement est suffisamment important pour que la création
du processus fils ne soit pas pénalisante) ; souvent utilisé en mode connecté. Il est
basé sur :
Parallélisme réel : systèmes multiprocesseurs par exemple

Pseudo‐parallélisme : schéma veilleur‐exécutants
La concurrence peut prendre plusieurs formes :
– plusieurs processus (un espace mémoire par processus)
– plusieurs processus légers (threads) dans le même espace mémoire
3.1.2. Gestion d’états

Pour pouvoir répondre à cela on se pose ces questions : 2 requêtes successives d'un
même client sont-elles indépendantes ? faut-il sauvegarder des infos entre 2 requêtes
successives d'un même client ?
Mode sans état (le plus simple)
• Pas d'info sauvegardée
• Les requêtes successives d'un même client sont indépendantes
Ex : NFS, HTTP
Types de requêtes envisageables
- demande d'écriture du k-ième bloc de données d'un fichier
Types de requêtes non envisageables
- demande d'écriture du bloc suivant
Mode avec état

Les requêtes successives s'exécutent en fonction de l'état laissé par les appels
précédents : sauvegarde de l'état
Notion proche : session cliente dans un serveur Web Suivi de l'activité d'un client entre le
moment où il arrive et celui où il quitte le site
Problème : y a-t-il un mécanisme explicite qui indique au serveur que le client part ?
- si oui (ex. déconnexion notifiée au serveur) alors ok
- si non
Problème : aucun sens de conserver ad vitam les données de la session
20
Heuristique : la session expire au bout d'un délai fixé

Inconvénients. : un client très lent peut revenir après expiration
→ (re)commencement d'une nouvelle session
3.2. Mode de communication client/serveur

3.2.1. Modes
Figure 9: Modes de Communication
• Synchrone le client attend la réponse pour continuer son exécution

• Asynchrone le client n’attend pas de réponse et continue tout de suite
• Semi-synchrone le client continue son exécution après l’envoi et récupère le résultat
ultérieurement
- à futur explicite le résultat est stocké dans une boîte à lettres (BAL) le client
consulte cette BAL pour récupérer le réseau.
- à futur implicite le résultat est fourni automatiquement au client par ex. via une
variable du programme client
Le client et le serveur doivent bien sûr utiliser le même protocole de communication au

niveau de la couche transport du modèle OSI. On parle souvent d'un service pour désigner la
fonctionnalité offerte par un processus serveur.
21
3.2.2. Notion de connexion

Pour qu’il ait communication, nous avons Besoin d’un support pour transporter les
informations entre le client et le serveur. Celui-ci peut être :
Bas niveau : Utilisation directe du transport : sockets (construits sur TCP ou UDP)
Haut niveau : Intégration dans le langage de programmation : RPC ou Remote

Procedure Call (construits sur sockets)
Il y’a Nécessité d’établir un protocole entre le client et le serveur pour qu’ils se comprennent.
Pour cela nous aurons besoin des Sockets.
Un socket est une norme de communication sur réseau, mis au point à Berkeley, qui
permet à une application de dialoguer avec un Protocol. Un socket peut aussi considérer comme
un API (application program interface) qui est une interface de programmation entre
l’application réseau et la couche transport. Un socket peut donc être défini comme un
mécanisme d’interface de programmation de bas niveau qui permet aux programmes
d’échanger les données.
Figure 10: API Socket
Les sockets se situent au niveau de la couche réseau.
22
Un socket est identifié par une adresse de transport qui permet d'identifier les processus
de l'application concernée. L’adresse de transport est définie par :
• Le type de Protocol utilisé (TCP ou UDP)

• L’adresse IP
• Le numéro de port associé aux processus : Le serveur doit utiliser un numéro de port
fixe vers lequel les requêtes clientes sont dirigées. Un service rendu par un programme
serveur sur une machine est accessible par un port. Le port serveur est le port local sur
lequel les connexions sont attendues. Le port client est alloué de façon dynamique par
le système.
Principes de fonctionnement :
Figure 11: Principes de Fonctionnement
Deux réalisations sont possibles :

Le mode connecté (Protocol TCP)
Le mode Non connecté (Protocol UDP)
a. Le mode connecté
Caractéristiques :
- Etablissement au préalable d’une connexion : le client demande au serveur s’il accepte
la connexion
23
- Garanties de TCP : Ordre, contrôle de flux, fiabilité

- Un serveur peut répondre aux demandes de service de plusieurs clients : mes requêtes
arrivées et non traitées sont stockées dans une file d’attente
- Apres initialisation le serveur est passif. Il est activé lors de l’arrivée d’une demande de
connexion du client
- Le serveur préserve son état entre deux processus
Contraintes :
Le client doit avoir accès à l’adresse du serveur (adresse IP, n° de port)
Modes de gestion des requêtes :
- Itératif : le processus traite les requêtes les unes après les autres
- Concurrent : par création de processus fils pour les échanges de chaque requête
(ouverture de connexion)
Processus de communication :
Pour que le client puisse contacter le serveur
1.le processus serveur doit déjà tourner
2.le serveur doit avoir créé au préalable une socket pour recevoir les demandes de connexion
des clients
Ensuite Le client contacte le serveur
3. en créant un socket local au client
4. en spécifiant une adresse IP et un numéro de port pour joindre le processus serveur
Le client demande alors l'établissement d'une connexion avec le serveur
5.Si le serveur accepte la demande de connexion
6.il crée un nouveau socket permettant le dialogue avec ce client
7.permet au serveur de dialoguer avec plusieurs clients
Client Serveur
24
Figure 12 : communication Mode Connecté
b. Mode Non Connecté

Caractéristiques :
- Pas d’établissement préalable d’une connexion
- Les requêtes successives sont indépendantes
- Pas de préservation de l’état entre les requêtes
- Le client doit indiquer son adresse à chaque requête (pas de liaison permanente)
- Pas de garanties de fiabilité. Gestion de toutes les erreurs à la main : il faut réécrire la
couche transport
Contraintes :
- Le client doit avoir accès à l’adresse du serveur
- Le serveur doit récupérer l’adresse de chaque client pour lui répondre
Modes de gestion des requêtes :
- Itératif : requêtes traitées l’une après l’autre
- Concurrent : un processus ou thread par client
Processus de communication :
Pour que le client puisse contacter le serveur
1.il doit connaître l'adresse du socket du serveur
2.le serveur doit avoir créé le socket de réception
3.Le client envoie sa requête en précisant, lors de chaque envoi, l'adresse de la socket
destinataire
25
4.Le datagramme envoyé par le client contient l'adresse de la socket émettrice (port, @IP)
5.Le serveur traite la requête et répond au client en utilisant l'adresse du socket émettrice de la
requête.
Client Serveur
Figure 13: mode non connecté
En mode connecté comme en mode non connecté, Le client a l’initiative de la

communication : le serveur doit être à l’écoute ; Le client doit connaître la référence du serveur
[adresse IP, N° de port] (il peut la trouver dans un annuaire si le serveur l’y a enregistrée au
préalable, ou la connaître par convention : N° de port pré affectés) ; Le serveur peut servir
plusieurs clients (1 thread unique ou 1 thread par client).
La liaison entre le client et le serveur correspond à tout un ensemble complexe de

logiciels appelé middleware qui se charge de toutes les communications entre les processus.
4. Le Middleware
4.1. Définitions
On appelle middleware, littéralement « élément du milieu », l'ensemble des couches
réseau et services logiciel qui permettent le dialogue entre les différents composants d'une
application répartie. Ce dialogue se base sur un protocole applicatif commun, défini par l’API
du middleware.
API : Application Programming Interfaces, ou interface de programmation du niveau

applicatif, encore appelée protocole applicatif. L'API prend en charge l'interface entre le
programme et le système.
26
Le Gartner Group définit le middleware comme une interface de communication

universelle entre processus. Il représente véritablement la clef de voûte de toute application
client-serveur.
L'objectif principal du middleware est d'unifier, pour les applications, l'accès et la

manipulation de l'ensemble des services disponibles sur le réseau, afin de rendre l'utilisation de
ces derniers presque transparente.
Figure 14 : Middleware
Pourquoi le Middleware :
Pour Assurer l’échanges données entre Client et Serveur en masquant les différents
problèmes potentiels liés à :
- Répartition des données et traitements (accès distant, baisse performances) ;
- Hétérogénéité des matériels et des logiciels en opération
Pour augmenter les performances sur chaque machine en parallèles ;
Pour éviter au client d’avoir du code non réseau dans son appel.
4.2. Fonctions du Middleware

Permettre à un programme de s’exécuter sur plusieurs machines reliées par un réseau
- à large échelle (Internet)
- local (intranet)
Les environnements middleware permettent à différents types de matériels (PC,
Mainframes, laptop, PDA…) de communiquer à distance
En général, le middleware
• n'est pas visible par l'utilisateur final
• est un outil pour le développeur d'applications
• se retrouve enfoui dans les applications
27
Middleware permet de mettre en œuvre des serveurs

• à finalité fixe : serveur Web, serveur de fichiers, serveur de BD, ...
• effectuant des traitements quelconques : CORBA, EJB, .Net, ...
Les services du middleware sont un ensemble de logiciels répartis qui existe entre
l’application, l’OS et les services réseaux sur un nœud du réseau.
4.3. Les services du Middleware

Un middleware est susceptible de rendre les services suivants
• Conversion : Service utilisé pour la communication entre machines mettant en œuvre

des formats de données différents, elle est prise en charge par la FAP
• Adressage : Permet d'identifier la machine serveur sur laquelle est localisé le service
demandé afin d'en déduire le chemin d'accès. Dans la mesure du possible, cette fonction
doit faire appel aux services d'un annuaire.
• Sécurité : Permet de garantir la confidentialité et la sécurité des données à l'aide de

mécanismes d'authentification et de cryptage des informations.
• Communication : Permet la transmission des messages entre les deux systèmes sans
altération. Ce service doit gérer la connexion au serveur, la préparation de l'exécution
des requêtes, la récupération des résultats et la déconnexion de l'utilisateur.
Le middleware masque la complexité des échanges inter-applications et permet ainsi

d'élever le niveau des API utilisées par les programmes. Sans ce mécanisme, la programmation
d'une application client-serveur serait extrêmement complexe et rigide.
Le choix d'un middleware est déterminant en matière d'architecture, il joue un grand

rôle dans la structuration du système d'information
4.4. Exemples de Middleware

• SQL*Net : Interface propriétaire permettant de faire dialoguer une application cliente avec
une base de données Oracle. Ce dialogue peut aussi bien être le passage de requêtes SQL
que l'appel de procédures stockées.
• ODBC (Open DataBase Connectivity) : Interface standardisée isolant le client du

serveur de données. C'est l'implémentation par Microsoft du standard CLI (Call Level
Interface) défini par le SQL Access Group. Elle se compose d'un gestionnaire de driver
28
standardisé, d'une API s'interfaçant avec l'application cliente (sous Ms Windows) et d'un
driver correspondant au SGBD utilisé.
• DCE (Distributed Computing Environment) : Mécanisme de RPC proposé par l’OSF :

Permet l'appel à des procédures distantes depuis une application.
Le choix d'un middleware est déterminant en matière d'architecture, il joue un grand

rôle dans la structuration du système d'information.
Pour certaines applications devant accéder à des services hétérogènes, il est parfois
nécessaire de combiner plusieurs middlewares. Dans ce cas, le poste client doit connaître et
mettre en œuvre plusieurs IPC (Inter Process Communication), on en vient à la notion de client
lourd.
IV. EXEMPLE DE CLIENT/SERVEUR
FTP (File Transfer Protocol) Le protocole de transfert de fichiers, ou FTP (File

Transfer Protocol), est un protocole de communication destiné à l’échange informatique de
fichiers sur un réseau TCP/IP. Il permet, depuis un ordinateur, de copier des fichiers vers un
autre ordinateur du réseau, d’alimenter un site web, ou encore de supprimer ou de modifier des
fichiers sur cet ordinateur. FTP obéit à un modèle client/serveur, c’est-à-dire qu’une des deux
parties, le client, envoie des requêtes et le serveur répond. En pratique, le serveur est un
ordinateur sur lequel fonctionne un logiciel lui-même appelé serveur FTP. Pour accéder à un
serveur FTP, on utilise un logiciel client FTP (possédant une interface graphique comme
FileZilla par exemple ou en ligne de commande).
Deux ports sont standardisés pour les connexions FTP : le port 21 pour les commandes
et le port 20 pour les données.
Le transfert de fichier consiste à recopier un fichier complet d’un système à un autre.
Pour utiliser FTP, il faut posséder un compte sur le système distant pour pouvoir s’y connecter.
Dans le cas de FTP anonyme, il n’y a pas besoin de compte. FTP est un protocole orienté
connexion. C’est-à-dire qu’il y a trois étapes :
· Etablir une connexion entre le site local et le site distant
· Effectuer les traitements désirés
· Fermer la connexion
FTP utilise deux connexions TCP pour transférer un fichier :
29
· Une connexion de contrôle est utilisée pour acheminer les commandes (ou requêtes)
du client vers le serveur et les réponses (ou résultats) du serveur vers le client.
· Une connexion de transfert de données qui est créée à chaque fois qu’un fichier est
transféré entre le client et le serveur.
30
CONCLUSION
En Somme, il était question pour nous tout au long de ce projet, de présenter

l’Architecture client-serveur, de donner ses origines, son principe de fonctionnement et
quelques exemples concret d’application. Il en ressort que l’architecture client/serveur un
Ensemble de machines pouvant communiquer entre elles, et s’échangeant des services :
traitement, données ou ressources, il tire ses origines de l’architecture centralisée
(Mainframes). Le client demande une ressource au serveur qui la fournit directement à partir
de ses propres ressources, sans solliciter d'autres machines. Pour pouvoir communiquer, le
client et le serveur doivent bien sûr utiliser le même protocole de communication au niveau de
la couche transport du modèle OSI ; les échanges peuvent se faire à travers un réseau, ou parfois
en local et ce protocole doit être connu des clients et des serveurs. Nous constatons que bien
que cohérent et centralisée, cette architecture regorge beaucoup de limites, entre autres : Si le
serveur tombe en panne plus rien ne fonctionne.
Pour résoudre les limitations du client-serveur deux tiers tout en conservant ses avantages, on
a cherché une architecture plus évoluée, facilitant les forts déploiements à moindre cout. La
réponse est apportée par les architectures distribuées.
31
BIBLIOGRAPHIE
1. Lionel Seinturier, Université Pierre & Marie Curie, Client/serveur Middleware, 2002
2. Sacha Krakowiak, Université Joseph Fourier Projet Sardes (INRIA et IMAG-LSR),
Programmation client-serveur sockets – RPC, 2004
3. Olivier GLÜCK Université LYON 1/Département Informatique, Architecture et
communications Client/Serveur, 2018
4. Anas ABOU EL KALAM, Technologie des applications client-serveur, Septembre 2005
5. Stéphane Bortzmeyer AFNIC, Centralisé, décentralisé, pair à pair, quels mots pour
l’architecture des systèmes répartis ? Montpellier, JRES 2015
6. Daniel MARTIN. Architecture des applications réparties, Octobre 1999.
WEBOGRAPHIE
https://whatis.techtarget.com/fr/definition/Remote-procedure-call-RPC
https://fr.wikipedia.org/wiki/Appel_syst%C
https://fr.wikipedia.org/wiki/File_Transfer_Protocol
https://www.cairn.info/revue-pensee-plurielle-2014-2-page-37
http://projet.eu.org/pedago/sin/ISN/8-client_serveur.pdf
32
TABLES DES MATIERES

SOMMAIRE ..........................................................................................................................1
LISTE DES FIGURES ...........................................................................................................3
RESUME ...............................................................................................................................4
ABSTRACT ...........................................................................................................................5
INTRODUCTION GENERALE.............................................................................................6
I. ORIGINE ........................................................................................................................7
II. PROBLEMATIQUE .......................................................................................................7
III. ETAT DE L’ART ........................................................................................................8
1. Définitions ...................................................................................................................8
1.1. Client ....................................................................................................................8
1.2. Le serveur .............................................................................................................9
2. Architecture Client/serveur ........................................................................................ 10
2.1. Définitions ..........................................................................................................10
2.2. Les principes généraux de l’architecture client/serveur ........................................ 11
2.3. Les différents modèles de client serveur .............................................................. 11
a. Le client-serveur de présentation ......................................................................... 12
b. Le client-serveur de traitement ............................................................................ 12
c. Le client-serveur de données ............................................................................... 13
2.4. Schéma du GARTNER Group ............................................................................ 13
2.5. Les différentes Architectures............................................................................... 15
2.5.1. Architecture peer to peer .............................................................................. 15
2.5.2. Architectures centralisées.............................................................................16
a. Architectures 1-tiers ............................................................................................ 16
b. Architectures 2-tiers client serveur ......................................................................16
2.5.3. Architectures Distribuées .............................................................................18
a. Architecture 3-tiers ............................................................................................. 18
b. Architecture n-tiers ................................................................................................ 18
3. Principes de Fonctionnement ..................................................................................... 19
3.1. Coté serveur ...........................................................................................................19
3.1.1. Gestion des processus ...................................................................................... 19
3.1.2. Gestion d’états................................................................................................. 20
3.2. Mode de communication client/serveur .................................................................. 21
3.2.1. Modes .............................................................................................................21
3.2.2. Notion de connexion ....................................................................................... 22
33
a. Le mode connecté ............................................................................................... 23

b. Mode Non Connecté ........................................................................................... 25
4. Le Middleware ...........................................................................................................26
4.1. Définitions ..........................................................................................................26
4.2. Fonctions du Middleware .................................................................................... 27
4.3. Les services du Middleware ................................................................................ 28
4.4. Exemples de Middleware .................................................................................... 28
IV. EXEMPLE DE CLIENT/SERVEUR ......................................................................... 29
CONCLUSION .................................................................................................................... 31
BIBLIOGRAPHIE ............................................................................................................... 32
WEBOGRAPHIE ................................................................................................................. 32
TABLES DES MATIERES .................................................................................................. 33
34

Architecture Client-Serveur PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architecture Client-Serveur PDF

Transféré par

Droits d'auteur :

Formats disponibles

ARCHITECTURE CLIENT/SERVEUR

LISTE DES FIGURES

L’architecture client/serveur désigne un mode de communication entre plusieurs

Client / Server architecture refers to a mode of communication between several

Un effort de recherche et de production industriel a été effectué au niveau mondial. La

Le client-serveur se situe dans ce besoin de centralisation (information cohérente, non

III. ETAT DE L’ART

Figure 1: communication client/serveur

2.2. Les principes généraux de l’architecture client/serveur

2.3. Les différents modèles de client serveur

Figure 2: modèle client/serveur

Dans le modèle client-serveur on distingue trois couches :

2.4. Schéma du GARTNER Group

Un groupe d’étude composé d’acteurs du marché a défini 6 types d’architectures

Figure 3: Schéma du GARTNER Group

Le Gartner Group distingue les types de client-serveur suivants, en fonction du type de

2.5. Les différentes Architectures

Les systèmes pair-à-pair permettent à plusieurs ordinateurs de communiquer via un

Figure 4: Architecture peer to peer

Avantage du Pair à pair :

- Plus il y a d'utilisateur plus les performances du réseau grandissent.

2.5.2. Architectures centralisées

Figure 5: Architectures 1-tiers

b. Architectures 2-tiers client serveur

Figure 6: Architectures 2-tiers

Avantages de l'architecture client/serveur

2.5.3. Architectures Distribuées

Figure 7: Architectures 3-tiers

• Elle permet l’utilisation d’interfaces utilisateurs riches ;

Une architecture à N niveaux ou architecture N tiers (N-tier architecture en anglais)

✓ La présentation est sur le client

Figure 8: Architectures n-tiers

- Le client est suspendu lors de l’exécution de la requête (appel synchrone)

Comme mode de gestion des requêtes nous avons :

Parallélisme réel : systèmes multiprocesseurs par exemple

3.1.2. Gestion d’états

Mode avec état

Heuristique : la session expire au bout d'un délai fixé

3.2. Mode de communication client/serveur

Figure 9: Modes de Communication

• Synchrone le client attend la réponse pour continuer son exécution

Le client et le serveur doivent bien sûr utiliser le même protocole de communication au

3.2.2. Notion de connexion

Haut niveau : Intégration dans le langage de programmation : RPC ou Remote

Figure 10: API Socket

Les sockets se situent au niveau de la couche réseau.

• Le type de Protocol utilisé (TCP ou UDP)

Figure 11: Principes de Fonctionnement

Deux réalisations sont possibles :

- Garanties de TCP : Ordre, contrôle de flux, fiabilité

Figure 12 : communication Mode Connecté

b. Mode Non Connecté

Figure 13: mode non connecté

En mode connecté comme en mode non connecté, Le client a l’initiative de la

La liaison entre le client et le serveur correspond à tout un ensemble complexe de

API : Application Programming Interfaces, ou interface de programmation du niveau

Le Gartner Group définit le middleware comme une interface de communication

L'objectif principal du middleware est d'unifier, pour les applications, l'accès et la

4.2. Fonctions du Middleware

Middleware permet de mettre en œuvre des serveurs

4.3. Les services du Middleware

• Conversion : Service utilisé pour la communication entre machines mettant en œuvre

• Sécurité : Permet de garantir la confidentialité et la sécurité des données à l'aide de