![]() |
![]() |
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 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.