Re: que signifie n-tiers

Selon Bruno Vernay <bruno.vernay@???>:

> Il est amusant de constater que la séparation entre les 3 tiers n'est
> pas effectué au même niveau dans les deux pages en référence.
> Talel devrait revoir un peu son schéma il me semble.
> Le probleme c'est aussi qu'on continue de parler de client/serveur alors
> que justement dans une archi n-tiers, tous les tiers sauf 2 sont client
> ET serveur. Cela porte à confusion.
> Pour certains un tier = une machine et pour d'autre, un tier = un
> serveur (ou service.) Pour des EJB qui tournent sur plusieurs machines
> différentes, sur des serveurs différents, c'est tentant. Pour des bases
> de donnée avec distribution de charge, c'est moins évident.
> Et si on parle de cluster, on les compte comme des tiers ??
> L'informatique distribué est encore loin ...

Un 'tiers' est un découpage logique de l'architecture globale du
logiciel. La base de données est un tiers, le serveur EJB (code applicatif,
calculs, contrôle, manipulation des données) un autre et
le serveur Web (présentation, interface avec l'utilisateur) un troisième...
peu importe le nombre d'instances de ces
serveurs sur l'environnement physique et donc peu importe le nombre de
machines.

Au passage, j'ai déjà vu déployer un cluster d'EJB sur WebSphere 3.5
(deux instances du serveur avec les mêmes composants logiciels EJB déployés)
sur la même machine windows (bi-proc) car on obtenait de meilleures
performances qu'avec une seule instance... Ok l'implémentation du Java 1.2
d'IBM y était bien pour quelque chose. Mais simplement pour expliquer qu'un
tiers correspond à un logiciel serveur ou à une machine uniquement dans des cas
très particuliers.

Et ce n'est pas parce que l'architecture de l'application est conçue en 3-tiers
qu'il faut nécessairement déployer Tomcat/JBoss/MySQL (pour rester dans de
l'open-source Linux) sur trois machines
différentes. On peut très bien tout faire tourner sur une même machine...
jusqu'à constater que la montée en charge de l'ensemble n'est pas suffisant.

Et c'est dans ce cas que le 3-tiers est intéressant: si par exemple, c'est
Tomcat qui consomme beaucoup de CPU/RAM, on peut le déporter sur une machine
dédiée (1 machine Tomcat et 1 machine JBoss/MySQL) sans modifier le code mais
simplement un peu de configuration du serveur.

On peut aussi imaginer répartir les EJB dans deux JBoss différents pour faire
une sorte de QoS sur les temps de réponses de certains services critiques.

Certes écrire une application 3-tiers est plus complexe et nécessite beaucoup
de rigueur pour concevoir le découpage logique et la configuration de
l'ensemble. Par contre, elle est plus facile à faire évoluer lorsque la
charge devient plus importante (modification du déploiement physique)
ou même lorsque les besoins à couvrir par le logiciel augmentent et à ce
moment-là, on peut ajouter facilement des "briques".

On peut aussi constater qu'à première vue une application 3-tiers n'est pas
forcément "optimale", des communications réseaux et des manipulations de
données sont faites plusieurs fois sur chaque tiers... ce qui fait dire à
certains que cela va plus vite de faire du PHP qui écrit dans MySQL
directement - ce qui est vrai mais jusqu'à une certaine limite de charge.
Le n-tiers est le prix à payer pour obtenir la souplesse de déploiement
dont je parle - en s'évitant de réviser profondément le code à chaque
ré-évaluation des besoins de charge.

--
Yves Martin