Client-serveur

Client/serveur désigne un mode de communication entre des programmes informatiques :

un programme tient le rôle de « serveur » : il est conçu de façon à pouvoir répondre à des requêtes extérieures ;
les autres programmes (« clients ») contactent le serveur pour lui soumettre des demandes, et attendent sa réponse.

Un serveur peut fournir un ou plusieurs services, et ce, à un ou plusieurs clients. Le programme serveur et le ou les programmes clients peuvent se trouver sur la même machine ou sur des machines différentes, reliées entre elles par réseau.

Le système X Window est un exemple typique d'architecture client-serveur: le programme X Window est le serveur ; il fournit aux autres applications des services d'affichage graphique, tels que création et déplacement de fenêtres, gestion des boutons, des zones de saisie et des listes déroulantes... Les applications clientes peuvent alors totalement se décharger des tâches d'affichage.

Le fonctionnement des sites Internet correspond également à une architecture de type client/serveur : chaque site est hébergé sur un serveur Web ; les internautes qui consultent le site utilisent un programme client pour envoyer des requêtes au serveur : le butineur (browser) internet.

Le client/serveur est aussi très courant dans les applications où de nombreux utilisateurs doivent accéder à une même base de données. On distingue, dans ces applications, plusieurs couches logicielles :

La couche présentation (c'est-à-dire client) est la partie du logiciel que l'on trouve du côté de l'utilisateur final. Comme son nom l'indique, cette partie ne contient que l'interface utilisateur (le plus souvent, une interface graphique sous X Window, MS Windows ou Mac OS)
La couche de gestion des données (le serveur), qui consiste en une base de données ou tout système de stockage des données.
La couche logique qui est le cœur même de l'application ; elle fait le lien entre le client et le serveur, et forme ce que l'on appelle le serveur d'application.

Ce type d'architectures en trois couches est appelé architecture 3-tiers.

Cependant, la couche logique n'est pas indispensable: en effet, elle peut très bien être déplacée vers le serveur (sous forme, par exemple, de procédures stockées dans la base de données), ou vers le client (toute l'application se trouvant alors sur le poste client, on ne fait plus que demander des données au serveur, via par exemple ODBC ou SQLNet...). Une telle architecture en deux couches est appelée 2-tiers.

Des architectures n-tiers sont bien entendu possibles, en combinant un ou plusieurs serveurs d'application (offrant chacun des services distincts) et une ou plusieurs bases de données.

L'emplacement physique des différentes couches composant une telle application est tout à fait variable.
Dans une application 3-tiers, par exemple, les trois couches peuvent être :

trois programmes distincts fonctionnant sur une même machine
le client sur une machine, les deux autres couches sur une deuxième machine
trois programmes fonctionnant chacun sur une machine distincte.

Une telle architecture est idéale lorsque l'on a un grand nombre de personnes utilisant la même application pour accéder aux mêmes données : un serveur d'application et une base de données permettent alors de desservir plusieurs dizaines, voire plusieurs centaines de machines clientes.

L'avantage théorique des applications client-serveur est la possibilité de remplacer une couche indépendamment des autres : pouvoir migrer par exemple une partie cliente de Visual Basic vers PowerBuilder sans avoir à modifier ni la base de données, ni le serveur d'application. Mais en pratique, tout n'est pas si rose : les couches sont en réalité rarement totalement indépendantes les unes des autres, et la modification d'une couche entraîne très souvent des modifications dans les autres. D'autre part, la complexité de l'application augmente propotionnellement au nombre de couches à développer et fiabiliser. Enfin, la maintenance de telles applications est plus complexe :

lorsqu'une erreur survient, il n'est pas toujours évident de déterminer la couche fautive.
lorsqu'une nouvelle version de l'application doit être livrée aux utilisateurs, toutes les couches doivent être livrées simultanément pour éviter les problèmes de désynchronisation entre les versions des clients, des serveur(s) d'application et des serveur(s) de données.