Choix d'une architecture trois-tiers

L'objectif premier d'un système d'information quel qu'il soit est de permettre à plusieurs
utilisateurs d'accéder aux mêmes informations. Pour cela il faut donc regrouper les
informations utilisées par l'entreprise. En terme technique, cela se traduit par la centralisation
des données au sein d'une base de données. L'évolution des systèmes d'information s'est donc
basée sur une meilleure subdivision entre les tâches à réaliser pour permettre l'exploitation de
ces données par les utilisateurs finaux. Ceci permet de structurer plus efficacement les
informations ce qui entraîne à la fois une meilleure organisation de l'entreprise et une
meilleure efficacité technique. Cette subdivision a été facilitée par l'avènement des
technologies orientées objets qui s'appliquent aussi bien au modèle client-serveur qu'au
modèle Internet. Ces technologies permettent une séparation entre les différents composants
du système. Il devient alors possible de réaliser de nouvelles architectures permettant la mise
à disposition des informations sous différentes formes tout en diminuant les temps de
développement. Ces technologies permettent également de faire collaborer une grande
diversité de systèmes. On parle alors d'architecture distribuée. Il est ainsi possible de présenter
des données en provenance d'un mainframe mélangées à des données en provenance d'un
SGBDR, le tout étant affiché dans un browser sur la même page HTML.

Trois tâches importantes

Tout système d'information nécessite la réalisation de trois groupes de fonctions: le stockage
des données, la logique applicative et la présentation. Ces trois parties sont indépendantes les
unes des autres: on peut ainsi vouloir modifier la présentation sans modifier la logique
applicative. La conception de chaque partie doit également être indépendante, toutefois la
conception de la couche la plus basse est utilisée dans la couche d'au dessus. Ainsi la
conception de la logique applicative se base sur le modèle de données, alors que la conception
de la présentation dépend de la logique applicative.

Stockage et accès aux données

Le système de stockage des données a pour but de conserver une quantité plus ou moins
importante de données de façon structurée. On peut utiliser pour cette partie des systèmes très
variés qui peuvent être des systèmes de fichiers, des mainframes, des systèmes de bases de
données relationnelles, etc... Le point commun entre tous ces systèmes est qu'ils permettent le
partage des données qu'ils contiennent via un réseau. La méthode d'accès à ces données
dépendra du type d'organisation de ces données. Dans le cas d'une base de données
relationnelle, l'accès peut se faire par des API qui dépendent du langage et de
l'environnement. Ainsi en JAVA l'accès se fait via JDBC, alors qu'en C++ il se fera à l'aide
d'ODBC. Quel que soit l'API, le langage SQL est utilisé.

Logique applicative

La logique applicative est la réalisation informatique du mode de fonctionnement de

l'entreprise. Cette logique constitue les traitements nécessaires sur l'information afin de la
rendre exploitable par chaque utilisateur. Les utilisateurs peuvent avoir des besoins très variés
et évolutifs. Il devient alors nécessaire de permettre l'évolution du système sans pour autant
devoir tout reconstruire. Cette partie utilise les données pour les présenter de façon
exploitable par l'utilisateur. Il convient donc de bien identifier les besoins des utilisateurs afin
de réaliser une logique applicative utile tout en structurant les données utilisées.

Présentation

La présentation est la partie la plus immédiatement visible pour l'utilisateur. Elle a donc une
importance primordiale pour rendre attrayante l'utilisation de l'informatique. Son évolution a
été très importante depuis les débuts de l'informatique. Depuis les terminaux en mode texte
connectés à des mainframes jusqu'au HTML de nos jours en passant par les applications
graphiques développées en client serveur, il y a eu beaucoup de chemin parcouru. Différents
types d'interfaces demeurent intéressantes. En effet l'ergonomie d'un site Intranet HTML n'est
pas forcément idéale pour tous les types d'applications. Il peut être intéressant de proposer
plusieurs types d'interface pour une seule logique applicative. Par exemple une entreprise
disposant d'un site de commerce électronique peut proposer un accès à la liste de ses produits
sur Internet en HTML mais disposer d'une interface d'administration réalisée à l'aide d'une
applet graphique.

Architecture client-serveur
Les architectures client-serveur constituent une étape importante dans l'évolution des
systèmes d'informations. Ce type d'architecture est constitué uniquement de deux parties: un
client qui gère la présentation et la logique applicative, un serveur qui stocke les données de
façon cohérente et gère éventuellement une partie de la logique applicative. L'interface entre
ces deux parties est classiquement le langage SQL (dans sa version normalisé ou dans une
version propriétaire). Dans ce type d'architecture on constate une certaine indépendance du
client par rapport au serveur. La programmation du client peut s'effectuer sans se préoccuper
de la mise en place de la base de données. En particulier, les questions concernant
l'administration des données ne concerneront pas le développeur du client (dimensionnement
des disques, répartition des données sur le système, optimisation des accès aux données,
sauvegarde des données,...). Un des objectifs des architectures multi-tiers sera de généraliser
ce type de fractionnement en éléments logiciels indépendants les uns des autres. La qualité de
ce type d'architecture est basé sur deux technologies éprouvées: la notion de base de données
relationnelle et le langage SQL. Toutefois on peut également constater deux inconvénients à
cette technologie: elle possède une sécurité limitée et surtout son déploiement demeure long et
laborieux.

Avantage: technologies éprouvées

Le modèle relationnel a été introduit par E. Codd en 1970. Il s'appuie sur des considérations
théoriques formulées sous la forme de 12 règles formant le cahier des charges initial. Ce
modèle est basé sur la notion de relation. Une relation est un ensemble de n-uplet (n est fixe)
qui correspondent chacun à une propriété de l'objet à décrire. Ce modèle permet la gestion
précise de contraintes d'intégrité qui garantissent la cohérence des données. Les systèmes de
gestion de base de données relationnels (SGBDR) sont interfacés à l'aide d'un langage
unique: le SQL (Structured Query Language). Ce langage permet d'effectuer l'ensemble des
opérations nécessaires sur la base de données. Ce langage permet également la gestion de
transaction. Une transaction est définie par quatre propriétés essentielles: Atomicité,
Cohérence, Isolation et Durabilité (ACID). Ces propriétés garantissent l'intégrité des données
dans un environnement multi-utilisateurs. L'Atomicité permet à la transaction d'avoir un
comportement indivisible; soit toutes les modifications sur les données effectuées dans la
transaction sont effectives, soit aucune n'est réalisée. On comprend l'intérêt de ce concept
dans l'exemple simple d'une transaction débitant un compte A et créditant un autre compte B :
il est clair que la transaction n'a de sens que si les deux opérations sont menées à leur terme;
L'atomicité de la transaction garantit que la base de données passera d'un état cohérent à un
autre état cohérent. La Cohérence des données de la base est donc permanente. L'Isolation
des transactions signifie que les modifications effectuées au cours d'une transaction ne sont
visibles que par l'utilisateur qui effectue cette transaction. Au cours de la transaction,
l'utilisateur pourra voir des modifications en cours qui rendent la base apparemment
incohérente, mais ces modifications ne sont pas visibles par les autres et ne le seront qu'à la
fin de la transaction si celle-ci est correcte (elle ne rend pas la base incohérente). La
Durabilité garantit la stabilité de l'effet d'une transaction dans le temps, même en cas de
problèmes graves tel que la perte d'un disque. L'ensemble de ces notions sont à la base des
systèmes d'information actuels. Les technologies supportant ces notions (en particulier les
SGBDR) forment l'aboutissement des recherches des 30 dernières années. Des systèmes
comme Oracle offrent désormais des performances intéressantes y compris sur de grosses
bases de données. Ces performances ont été obtenues sans faire de compromis sur les
concepts théoriques sur lesquels ils se basent (modèle relationnel). Ces systèmes servent donc
tout naturellement de base aux futurs systèmes d'information utilisant les nouvelles
technologies Internet.

Inconvénients

L'architecture client-serveur possède toutefois des inconvénients. Ce sont ces inconvénients

qui poussent les entreprises à utiliser d'autres technologies. Les deux inconvénients principaux
sont la difficulté à gérer correctement les questions de sécurité et le coût du déploiement. La
sécurité d'un système en architecture client-serveur est gérée au niveau du SGBDR. Celui-ci
contrôle l'accès aux données en attribuant des autorisations d'accès aux différents utilisateurs
du système. Le problème vient du fait que cette attribution de droit ne peut pas tenir compte
des spécificités du logiciel réalisé. Pour pouvoir gérer les droits d'accès de cette façon il faut
accorder à chaque utilisateur des droits sur un grand nombre de tables, ce qui devient vite
laborieux. En pratique il est souvent plus rapide de ne créer qu'un utilisateur sur le SGBDR
avec lequel tous les utilisateurs se connectent. Cette approche ne permet aucune gestion de la
sécurité. Il suffit de connaître le login et le mot de passe d'accès à la base pour accéder à
l'ensemble des données sans aucune restriction. L'autre problème est souvent considéré
comme beaucoup plus important par les entreprises car il est beaucoup plus visible. Il s'agit
des durées et coûts de déploiement des logiciels. En effet un logiciel classique, développé en
architecture client-serveur, nécessite une installation et une éventuelle configuration sur
chaque poste utilisateur. Le déplacement d'un technicien coûte déjà très cher aux entreprises.
Mais ce qui reste le plus laborieux est la nécessité de mettre à jour régulièrement le logiciel.
Dans une architecture client-serveur, chaque mise à jour du logiciel nécessite un nouveau
déploiement accompagné de nombreux coûts.

Architecture trois-tiers
Le principe d'une architecture trois-tiers est relativement simple: il consiste à séparer la
réalisation des trois parties vues précédemment (stockage des données, logique applicative,
présentation). Nous avons déjà pu entrevoir la possibilité de séparer la conception de ces trois
subdivisions, ici il s'agit de séparer leur implantation. Tout comme dans le client-serveur cette
séparation signifie qu'il est possible de déployer chaque partie sur un serveur indépendant,
toutefois cela n'est pas obligatoire. La mise en place de ce type d'architecture permet dans tous
les cas une plus grande évolutivité du système. Il est ainsi possible de commencer par
déployer les deux serveurs sur la même machine, puis de déplacer le serveur applicatif sur une
autre machine lorsque la charge devient excessive. Les éléments permettant la réalisation
classique d'un système en architecture trois tiers sont les suivants:

 système de gestion de base de données relationnelle (SGBDR) pour le stockage des

données
 serveur applicatif pour la logique applicative
 navigateur web pour la présentation

Il est important de remarquer que l'essentiel du travail de développement sera implanté au

niveau du serveur applicatif. Le SGBDR nécessitera un travail d'administration surtout dans le
cas d'une quantité de données importante. Le travail de conception de la base de données sera
la pierre angulaire du système. En effet l'ensemble du développement s'appuiera sur cette
conception. Le navigateur web nécessitera la programmation de code spécifique permettant de
gérer l'affichage par ce navigateur. Ce code sera placé sur le serveur applicatif pour permettre
une mise à jour sans nécessiter de nouveaux déploiements.

Avantages de cette architecture

Cette architecture se développe actuellement au sein des entreprises grâce aux nombreux
avantages qu'elle présente. Malgré la différence évidente entre une architecture trois tiers et
un système client-serveur (l'apparition d'un serveur pour la logique applicative), le système
reste basé sur les technologies éprouvées détaillées précédemment (aspect relationnel et
transaction). La logique applicative est déplacée au niveau du serveur d'application mais reste
programmée à l'aide des mêmes technologies liées aux bases de données relationnelles. En
particulier l'utilisation du langage SQL reste jusqu'à présent la solution la plus intéressante au
niveau de la qualité logicielle. Elle présente à la fois une grande fiabilité, une bonne
disponibilité, une excellente évolutivité,... Toutefois il faut prendre en compte deux facteurs
importants: d'une part le choix du SGBDR (ils n'ont pas tous les mêmes qualités), d'autre part
la qualité des programmes utilisant la base de données (aussi bien au niveau de la conception
que de la programmation). L'avantage principal d'une architecture multi-tiers est la facilité de
déploiement. L'application en elle même n'est déployée que sur la partie serveur (serveur
applicatif et serveur de base de données). Le client ne nécessite qu'une installation et une
configuration minime. En effet il suffit d'installer un navigateur web compatible avec
l'application pour que le client puisse accéder à l'application, ce navigateur étant par ailleurs
souvent installé par défaut sur toutes les machines. Cette facilité de déploiement aura pour
conséquence non seulement de réduire le coût de déploiement mais aussi de permettre une
évolution régulière du système. Cette évolution ne nécessitera que la mise à jour de
l'application sur le serveur applicatif. Ceci est très important car cette évolutivité est un des
problèmes majeurs de l'informatique. Le troisième avantage est l'amélioration de la sécurité.
Dans un système client-serveur tous les clients accédaient à la base de données ce qui la
rendait vulnérable. Avec une architecture multi-tiers l'accès à la base n'est effectué que par le
serveur applicatif. Ce serveur est le seul à connaitre la façon de se connecter à cette base. 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. Il est alors possible de gérer la sécurité au niveau de ce serveur
applicatif, par exemple en maintenant la liste des utilisateurs avec leurs mots de passe ainsi
que leurs droits d'accès aux fonctions du système. On peut même améliorer encore la sécurité
par la mise en place d'une architecture réseau interdisant totalement l'accès au serveur de base
de données pour les utilisateurs finaux. La mise en place de firewall correctement configuré
permettra ceci.

Architecture multi-tiers
Une architecture multi-tiers va plus loin dans le découpage de l'application sur différents
serveurs. Une architecture multi-tiers est également appelé architecture distribuée du fait de la
distribution des traitements et des données sur différents serveurs. Le découpage de base du
système reste toujours le même: une partie gestion de données, une partie gestion de la
logique applicative et bien entendu le client assurant la présentation. Toutefois les deux
parties développées coté serveur vont pouvoir être déployées chacune sur plusieurs serveurs.
L'objectif général de ce type d'architecture est de permettre l'évolutivité du système sous
plusieurs aspects: la quantité de données stockée, la disponibilité du serveur, le nombre
d'utilisateurs,... Il faut également bien comprendre qu'un système conçu en architecture multi-
tiers n'est pas forcément déployé sur plusieurs machines dès le départ. Toutefois son mode de
programmation doit permettre de modifier le déploiement du système en cours d'exploitation
par un administrateur. Le développeur doit donc rendre le système indépendant du serveur sur
lequel il s'exécute. Il existe deux types de répartition possibles dans une architecture
distribuée. Il est possible de répartir les données et de répartir la logique applicative. Chacune
de ces deux répartitions permet de résoudre des problèmes de natures différentes. Elles
peuvent donc être mises en place soit séparément soit en parallèle sur le même système.

Répartition des données sur différents serveurs

Il s'agit d'utiliser plusieurs sources de données dans une même application. Chaque source
possède sa propre structure de données. Chaque serveur de données peut être géré de façon
très différente. Toutefois une interface de programmation commune à toutes les sources doit
pouvoir exister. Il peut exister des relations entre les données des différents serveurs, il sera
alors nécessaire de gérer des transactions distribuées entre des différents serveurs de données.
Cette répartition de données correspond à la notion de base de données distribuée. Les bases
de données distribuées permettent de résoudre deux types de problèmes. La première est la
performance du système: la répartition des données permet d'augmenter la disponibilité des
données. Toutefois il est nécessaire de bien penser cette répartition afin de ne pas démultiplier
le nombre de transactions distribuées nécessaires. Ceci aurait pour effet de diminuer la
performance plus que de l'augmenter. Le deuxième type de problèmes est la réutilisation des
systèmes existants. En effet de nombreux systèmes informatiques stockent actuellement une
grande quantité de données. Toutefois ces systèmes ne sont pas toujours bien coordonnés
entre eux. Ceci risque d'entraîner des redondances dans les données et des incohérences entre
plusieurs sources de données. L'objectif est donc de réutiliser ces systèmes dans une même
application afin de restructurer le système d'information sans pour autant repartir de zéro (ce
qui est non seulement un non sens mais est aussi impossible). Les systèmes réutilisés sont
bien souvent hétéroclites (mainframe, SGBDR,...) et nécessitent d'être réunis en utilisant
diverses technologies (moniteurs transactionnels, serveurs d'applications,...).

Répartition de la logique applicative

La répartition de la logique applicative permet de distribuer les traitements sur différentes

machines. Cette distribution est facilitée par l'utilisation de la programmation orientée objet et
plus particulièrement de ce qu'on appelle les composants. Un composant possède entre autre
la caractéristique d'être accessible à travers le réseau. Un composant peut ainsi être instancié
puis utilisé au travers du réseau. Il est également possible de trouver un serveur permettant
l'utilisation d'un composant, ce qui permet une forte évolutivité ainsi qu'une résistance aux
pannes importantes (le service sera toujours disponible sur un serveur même si une machine
tombe en panne). La réalisation de ce type de répartition nécessite l'utilisation de technologies
spécifiques. D'une part il faut permettre la communication entre les différents éléments de
l'application (RMI), d'autre part le déploiement et l'évolution du système doivent pouvoir être
assurés (JNDI + fichiers XML). Certaines technologies proposent une architecture cohérente
pour la mise en place des différentes technologies intervenant sur un système distribué (EJB).
Les buts recherchés lors de la mise en place de ce type d'architecture sont la performance,
l'évolutivité, la maintenabilité...