NSY107 - Intgration des systmes client-serveur

Cours du 13/05/2006 (4 heures) Emmanuel DESVIGNE <emmanuel@desvigne.org>

Document sous licence libre (FDL)

Plan du cours
Introduction Historique Les diffrentes approches Architecture (initiation) Bilan

Rappels - Introduction [1/13]

La notion de client-serveur est trs floue. Intuitivement, on suppose quil existe un client , souvent assimil au poste de travail de lutilisateur, qui interroge une grosse machine associe au serveur. Si ce modle existe, nous verrons quil nest pas unique (loin de l), et que la ralit est souvent plus complexe.
3

Rappels - Introduction [2/13]

En ralit, la notion de client-serveur peut se concevoir :
dun poste client un serveur (notion classique, quoi que). Par exemple :
Un PC (Pentium 4 2 GHz) <-> un serveur de logiciel de paie (bi-proc 2 x Xon 3GHz), Un PC (Athlon 2600+) <-> serveur dimpression (parfois un serveur puissant sous Unix ou Windows, parfois un petit botier avec un processeur ARM 200 MHz, voire un simple serveur intgr limprimante), Un client lger (tout petit PC avec un cran, avec un systme dexploitation minimal, une carte mre, pas de disque dur dont le rle est de ne faire que de laffichage) <-> serveur TSE ou Citrix (proche du concept Serveur/Terminal passif).
4

Rappels - Introduction [3/13]

Mais aussi, dun serveur un autre serveur. Par exemple :
Une application mtier (logiciel de paie, de compta, de dossier mdical, de commerce en ligne, etc.) <-> serveur de Systme de Gestion de Base de Donnes (SGBD), Un serveur SGBD avec un serveur de fichiers, Un serveur de fichiers avec un serveur dauthentification/habilitations, Un serveur demails avec un serveur dannuaires, Etc.
5

Rappels - Introduction [4/13]

Voire... dun serveur un client !?!? :
Ex : machine Unix (pourtant appele serveur) sur laquelle tourne un programme scientifique qui envoie le contenu des fentres afficher sur un serveur X11 situ... sur un poste de lutilisateur (pourtant appel poste client).
serveur X11

logiciel

fentre X11 Serveur Unix Poste client

6

Rappels - Introduction [5/13]

Oxymoron ?
en fait, ce dernier paradoxe vient dun abus de langage. Le mot serveur est la fois utilis pour parler :
de la machine sur laquelle tourne le logiciel qui fourni les traitements ou les donnes sur lesquels travaille lutilisateur, et aussi pour parler du service X11, qui ralise laffichage des fentres gnres par le logiciel.

Rappels - Introduction [6/13]

Tentative de dfinition [source Wikipedia] :
L'architecture client-serveur dsigne un mode de communication entre des ordinateurs ou des logiciels. Les mots serveur et client peuvent soit dsigner :
les ordinateurs, on parle alors de serveur informatique et de poste client ; soit dsigner les logiciels fonctionnant sur ces ordinateurs, on parle alors de logiciel serveur [ou service] ou de logiciel client.

Le serveur est l'coute sur un rseau informatique, prt rpondre aux requtes envoyes par des clients.
8

Rappels - Introduction [7/13]

Tentative de dfinition, suite :
Les clients sont pilots par les utilisateurs* et envoient des requtes au serveur, puis attendent la rponse pour la donner l'utilisateur. [Pas toujours vrai] : un serveur est capable de servir plusieurs clients simultanment, jusqu' plusieurs milliers. (*) certains clients envoient des requtes sans intervention directe de lutilisateur (intelligence artificielle, tches programmes, etc.)
9

Rappels - Introduction [8/13]

Il existe deux grands modes de fonctionnement client/serveur (qui seront dtaills plus tard) :
Le mode connect : un canal de communication se cre entre le client et le serveur ( la demande du client), et les changes (ordres, accuss de rception, donnes...) transitent par ce canal, ou alors via dautres canaux ouverts pour loccasion (ex : HTTP, IMAP, FTP...) ; Le mode datagramme , ou changes de paquets : il sagit souvent de systmes plus simples, o le client envoie sa requte (un ordre) dans un paquet, et le serveur lui rpond dans un ou plusieurs paquets (ex: TFTP). 10

Rappels - Introduction [9/13]

La notion de client-serveur est intimement lie deux concepts informatiques :
systme : les systmes [df :architecture physique + systme dexploitation] modernes permettent :
le multi-tche (voire le multi-thread), mono et multiprocesseurs, la gestion des vnements (interruptions).

rseau : si, sur le papier, il est possible dimaginer du client/serveur monoposte, le client communiquant avec le serveur via des IPC, la notion de client-serveur na dintrt que pour plusieurs machines.
11

Rappels - Introduction [10/13]

IPC (Inter-Process Communication, soit communication inter-processus ) : ensemble de mcanismes mis disposition par un systme dexploitation pour que plusieurs programmes concurrents (qui utilisent les mmes ressources) tournant sur une mme machine puissent communiquer entre-eux (changes de donnes, synchronisation ou points de rendez-vous). Ex :
fichiers, pipes (tubes), smaphores, mmoire partage (shared memory)

12

Rappels - Introduction [11/13]

Petit rappel du modle OSI :

13

Rappels - Introduction [12/13]

Comparaison OSI-IP (Rq : il arrive que dans certaines revues, les couches 5 7 soient regroupes) :

14

Rappels - Introduction [13/13]

Relation client-serveur et rseau :
la notion de client/serveur se calque avec la notion de protocole rseau . En fait, fondamentalement, programmer du client/serveur revient dvelopper un protocole rseau, depuis ~20 ans, divers mcanismes (RPC par exemple, que nous retrouverons plus tard) permettent de simplifier (voire, de rendre transparent) lcriture de ces protocoles pour les programmeurs, certains protocoles utilisent des changes de flux en texte (ex : ASCII) et peuvent tre compris par des humains (ex: SMTP, POP3, HTTP, etc.). Dautres utilisent des changes de flux binaires (ex : DNS). 15

Rappels - Historique [1/5]

lorigine : systmes centraliss :
Version simple : le serveur central avec terminal passif (ex : serveur Unix avec terminaux passifs):

Liens sries

Terminaux passifs Serveur Unix

16

Rappels - Historique [2/5]

volution (initialement invente par IBM dans le monde des mainframes et autres terminaux 3270): la gestion des terminaux nest plus traite par le serveur central (Rq : cest dj du client-serveur !) :

17

Rappels - Historique [3/5]

autre volution dans le monde Unix : le terminal qui cause travers un rseau (telnet). Rq : cest aussi du client serveur

Terminal rseau (platine) Rseau informatique

Serveur Unix

Micro-ordinateur avec mulateur terminal (telnet)

18

Rappels - Historique [4/5]

La suite de lhistoire du client-serveur nest pas linaire. Il sagit surtout de la naissance et de lvolution de diffrents modles, correspondant diffrentes approches pour rsoudre un problme. Parmi les ides dveloppes :
certains proposent de concentrer la puissance dans le serveur, et de mettre des clients idiots (bien que nous verrons quils deviennent de moins en moins idiots), dautres proposent de mettre lintelligence dans le client, le serveur ntant que la zone de stockage, et lentit qui assure lintgrit de lensemble,
19

Rappels - Historique [5/5]

dautres encore proposent de morceler lapplication informatique en autant de clients et de serveurs ncessaires,

Mais en fait... Il nexiste pas LA solution. Nous aborderons plus tard la notions d architecture , qui permet de mixer ces approches, afin de choisir le meilleur compromis VOTRE problmatique.
20

Les diffrentes approches [1/6]

Une approche consiste centraliser la puissance dans le serveur, et avoir des clients idiots :
Exemple dj vu :
Terminal rseau (platine) Rseau informatique

Serveur Unix

Micro-ordinateur avec mulateur terminal (telnet)

21

Les diffrentes approches [2/6]

une extension de ce concept en version graphique : le terminal X11
Zone graphique afficher

Terminal X11 Rseau informatique

Serveur Unix

Micro-ordinateur avec serveur X11

22

Les diffrentes approches [3/6]

une extension du terminal X11 : le client lger (protocoles RDP ou ICA pour Windows, LNA pour Linux, ...). Exemple :

Client ICA Rseau informatique

Serveur Windows + couches CITRIX

Micro-ordinateur avec client Citrix

23

Les diffrentes approches [4/6]

Extension du modle client-serveur appliqu aux serveurs : le cluster

Rseau informatique Poste client

Grappe de machines (cluster) vue comme un seul serveur

24

Les diffrentes approches [5/6]

Une autre approche est de mettre une grande partie de la puissance dans le client. Exemple : client de courrier lectronique avec POP3 et SMTP
Courrier entrant Courrier sortant

Serveur POP3 Poste utilisateur

Serveur SMTP
25

Les diffrentes approches [6/6]

Mix des solutions
Courrier entrant Courrier sortant

Serveur POP3

RDP

Serveur Windows TSE (sur lequel tourne un client email)

Serveur SMTP

Client lger RDP

26

Architecture (initiation) [1/3]

Pour faire simple : cest lart de dcouper tout une application en composantes clients et en serveurs, de mixer les diffrentes approches client-serveur vues prcdemment. Tout comme il nexiste pas UNE approche client-serveur parfaite, il nexiste pas UNE architecture unique ayant tous les avantages. Tout dpend de vos besoins.
27

Architecture (initiation) [2/3]

Exemple (classique) : architecture 3-tiers :
Couche prsentation (ou cliente) : correspondant l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur, etc. (interface homme-machine) Couche mtier (ou applicative) : traitements propres lapplication (exemple : pour un logiciel de compta, gestion de stock, de la paie, gestion des tats, de la balance) Couche accs aux donnes : correspondant aux donnes qui sont destines tre conserves sur la dure, voire de manire dfinitive. Pour faire simple : mcanismes de cache + SGBD
28

Architecture (initiation) [3/3]

Architecture N-tiers (multi-tiers) : la couche applicative est elle-mme compose de plusieurs niveaux

Front-end Clients : navigateur web

SGBD

Plusieurs serveurs ralisent lapplication mtier

29

Bilan [1/2]
Intrts de lapproche client-serveur (liste non exhaustive) :
Gagner de largent (Ooops) Optimiser lachat de grosses et de petites machines en fonction du prix du march (de moins en moins vrais) Rutilisation des serveurs (un mme service peut tre utilis par plusieurs applicatifs) Rpartition de la charge plus simple, et facilit dajouter des machines pour rpondre une monte en charge Scuriser (redondance de serveurs)
30

Bilan [2/2]
Inconvnients (liste non exhaustive) :
Plus il y a de maillons, plus il y a risque de panne dun lment dans la chane (mais il y a des solutions : redondance, virtualisation) Problme de scurit, plusieurs niveaux (authentifications, gestion des droits daccs, cryptage des donnes, et risque de trous de scurit dans les APIs).

31

Questions/Rponses ?