II.4.2. Présentation distante
Encore appelée client-serveur de présentation.
L'ensemble des traitements est exécuté par serveur, le client ne
prend en charge que l'affichage. Ce type d'application présentait
jusqu'à présent l'inconvénient de générer un
fort trafic réseau et de ne permettre aucune répartition de la
charge entre client et serveur. S'il n'était que rarement retenu dans sa
forme primitive, il connaît aujourd'hui un très fort regain
d'intérêt avec l'exploitation des standards internet.
II.4.3. Gestion distante des données
Correspond au client-serveur des données, sans doute le
type de client-serveur le plus répandu. L'application fonctionne dans sa
totalité sur le client, la gestion des données et le
contrôle de leur intégrité sont assurés par un SGBD.
Cette architecture, de part sa souplesse, s'adresse très bien aux
applications type info centre, interrogeant la base de façon ponctuelle.
Il génère toutefois un trafic réseau assez important et ne
soulage pas énormément le poste client, qui réalise,
encore la grande majorité des traitements.
II.4.4. Traitement distribué
Correspond au client-serveur de traitement. Le
découpage de l'application se fait ici au plus près de son noyau
et les traitements sont distribués entre le client et le(S) serveur(S).
Le client-serveur de traitements s'appuie, soit à un mécanisme
d'appel de procédure distante, soit sur la notion de procédure
stockée proposée par les principaux SGBD du marché.
Cette architecture permet d'optimiser la répartition de
la charge de traitement entre machines et limite le trafic réseau. Par
contre il n'offre pas la même souplesse que le client-serveur de
données puisque les traitements doivent être connus du serveur
à l'avance.
II.4.5. Bases de données distribuées
Il s'agit d'une variante du client-serveur de données
dans laquelle une partie de données est prise en charge par le client.
Ce modèle est intéressant si l'application doit gérer de
gros volumes de données, si l'on souhaite disposer de temps
d'accès très rapides sur certaines données ou pour
répondre à de fortes contraintes de confidentialité. Ce
modèle est aussi puissant que complexe à mettre en oeuvre.
II.4.6. Données et traitements distribués
Ce modèle est très puissant et tire partie de la
notion de composants réutilisables pour répartir au mieux la
charge entre client et serveur. C'est bien entendu, l'architecture la plus
complexe à mettre en oeuvre.
| 
