Principe du Client Serveur

Définition du Client Serveur

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

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

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.

L’auteur

Alain Fernandez est un spécialiste de la mesure de la performance et de l’aide à la décision. Au fil de ces vingt dernières années, il a conduit et accompagné de nombreux projets d'entreprise en France et à l'International. Il est l'auteur de plusieurs livres publiés aux Éditions Eyrolles consacrés à ce thème et connexes, vendus à plusieurs dizaines de milliers d'exemplaires et régulièrement réédités.

À ce sujet, voir aussi

• EAI, Enterprise Application Integration
• SOA, Architectures Orientées Services
• Annuaires LDAP

Ressources web

• TOGAF sur la version française du site de l'Open Group

---

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

Piloter l'Entreprise Innovante...

Avez-vous déjà essayé d'instaurer la prise de décision en équipe ? Sans précautions préalables, rapidement, le consensus le plus mou qui soit vient casser les plus pures ambitions. Mais connaissez-vous la méthode SOCRIDE centrée sur les questions incontournables de Confiance et de Reconnaissance ? Rien de plus facile ! Elle est expliquée, illustrée et détaillée dans ce livre :

Les tableaux de bord du manager innovant
Une démarche en 7 étapes pour faciliter la prise de décision en équipe
Alain Fernandez
Éditeur : Eyrolles
Pages : 320 pages

Consultez la fiche technique »»»

Pour acheter ce livre :

   

Format ebook : PDF & ePub, Format Kindle

Voir aussi...

Partagez cet article...

  
(total partages cumulés > 45)