Chapitre 1 

:
Technologie des
serveurs web et
Architecture client/
serveur
Support du cours BDD / SITW M1

Dr. GHEMMAZ Wafa

Email : [email protected]

Université de Constantine 2 - Faculté NTIC - Département TLSI

2020/2021
 Table des
matières
Objectifs 3

Introduction 4

I - Différentes Architectures 6

1. Architecture 1-tier ......................................................................................................................................... 6

2. Architecture 2-tiers : Client/Serveur ........................................................................................................... 7

3. Architecture 3-tiers .................................................................................................................................... 10

4. Architecture n-tiers .................................................................................................................................... 11

II - Les applications client/serveur 13

1. Les applications client/serveur selon le schéma du " Gartner Group" ................................................. 13

2. Une autre vision des applications client-serveur .................................................................................... 15

III - Les bases de données en Client /serveur 17

IV - Médiateur 20

1. Définitions ................................................................................................................................................... 20

2. Composants du médiateur ........................................................................................................................ 20

3. Services de Middleware ............................................................................................................................ 22

4. Exemples de Middleware .......................................................................................................................... 22

Glossaire 23

Abréviations 24

Références 25
 Objectifs
A la fin de ce cours, vous serez capables de :

Identifier les différentes architectures.

Enumérer les caractéristiques de chaque architecture
Expliquer le principe de fonction de chaque architecture
Enumérer les avantages et les inconvénients de chaque architecture.
Identifier les différentes applications client/serveur.
Différencier entre un SGBD de type fichier et un SGBD de type client
/serveur.
Enumérer les composants d'un médiateur.
Expliquer les services d'un médiateur.

3
 Introduction

Une application informatique peut être découpée en trois niveaux d'abstraction (Voir la figure 1) :

(i) Présentation, (ii) Logique applicative (traitements) et (ii) Données.

1. Présentation  : La couche présentation est appelée aussi IHMp.24 > . Elle assure l'interaction de
*

l'application avec l'utilisateur. Elle gère les saisies clavier/souris, la présentation de l'information à
l'écran. L'interface doit être conviviale et ergonomique.
2. Logique applicative décrit l'ensemble des traitements à réaliser par l'application afin de répondre
aux besoins des utilisateurs. Il existe deux types de traitement :

Traitements locaux : incluant les contrôles effectués au niveau du dialogue avec IHM (
Formulaire, boutons, ...) , aide à la saisie, etc.
Traitements globaux: représentant les règles de l'application elle même " Logique métier"
(business logic).

3. Données: l’accès aux données regroupe l'ensemble des mécanismes permettant la gestion des
informations stockées par l'application. Les données sont gérées par des SGBDs  assurant les
fonctions suivantes :

La définition des données

La manipulation des données
La sécurité des données
La gestion des transactions
etc.

Figure 1 : Niveaux d'abstraction

4
- Le noyau de l'application est composé de la logique de l'affichage (présentation) et la logique des
traitements.

- Le découpage et la répartition de ce noyau permettent de distinguer les architectures suivantes :

1-tiers

2-tiers
3-tiers
n-tiers.

5
 Différentes Architectures

Différentes
Architectures I

Architecture 1-tier 6
Architecture 2-tiers : Client/Serveur 7
Architecture 3-tiers 10
Architecture n-tiers 11

1. Architecture 1-tier
 

Définition : Architecture 1-tier

Une architecture centralisée dans laquelle les trois couches (Présentation, Traitements, Données) sont
fortement liées. Ces couches s'exécutent sur la même machine ou serveur.

Dans un contexte multi-utilisateurs, deux types d'architecture mettant en œuvre des applications 1-tier
peuvent être rencontrées :

1. Des applications sur le site central (Mainframe)

2. Des applications 1-tier déployées sur des machines indépendantes (Terminaux passifs) depuis
lesquelles les utilisateurs accèdent aux mêmes données et se partagent des fichiers
physiquement localisés dans le site central.

L'architecture 1-tier est illustrée dans la figure 2.

Figure 2 : Architecture 1 tier

6
 Architecture 2-tiers : Client/Serveur

Dans cette architecture, :

Les utilisateurs se connectent aux applications situées dans le serveur central via des terminaux
passifs (Esclaves).
Les applications sont exécutées sur le serveur central qui prend en charge le gestion des
données, l'intégralité de traitements, y compris l'affichage qui doit être transmis sur des
terminaux passifs.

Avantages

Facilité d'administration.
Fiabilité grâce à la gestion centralisée des données.

Limites

Point dur : Mainframe

Interface utilisateur en mode caractère
Cohabitation des applications exploitant des données communes n'est pas fiable au delà d'un
certain nombre d'utilisateurs (application 1-tier).

Solution

la solution doit concilier :

Interface utilisateur moderne.

Découpage de l'application en plusieurs parties distinctes et coopérantes  :
- Gestion centralisée des données.
- Gestion locale de l'interface utilisateur.

Ainsi est né le concept du client-serveur ...

2. Architecture 2-tiers : Client/Serveur

Définition : Architecture Client/Serveur
L'architecture Client/Serveur (Voir la Figure 3) est une architecture réseau qui peut se réaliser sur tout
type d'architecture matérielle ( grosses ou petites machines). Cette architecture est basée sur :

L'utilisation de deux composants essentiels  : le client et le serveur (Les données sont

accessibles aux clients, localisées et traitées sur un serveur).
L'utilisation d'un mécanisme de communication entre le client et le serveur.

7
 Architecture 2-tiers : Client/Serveur

Figure 3 : Architecture Client / Serveur

Le dialogue entre le client et le serveur peut se résumer par :

Client :
- Initie le contact
- Demande un service auprès du serveur.
Serveur :
- Est à l'écoute des requêtes de clients.
- Réalise le service demandé et le renvoi au client.

Le client peut être défini comme suit

Définition : Client
Le client est un logiciel ou programme qui utilise le service offert par un serveur. Il envoi la requête au
serveur et reçoit la réponse (Résultat)

Le serveur peut être défini comme suit :

Définition : Serveur
Le serveur est un programme qui offre un service sur le réseau. Il accepte les requêtes, les traite et
renvoi les résultats aux clients demandeurs.

Remarque
Le client et le serveur ne sont identiques. Ils forment un système coopératif.
Les parties client et serveur peuvent s'exécuter sur des systèmes différents.
Les cotés client et serveur peuvent être implanter sur la même machine.
Un serveur peut répondre à plusieurs clients simultanément.

8
 Architecture 2-tiers : Client/Serveur

Définition : Application client-serveur

Une application réalisée en architecture client-serveur est un logiciel qui s'exécute en partie côté client
(à savoir du côté de l'utilisateur du logiciel) et en partie côté serveur.

Complément : Application Web client/serveur

Dans une application web  : le programme s'exécute en partie sur le navigateur de l'utilisateur (côté
client) et en partie côté serveur web.

Le clients = les navigateurs.

Le serveur = serveur web

Avantages

Le modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant un grand
niveau de fiabilité, ses principaux atouts sont :

Ressources centralisées : Étant donné que le serveur est au centre du réseau, il peut gérer des
ressources communes à tous les utilisateurs.
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 ont peu supprimer ou rajouter des clients sans
perturber le fonctionnement du réseau et sans modifications majeures

Inconvénients

Un coût élevé : dû à la technicité du serveur

Un maillon faible : le serveur est le seul maillon faible du réseau client/serveur, étant donné que
tout le réseau est architecturé autour de lui.
Poste client supporte la grande majorité des traitements applicatifs (Client lourd ou fat client)
poste client est :

fortement sollicité,
devient de plus en plus complexe
doit être mis à jour régulièrement pour répondre aux besoins des utilisateurs -> coûts et
la complexité de sa maintenance.
la conversation entre client et serveur est assez bruyante et s'adapte mal à des bandes
passantes étroites
les applications se prêtent assez mal aux fortes montées en charge car il est difficile de
modifier l'architecture initiale,

9
 Architecture 3-tiers

Solution

Afin de résoudre ces limites tout en conservant des avantages, une architecture plus évoluée, facilitant
les forts déploiements à moindre coût est primordiale : Architecture Distribuée ( architecture 3-tiers et
architecture n-tiers )

3. Architecture 3-tiers
Principe

Cette architecture est basée sur une utilisation d'un poste client simple communicant avec le serveur
par le biais d'un protocole standard dont :

1. Les données sont toujours gérées de façon centralisée,

2. La présentation est toujours prise en charge par le poste client,
3. Logique applicative est prise en charge par un serveur intermédiaire.

Répartition des traitements

L'architecture 3-tiers séparent l'application en 3 niveaux (voir figure 4) :

Niveau 1 : l'affichage et les traitements locaux (contrôles de saisie, mise en forme de

données...) sont pris en charge par le poste client .
Niveau 2 : les traitements applicatifs globaux sont pris en charge par le service applicatif :
serveur d'application.
Niveau 3 : les services de base de données sont pris en charge par le serveur de données
(SGBD).

Figure 4 : Répartition des traitements de l'architecture 3-tiers

Dans l'architecture 3-tiers, le client est léger (Thin Client). Il ne prend en charge que :

Présentation de l'application.
Partie de la logique applicative (Traitement locaux qui permettent la vérification immédiate de la
saisie et la mise en forme des données).

Le client est souvent constitué d'un simple navigateur Internet. Il ne communique qu'avec la façade
web HTTP de l'application et ne dispose d'aucune connaissance des traitements applicatifs ou de la
structure des données exploitées. Donc, les évolutions de l'application sont donc possibles sans
nécessiter de modification de la partie cliente.

Dans cette architecture, le serveur d'application nécessite une couche web appelée "Serveur Web" afin

10
 Architecture n-tiers

de communiquer avec le navigateur.

Fonctionnement

1. Le serveur web transmet au client, lui ayant fait une demande HTTP via URL , les fichiers
statiques présents sur son disque dur (pages HTML , images, fichiers CSS,...)
2. Lorsque le client demande un traitement, page dynamique, le serveur web aiguille cette
demande vers la couche applicative dans le serveur d'application.
3. Une fois le traitement effectué, le serveur d'application renvoie la page HTML au serveur web
qui se charge de la router vers le client

Avantage de l'architecture 3-tiers

L'architecture 3-tiers a corrigé les excès du client lourd :

En centralisant une grande partie de la logique applicative sur un serveur.

Le poste client, qui ne prend à sa charge que la présentation et les contrôles de saisie,
s'est trouvé soulagé et plus simple à gérer.

Évolutions transparentes pour l'utilisateur.

Inconvénient de l'architecture 3-tiers

Le serveur constitue la pierre angulaire de l'architecture et se trouve souvent fortement sollicité

Il est difficile de répartir la charge entre client et serveur.

On se retrouve confronté aux problèmes de dimensionnement serveur et de gestion de la
montée en charge.p.23 § *

Donc

Le client est soulagé, mais le serveur est fortement sollicité .

Solution

L'équilibrage de la charge entre le client et le serveur :

-> Apparition des architectures n-tiers.

4. Architecture n-tiers
L'objectif de l'architecture n-tiers est de :

Pallier les limitations des architectures 3- tiers et concevoir des applications puissantes et
simples à maintenir.
Solution :

11
 Architecture n-tiers

Distribuer plus librement la logique applicative,

Faciliter la répartition de la charge entre tous les niveaux.

Mettre en œuvre une approche objet pour offrir :

plus grande souplesse d'implémentation

faciliter la réutilisation des développements.
Capacités d'extension:

permettre l'utilisation d'interfaces utilisateurs riches

séparer nettement tous les niveaux de l'application

Attention : Nomination n-tiers

L'appellation n-tiers ne signifie pas que cette architecture met en œuvre un nombre indéterminé de
niveaux de service, alors que ces derniers sont au maximum trois.

L'architecture n-tiers qualifie la distribution de la logique applicative entre de multiples services et

non la multiplication des niveaux de service

Composant

Dans l'architecture n-tiers, la distribution de l'application est facilitée par l'utilisation des composants
métiers spécialisés et indépendants, introduits par les concepts orientés objets.

Les composants métiers sont:

réutilisables
rendent un service générique/réutilisable et clairement identifié.
capables de communiquer entre eux et peuvent donc coopérer en étant implantés sur des
machines distinctes

Dans l'architecture n-tiers, la distribution de l'application sur plusieurs serveur facilite l'intégration de
traitements existants dans les nouvelles applications.

12
 Les applications client/serveur

Les applications client

/serveur II

Les applications client/serveur selon le schéma du " Gartner Group" 13

Une autre vision des applications client-serveur 15

les applications client/serveur peuvent se différencier par la façon dont les fonctions réparties se
partagent entre le client et le serveur. En effet, plusieurs classifications des architectures client-
serveur existent à ce jour. La première, et la plus connue, est une classification issue des travaux du
Gartner Group. La seconde est plus récente et prend en compte les évolutions matérielles qui
influence le déploiement des applications client-serveur.

1. Les applications client/serveur selon le schéma

du " Gartner Group"
Gartner Group est un groupe d'étude composé d'acteurs du marché a défini 6 types d'architectures
client/serveur, en fonction du type de service déporté du cœur de l'application (Voir la figure 5):

1. Présentation distribuée
2. Présentation distante
3. Gestion distante des données
4. Traitement distribué
5. Bases de données distribuées
6. Données et traitements distribués

13
 Les applications client/serveur selon le schéma du " Gartner Group"

Figure 5 : Le schéma du Gartner Group

Présentation distribuée ;

Application appelée revamping.

Correspond à l'habillage ``graphique'' de l'affichage en mode caractères d'applications
fonctionnant sur le site central.
La classification "client-serveur'' du revamping est souvent jugée abusive, du fait que
l'intégralité des traitements originaux est conservée et que le poste client conserve une position
d'esclave par rapport au serveur.

Présentation distante :

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

Gestion distante des données :

Application Correspond au client-serveur de données (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 SGBDp.24 > centralisé.
*

Traitement distribué :

Application 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é.

Bases 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

14
 Une autre vision des applications client-serveur

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

Un modèle est très puissant et tire partie de la notion de composants réutilisables et

distribuables pour répartir au mieux la charge entre client et serveur.
L'architecture la plus complexe à mettre en œuvre.

Remarque
Les différents modèles du client/serveur proposés par le groupe Gartner sont indépendants et
combinables.

2. Une autre vision des applications client-serveur

Dans cette classification, trois grandes catégories sont proposées :

client-serveur de présentation.
client-serveur de données.
client-serveur à trois niveaux.

client-serveur de présentation.

La logique de présentation est placée sur le poste client et les traitements sont placés sur le serveur.

client-serveur de données (fat client- thin server)

La couche de présentation et la logique d'application sont à la charge du client alors que la gestion des
données est assurée par le serveur. Cette architecture est actuellement la plus répandue et la mieux
maîtrisée.

client-serveur à trois niveaux.

La logique et le traitement de l'application sont placés dans un serveur spécialisé. Le client conserve
néanmoins la présentation incluant le dialogue avec l'utilisateur et plus généralement l'interface homme-
machine. La communication entre le client et le serveur d'applications et entre le serveur d'applications
et le serveur de données s'établissent par l'intermédiaire d'une couche médiateur (middleware) (Voir la
section IV:Médiateur )

Remarque
Architecture 2-tiers = client/serveur de première génération = Client /serveur de données.

Fondamental
Tout simplement, une architecture 2-tiers est une architecture dont :

15
Une autre vision des applications client-serveur

Le client s'occupe de la présentation et la logique applicative.

Le serveur s'occupe de la gestion des données.

16
 Les bases de données en Client /serveur

Les bases de données

en Client /serveur III

Un SGBD est un ensemble de processus et de tâches qui supportent l'exécution du code du SGBD
pour satisfaire les commandes des utilisateurs. Depuis le milieu des années 80, les SGBD fonctionnent
selon l'architecture client-serveur.

L'architecture client-serveur inclut le noyau d'un SGBD appelé DMCS (Description Manipulation and
Control Sub-system), qui fonctionne en mode serveur. Autour de ce serveur s'articulent des processus
attachés aux utilisateurs supportant les outils et les interfaces externes.

Dans le monde des SGBDs, deux grandes techniques de bases de données s'affrontent :

Celle à base de fichiers plats structurés nécessitant un moteur sur chaque poste (middleware
ou database engine) et,
Celle à base de serveur de données.

La différence fondamentale est perçue lors de l’exécution des ordres SQL. Elle se reflète au niveau de
congestionp.23 § du trafic réseau.
*

Dans un SGBD de type fichier, la requête est exécutée d'une manière globale.
Dans un SGBD de type Client/serveur, la requête est exécutée sur le serveur.

Exemple
Pour comprendre la différence, voici un exemple simple. Une table de nom CLIENT contient 50 000
enregistrements de 200 octets chacun. La requête est la suivante :

1 SELECT * FROM Etudiant WHERE (Nom_Etud like ‘%M');

Dans un SGBD de type fichier, voici le flot de données :

Le PC rapatrie depuis le serveur le fichier contenant la table CLIENT (Soit au minimum 50 000 x
200 octets (sans compter les index et le reste )
Le PC traite localement la requête
Le PC affiche le résultat (soit par exemple 5 lignes de 200 octets)

Dans un SGBD de type C/S, voici le flot de données :

Le PC envoie au serveur le fichier texte de la requête (soit environ 50 octets)

17
 Les bases de données en Client /serveur

Le serveur exécute la requête sur la table CLIENT

Le serveur renvoie au PC les données répondant à la requête (soit nos 5 lignes de 200 octets)
Le PC affiche le résultat.

Bilan de ces opérations :

SGBD fichier : environ 10 000 000 octets ont été véhiculé sur le réseau
SGBD C/S : environ 1 050 octets ont été véhiculés sur le réseau

Rappel
Dans une architecture client/serveur, un applicatif est constitué de trois parties :

Interface utilisateur.
Traitements.
Gestion des données.

Le langage DL (Data Language) est le langage standard d'accès au SGBD, supporté par un protocole
de niveau application pour le fonctionnement en mode réparti, appelé protocole d'accès aux données
distantes (Remote Data Access RDA). Ce protocole est aujourd'hui en bonne voie de standardisation.
Il est d'ailleurs complété par un protocole de gestion de transactions réparties.

Dans l'architecture client/serveur :

le serveur de bases de données prend en charge les tâches suivantes :

La gestion d'une mémoire cache

L'exécution de requêtes exprimées en SQL.
La gestion des transactions.
La sécurité des données.

Le client :

Doit ouvrir une connexion pour pouvoir effectuer une demande des services du serveur.
Il peut ouvrir plusieurs connections simultanées sur plusieurs serveurs.
Exécute l'interface utilisateur et la logique de traitements.

Communication entre le client et le serveur :

Puisque l'application doit pouvoir se connecter à divers serveurs de façon transparente,

le langage de communication SQL doit être compatible avec la syntaxe SQL de chaque
serveur .
Les dialectes SQL sont nombreux et parfois source d'incompatibilité. La seule façon de
permettre une communication plus large est d'adopter un langage SQL standardisé de
communication.
Une couche fonctionnelle du client traduit les requêtes du dialecte SQL client en SQL
normalisé.
La requête transformée est envoyée au serveur.

18
 Les bases de données en Client /serveur

Le serveur traduit la requête dans le dialecte SQL-serveur et l'exécute.

Le résultat de la requête suit le chemin inverse.

Le langage de communication normalisé le plus fréquent est :

l'ODBC (Open DataBase Connectivity) de Microsoft.

IDAPI (Integrated Database Application Programming Interface) de Borland.

19
 Médiateur

Médiateur
IV
Définitions 20
Composants du médiateur 20
Services de Middleware 22
Exemples de Middleware 22

1. Définitions
Un médiateur peut être défini comme suit :

Définition : Médiateur (Middleware)

Le médiateur est un logiciel qui permet aux composants d'une application d'interopérer à travers des
réseaux informatiques, en dépit des différences de protocoles de communication, d'architectures
systèmes, de systèmes d'exploitation, de bases de données, etc

Définition : Middleware selon Gartner Group

Un middleware est défini comme une interface de communication universelle entre processus.

L'objectif principal de 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.

2. Composants du médiateur

Tous les produits médiateurs ont les mêmes composants de base p.25 ¤ (Voir la figure 6):
*

1. Les outils de développement qui tendent de plus en plus à être intégrés dans des Ateliers de
Génie Logiciel (AGL) ;
2. L'environnement d'exécution composé de certains services de base (comme le nommage ou la
sécurité), de services de communication (par l'intermédiaire d'API) et les services d'applications
(telles que l'accès aux bases de données avec SQL, la gestion du courrier électronique, la
gestion et l'exécution des transactions et la gestion des documents) ;
3. lLes outils d'administration et de déploiement des applications créées.

20
 Composants du médiateur

Figure 6 : Composants du médiateur

Si on se concentre sur les couches médiateur d'accès au système de gestion de bases de données
(SGBD), une nouvelle classification est possiblep.25 ¤ . Le médiateur est alors décomposé en trois
*

types : propriétaire, éditeur et indépendant (Voir la figure 7)

Les médiateur propriétaires sont construits par le fabriquant du SGBD et ne sont utilisables que
dans un environnement fixe.
Les médiateurs éditeurs sont avant tout des interfaces applicatives de communication avec les
SGBD qui s'appuient sur des protocoles d'accès et des formats définis par le constructeur du
SGBD.
Les médiateur indépendants sont fournis par un éditeur tiers différent de celui du SGBD et des
outils de développement. Ils permettent ainsi des accès à des multibases et sont plus ou moins
compatibles avec des outils de développement du marché.

Figure 7 :Accès aux systèmes de gestion de bases de données par médiateur

21
 Services de Middleware

3. Services de Middleware
Un médiateur est capable de rendre les services suivants :

Conversion : Service utilisé pour la communication entre machines mettant en œuvre des
formats de données différents.
Adressage : Permet d'identifier la machine serveur sur laquelle est localisé le service demandé
afin d'en déduire le chemin d'accès.
Sécurité : Permet de garantir la confidentialité et la sécurité des données à l'aide de
mécanismes d'authentification et de chiffrement des informations.
Communication : Permet la transmission des messages entre les deux systèmes sans
altération. le service de communication doit gérer :

connexion au serveur
préparation de l'exécution des requêtes
récupération des résultats
déconnexion.

4. Exemples de Middleware
SQL*Net

SQL*Net : Interface permettant de faire dialoguer une application cliente avec une base de données
Oracle.

Passage requête SQL, Appel procédures

indépendance vis à vis du réseau (topologie, protocole) et des OS

multi-thread = plusieurs connexions dans un seul process Oracle Serveur

journalisation et traçage, gestion des connexions avortées, ...

ODBC

Interface standardisée isolant le client du serveur de données. C'est l'implémentation par Microsoft du
CLI (Call Level Interface) du SQL Access Group Elle se compose de :

gestionnaire de driver standardisé,

API s'interfaçant avec l'application cliente.

Remarque
Le choix d'un middleware est déterminant en matière d'architecture, l 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.

22
 Glossaire

Glossaire
Congestion

La congestion d'un réseau informatique est la condition dans laquelle une augmentation du trafic
(flux) provoque un ralentissement global de celui-ci

Montée en charge

La montée en charge est un phénomène par lequel le trafic d'un site web ou le volume d'informations
demandé à un serveur (ou des serveurs) augmente très fortement et de manière brutale.

23
 Signification des abréviations

Abréviations
IHM : Interface Homme Machine

SGBD : Système de Gestion des Bases de Données

24
 Références

Références
[Réf1]
M. Tamer Özsu & Patrick Valduriez."Principles of Distributed Database Systems". Novembre 2010.

[Réf2]
Bachtarzi C, Support de cours " Bases de Données Avancées" Matser1, université de Constantine2.

[Réf3]
https://www.toolsqa.com/client-server/client-server-architecture-and-http-protocol/

[Réf4] Gardarin G., Gardarin O., Le Client-Serveur, 470 pages, Éditions Eyrolles, 1997.

[Réf5] Rymer, J., The Muddle in the Middle, in: Byte, April 1996, S. 67–70

[Réf6]
Anas ABOU EL KALAM, support de cours "Technologie des applications client-serveur".

25