Architecture N-tier

L’architecture N-tier

L’architecture N-tier (anglais tier : étage, niveau), ou encore appelée multi-tier, est une architecture client-serveur dans laquelle une application est exécutée par plusieurs composants logiciels distincts.

Une architecture n-tiers comprend généralement une couche de présentation, une couche applicative, une couche objets métiers et une couche d’accès aux données.

[pic 1]

La couche de présentations contient différents types de clients léger (JSP, ASP,..) et lourd (Swing, WinForm,…)

La couche applicative contient les traitements représentant les règles métier (crée un compte, rechercher un client, calculer un facture,…)

La couche d’objets métier est représentée par les objets du domaine, c’est-à-dire l’ensemble des entités persistantes de l’application (Facture, Bon de commande, client,…)

La couche d’accès aux données contient les usines d’objets métier, c’est-à-dire les classes chargées de crée et manipuler des objets métier de manière totalement transparente, indépendamment de leur mode de stockage.

Performances techniques :

Le parcours d’une requête à travers les couches d’un système tend à ralentir l’exécution.  Cette faiblesse sera évidemment observable pour des systèmes répondant à de grande charge de travail.

Besoins en ressources (matérielles, humains) :

L’organisation en couche s’avère le bon choix lorsqu’une équipe de développeurs est composé de spécialistes, particulièrement de créateurs d’interfaces graphiques. Par exemple une équipe de développement d’applications web composé de programmeurs et d’infographistes. Elle convient aussi d’avantage à des développeurs dont l’équipe est géographiquement localisée au même endroit et qui se côtoient quotidiennement.

Sécurité, disponibilité, risque :

L’accès à la base n’est effectué que par le serveur applicatif, il ne partage aucune des informations permettant l’accès aux données, en particulier le login et le mot de passe de la base.

Le système est indépendant du serveur sur lequel il s’exécute au cas où le serveur se plante.

Création de valeur :

Eviter l’impact d’évolution futurs de l’application. (Si l’on est amené à devoir changer la base de données relationnelles, seule la couche d’accès aux données sera impactée, la couche de service et la couche de présentation ne seront pas concernées car elles auront été découplées des autres.

Alignement stratégique avec les ambitions de STELEC :

La facilite de déploiement qui aura pour conséquence non seulement de réduire le cout de déploiement mais aussi de permettre une évolution régulière de système.

La possibilité d’utiliser le système en extranet permettra de faciliter la communication entre différentes filiales de STELEC.

...