Principe du Client Serveur

22 mars 2017  Par         Partagez

Définition du Client Serveur

Middleware messagesLe 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'autre extrémité, les postes de travail des utilisateurs, appelés "clients", sont reliés grâce au réseau à la machine ou au groupe de machines "serveur". Ils utilisent directement, et selon leurs besoins,les données et/ou les traitements partagés, tous stockés sur les machines dites "serveur".

Une application dite "répartie" se décompose en trois entités :
1. Les données communes à tous les postes
2. Les traitements communs à tous les postes
3. Les traitements spécifiques à chacun des postes tels que l’interface utilisateur. Voilà pour le principe dans sa version la plus simple.

Historique du client/Serveur

Architecture 2-tiers

À l'origine, les toutes premières architectures de type client/serveur proposaient de stocker sur le serveur uniquement les données communes à tous les clients à l'aide d’un SGBD. Tous les traitements sont résidents sur les postes clients. Les clients accèdent aux données communes en utilisant simplement des requêtes SQL. Il s'agit d'une architecture à deux niveaux : 2-tiers.

CLient/Serveur 2-tiers

Légende : Client/Serveur architecture à deux niveaux, 2-tiers source : Le bon usage des technologies

Ce modèle d'architecture assez simple a rapidement évolué vers un stockage de traitements standards afin de mieux structurer le développement d'applications. Les procédures stockées traitées par le SGDB remplissent cet office. Les demandes du client sont alors plus simples et mieux structurées. Il était alors temps de pousser plus avant ce type d'architecture pour mieux isoler les données communes, les traitements communs et les traitements spécifiques à chacun des postes. Les architectures à 3 niveaux de type 3-tiers étaient nées.

Architecture 3-tiers

Si les architectures à 2 niveaux étaient suffisantes pour des applications réparties auprès de quelques dizaines d’utilisateurs, les besoins en matière d'e-business et, plus généralement, le déploiement des applications sur l'Internet avec un nombre bien plus important de clients exigent des architectures multi-tiers. Voir notamment l'article dédié au client léger ainsi que l'article dédié au Middleware

CLient/Serveur 3-tiers

Légende : Client/Serveur architecture à trois niveaux, 3-tiers source : Le bon usage des technologies

La plupart des ressources communes sont centralisées et partagées. Les postes utilisateurs n'ont besoin pour fonctionner que d’un simple navigateur internet. Les scripts, applets java et autres composants logiciels, et les architectures de type Ajax dotent les postes clients des indispensables fonctions pour une utilisation optimale des applications du système d'information. Cette manière de procéder est incontournable pour assurer le déploiement de l’application et sa maintenance.

La verticalité n'est pas la panacée

Dans un système d'information, les applications ne sont pas que serveurs, elles sont aussi clientes d'autres applications. Bref la modélisation hiérarchisée n'est pas vraiment la meilleure représentation de la réalité. L’e-business et le déploiement des applications distribuées sur l’Internet ont quasiment mis un terme aux approches exclusivement verticales du passé. Avec les architectures multi-niveaux, on parle plutôt de fournisseurs et de consommateurs de services dans une dimension transversale et selon une approche multi-couches. Voir à ce sujet l'article à propos de l'urbanisation des systèmes ainsi que les SOA et les Architectures Orientées Services.

Architecture et pilotage

Il est intéressant, voire prudent, ne pas dissocier les questions de définition d'architecture de celle de pilotage du système d'information. Le thème de la Gouvernance du système d'information s'impose. Voir aussi, à titre d'information, le framework TOGAF® (The Open Group Architecture Framework), soit un jeu d'outils, de méthode, un vocabulaire standardisé et de bonnes pratiques pour une conception centrée pilotage.

À ce sujet, voir aussi

Ressources web



Lecture recommandée

TOGAF en pratique
Modèles d'architecture d'entreprise
de Philippe Desfray, Gilbert Raymond Dunod
Guide pratique francophone du Framework de l'Open Group

Dispo chez :
www.amazon.fr

Architecture et transformation de l'entreprise et du SI
La méthode TOGAF en pratique
de Romain Hennion, Alison Hawksworth, Hubert Tournier Eyrolles

Dispo chez :
www.amazon.fr


Partagez cet article...

Envoyer le lien de cet article par e-mail   
(total partages cumulés > 125)

Si vous souhaitez partager votre point de vue sur cet article, utilisez désormais Twitter ou votre réseau social favori.

La reproduction ou la traduction totale ou partielle de ce texte, images et documents est formellement interdite. Voir ici les conditions pour publier un extrait sur votre site ou blog. Ce texte et les images et documents qu'il contient est déposé auprès de l'IDDN

Suivez aussi les news du portail sur Twitter et rejoignez-nous sur Facebook

Twitter    Facebook

Excel ® est une marque déposée de Microsoft Corp ®
Gimsi ® est une marque déposée de Alain Fernandez


Piloter.org le portail francophone du pilotage de la performance
Copyright : Alain FERNANDEZ ©1998-2018 Tous droits réservés Mentions légales


Le Portail du Manager Innovant
Le portail du Manager Efficace Piloter.org