Les Architecture 3-Tiers

L'architecture 3-tier ou architecture à trois niveaux est l'application du modèle plus général qu'est le multi-tiers. L'architecture logique du système est divisée en trois niveaux ou couches :

• couche présentation
• couche métier
• couche accès aux données

C'est une extension du modèle client/serveur.

Définition et concepts

Exemple d'architecture en 3 couches

L'architecture 3-tier (de l'anglais tier signifiant étage ou niveau) est un modèle logique d'architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d'une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini :

• la présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur ;
• le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des règles de gestion et de la logique applicative ;
• et enfin l' accès aux données persistantes (persistence en anglais) : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.

Dans cette approche, les couches communiquent entre elles au travers d'un « modèle d'échange », et chacune d'entre elles propose un ensemble de services rendus. Les services d'une couche sont mis à disposition de la couche supérieure. On s'interdit par conséquent qu'une couche invoque les services d'une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque niveau ne communique qu'avec ses voisins immédiats).

Le rôle de chacune des couches et leur interface de communication étant bien définis, les fonctionnalités de chacune d'entre elles peuvent évoluer sans induire de changement dans les autres couches. Cependant, une nouvelle fonctionnalité de l'application peut avoir des répercussions dans plusieurs d'entre elles. Il est donc essentiel de définir un modèle d'échange assez souple, pour permettre une maintenance aisée de l'application.

Ce modèle d'architecture 3-tier a pour objectif de répondre aux préoccupations suivantes :

• allègement du poste de travail client (notamment vis-à-vis des architectures classiques client-serveur de données –- typiques des applications dans un contexte Oracle/Unix) ;
• prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages, etc.) ;
• introduction de clients dits « légers » (plus liée aux technologies Intranet/HTML qu'au 3-tier proprement dit) ;
• amélioration de la sécurité des données, en supprimant le lien entre le client et les données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier l'intégrité et la validité des données avant de les envoyer dans la couche de données.
• et enfin, meilleure répartition de la charge entre différents serveurs d'application.

Précédemment, dans les architectures client-serveur classiques, les couches présentation et traitement étaient trop souvent imbriquées. Ce qui posait des problèmes à chaque fois que l'on voulait modifier l'interface homme-machine du système.

L'activation à distance (entre la station et le serveur d'application) des objets et de leurs méthodes (on parle d'invocation) peut se faire au travers d'un ORB (avec le protocole IIOP ou au moyen des technologies COM/DCOM de Microsoft ou encore avec RMI en technologie J2EE). Cette architecture ouverte permet également de répartir les objets sur différents serveurs d'application (soit pour prendre en compte un existant hétérogène, soit pour optimiser la charge).

Il s'agit d'une architecture logique qui se répartit ensuite selon une architecture technique sur différentes machines physiques, bien souvent au nombre de 3, 4 ou plus. Une répartition de la charge doit dans ce cas être mise en place.

Les trois couches

Couche Présentation (premier niveau)

Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle d'Interface Homme Machine. En informatique, elle peut être réalisée par une application graphique ou textuelle. Elle peut aussi être représentée en HTML pour être exploitée par un navigateur web ou en WML pour être utilisée par un téléphone portable.

On conçoit facilement que cette interface peut prendre de multiples facettes sans changer la finalité de l'application. Dans le cas d'un système de distributeurs de billets, l'automate peut être différent d'une banque à l'autre, mais les fonctionnalités offertes sont similaires et les services identiques (fournir des billets, donner un extrait de compte, etc.).

Toujours dans le secteur bancaire, une même fonctionnalité métier (par exemple, la commande d'un nouveau chéquier) pourra prendre différentes formes de présentation selon qu'elle se déroule sur Internet, sur un distributeur automatique de billets ou sur l'écran d'un chargé de clientèle en agence.

La couche présentation relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les informations renvoyées par les traitements de cette couche. Il s'agit donc ici d'un assemblage de services métiers et applicatifs offerts par la couche inférieure.

Couche Métier / Business (second niveau)

Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la « logique », et qui décrit les opérations que l'application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation.

Les différentes règles de gestion et de contrôle du système sont mises en œuvre dans cette couche.

La couche métier offre des services applicatifs et métier^[1] à la couche présentation. Pour fournir ces services, elle s'appuie, le cas échéant, sur les données du système, accessibles au travers des services de la couche inférieure. En retour, elle renvoie à la couche présentation les résultats qu'elle a calculés.

Couche Accès aux données (troisième niveau)

Elle consiste en la partie gérant l'accès aux gisements de données du système. Ces données peuvent être propres au système, ou gérées par un autre système. La couche métier n'a pas à s'adapter à ces deux cas, ils sont transparents pour elle, et elle accède aux données de manière uniforme (couplage faible).

Données propres au système

Ces données sont pérennes, car destinées à durer dans le temps, de manière plus ou moins longue, voire définitive.

Les données peuvent être stockées indifféremment dans de simples fichiers texte, ou eXtensible Markup Language (XML), ou encore dans une base de données. Quel que soit le support de stockage choisi, l'accès aux données doit être le même. Cette abstraction améliore la maintenance du système.

Les services sont mis à disposition de la couche métier. Les données renvoyées sont issues du/des gisements de données du système.

Pour une implémentation « native », le motif de conception (en anglais design pattern) à implémenter dans cette couche est le Data Access Object (DAO). Ce dernier consiste à représenter les données du système sous la forme d'un modèle objet. Par exemple un objet pourrait représenter un contact ou un rendez-vous.

La représentation du modèle de données objet en base de données (appelée persistance) peut s'effectuer à l'aide d'outils tels que Hibernate.

Données gérées par un autre système

Les données peuvent aussi être gérées de manière externe. Elles ne sont pas stockées par le système considéré, il s'appuie sur la capacité d'un autre système à fournir ces informations.

Par exemple, une application de pilotage de l'entreprise peut ne pas sauvegarder des données comptables de haut niveau dont elle a besoin, mais les demander à une application de comptabilité. Celle-ci est indépendante et pré-existante, et on ne se préoccupe pas de savoir comment elle les obtient ou si elle les sauvegarde, on utilise simplement sa capacité à fournir des données à jour.