Chapitre 2 : Systèmes répartis et architectures des

applications informatiques

1. Principe Système répartis

Définition très large : un système réparti est système informatique dans

lequel les ressources ne sont pas centralisées.
Les ressources telles que :
- Stockage (disques durs, bases de données)
- Utilisateurs ;
- Puissance de calcul
Ceci a pour but permettre à des utilisateurs de manipuler (calcul) leurs données (stockage)
sans contrainte sur les localisations respectives des éléments du système, améliorer le
schéma client/serveur en :
- serveurs multiples (équilibrage de charge, redondance)
- Systèmes multi-couches (tiers)
- Peer to peer (P2P)

2. Exemples de système repartis

2.1. Le DNS
Exemple typique d’un système réparti (1984) :
DNS : Domain Name System est le système qui permet de trouver l’adresse IP
associée à un nom de machine.
Exemple : www.dauphine.fr → 193.49.168.65
Système hiérarchique : arbre avec un nom par nœud
Le nom de la racine est vide
chaque noeud est associé à des enregistrements (A pour l’adresse IP, MX pour le
serveur de mail, etc.) ;

- domaine : sous-arbre
o dauphine est un sous-domaine du domaine fr
o ufrmd sous-domaine de dauphine
- nom de domaine : nom d’un noeud (dauphine)
- nom complet : suite des noms des noeuds en remontant dans l’arbre, séparés par . et
sans prendre en compte la racine :
o www.dauphine.fr
o www.ufrmd.dauphine.fr

2.1.1. L’architecture physique DNS

Tout est basé sur un système de délégation et de réplication :
- Un serveur DNS gère un domaine
- Chaque domaine est géré par aux moins 2 serveurs

- Le protocole DNS propose un mécanisme de réplication (Une serveur maître et des

esclaves) ;
- Le gestionnaire d’un domaine peut déléguer la gestion d’un sous-domaine à un autre
gestionnaire :
o Fr délègue la gestion de dauphine.fr aux serveurs de dauphine
o dauphine.fr délègue ufrmd.dauphine.fr aux serveurs.

2.1.2. DNS : Traitement d’une requête

 2.2. Serveur web
Hyper Text Transfert Protocol (HTTP)
C’est une solution de base de type client/serveur intrinsèquement réparti à cause
des liens (par exemple, toutes les requêtes cgi peuvent être exécutée sur un serveur
différent du serveur principal)

Evolutions :
- traitement sur le client (Javascript, Java, Flash, SVG, etc.) répartition des calculs entre
client et serveur
- équilibrage de charge (load balancing ) :
o les requêtes arrivent sur un serveur principal
o elles sont relayées (mécanisme de proxy) sur plusieurs serveurs effectifs
(grâce à mod_rewrite sous apache par exemple)

- Programmes sur le serveur : cgi, servlet, langages de script serveur (JSP, JSF, PHP,
ASP, etc.) → base des architectures multi-niveau

Figure 1 Serveur Web basique

 Figure 2: Serveur web avec équilibrage de charge

2.2. Systèmes multi-couches

Beaucoup d’applications classiques se découpent en plusieurs couches (ou niveau) :
- Présentation : tout ce qui permet l’interaction avec l’utilisateur
- Application (Business ou Métier) : toute la logique applicative (vérification des entrées
de l’utilisateur, etc.) Stockage : stockage permanent des informations relatives à
l’application
Exemple:
- présentation : site web, catalogue papier ( !) application : modalité de réduction, frais de
port, identification du client, etc.
- stockage : SGBD (catalogue, stock, etc.), facturation, analyse des coûts (ERP)

2.2.1 Modèles de Systèmes multi-couches

On peut implémenter une application de nombreuses façons :

- Monolithique : les différents niveaux sont imbriqués dans un programme unique
- Deux couches : presque obligatoire quand on travaille avec un SGBD
o sur le serveur : le SGBD, avec une partie de la logique applicative (contraintes
d’intégrité, procédures stockées, etc.)
o sur le client : présentation et l’autre partie de l’application
- Trois couches (ou plus) :
o client : présentation des objets métier
o objets métier : toute la logique
o applicative SGBD : stockage des objets métier

3 Principe Système répartis

Nous classerons les architectures des SI en 03 catégories :
 - L’architecture centralisée
- L’architecture distribuée multicouche
- Les autres architectures multicouches

3.1 L’architecture centralisée

Dans l’histoire de l’informatique, on a tout d’abord conçu des applications monolithiques, les
sites centraux : C’est l’architecture centralisée. Dans cette architecture, la présentation, les
traitements, les données et toute logique de persistance se trouve sur un seul et unique ensemble
indissociable. Toute l’informatique des entreprises est alors concentré dans un serveur unique :
le mainframe. Il peut éventuellement exister des terminaux mais ce ne sont que des terminaux
passifs. Cette architecture est la première architecture développée pour les logiciels (et les SI)
dès l’avènement de l’informatique

Avantages :

- Simplicité d’administration

- Le fait que les données soient centralisées, fait qu’il peut être facile d’y accéder

- Cette architecture offre à l’entreprise un système totalement cohérent et fiable

Inconvénients :

- La montée en charge. En effet, le fait que tout soit centralisé sur un seul serveur, le rend
moins performant et alourdi les traitements
- Les coûts d’acquisition et d’exploitation sont élevés

- Ce système ne permet pas la mobilité car tout y est centralisé.

- Il ne permet pas d’assurer la haute disponibilité et l’intégrité des données.

3.2 Architecture distribuée et multicouches :
Avec l’invention des PC, des architectures plus légères sont apparues ; elles sont basées
sur des modèles dits client-serveur. Ces architectures proposent globalement de déporter
certains composants du logiciel sur des postes clients et de conserver le serveur pour la
persistance aux données. Ces architectures ont apporté plus de graphisme et de sophistication
en termes d’ergonomie. Les architectures en couches existent en plusieurs modèles mais ce sont
généralement tous des architectures client-serveur.

Avantages

- Faible coût des applications, ce qui entraine leur multiplication au sein des entreprises
pour la messagerie, la gestion financière, l’aide à la décision…
- L’informatique commence à être utilisée par les métiers et progressivement par tous les
profils de l’entreprise. Ce qui entraine une évolution rapide des Systèmes d’Information,
à la suite d’initiatives éparses des différents départements et métiers de l’entreprise.

Inconvénient

- L’absence de gouvernance de cette croissance a souvent abouti à des duplications

d’informations, saisies et gérées de manière autonome par ces différents services
- L’enthousiasme autour des applications client/serveur a engorgé les postes de travail de
multiples exécutables difficiles à maintenir et dotés d’interfaces incohérentes. Cette
multiplication des interfaces s’est révélée complexe à maîtriser et donc improductive
pour l’utilisateur.

3.3 Les applications Web

À la fin des années 1990, les problématiques de déploiement et de gestion des parcs de PC ont
montré les limites des applications client/serveur. De plus, un nouveau besoin s’est fait sentir :
celui de proposer l’accès aux applications non plus seulement aux employés de l’entreprise,
mais aussi à ses clients et partenaires. C’est l’arrivée des applications web.

Avantages - apports

- Accès facile à l’aide d’un simple navigateur.

- Elles ont permis d’intégrer les clients et partenaires aux processus métiers de l’entreprise
- Développement du commerce électronique.
- Réduction des coûts de gestion et de licence du parc informatique.
La montée en puissance de la programmation orientée objet a accompagné le développement
des applications Web avec tous les bénéfices qu’on connaît : usage de composants et des
Frameworks, réutilisabilité, modélisation UML, etc. Cependant, les architectures n-Tiers,
associées à ces technologies, ont augmenté le morcellement du SI.

Les applications web ont favorisées la multiplication des applications qui est de plus en plus
croissante. Ceci a introduit les problèmes d’hétérogénéité auxquels font face les DSI (Direction
des Systèmes d’Information). Ils doivent trouver un moyen d’organiser et de maîtriser cette
hétérogénéité

3.4 Autres architectures

3.4.1 EDA (Event Driven Architecture)

C’est un modèle d’architecture posant comme principe fondateur la propagation automatisée

des événements métiers dans le Système d’Information. L’objectif est d’éviter, autant que
possible, la désynchronisation de multiples référentiels, et surtout d’assurer un traitement en
temps réel de ces événements, ni trop tard ou, pire, jamais effectué. EDA ne permet pas une
réelle automatisation des processus métiers. D’où l’émergence du modèle POA.

3.4.2 POA (Process Oriented Architecture)

C’est un modèle d’architecture posant comme principe fondateur que toute application du SI
doit être modélisée comme un processus, et comme conséquence la nécessité de mettre en place
un moteur (de type workflow) pour automatiser ces processus.

Le point de départ de POA est important : en considérant que toute application du SI traite en
réalité un événement métier, ce modèle recentre les efforts de modélisation sur l’objectif
prioritaire du SI, à savoir la capture, le traitement et l’historique des événements métiers.

3.4.3 SOA (Service Oriented Architecture, ou architecture orientée services)

Un service, au sens SOA, met à disposition d’acteurs (humains ou logiciels) intervenants dans
des processus métiers, un accès vers une ou plusieurs fonctions métiers.

Un service concrétise le lien entre la couche métier (constituant le côté consommateur) et les
implémentations dans le SI (constituant le côté fournisseur) en prenant à sa charge un contrat
(réalisé par le côté pourvoyeur).

Le terme de service est introduit par analogie avec le monde réel : lorsqu’il utilise un service
de distribution de billets de banque via un distributeur automatique de billets, le consommateur
de ce service n’a pas à connaître le fonctionnement technique du distributeur et encore moins
le détail de ses connexions avec les serveurs des différentes banques impliquées. Cette
simplicité, liée à un effort de standardisation du dialogue homme-machine, permet à n’importe
quel consommateur de (ré) utiliser le service avec un minimum d’effort cognitif.

Un service vise donc à être simple d’emploi et réutilisable.

Par exemple, un service de calcul de montant d’une commande permet à un utilisateur de ce

service d’obtenir un montant toutes taxes comprises. Ce calcul peut faire appel à un moteur de
tarification et à un calculateur de taxe, mais l’utilisateur n’a pas à s’en préoccuper.

L’essor d’Internet permet également d’envisager d’accéder à des services offerts par le SI d’une
autre entreprise. Réciproquement, il est envisageable d’ouvrir ses propres services au « monde
extérieur » de façon contrôlée (accès extranet) ou non (accès internet). Un service doit donc
être interopérable via Internet – au moins pour certains d’entre eux.

SOA propose un modèle d’architecture informatique basé sur l’émergence d’une couche de
services.

Ces services offrent une vue « logique » des traitements et données existant déjà ou à
développer. Chaque service encapsule ces traitements et données et masque ainsi l’hétérogénéité
du système d’information. L’exemple suivant illustre le propos.

Un service « gestion des clients » offre par exemple une « vision client » unifiée. Pour cela il
agrège les informations éparses dans le SI : il récupère la fiche d’identité du client et les noms
des contacts dans le logiciel CRM (Customer Relation Management ou Gestion de la relation
client), le contrat du client dans l’ERP et les éventuels contentieux dans un outil spécialisé. Tout
ce travail d’agrégation est masqué aux utilisateurs de ce service.

Le service « gestion du catalogue produit » met à disposition les informations sur les produits
de l’entreprise. Ce service masque l’accès à l’ERP (récupération des tarifs), l’accès à l’outil de
PLM (récupération de certaines caractéristiques techniques), et l’accès au Catalogue Marketing
(promotions en cours).

Le service « gestion des stocks » met à disposition les informations récupérées soit dans le
mainframe de l’entreprise (pour les usines et les entrepôts) soit dans les serveurs des filiales non
intégrées.
3.4.4 Relation EDA, POA et SOA
On peut cependant considérer que l’évolution certes récente de SOA conduit à intégrer la
problématique POA dans le modèle SOA. Autrement dit, le modèle SOA propose non seulement
une vision « service » de l’architecture du SI, mais également une vision « processus
». On peut également considérer que SOA constitue l’aboutissement de la démarche EDA, en
prenant en compte les aspects « propagation d’événement et synchronisation des référentiels ».