L’architecture client / serveur
(pour référence)
L’architecture client / serveur n’est guère plus qu’un concept assez simple et peu développé, qui confine à l’évidence dans notre monde moderne dans lequel le réseau est omniprésent. Aussi cet article sera t’il court, pour le décrire et servir de référence à pointer dans d’autres articles qui évoqueront ce concept.
Avant les années 1970 / 1980, les réseaux informatiques étaient pratiquement inexistants dans les entreprises.
En conséquence, les logiciels utilisés à cette époque étaient nécessairement monopostes et leur structure pouvait éventuellement se contenter d’être monolithique (sans découpage en plusieurs composants logiciels).
Les données élaborées et exploitées par ces logiciels devaient également être stockées localement sur le poste de travail. Il y avait donc beaucoup de duplication de données entre les différents postes de travail. Et il y avait également des problèmes de divergence de ces données, quand elles étaient modifiées localement sur un poste de travail et pas sur les autres.
Par exemple, le fichier clients de l’entreprise devait se retrouver dupliqué sur tous les postes de travail des agent·es commerciaux·ales de l’entreprise. Et quand l’adresse d’un client était modifiée sur un poste de travail donné, elle ne se trouvait pas magiquement également mise à jour sur tous les autres postes de travail.
À partir du moment où les réseaux informatiques ont commencé à être déployés dans les entreprises, il est devenu envisageable pour elles de chercher à centraliser ces données pour éviter leur duplication et leur divergence.
C’est là qu’apparaît la notion de client / serveur. Il s’agit de décomposer le logiciel en deux parties :
Une partie serveur qui sera exécutée sur une unique machine (elle aussi appelée serveur) de l’entreprise.
C’est sur cette machine que seront centralisées les données.
Une partie client qui sera exécutée sur chacun des postes de travail qui auront à exploiter ces données.
La partie client a nécessairement la charge de présenter à son utilisateur·ice les écrans qui lui permettrons d’afficher (et éventuellement de saisir) les données.
La partie serveur a nécessairement la charge de réaliser les opérations de lecture et d’écriture sur les données centralisées.
Pour le reste, le client et le serveur doivent évidemment communiquer d’une façon ou d’une autre, qui mettra en œuvre un protocole réseau. Mais, à ce stade, le concept de client serveur ne s’étend pas sur les responsabilités respectives du client et du serveur pour ce qui est des autres opérations que celles d’affichage et saisie des données côté client et des opérations de persistance de ces données côté serveur. Il ne précise notamment pas quel composant à la responsabilité d’appliquer d’éventuelles règles de gestion à ces données, ce que l’on nommera plus tard la logique métier.
D’autres architectures, comme l’architecture 3 tiers, chercherons à étendre ce concept de client / serveur et à couvrir ses angles morts.