Introduction aux

Architecture
Client/Serveur
 Introduction aux Architecture
Client/Serveur
Contenu Objectifs spécifiques
– Historique des architectures
client-serveur ;
– la typologie des architectures – de proposer une
client-serveur ; architecture client-serveur
– la conception d'une approprié pour résoudre un
architecture client-serveur problème ;
– la présentation du modèle – de justifier les différents
client-serveur à deux niveaux ; équipements qu'il faut dans
– la présentation du modèle une architecture client-
client-serveur à trois niveaux serveur ;
– le middleware et son – d'évaluer le coût d'une
importance architecture client-serveur.
Présentation du
Modèle
Client/Serveur
Partie 1
Introduction
• Ces vingt dernières années ont vues une
évolution majeure des systèmes d'information,
à savoir le passage d'une architecture centralisée
à travers de grosses machines (des Mainframe)
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 évolution a été possible essentiellement

grâce à 2 facteurs qui sont :
o la baisse des prix de l'informatique personnelle
o le développement des réseaux.
Un peu d’histoire
Le client serveur est l'état actuel de l'évolution des architectures
informatiques :
• Avant les Années 80 : Système Centralisé (ordinateur central
avec des terminaux passifs de type texte).

• Les Années 80 : Développement du transactionnel et apparition

des SGBD non-propriétaires (indépendants des constructeurs) -
SGBD relationnel + SQL

• Les Années 90 : Développement des réseaux. L'efficacité et le

partage des systèmes d'informations doivent être optimum
(concurrence économique, etc.).
Le client-serveur se situe dans ce besoin de centralisation
(information cohérente, non redondante et accessible) et de
décentralisation (conserver la puissance et l'interface des micro-
ordinateurs)
Le modèle Multi-Utilisateur
centralisé
Serveur = Ordinateur central qui effectue tous les
traitements
Client = Terminal sans puissance locale de
traitement

E CLIENT
C INTELLIGENCE
R
A
N SERVEUR
Le modèle réseau local
traditionnel
Serveur = Gère le réseau et stocke les bases de
données sans les gérées.
Client = Les stations effectuent tous les
traitements

E CLIENT
C
R
A INTELLIGENCE
N SERVEUR
Le modèle Client-
Serveur
• Répartition judicieuse de la puissance de
traitement entre le serveur et les différentes
stations interconnectées.

E CLIENT
C INTELLIGENCE
R
A INTELLIGENCE
N SERVEUR
Pourquoi le Client-
Serveur ?
• Contraintes sur l'entreprise
• Contraintes externes : compétitivité, exigence de la clientèle, produire
mieux et plus vite, etc.
• Contraintes internes : Compression des budgets (limitation des
ressources), manque de temps, absorption des technologies nouvelles
• Mieux maîtriser le système d'information
• Une architecture ouverte C/S bâtie autour d'un moteur relationnel
améliore cette maîtrise : présentation naturelle des données, meilleure
productivité des développeurs avec le SQL
• Prise en compte des évolutions technologiques
Aspect ouvert et modulaire du Client-serveur.
Mais….
• Réduire les coûts ?
L'architecture C/S coûte plus cher qu'une architecture
centralisée :
• Postes de travail
• Réseau local
• Formation des développeurs (SGBD, Middleware, l'objet et les interfaces
graphiques)
• Techniciens de maintenance réseau et PC
Architecture Client/serveur:
Définition
• 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.
Client-Serveur: Définition
• CLIENT
Processus qui demande l'exécution d'une
opération par l'envoi d'une demande.
• SERVEUR
Processus qui exécute la demande du
client et qui transmet la réponse.
• REQUÊTE (Request)
Message transmis par le client.
• REPONSE (Reply)
Message transmis par le serveur.
Les principes généraux Huit

• 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 plates-formes
matérielles et logicielles.
Principes généraux (suite)
• 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.
Découpage des applications
client-serveur
• On reconnaît traditionnellement dans une
application 3 modules :
o l'interface utilisateur
o la logique des traitements
o la gestion des données.
DONNEES

TRAITEMENT

PRESENTATION
Découpage des applications
client-serveur
La répartition de ces 3 modules variera
entre le client et le serveur et sera
fonction :

• Des types d’architecture retenu

• De la capacité des machines

• De la capacité du réseau
Les différents modèles de client-
serveur

• le client-serveur de donnée.
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 et
qui est utilisé par tous les grands SGBD :
La base de donnée avec tous ses outils
(maintenance, sauvegarde 0) 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ée 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
Les différents modèles de client-
serveur
• 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.

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

Ces traitements peuvent être réalisés par des programmes installés

sur des serveurs mais également intégrés dans des bases de données
(triggers, procédures stockées), dans ce cas, la partie donnée et
traitement sont intégrées.

• Cette synthèse s'illustre par un schéma du Gartner Group qui

représente les différents modèles ainsi que la répartition des tâches
entre serveur et client
Une synthèse des
différents cas
 conclusion
Modèle client/serveur se
caractérise donc par :
• Des ressources
indépendantes,
• L'importance du dialogue
entre le client et le serveur,
• La place centrale du réseau.
Ressources
indépendantes
• Hébergement
• Toute plate-forme matérielle peut devenir serveur
• Tout système d’exploitation peut héberger un
service
• Toutes configurations matérielles ou logicielles
envisageables
• Localisation
• Les ressources peuvent être n’importe où sur le
réseau
• Architecture plus modulaire
• Administration plus complexe
• Utilisation
• Les ressources ne sont pas dédiées à une utilisation
particulière
• Partage des ressources facilité
Importance du
Dialogue
• Importance accrue des communications
• Le réseau devient «le centre de gravité du SI»
• Le réseau devient «la clé de voûte» du modèle
client-serveur

• Complexification du dialogue
• Dialogue entre systèmes hétérogènes
• Dialogue à distance

• Nécessité de couches intermédiaires

• Pour gérer la complexité
• Pour rendre «transparent» le dialogue
Les protocoles
L'importance du réseau les placent au premier
plan :

• Définissent le fonctionnement des réseaux

• Couvrent 3 types de services

• les services d’application
• les services de transport
• les services de liaison

• Respectent le modèle OSI (interconnexion

des systèmes ouverts) défini par l’ISO
Les différentes
architectures
Client/serveur
Partie 2
Architecture 1 tiers
• Les 3 couches applicatives s‘ exécutent sur
la même machine
• On parle d'informatique centralisée :
• Contexte multi-utilisateurs dans le cadre
d'un site central (mainframe)
L’architecture 2 tiers
• Présentation et traitements sont sur le client
• Les données sur le serveur
• Contexte multi-utilisateurs avec accès aux
données centralisées (middleware)
L’architecture 2 tiers

Encore appelée client-serveur de première

génération ou client-serveur de données, le
poste client se contente de déléguer la gestion des
données à un service spécialisé. Le cas typique de
cette architecture est une application de gestion
fonctionnant sous Windows ou Linux et exploitant
un SGBD centralisé.

Ce type d'application permet de tirer partie de la

puissance des ordinateurs déployés en réseau
pour fournir à l'utilisateur une interface riche, tout
en garantissant la cohérence des données, qui
restent gérées de façon centralisée.
L’architecture 2 tiers
(suite)
• 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. Le dialogue entre
client et serveur se résume donc à l'envoi de
requêtes et au retour des données correspondant
aux requêtes.
L’architecture 2 tiers
(suite)
• Cet échange de messages transite à travers le
réseau reliant les deux machines. Il met en œuvre
des mécanismes relativement complexes qui sont,
en général, pris en charge par un middleware.
• L'expérience a démontré qu'il était coûteux et
contraignant de vouloir faire porter l'ensemble des
traitements applicatifs par le poste client. On en
arrive aujourd'hui à ce que l'on appelle le client
lourd, avec un certain nombre d'inconvénients
• on ne peut pas soulager la charge du poste client,
qui supporte la grande majorité des traitements
applicatifs,
L’architecture 2 tiers
(suite)
• le poste client est fortement sollicité, il devient de
plus en plus complexe et doit être mis à jour
régulièrement pour répondre aux besoins des
utilisateurs,
• les applications se prêtent assez mal aux fortes
montées en charge car il est difficile de modifier
l'architecture initiale,
• la relation étroite qui existe entre le
programme client et l'organisation de la partie
serveur complique les évolutions de cette
dernière,
• ce type d'architecture est grandement rigidifié
par les coûts et la complexité de sa
maintenance.
L’architecture 2 tiers
(suite)
• Malgré tout, l'architecture deux tiers présente de
nombreux avantages qui lui permettent de présenter un
bilan globalement positif :

•elle permet l'utilisation d'une interface utilisateur

riche,
• elle a permis l'appropriation des applications par
l'utilisateur,
•elle a introduit la notion d'interopérabilité.

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 coût. La réponse est apportée par les
architectures distribuées
L'architecture 3 tiers
• 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
L'architecture 3 tiers
• Les limites de l'architecture deux tiers
proviennent en grande partie de la nature du
client utilisé :

•le frontal est complexe et non standard (même

s'il s'agit presque toujours d'un PC sous Windows),

•le middleware entre client et serveur n'est pas

standard (dépend de la plate-forme, du SGBD ).
L'architecture 3 tiers

• La solution résiderait donc dans l'utilisation d'un

poste client simple communicant avec le serveur par
le biais d'un protocole standard. Dans ce but,
l'architecture trois tiers applique les principes
suivants :

•les données sont toujours gérées de façon

centralisée,
•la présentation est toujours prise en charge par
le poste client,
•la logique applicative est prise en charge par un
serveur intermédiaire.
L'architecture 3 tiers
• Cette architecture trois tiers, également appelée
client-serveur de deuxième génération ou client-
serveur distribué sépare l'application en 3 niveaux
de services distincts, conformes au principe
précédent :
Architecture 3 tiers
•premier niveau l'affichage et les
traitements locaux (contrôles de saisie, mise en
forme de données... ) sont pris en charge par le
poste client,
•deuxième niveau les traitements applicatifs
globaux sont pris en charge par le service
applicatif,
•troisième niveau les services de base de
données sont pris en charge par un SGBD
L'architecture 3 tiers
• Tous ces niveaux étant indépendants, ils peuvent être
implantés sur des machines différentes, de ce fait :
•le poste client ne supporte plus l'ensemble des
traitements, il est moins sollicité et peut être moins
évolué, donc moins coûteux,
•les ressources présentes sur le réseau sont mieux
exploitées, puisque les traitements applicatifs
peuvent être partagés ou regroupés (le serveur
d'application peut s'exécuter sur la même machine que le
SGBD),
•la fiabilité et les performances de certains traitements se
trouvent améliorées par leur centralisation,
• il est relativement simple de faire face à une forte
montée en charge, en renforçant le service applicatif.
L'architecture 3 tiers
• Dans l'architecture trois tiers, le poste client est
communément appelé client léger ou Thin Client, par
opposition au client lourd des architectures deux tiers. Il ne
prend en charge que la présentation de l'application avec,
éventuellement, une partie de logique applicative permettant
une vérification immédiate de la saisie et la mise en forme des
données.

• le serveur de traitement constitue la pierre angulaire de

l'architecture et se trouve souvent fortement sollicité. Dans ce
type d'architecture, il est difficile de répartir la charge entre
client et serveur. On se retrouve confronté aux épineux
problèmes de dimensionnement serveur et de gestion de la
montée en charge rappelant l'époque des mainframes.
• De plus, les solutions mises en œuvre sont relativement
complexes à maintenir et la gestion des sessions est
compliquée.
Architecture n tiers
• 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
 L'architecture n-tiers
• L'architecture n-tiers a été pensée pour pallier aux
limitations des 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 architectures trois tiers met en œuvre une

approche objet pour offrir une plus grande souplesse
d'implémentation et faciliter la réutilisation des
développements. Théoriquement, ce type d'architecture
supprime tous les inconvénients des architectures
précédentes :
•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
Architecture n tiers
• L'appellation ''n-tiers'' pourrait faire penser que cette architecture met en
œuvre un nombre indéterminé de niveaux de service, alors que ces
derniers sont au maximum trois (les trois niveaux d'une application
informatique). En fait, l'architecture n-tiers qualifie la distribution d'application
entre de multiples services et non la multiplication des niveaux de service.

• Cette distribution est facilitée par l'utilisation de composants ''métier'',

spécialisés et indépendants, introduits par les concepts orientés objets
(langages de programmation et middleware). Elle permet de tirer pleinement
partie de la notion de composants métiers réutilisables.

• Ces composants rendent un service si possible générique et clairement

identifié. Ils sont capables de communiquer entre eux et peuvent donc
coopérer en étant implantés sur des machines distinctes.

• La distribution des services applicatifs facilite aussi l'intégration de

traitements existants dans les nouvelles applications. On peut ainsi envisager
de connecter un programme de prise de commande existant sur le site
central de l'entreprise à une application distribuée en utilisant un
middleware adapté.
Middleware
Partie 3
Définition:
• Georges GARDARIN définit le middleware
comme :
"L'ensemble des services logiciels construits
au-dessus d'un protocole de transport afin
de permettre l'échange de requêtes et des
réponses associées entre client et serveur
de manière transparente."
• D'autres auteurs intègrent les couches
Application(s)
réseaux dans le middleware. Serveur(s)
MIDDLEWARE
RESEAU
Middleware: définition
(suite)
• Une triple transparence :
• Transparence aux réseaux. Tous les types de
réseaux doivent être supportés.
• Transparence aux serveurs. Tous le SGBD
(avec leur SQL souvent différents) doivent être
accessibles.
• Transparence aux langages. Les fonctions
appelées doivent être aussi indépendantes
que possible des langages.
Pourquoi le
Middleware ?
La complexité du dialogue client/serveur est à
l'origine du middleware. Complexité due à la
présence :
• Des Systèmes hétérogènes
• Des Systèmes propriétaires
• Du dialogue à distance
Le Middleware : à quoi
ça sert ?
• Avantages
• Offre des services de «haut niveau» aux
applications
• Rend portable les applications (avec certaines
limites)
• Prend en charge les protocoles de conversion
de caractères et d’établissement de sessions
entre clients et serveurs hétérogènes
• C’est la «glue» qui rend possible le client-
serveur
• C’est la boîte à outils pour le
développement des applications.
L'architecture type du
Middleware
• L'IPC (Inter Processus Communication) est
l'autre nom du middleware.
• L'IPC se compose :
• L'interface API (Application
Programming Interface) -
Interface de programmation
au niveau applicatif.
Interface entre un
programme et le système qui
propose un ensemble de
fonctions standards pour
L'architecture type du
Middleware
• L'interface FAP (Format And
Protocols) - Protocoles de
communication et format des
données.
Ce module assure :
• la synchronisation entre client et
serveur,
• la reconnaissance du format des
données échangées
• l'appel aux fonctions de transport
du réseau.
L'architecture type du
Middleware
Client serveur et
modèle OSI
Couche 7 - Application API
Couche 6 - Présentation
FAP
Couche 5 - Session
Couche 4 - Transport Par Ex : TCP
Couche 3 - Réseau Par Ex : IP
Couche 2 - Liaison Par Ex : CSMA/CD
Couche 1 - Physique Par Ex : Paire torsadée
Client serveur et
modèle OSI
Le dialogue avec
session
Client Réseau Serveur

Application
Prise en compte de demande
Demande de connexion et création d'un contexte
Requête
Résultats
Synchronisation Exécution des requêtes
Requête et gestion de la
synchronisation
Résultats
Synchronisation
Déconnexion Fin du contexte
Le dialogue avec
session
• Dans les dialogues avec session
(ou avec connexion). Les échanges
d’informations sont subordonnés à
l’ouverture d’une «session» par le
client vers le serveur.
• IPC avec connexion :
• Protocole APPC de l’architecture
réseau SNA d’IBM (Application
Programm to Progamm Application)
• Protocole RDA, basé sur SQL défini
par l’ISO (Remote Data Access)
Le dialogue avec
session
• Si le serveur accepte la connexion, il crée un contexte
propre à chaque application cliente connectée.
• Client et serveur s'échangent des requêtes, des
réponses et des points de synchronisation.
• Le client a la responsabilité de conduire les phases
successives de l'échange
• Le serveur a la responsabilité de garantir le contexte
perçu par le client
• Les ordres SQL "COMMIT" ou "ROLL BACK" sont des
exemples de points de synchronisation.
• A la suite d'une requête le :
• COMMIT confirmera la transaction,
• ROLL BACK l'annulera.
• Le serveur mettra réellement à jour la base de données
qu'à la suite de ces ordres de synchronisation (avant
cela les transactions s'appliquent dans le "contexte")
 Le dialogue sans
connexion : les RPC
Client Réseau Serveur

Application
Requête
Appel de la procédure Prise en compte
distante de la demande

Réponse
Réception du résultat Exécution de la
poursuite de l'exécution procédure
Le dialogue sans
connexion : les RPC
• Les dialogues sans connexion avec appels
de procédures distantes (RPC - Remote
Procedure Call).
Le processus client invoque une procédure
distante située sur le serveur.
La requête contient tous les éléments
nécessaires au serveur (nom de la
procédure, paramètres, identité du
processus).
Le message en retour contient toute la
réponse.
L’offre Middleware»
Les offres Middleware sont variées :
• Offres propriétaires,
• Offres d'accès universel aux bases,
• Offres pour des accès multibases

• Les offres propriétaires aux SGBDR :

• ORACLE avec Sql*Net
• SYBASE avec Db-lib
L’offre Middleware»
• Les offres multi-clients, multi-serveurs. Elles
permettent aux clients d'accéder en toute
transparence à plusieurs bases
hétérogènes, situées éventuellement sur
des serveurs différents.
• SEQUELINK : Techgnosis propose une API sur
presque toutes les architectures clientes ou
serveurs
• EDA/SQL : Information Builders propose
d’accéder à tout type de bases de données à
partir de plates-formes hétérogènes
L’offre Middleware»
• DRDA (Distributed Relational Database
Architecture) d'IBM pour fédérer les bases IBM
(DB2) et non IBM.
• IDAPI (Integrated Database Application
Programming Interface) de Borland en
collaboration avec Novell et IBM.

Note : Évidemment l'accès multibases

permet également l'accès monobase.
L’offre Middleware»
• L’accès universel aux données pour les
clients
• ODBC de Microsoft : accès standardisé aux
principales bases de données du marché
(drivers)
• IDAPI de Borland et Novell
Le Standard ODBC
• ODBC (Open DataBase Connectectivity) est
présenté en 1992 par Microsoft comme une
interface universelle aux bases de données.
• Il ne s'agit pas d'un middleware à
proprement parlé mais d'une API que l'on
utilise en lieu et place des API des éditeurs
de SGBDR
Le Standard ODBC
Exemple : De Sybase à ODBC
Application Application
API : db-lib API : ODBC
(lié au SE -
db-lib pour OS2,
DataBase Driver
pour Windows, etc)
FAP : net-lib FAP : net-lib
(lié au SE et au (lié au SE et au
réseau) réseau)
Réseau Réseau
Le Standard ODBC