Historiquement, on remarque que les applications sur site central étaient les premières à proposer et mettre en œuvre un accès multi-utilisateurs, soit une très bonne chose. Dans ce contexte, les utilisateurs se connectent aux applications exécutées via le serveur central à l'aide de terminaux passifs qui se comportent comme des esclaves. On délaisse l'intégralité des traitements au serveur central, y compris l'affichage qui se voit simplement déporté sur des terminaux passifs.

Plusieurs avantages lui sont reconnus, dont une grande facilité d'administration et une haute disponibilité. Aujourd'hui, il bénéficie d'une large palette d'outils de conception, de programmation et d'administration ayant atteint un niveau de maturité et de fiabilité qui lui permettent encore de soutenir la comparaison avec des solutions nettement plus modernes. De plus, on notera que la centralisation de la puissance sur une seule et même machine permet une utilisation optimale des ressources et se prête très bien à des traitements par lots.

Avec l'arrivée dans les entreprises des premiers ordinateurs en réseau, il est devenu possible de déployer une application un-tiers sur plusieurs machines indépendantes. Des programmes plus ou moins simples ont fait leur apparition et permet la création d'application de ce genre.

En général, ce type d'application répond aux besoins d'une seule personne isolée ou d'un petit groupe de personne, et sa mise en œuvre dans un environnement multi-utilisateurs est envisageable.

L'envoie intégral des données nécessaires à l'exécution d'une requête fait vite saturer le réseau. Des techniques existent pour alléger le réseau, mais on arrivera toujours à une saturation malgré tout. De plus, la cohabitation de plusieurs moteurs de base de données indépendants manipulant les mêmes données tend à devenir instable à l'usage. Il n'est pas rare de rencontrer des conflits lors de la consultation ou de la modification simultannée par rapport à un même renseignement par plusieurs utilisateurs. Ces conflits peuvent altérer l'intégrité des données. Il peut arriver que la confidentialité des données ne soit plus conservée, c'est aussi très dangereux.

Ce type de solution est donc à réserver à des applications non critiques exploitées par de petits groupes de travail.

Dans ce type de conversation, on distingue donc deux parties :

Le client provoque l'établissement d'une conversation afin d'obtenir des données ou un résultat de la part du serveur.

Cet échange de message transite à travers le réseau reliant les deux machines. Il met en œuvre des mécanismes relativement complexes qui sont, en général, pris en charge par un intergiciel (middleware).

Le middleware est l'ensemble des couches réseau et services logiciels qui permettent le dialogue entre différents composants d'une application répartie. Ce dialogue s'établie sur des protocoles applicatifs communs, défini par l'API du middleware.

Le middleware se contente d'unifier, pour les applications mises en jeu, l'accès et la manipulation de l'ensemble des services disponibles sur le réseau, afin de rendre l'utilisation de ces derniers presque transparente.

L'architecture client-serveur de première génération présente les inconvénients suivants :

Néanmoins, on peut noter quelques avantages non négligeables de ce type d'architecture :

Dans l'architecture trois-tiers, on reconnait le poste client. Plus communément appelé client léger ou Thin Client, par opposition au client lourd des architectures deux-tiers. Il se contente de présenter un rendu fidèle, avec, éventuellement, une partie de logique application permettant une vérification immédiate de la saisie. Comme dit précédemment, il est souvent constitué d'un navigateur Web simple.

Dans une architecture trois-tiers, la logique application est prise en charge par le serveur HTTP. Ce dernier se retrouve dans la position du poste client d'une application deux-tiers et les échanges avec le serveur de données mettent en œuvre les mécanismes déjà vus dans ce type d'application.

En général, le protocole HTTP n'est pas supporté totalement par les navigateurs, c'est pourquoi on préfère que les applications transactionnelles doivent gérer elles-mêmes le contexte utilisateur afin de contrôler :

L'architecture trois-tiers a corrigé les excès du client lourd en centralisant une grande partie de la logique applicative sur un serveur HTTP. Le poste client, qui ne prend à sa charge que la présentation et les contrôles de saisie, s'est trouvé soulagé et plus simple à gérer.

En revanche, le serveur HTTP constitue la pierre angulaire de l'architecture et se trouve souvent fortement sollicité : il est difficile de répartir la charge entre client et serveur. On se retrouve confronté aux épineux problèmes de dimensionnement serveur et de gestion de la montée en charge rappelant l'époque des mainframes. De plus, les solutions mises en œuvre sont relativement complexes à maintenir et la gestion des sessions est compliquée, mais c'est possible.

Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures deux-tiers : le client est soulagé, mais le serveur est fortement sollicité.

Le juste équilibre de la charge entre client et serveur semble atteint avec la génération suivante : les architectures n-tiers.