INTRODUCTION

Jusqu’à une date récente l’architecture multi tiers étant une notion qui ne
dépassait pas le cercle très restreint des concepteurs du système d’exploitation, ou celui des
concepteurs des systèmes temps réel pour la défense.
Dans le système d’information « traditionnel » disons les années 70-80, sur une machine
centralisée(le mainframe) le système prenait complètement à sa charge tout le contrôle de ce
qui se passe dans la machine ainsi que les diverses régulations nécessaires à une répartition
équitable des ressources disponible pour les applications que la machines héberge. Ces
dernières années, l’architecture client-serveur fut la principale solution préconisée par les
constructeurs d’applications.
Ayant acquis de la maturité, l’architecture n-tiers devient aujourd’hui une alternative.
Apres avoir présenté brièvement les types d’architectures et les modelés un tiers, deux tiers,
trois tiers et n tiers ; nous ferons une synthèse sur tous ces modèles, enfin nous allons
compléter la présentation d’une solution concrète.

1
 I. CONTEXTE

Dans les années 1960, l’informatique conquiert de nouveaux champs d’application

initialement centrée sur le calcul scientifique, elle s’impose dans la gestion des entreprises,
puis dans les applications embarquées (avionique, spatial, communication, domaine
militaire).Avec la naissance des sociétés de services informatiques, la production de logiciel,
initialement concentrée chez les constructeurs d’ordinateurs et les grands utilisateurs, devient
l’Object d’une industrie spécifique.

Au cours de cette période, la taille du système informatique connait une croissance

exponentielle, ainsi la taille (en milliers de ligne de code) du logiciel de base des machines IBM
croit de 25 en 1958(IBM) à 500 en 1964(IBM 7090) puis à 5 0000 en 1968(IBM 360). Leur
complexité dont une estimation grossière est le nombre d’interactions entre les différents
composants qui constituent un logiciel, croit en proportion.

II. PROBLEMATIQUE
Dans un environnement marqué par une croissance de plus en plus exponentielle de
nouvelles technologies, l’amélioration continue des besoins dans un système d’information
moderne. Voici un défi global qui pousse les directeurs du système d’information à améliorer
leurs architectures informatique pour suivre la tendance. Dès lors, comment alléger les postes
clients ? Quelle architecture est mieux adaptée pour les conceptions des logiciels ? Comment
implémenter une architecture pour le nouveau système d’exploitation ?

III. PRESENTATION DES ARCHITECTURES

INFORMATIQUE

2
 D’Après Wikipédia, une architecture désigne la structure générale inhérente
à n système informatique, l’organisation des différents éléments du système
(logiciels et/ou matériels et/ou humain et/ou information) et des relations entre
les éléments. Cette structure fait suite à un ensemble de décisions stratégiques
prises durant la conception de tout ou partie du système informatique, par
l'exercice d'une discipline technique et industrielle du secteur de l'informatique
dénommée elle aussi architecture, et dont le responsable est l'architecte
informatique. Il peut y avoir plusieurs diagrammes d'architecture s pour un même
système, tels que : architecture des informations, architecture métier,
architecture applicative et architecture technique.

A. ARCHITECTURE METIER
L'architecture métier décrit les applications informatiques, les principales bases de
données du système informatique d'une institution ou d'une entreprise, les utilisations faites
de ces éléments dans le cadre de l'activité de l'institution et leur alignement à l'organisation
générale de l'institution. La vue métier fait ressortir les éléments historiques et en fin de vie,
les interfaces avec des éléments appartenant à des tiers, ainsi que les possibilités d'ajouter
des nouveaux éléments.Le diagramme d'architecture métier servira à guider la direction de
l'institution dans le choix de création de nouveaux éléments, et aidera les ingénieurs à créer
des produits informatiques en ligne avec les activités et l'organisation générale de l'institution.
Il permettra également d'informer les collaborateurs de l'institution sur son organisation
générale, ses buts, sa stratégie, et les flux d'informations au sein de l'institution.

Figure 1:architecture métier

B. ARCHITECTURE DES INFORMATIONS

L'architecture des informations concerne la manière dont les informations sont
organisées et agrégées : ordre alphabétique, chronologique, taxinomie. Les manières

3
d'accéder à ces informations, la compréhension qu'ont les lecteurs et comment ils manipulent
et s'échangent les informations ainsi que l'organisation de la base de données qui contiendra
les informations. L'architecture repose sur trois axes clés:

 Le contexte: commercial, politique, et culturel qui entoure ces informations.

 Le type d'informations: le format de données, la quantité, et les éventuelles
structures existantes.
 les personnes : l'audience, les tâches des lecteurs/rédacteurs, leurs habitudes
et leur expérience.

Les sites web contenant de nombreuses informations, tels que les sites de vente en ligne, les
médias, les bases de connaissances ou les encyclopédies en ligne sont les premiers concernés
par l'architecture des informations.

Figure 2: architecture des informations

C. ARCHITECTURE LOGICIELLE
L'architecture logicielle est une vue tournée sur l'organisation interne et le découpage
d'un logiciel en modules. Dans les logiciels les caractéristiques communes concernent
les interfaces, c'est-à-dire la connectique qui permet la communication entre les modules,
ainsi que les caractéristiques du matériel informatique et du système d'exploitation sur lequel
le logiciel s'exécutera et les caractéristiques du réseau informatique qui sera utilisé 7.Le
diagramme d'architecture logicielle décrit la nature des différents modules d'un logiciel, les
responsabilités et les fonctionnalités de chaque module, quelle machine va les exécuter, et
quand. Il décrit également la nature des relations entre les modules. Vont-ils s'échanger des
informations ? Un module en pilote-t-il un autre, lui envoie-t-il des informations, ou lui fait-il

4
des demandes ? En ingénierie informatique le diagramme d'architecture donne une première
série de réponses sur comment sera le futur logiciel, avant le début du travail
de programmation.

Figure 3: Architecture logicielle

D. ARCHITECTURE MATERIELLE
Le mot architecture matérielle est parfois utilisé pour désigner l'architecture du jeu
d'instructions d'un processeur. L'architecture matérielle comprend toutes les caractéristiques
générales, la conception, le choix et l'organisation des différents dispositifs électroniques des
appareils informatiques (ordinateurs personnels, serveurs, assistants personnels, téléphones
portables, consoles de jeu...). L'architecture est fonction du type d'appareil, du client cible, de
l'espace d'adressage - qui est fonction du nombre de bits utilisés pour les adresses mémoire,
du système d'exploitation et du langage de programmation cible. L’architecture matérielle est
un premier élément de réponse sur la manière de concevoir le futur ordinateur, recherchant
la performance tout en respectant les contraintes de coût, de consommation électrique et de
fiabilité. Le choix de l'architecture est inspiré par le marché, en particulier par les logiciels
applicatifs existants et auxquels l'appareil est destiné. La conception d'une architecture
matérielle requiert la connaissance d'une large gamme de technologies concernant
les compilateurs, les systèmes d'exploitation, les circuits logiques et l'isolation. L’architecture
du jeu d'instruction est le point de rencontre entre le matériel et le logiciel informatique. Selon
son architecture, le jeu d'instruction peut être de type register-memory - chaque instruction
peut être effectuée sur le contenu d'une adresse mémoire ou d'un registre - ou du type load-
store - toutes les instructions sont effectuées sur des registres sauf les

5
instructions load et store qui copient des informations de et vers une certaine adresse
mémoire.

Figure 4:Architecture Matérielle

E. ARCHITECTURE TECHNIQUE
L'architecture technique est une vue tournée sur l'organisation logique de la plateforme
informatique, c'est-à-dire les moyens techniques clés qui seront utilisés par tous les logiciels
applicatifs. La vue contient le matériel informatique, les logiciels systèmes, les middlewares,
ainsi que les réseaux de télécommunication et les relations entre ces différents éléments. Pour
une entreprise ou une institution, le choix de l'architecture technique vise à maximiser les
possibilités d'implantation de logiciels du commerce ainsi que de réalisation de logiciels sur
mesure. Il vise également à rentabiliser l'utilisation du matériel et des logiciels déjà acquis par
l'institution. Pour une entreprise ou une institution qui transforme son architecture technique,
le plan d'architecture est accompagné d'un planning et d'un budget des acquisitions, des
ventes et des opérations de migration nécessaires pour aligner le système informatique avec
le plan.

Figure 5: Architecture technique

6
 IV. LANGAGE DE PROGRAMMATION
Entre 1842 et 1843, une jeune comtesse du nom d'Ada Lovelace traduisait le mémoire
d'un mathématicien italien du nom de Luigi Menabrea sur la machine analytique proposée
par Charles Babage. À cette traduction, la jeune comtesse avait ajouté ses propres notes dont
l'une décrivait de façon détaillée une séquence progressive d'opérations pour résoudre
certains problèmes mathématiques. Le premier programme était né. Depuis cette époque les
choses n'ont pas bien évolué. De 1957 à 1959 on note le développement des langages Fortran,
Lisp et COBOL. À partir de 1970 on assiste à la naissance du Pascal créé par Niklaus Wirth.
En 1972 le C (premier au classement de TIOBE) fait son apparition. Créé par le regretté Denis
Ritchie, ce langage a servi à coder le système Unix. L'année 1995 voit la naissance de trois
langages populaires, Java créé par James Gosling, PHP créé par Rasmus Lerdof et JavaScript
par Brendan Eich. La tendance pour les langages de programmation est à la hausse et leur
nombre s'en va sans cesse grandissant.

Avant 1940
Au départ, les langages étaient de simples codes . Pendant neuf mois entre 1842 et
1843, Ada Lovelace a traduit le mémoire du mathématicien italien Luigi Menabrea sur
la machine analytique, la dernière machine proposée par Charles Babbage. Elle ajouta cet
article à une collection de notes dans lesquelles elle détaillait une méthode pour calculer
les nombres de Bernoulli à l'aide de la Machine. Ces notes furent reconnues par certains
historiens comme le premier programme informatique au monde1 Mais l'étendue des
contributions originales d'Ada Lovelace, comparées à celles de son mari, est l'objet de débat
parmi certains biographes[réf. souhaitée]2.

En 1801, le métier Jacquard utilisait des trous dans des cartes perforées pour représenter les
mouvements du bras du métier à tisser, et ainsi générer automatiquement des motifs
décoratifs.

En observant les tickets de trains, où était décrite l'apparence du voyageur à l'aide de trous
perforés sur les tickets (couleur des cheveux et des yeux, taille…), Herman Hollerith s'est rendu
compte qu'il pouvait encoder de l'information sur des cartes perforées. Il a pu ainsi créer une
machine à cartes perforées qui a servi au recensement de 1890.

7
À leurs débuts, les langages de programmation étaient très influencés par les restrictions
matérielles. De ce fait, le premier vrai langage de programmation est difficile à identifier. Par
exemple, les cartes perforées pouvaient avoir 80 colonnes, certaines d'entre elles étant
utilisées comme numéro de tri sur chaque carte. Plus tard, les mémoires utilisées dans les
premiers ordinateurs étaient faites de tambours magnétiques. Les programmes devaient donc
tenir compte des rotations du tambour. Ils étaient donc beaucoup plus dépendants du
matériel qu'à l'heure actuelle.

Pour certaines personnes, il est nécessaire que les « programmes » soient facilement lisibles
par des êtres humains, et que la puissance mise en œuvre soit suffisante, pour pouvoir parler
de langage de programmation. Le Métier Jacquart et la machine Analytique de Charles
Babbage avaient des langages extrêmement simples et limités pour décrire les actions
effectuées par ces machines. On peut également considérer les rouleaux en papier d'un
pianola (piano mécanique) comme un programme limité à un domaine très particulier,
quoique non destiné à être exploité par des humains

Les années 1940

Les premiers ordinateurs électriques de l'ère moderne sont apparus dans les années
1940. Les limitations en rapidité et en capacité de mémoire imposent une écriture des
programmes laborieuse en langage assembleur voire langage machine, optimisés « à la
main ». On constate très vite qu'en plus de nécessiter beaucoup d'effort intellectuel, cette
manière de programmer engendre un certain nombre d'erreurs.

En 1948, Konrad Zuse publie un article sur son langage de programmation qu'il a développé
entre 1943 et 1945 : le Plankalkül. Son créateur le considère comme étant le premier langage
de programmation de haut niveau. Néanmoins, il n'aura jamais été implémenté à l'époque et
les contributions de l'auteur sont d'ailleurs restées très isolées du courant dominant.

Parmi les langages importants développés à cette période on peut citer :

 1943 : Le Plankalkül
 1943 : Le langage de programmation de l'ENIAC
 1948 : Le langage machine du premier programme enregistré, i.e. le jeu
d'instructions de la SSEM : première machine à programme enregistré.

8
  1949 : Le langage C-10

Les années 1990

Les années 1990 voient peu de nouveautés fondamentales apparaître. Au contraire,
beaucoup d'idées anciennes sont combinées et portées à maturité, pour augmenter la
productivité des programmeurs et la fiabilité des programmes. Beaucoup de langages pour le
« développement rapide d'applications » (RAD : rapid application development) apparaissent.
Ce sont souvent des descendants de langages plus anciens. Ils sont généralement orientés
objet et fournis avec un environnement de développement intégré ainsi qu'avec un ramasse-
miettes (mise à jour des tables d'allocation de mémoire pour récupérer les emplacements qui
ne sont plus utilisés). C'est ainsi que sont apparus Pascal Objet, Visual Basic et C#.

Java, de Sun Microsystem, est un langage comportant une large palette de classes
réutilisables. Il possède un ramasse-miettes. Il a eu un développement important dans
l'industrie du logiciel.

Les nouveaux langages de scripts, héritiers des langages de commande intégrés dans les
systèmes d'exploitation, ont une approche plus novatrice parce qu'ils sont interprétés.
Certains sont intégrés dans des pages Web. Ils présentent de nouvelles caractéristiques
syntaxiques et de nouvelles fonctionnalités leur sont incorporées de manière à faciliter
l'enchaînement de commandes simples. Ils fonctionnent bien quand les programmes sont
petits. Les programmes plus gros sont plus difficiles à mettre en œuvre et à maintenir que des
programmes compilés analogues.

Quelques langages importants ont été développés au cours de cette période :

 1990 - Haskell
 1991 - Python
 1993 - Ruby
 1993 - Lua
 1994 - ANSI Common Lisp
 1995 - JavaScript
 1995 - Java
 1995 - PHP

9
  2000 - C#

Tendance actuelle
L'évolution des langages de programmation continue, à la fois dans l'industrie et la
recherche. Quelques tendances actuelles :

1. Ajouter de la sécurité et de la sûreté, notamment dans la vérification du langage

(analyse statique de programmes), dans le contrôle du flux d'information (format des
entrées/sorties) et dans la protection lors de l'exécution de threads simultanés
(threadsafe).
2. Nouveaux concepts concernant la modularité : les mixin, la délégation,
la programmation orientée aspect.
3. Le développement orienté composant.
4. La métaprogrammation, et en particulier la réflexivité ou la manipulation de l'arbre
syntaxique abstrait.
5. Concentration sur la distribution et la mobilité.
6. Intégration avec les bases de données, en particulier les bases de données
relationnelles et XML.
7. Internationalisation avec le support de l'Unicode dans le code source : possibilité
d'utiliser différents caractères dans le code source (en dépassant les limites de l'ASCII).
8. Utilisation généralisée d'XML, notamment pour les interfaces graphiques (XUL, XAML).

V. LA NAISSANCE DES SYSTEME D’EXPLOITATION

La conception des systèmes d’exploitation des ordinateurs est soumise à une tension
entre deux objectifs contradictoires : améliorer le confort des utilisateurs ; exploiter
efficacement les ressources physiques des machines. Le début de l’histoire de ces systèmes
traduit bien le va-et-vient entre ces objectifs.

i. La préhistoire
Les premiers ordinateurs n’avaient pas à proprement parler de système d’exploitation,
et cette situation dura de 1949 avec les premières machines à programme enregistré jusqu’en

10
1956, année du premier moniteur de traitement par lots. En effet, les langages initialement
utilisés étaient très proches de la machine physique : code binaire, assembleurs primitifs,
collections de sous-programmes. D’autre part, le partage de la machine se faisait simplement
par réservation : chaque utilisateur avait la machine pour lui seul pendant une tranche de
temps déterminée. En ce sens, l’exploitation des ordinateurs privilégiait le confort des
utilisateurs, donc le côté « ergonomie ».
On peut néanmoins noter les premiers embryons de mécanismes d’assistance à l’utilisation
des ordinateurs. L’EDSAC de Cambridge, première machine à programme enregistré, avec
le Manchester Mark-1, utilisait une forme rudimentaire de langage assembleur, où les
instructions étaient écrites sous forme symbolique et les adresses (absolues) sous forme
décimale. Les programmes, enregistrés sur ruban perforé, étaient traduits en binaire et placés
en mémoire par un mécanisme appelé « ordres initiaux », lui-même enregistré sur une
mémoire externe en lecture seule. Plus tard furent introduits les sous-programmes, conservés
dans une bibliothèque sous forme de rubans ; ceux-ci devaient être physiquement copiés
avant exécution, sur le ruban contenant le programme principal. Les ordres initiaux devaient
donc assurer ce qu’on appelle aujourd’hui l’édition de liens, c’est-à-dire fixer les adresses
d’appel et de retour des sous-programmes pour garantir leur exécution correcte. D’autres
langages primitifs utilisant des sous-programmes furent développés plus tard, notamment sur
UNIVAC par Grace Hopper. Leur traduction en langage machine était cette fois à la charge
d’un programme enregistré, mais l’exploitation de l’ordinateur restait sous contrôle manuel.
Compte-tenu de l’important investissement que représentait à l’époque l’achat d’un
ordinateur, il n’est pas étonnant que l’on ait recherché les moyens de rendre son exploitation
plus efficace. Les programmes des utilisateurs furent ainsi regroupés en lots ou fournées (en
anglais batch), pour les traiter en série, sans transitions. Une nouvelle fonction apparut, celle
d’opérateur, un technicien chargé de préparer les lots d’entrée à partir des programmes
fournis par les utilisateurs, de surveiller l’exécution des travaux, et de distribuer les résultats
de sortie. L’enchaînement des travaux était réalisé par un programme appelé moniteur, ou
système de traitement par lots, qui fut la première forme de système d’exploitation.
L’économie prit alors le pas sur l’ergonomie, les usagers étant désormais privés de l’accès libre
à la machine et de la mise au point interactive

Le traitement par lots et la course à l’efficacité

Principes de fonctionnement
11
Les principaux périphériques des ordinateurs des années 1950 étaient les lecteurs de cartes
perforées, les imprimantes et les dérouleurs de bandes magnétiques. Dans le schéma initial,
les travaux à exécuter avaient la forme d’un paquet de cartes, préparé par l’utilisateur ou par
un atelier de perforation. Un programme résidant en permanence en mémoire, le moniteur
d’enchaînement, avait pour rôle de lire les cartes, de lancer l’exécution des programmes et
d’imprimer les résultats.

//job
//fortran
<cartes constituant un programme en Fortran>
//run
//data
<données pour le programme Fortran>
//job
<le travail suivant>
…

Des cartes particulières, les cartes de commande, s’adressaient au moniteur en lui

spécifiant quel programme il devait lancer. Ainsi, dans le petit exemple ci-contre, les lignes
commençant par // représentent le contenu des cartes de commande. La
ligne //fortran indique au moniteur qu’il doit lancer le compilateur Fortran pour traduire le
texte qui suit ; la ligne //run demande l’exécution du résultat de la compilation, en utilisant
les données qui suivent la ligne //data.
Il est intéressant de noter que le premier système d’exploitation fonctionnant sur ce
principe, GM-NAA I/O a été développé sur IBM 704 par des entreprises utilisatrices, General
Motors et North American Aviation, et non par IBM, le constructeur de la machine. IBM devait
fournir plus tard un système comparable, IBSYS, pour les ordinateurs de la série 7000.
Aussi simple soit-il, un tel système pose deux problèmes de sécurité :

 si un programme d’utilisateur tourne en boucle infinie, par suite d’une faute de

programmation, l’exécution du lot est bloquée indéfiniment (l’opérateur peut certes
intervenir, mais il doit alors avoir une idée de la durée maximale du travail) ;
 toujours à la suite d’une faute de programmation, un programme d’utilisateur peut écrire
« n’importe où » dans la mémoire, et en particulier dans la zone réservée au moniteur. Il
y a de nouveau un risque de blocage ou de dysfonctionnement de l’ensemble.

12
Deux innovations matérielles permirent de remédier à ces problèmes.

Figure 6: Fonctionnement du traitement par lots

En premier lieu, une horloge programmable, pouvant interrompre l’unité centrale

après écoulement d’un délai spécifié. L’utilisateur devait alors préciser sur une carte de
commande une durée maximale pour son travail, dans des limites fixées. Si ce temps
d’exécution était dépassé, le moniteur interrompait le travail et passait au travail suivant. En
second lieu, un dispositif permettant de protéger une zone de mémoire contre l’écriture. Le
programme du moniteur était placé dans une zone ainsi protégée.

ii. Où en est-on aujourd’hui ?

Avec l’apparition de la micro-informatique et la banalisation d’ordinateurs de plus en
plus puissants, avec les changements d’ordres de grandeur des vitesses des processeurs, des
tailles de mémoire et des disques, on pourrait penser que les systèmes modernes n’ont plus
rien à voir avec les systèmes historiques. Il n’en est rien, et tous les concepts des systèmes
actuels étaient bien connus au début des années 1970. L’un des systèmes phares, MacOS X [6],
est directement construit sur une version d’Unix. Linux, une version open source d’Unix,
équipe de nombreuses installations, tant dans les universités et centres de recherche que dans
l’administration et l’industrie. La complexité des systèmes d’exploitation explique sans doute
ce conservatisme, dont le résultat est de fait la normalisation autour d’un très petit nombre
de systèmes.
Plutôt que sur une redéfinition de la structure de base des systèmes, l’accent a été mis sur
l’interaction avec l’utilisateur (écrans graphiques et fenêtres, clavier, souris). Après leur

13
introduction dans le Perq et l’Apple Lisa, c’est le Macintosh qui a popularisé ces idées qui sont
maintenant reprises par l’ensemble des systèmes pour ordinateur individuel (voir à ce propos
l’article « Xerox PARC et la naissance de l’informatique contemporaine »).
Les données ne sont plus de simples textes, mais des structures complexes comprenant des
textes associés à des images, des sons et des films. La conservation fiable et à long terme de
ces données fait largement appel à la virtualisation à grande échelle s’appuyant sur
d’abondantes ressources réparties (cloud computing). Le souci d’économie revient sous une
nouvelle forme : plutôt que le coût du matériel, c’est l’énergie consommée par ces
concentrations de machines qu’il s’agit maintenant de réduire.
La vision centralisatrice du système telle qu’on la concevait au début des années 1970 est
définitivement abandonnée au profit d’une structure répartie. Mais les questions éthiques
posées par cette structure centralisée (ordinateur Big Brother) sont toujours présentes, avec
la difficulté d’assurer confidentialité et sécurité dans un environnement où tout est en ligne.
Même si les ordinateurs individuels sont la plupart du temps oisifs, la course à la puissance de
calcul se poursuit, tirée par les applications (images animées, simulation de systèmes
complexes, jeux vidéo). Elle repose sur le parallélisme, soit à l’intérieur d’un processeur
(structure multicœur), soit à l’aide de calculateurs interconnectés (grappes de milliers de
machines ).
Enfin, la généralisation de l’informatique enfouie (embedded systems) dans presque tous les
appareils de la vie courante a donné lieu au développement à la carte de systèmes adaptés à
des appareils et à des applications spécifiques : téléphonie mobile (smartphones), réseaux de
capteurs, automobile, avionique, etc. Ces systèmes étant en général plus petits et plus simples
que les systèmes à usage général, on peut prévoir qu’il sera possible à terme de les certifier,
c’est-à-dire d’établir rigoureusement leur conformité à leurs spécifications. Des avancées
spectaculaires ont récemment eu lieu dans ce sens (voir l’article Les débuts d’une approche
scientifique des systèmes d’exploitation).

VI. LES TYPES D’ARCHITECTURES EN COUCHE

En règle générale, une application informatique peut être découpée en trois niveaux
d’abstraction distincte :

14
 la couche de présentation, encore appelée IHM, permet l'interaction de l'application avec
l'utilisateur. Cette couche gère les saisies au clavier, à la souris et la présentation des
informations à l'écran. Dans la mesure du possible, elle doit être conviviale et
ergonomique.
 la logique applicative, les traitements, décrivant les travaux à réaliser par l'application. Ils
peuvent être découpés en deux familles :
 les traitements locaux, regroupant les contrôles effectués au niveau du dialogue
avec l'IHM, visant essentiellement le contrôle et l'aide à la saisie,
 les traitements globaux, constituant l'application elle-même. Cette couche,
appelée Business Logic ou couche métier, contient les règles internes qui
régissent une entreprise donnée.
 les données, ou plus exactement l'accès aux données, regroupant l'ensemble des
mécanismes permettant la gestion des informations stockées par l'application.

Ces trois niveaux peuvent être imbriqués ou répartis de différentes manières entre plusieurs
machines physiques
Le noyau de l'application est composé de la logique de l'affichage et la logique des traitements.
Le découpage et la répartition de ce noyau permettent de distinguer les architectures
applicatives suivantes :
 l'architecture 1-tiers
 l'architecture 2-tiers,
 l'architecture 3-tiers,
 les architectures n-tiers.

Nous allons faire un rapide tour des premières architectures, en introduisant

progressivement les notions utiles à leur compréhension, et nous attardé ensuite plus
longuement sur les architectures n-tiers.

15
 a. Architecture un tiers
Présentation

Dans une application un tiers, les trois couches applicatives sont intimement liées et
s'exécutent sur le même ordinateur. On ne parle pas ici d'architecture client-serveur, mais
d'informatique centralisée. Dans un contexte multi-utilisateurs, on peut rencontrer deux
types d'architecture mettant en œuvre des applications un tiers:
 des applications sur site central,
 des applications réparties sur des machines indépendantes communiquant par
partage de fichiers.

Les solutions sur site central (mainframe)

Historiquement, les applications sur site central furent les premières à proposer un
accès multiutilisateurs. Dans ce contexte, les utilisateurs se connectent aux applications
exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs se comportant
en esclaves. C'est le serveur central qui prend en charge l'intégralité des traitements, y
compris l'affichage qui est simplement déporté sur des terminaux passifs

Figure 7:Architecture sur une application site centrale

Ce type d'organisation brille par sa grande facilité d'administration et sa haute disponibilité. Il

bénéficie aujourd'hui d'une large palette d'outils de conception, de programmation et
d'administration ayant atteint un niveau de maturité et de fiabilité leur permettant encore de
soutenir la comparaison avec des solutions beaucoup plus modernes. De plus, 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 (en batch). L'émergence des
interfaces utilisateur de type Windows - Macintosh, démocratisées par les outils bureautiques
16
sur micro-ordinateur, a fortement démodé les applications mainframe. Ces dernières
exploitaient exclusivement une interface utilisateur en mode caractère jugée obsolète par les
utilisateurs, qui réclamaient alors massivement une convergence entre la bureautique et le
système d'information de l'entreprise. Le ré-habillage d'application centralisée, ou revamping,
permet de rajeunir ces dernières en leur faisant profiter d'une interface graphique moderne
(GUI3.3), mais au prix d'une telle lourdeur qu'il doit être considéré comme une simple étape
vers une architecture plus moderne.

Les applications un tiers déployées

Avec l'arrivée dans l'entreprise des premiers PC en réseau, il est devenu possible de
déployer une application un tiers sur plusieurs ordinateurs indépendants.
Ce type de programme est simple à concevoir et à mettre en œuvre. Il existe pour cela de
nombreux environnements de développement (dBase, Ms Access, Lotus Approach, Paradox...
) qui sont souvent intégrés aux principales suites bureautiques. L'ergonomie des applications
mises en œuvre, basée sur celle des outils bureautiques, est très riche. Ce type d'application
peut être très satisfaisant pour répondre aux besoins d'un utilisateur isolé et sa mise en œuvre
dans un environnement multi-utilisateur est envisageable. Dans ce contexte, plusieurs
utilisateurs se partagent des fichiers de données stockés sur un serveur commun. Le moteur
de base de données est exécuté indépendamment sur chaque poste client. La gestion des
conflits d'accès aux données doit être prise en charge par chaque programme de façon
indépendante, ce qui n'est pas toujours évident. Lors de l'exécution d'une requête,
l'intégralité des données nécessaires doit transiter sur le réseau et on arrive vite à saturer ce
dernier. De plus, la cohabitation de plusieurs moteurs de base de données indépendants
manipulant les mêmes données peut devenir assez instable. Il n'est pas rare de rencontrer des
conflits lors de la consultation ou de la modification simultanée d'un même enregistrement
par plusieurs utilisateurs. Ces conflits peuvent altérer l'intégrité des données. Enfin, il est
difficile d'assurer la confidentialité des données. Ce type de solution est donc à réserver à des
applications non critiques exploitées par de petits groupes de travail (une dizaine de
personnes au maximum).

Limitations

17
On le voit, les applications sur site central souffrent d'une interface utilisateur en mode
caractères et la cohabitation d'applications micro exploitant des données communes n'est pas
fiable au-delà d'un certain nombre d'utilisateurs. Il a donc fallu trouver une solution conciliant
les avantages des deux premières :
 la fiabilité des solutions sur site central, qui gèrent les données de façon centralisée,
 l'interface utilisateur moderne des applications sur micro-ordinateurs.
Pour obtenir cette synthèse, il a fallu scinder les applications en plusieurs parties
distinctes et coopérants
 gestion centralisée des données,
 gestion locale de l'interface utilisateur. Ainsi est né le concept du client-serveur.

2. Architecture deux tiers

Présentation
Dans une architecture deux tiers, encore appelée client-serveur de première génération
ou client-serveur de données, le poste client se contente de déléguer la gestion des données
à un service spécialisé. Le cas typique de cette architecture est l'application de gestion
fonctionnant sous Ms-Windows et exploitant un SGBD centralisé. Ce type d'application
permet de tirer parti de la puissance des ordinateurs déployés en réseau pour fournir à
l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent
gérées de façon centralisée. La gestion des données est prise en charge par un SGBD
centralisé, s'exécutant le plus souvent sur un serveur dédié. Ce dernier est interrogé en
utilisant un langage de requête qui, le plus souvent, est SQL. Le dialogue entre client et serveur
se résume donc à l'envoi de requêtes et au retour des données correspondant aux
requêtes. Ce dialogue nécessite l'instauration d'une communication entre client et serveur.
Nous allons étudier de quoi elle se compose.
Le dialogue client-serveur
Le modèle client-serveur met en oeuvre une conversation entre deux programmes que
l'on peut opposer à l'échange figé ``maître-esclave'' qu'entretiennent les applications sur site
central avec leurs terminaux passifs. Dans une conversation client-serveur, on distingue donc
les deux parties suivantes:
 Le client, c'est le programme qui provoque le dialogue,

18
  Le serveur, c'est le programme qui se contente de répondre au client.

Figure 8: A la base du dialogue, un besoin du client

Le client provoque l'établissement d'une conversation afin de d'obtenir des données ou un

résultat de la part du serveur.

Figure 9:Accès aux données en mode deux tiers

Cet échange de messages 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
middleware.
Le Middleware
Définition
On appelle middleware, littéralement ``élément du milieu'', l'ensemble des couches réseau et
services logiciel qui permettent le dialogue entre les différents composants d'une application
répartie. Ce dialogue se base sur un protocole applicatif commun, défini par l'API du
middleware.
Le Gartner Group définit le middleware comme une interface de communication universelle
entre processus. Il représente véritablement la clef de voûte de toute application client-
serveur. L'objectif principal du middleware est d'unifier, pour les applications, 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.

19
 Figure 10: positionnement du middleware entre client et serveur

Limites du client-serveur deux tiers : Le client lourd

L'expérience a démontré qu'il était coûteux et contraignant de vouloir faire porter l'ensemble
des traitements applicatifs par le poste client. On en arrive aujourd'hui à ce que l'on appelle
le client lourd, ou fat client. L'architecture client-serveur de première génération s'est heurtée
à ce constat à l'heure des premiers bilans :
 on ne peut pas soulager la charge du poste client, qui supporte la grande majorité des
traitements applicatifs,
 le poste client est fortement sollicité, il devient de plus en plus complexe et doit être
mis à jour régulièrement pour répondre aux besoins des utilisateurs,
 la conversation entre client et serveur est assez bruyante et s'adapte mal à des bandes
passantes étroites. De ce fait, ce type d'application est souvent cantonné au réseau
local de l'entreprise,
 les applications se prêtent assez mal aux fortes montées en charge car il est difficile de
modifier l'architecture initiale,
 la relation étroite qui existe entre le programme client et l'organisation de la partie
serveur complique les évolutions de cette dernière,
 ce type d'architecture est grandement rigidifié par les coûts et la complexité de sa
maintenance.
Malgré tout, l'architecture deux tiers présente de nombreux avantages qui lui permettent de
présenter un bilan globalement positif :
 elle permet l'utilisation d'une interface utilisateur riche,
 elle a permis l'appropriation des applications par l'utilisateur,
 elle a introduit la notion d'interopérabilité.

20
Pour résoudre les limitations du client-serveur deux tiers tout en conservant ses avantages,
on a cherché une architecture plus évoluée, facilitant les forts déploiements à moindre coût.
La réponse est apportée par les architectures distribuées.

3. Architecture trois tiers

Objectifs
Les limites de l'architecture deux tiers proviennent en grande partie de la nature du client
utilisé :

 le frontal est complexe et non standard (même s'il s'agit presque toujours d'un PC sous
Windows),

 le middleware entre client et serveur n'est pas standard.

La solution résiderait donc dans l'utilisation d'un poste client simple communicant avec le
serveur par le biais d'un protocole standard.
Dans ce but, l'architecture trois tiers applique les principes suivants :

 les données sont toujours gérées de façon centralisée,

 la présentation est toujours prise en charge par le poste client,

 la logique applicative est prise en charge par un serveur intermédiaire.

Les premières tentatives

Les premières tentatives de mise en œuvre d'architecture trois tiers proposaient l'introduction
d'un serveur d'application centralisé exploité par les postes clients à l'aide dialogue RPC
propriétaire.
Les mécanismes nécessaires à la mise en place de telles solutions existent depuis longtemps :

 UNIX propose un mécanisme de RPC intégré au système NFS,

 NetDDE, puis DCOM de Microsoft permettent l'instauration d'un dialogue RPC

entre client et serveur,

 certains environnements de développement facilitent la répartition des

traitements entre le poste client et le serveur,

21
  des solutions propriétaires comme ForT ou Implicite permettent l'exploitation d'un
serveur d'application par des clients simplement équipés d'un environnement
d'exécution (runtime).
Cependant, l'application de ces technologies dans une architecture trois tiers est complexe et
demande des compétences très pointues, du fait du manque de standards. Malgré ses
avantages techniques évidents, ce type d'application fut souvent jugé trop coûteux à mettre
en place. Ce premier essai s'est soldé par un échec dû en grande partie à l'absence de standard
et à la complexité des mécanismes mis en œuvre.

Le serveur de transaction
Ce type de serveur héberge un moniteur transactionnel qui s'occupe de la mise en relation du
client avec un ensemble de serveurs de données. Le serveur transactionnel, interrogé en
utilisant une API unique, masque au client la complexité de l'organisation des serveurs de
données.

Figure 11: fonctionnement d'un moniteur transactionnel

Le moniteur transactionnel permet de garantir que toutes les transactions vérifient la règle
ACID :
 Atomicité : La transaction ne peut être partiellement effectuée,
 Cohérence : Une transaction fait passer la base d'un état cohérent à un autre,
 Isolation : Une transaction n'est pas affectée par le résultat des autres transactions,
 Durée : Les modifications dues à une transaction sont durablement garanties.
En fait, soit une transaction a définitivement eu lieu, soit elle n'a jamais existé.
La notion de serveur transactionnel est citée brièvement ici car elle correspond, à mon avis, à
une architecture trois tiers puisqu'une partie des traitements applicatifs est centralisée.

Répartition des traitements

22
 L'architecture trois tiers, encore appelée client-serveur de deuxième génération ou
client-serveur distribué, sépare l'application en trois niveaux de service distincts :
 premier niveau : l'affichage et les traitements locaux (contrôles de saisie, mise
en forme de données...) sont pris en charge par le poste client,
 deuxième niveau : les traitements applicatifs globaux sont pris en charge par le
service applicatif,
 troisième niveau : les services de base de données sont pris en charge par un
SGBD.

Figure 12:Le découpage d'une application en paves fonctionnels indépendants

Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes,
de ce fait :
 le poste client ne supporte plus l'ensemble des traitements, il est moins sollicité et
peut être moins évolué, donc moins coûteux,
 les ressources présentes sur le réseau sont mieux exploitées, puisque les traitements
applicatifs peuvent être partagés ou regroupés (le serveur d'application peut
s'exécuter sur la même machine que le SGBD),
 La fiabilité et les performances de certains traitements se trouvent améliorées par leur
centralisation,
 il est relativement simple de faire face à une forte montée en charge, en renforçant le
service applicatif.
Dans le cadre d'un Intranet, le poste client prend la forme d'un simple navigateur Web, le
service applicatif est assuré par un serveur HTTP et la communication avec le SGBD met en
œuvre les mécanismes bien connus des applications client-serveur de la première génération.
Ce type d'architecture fait une distinction nette entre deux tronçons de communication
indépendants et délimités par le serveur HTTP :
 Le premier tronçon relie le poste client au serveur Web pour permettre l'interaction
avec l'utilisateur et la visualisation des résultats. On l'appelle circuit froid et n'est

23
 composé que de standards (principalement HTML et HTTP). Le serveur Web tient le
rôle de ``façade HTTP'',
 Le deuxième tronçon permet la collecte des données, il est aussi appelé circuit chaud.
Les mécanismes utilisés sont comparables à ceux mis en œuvre pour une application
deux tiers. Ils ne franchissent jamais la façade HTTP et, de ce fait, peuvent évoluer sans
impacter la configuration des postes clients.

Figure 13:Repartition des couches applicatives dans une architecture trois tiers

Limitations
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é ainsi soulagé et plus simple à gérer.
Par contre, le serveur HTTP constitue la pierre angulaire de l'architecture et se trouve souvent
fortement sollicité et 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.
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é6.22. Le phénomène
fait penser à un retour de balancier. Le juste équilibrage de la charge entre client et serveur
semble atteint avec la génération suivante : les architectures n-tiers.

24
 4. Architecture n-tiers
Présentation
L'architecture n-tiers a été pensée pour pallier aux limitations des architectures trois tiers et
concevoir des applications puissantes et simples à maintenir. Ce type d'architecture permet
de distribuer plus librement la logique applicative, ce qui facilite la répartition de la charge
entre tous les niveaux. Cette évolution des architectures trois tiers met en œuvre une
approche objet pour offrir une plus grande souplesse d'implémentation et faciliter la
réutilisation des développements. Théoriquement, ce type d'architecture supprime tous les
inconvénients des architectures précédentes :
 elle permet l'utilisation d'interfaces utilisateurs riches,
 elle sépare nettement tous les niveaux de l'application,
 elle offre de grandes capacités d'extension,
 elle facilite la gestion des sessions.

Que de niveaux...
L'appellation ``n-tiers'' pourrait faire penser que cette architecture met en œuvre un
nombre indéterminé de niveaux de service, alors que ces derniers sont au maximum trois (les
trois niveaux d'une application informatique). En fait, l'architecture n-tiers qualifie la
distribution d'application entre de multiples services et non la multiplication des niveaux de
service. Cette distribution est facilitée par l'utilisation de composants ``métier'', spécialisés et
indépendants, introduits par les concepts orientés objets (langages de programmation et
middleware). Elle permet de tirer pleinement partie de la notion de composants métiers
réutilisables. Ces composants rendent un service si possible générique et clairement identifié.
Ils sont capables de communiquer entre eux et peuvent donc coopérer en étant implantés sur
des machines distinctes. La distribution des services applicatifs facilite aussi l'intégration de
traitements existants dans les nouvelles applications. On peut ainsi envisager de connecter un
programme de prise de commande existant sur le site central de l'entreprise à une application
distribuée en utilisant un middleware adapté.

Le rôle de l'approche objet

L'approche objet

25
Les évolutions successives de l'informatique permettent de masquer la complexité des
mécanismes mis en œuvre derrière une approche de plus en plus conceptuelle.
Ainsi, les langages de programmation ont tout d'abord été très proches de la machine (langage
machine de bas niveau), puis procéduraux et, enfin, orientés objets. Le succès du langage Java
a véritablement popularisé ce mode de programmation. Les protocoles réseau ont suivi le
même type d'évolution. Ils furent d'abord très proches de la couche physique, avec les
mécanismes de sockets orientés octets. Ensuite, la notion de RPC a permis de faire abstraction
des protocoles de communication et, ainsi, a facilité la mise en place d'application client-
serveur. Aujourd'hui, l'utilisation d'ORB7.1 permet une totale transparence des appels
distants et permet de manipuler un objet distant comme s'il était local. Le flux d'informations
fut donc initialement constitué d'octets, puis de données et, enfin, de messages. Les méthodes
de conception orientées objet telles qu'UML ou OMT permettent une modélisation plus
concrète des besoins et facilitent le passage de la conception à la réalisation. Aucune de ces
évolutions ne constitue en soi une révolution, mais elles rendent économiquement réalisables
des architectures qui n'étaient jusqu'à présent que techniquement envisageables.

26
 CONCLUSION

Avec les applications n-tiers, on dispose enfin d'une vision cohérente du système
d'information. Tous les services sont représentés sous la forme d'objets interchangeables
qu'il est possible d'implanter librement, en fonction des besoins.
Le potentiel de ce type d'application est très important et permettrait enfin l'utilisation
d'objets métiers réutilisables.
Serions-nous en présence de l'architecture parfaite, nous permettant de mettre en oeuvre les
applications les plus ambitieuses au moindre coût et de les faire évoluer librement en
fonction des besoins ?
Si, sur le papier, on pourrait répondre par l'affirmative, l'expérience des précédentes
``révolutions'' de l'informatique nous pousse à plus de modération. L'architecture n-tiers
propose effectivement un potentiel énorme, reste à voir comment il sera utilisé, à quel coût
et, surtout, comment sera gérée la transition depuis les environnements actuels.

27