Retour

COMPRENDRE L'ARCHITECTURE CLIENT / SERVEUR

L'informatique Client/Serveur constitue une alternative aux architectures de traitements centralisés sur un mainframe. Favorisée par la montée en puissance des plates-formes micros et mini, cette nouvelle approche du traitement de l'information apparaît comme l'axe essentiel de développement des techniques informatiques d'aujourd'hui. La phrase clef du Client/Serveur pourrait être " utiliser l'outil qui correspond au besoin ". Cet aphorisme s'applique non seulement à la répartition des traitements entre serveur et station, mais aussi au choix des outils sur la station.

Dans une architecture Client/Serveur, les machines clientes (en général des micro-ordinateurs) se chargent des fonctions d'affichage et de traitement "logique" des données.

Les serveurs sont dédiés aux fonctions de stockage et de gestion des données. L'architecture Client/Serveur repose sur l'utilisation des liaisons réseau pour distribuer les traitements sur ces divers systèmes. Le dialogue entre les clients et les serveurs se fait sous forme de requêtes. Les architectures Client/Serveur cherchent à résoudre un problème double : répartir les traitements sur différents processeurs et minimiser le trafic sur les réseaux de communication. Pour illustrer ce problème, le schéma ci-dessous retrace les différentes phases du traitement permettant à un utilisateur final d'interroger une base de données.

MICRO PC A INTERFACE

B

 PROGRAMMES C SGBD D DONNEES E ORDINATEUR CENTRAL

La première partie gère les fonds d'écran, les aides en ligne, le dialogue avec l'utilisateur. La seconde partie représente le coeur même de l'application : préparation des requêtes, manipulation des données reçues, calculs, contrôles, préparation des affichages. La troisième et dernière partie est constituée de l'accès proprement dit aux données ou aux fichiers. La notion de client/serveur sous-entend deux types d'acteurs : le client et le serveur, dont la relation est de type maître/esclave.

Les points A, B, C, D et E représentent les façons les plus courantes de placer la frontière entre le client et le serveur.

Le point A représente l'ancêtre de nos architecture informatiques : il s'agit du terminal passif relié à un ordinateur central. Architecture éprouvée, ancienne, mais qui a encore de beaux jours devant elle. La part des travaux allouée au terminal est nulle.

Le point E est quant à lui caractéristique de l'application entièrement micro-ordinateur. Le site central n'est plus présent, sauf peut-être pour des échanges d'informations ponctuels.

Dans le cas du point B, le poste de travail assure l'ensemble de l'interface utilisateur : menus, icônes, aides en ligne, messages d'erreur. L'objectif déclaré d'une telle répartition est d'offrir une interactivité et une convivialité équivalente à celle offerte sur un micro-ordinateur. Cette répartition des tâches est celle qui est retenue lors d'opérations de " revamping" (ravalement). Dans cette architecture, une couche logicielle sur le micro interprète le flot d'écrans formaté et le restitue dans l'environnement graphique. Ce découpage est aussi celui du " Client Serveur 2 ème génération ". Mais dans ce cas, les programmes applicatifs sont confiés à un moniteur transactionnel qui dialogue d'un côté avec le SGBD de l'autre avec l'application cliente. Nous passons d'une architecture à 2 niveaux (Client/Serveur) à une architecture à 3 niveaux (Client/Moniteur/Serveur) correspondant aux niveaux présentation, application, données. Nous ne sommes plus alors dans une opération de revamping : le dialogue entre l'applicatif et le client se code directement en mode coopératif.

Le point D nous donne une solution très proche d'une application micro-ordinateur : l'ensemble de l'applicatif se trouve sur le poste client. Le système serveur joue uniquement le rôle de serveur de fichiers. Cette solution est principalement mise en oeuvre sur les réseaux locaux de micro-ordinateurs.

Le point C représente la répartition privilégiée des modèles client/serveur de première génération : le gestionnaire de données est accédé à distance par les applications. Le poste client pose des questions au serveur, qui lui retourne les réponses, lesquelles sont traitées par le poste client. Le concept client/serveur est susceptible de s'appliquer à la plupart des services disponibles dans le domaine informatique : applications, impression, fichiers, communication, messagerie, ... Mais c'est dans le domaine des bases de données que l'architecture client/serveur trouve son plein emploi.

LES AVANTAGES DU TROIS TIERS FACE AU CLIENT SERVEUR

Les architectures client-serveur de première génération consistaient en un client gérant uniquement la couche présentation et en un serveur réalisant l'ensemble des applications.
La 2e génération de système client-serveur, elle, s'est développée avec Windows et les PC. L'idée de base étant d'utiliser la puissance des PC, les traitements applicatifs ont donc été protés sur ceux-ci. Le serveur gère les accès aux bases de données selon les requêtes SQL des clients. Cette architecture présente des défauts très pénalisantes, tels l'absence de standard, la difficulté d'administrer les postes clients, le déploiement coûteux et très difficile à réaliser à grande échelle ainsi que le trafic important sur les réseaux, entraînant une importante facture de télécom.
Avec la technologie Internet, une 3e génération est née, intitulée client-serveur à 3 niveaux, ou encore architecture 3 tiers. Cette dernière est consituée d'un niveau client gérant la présentation, d'un niveau serveur applicatif prenant en compte les applications (et notamment les objets métiers), et d'un troisième niveau contenant les serveurs de base de données.
Les architectures client serveur à trois niveaux sont simples : les postes clients, le middleware de communication et l'accès aux serveurs sont standardisés. Les postes clients sont pourvus d'un navigateur WEB à partir duquel les composants du poste client, tels les applets Java et les contrôles ActiveX, sont mis à jour. Cela résout les problèmes de déploiement et de gestion de versions des logiciels des postes clients.
A partir de 50 postes clients, le choix d'une architecture 3 tiers est bien meilleur que celui d'une architecture client-serveur traditionnelle. De plus la logique métier se déplace sur le serveur, ce qui autorise un contrôle plus efficace de sa diffusion.
Les architectures client-serveur à 3 niveaux ou plus autorisent une montée en charge du système au fur et à mesure de la croissance du nombre d'utilisateurs par une augmentation du nombre de machines serveurs. En plus l'administration du système distribué est centralisée. Le coût de développement de cette infrastructure interopéable et évolutif représente 70% du coût total de développement d'une application.

LES MOM (MESSAGE ORIENTED MIDDLEWARE)

Qui pense middleware pense généralement aux mécanismes de communication entre objets, avec à l'esprit les architectures CORBA (Common Objetc Request Broker Architecture), DCOM (Distributed Component Object Model) ou RMI (Remote Method Invocation). Ces architectures ont en commun leur appartenance à une même famille issue des systèmes de type RPC (Remote Procedure Call) ou plus précisément de son extension objet : les ORB (Object Request Broker).

Les MOM font partie d'une 2e grande famille. Moins connus et moins standardisés, bien qu'ils soient utilisés depuis plus de 20 ans dans les environnements de grands systèmes, ils répondent cependant au même besoin de mettre en relation des applications distribuées.
Toutefois, ils reposent sur des concepts différents, en l'occurrence la communication par messages structurés et sur l'asynchronisme des liaisons.
Les besoins actuels des entreprises sont nombreux : faire communiquer les environnements applicatifs hétérogènes et généralement répartis sur plusieurs istes, s'ouvrir vers le commerce électronique et être capable de s'adapter à un nombre toujours grandissant d'utilisateurs.
Les technologies de l'Internet, les architectures multiniveaux et les MOM sont des réponses particulièrement adaptées à ces besoins.

Un MOM est un middleware qui permet l'échange de commandes et de données par le biais des messages. Contrairement aux ORB, qui ne supportent aujourd'hui que le mode de communication synchrone, le MOM peut travailler dans les deux modes asynchrone et synchrone.

Début