Introduction

aux systèmes et applications

distribués

Master RSSI/Réseaux et Systèmes Répartis

1ème année (Semestre 2)
UDL-SBA

Dr BOUAMAMA Samah

2016/2017
 Systemes distribués ou répartis

• Un système distribué est une collection d’ordinateurs indépendants qui

apparaissent à l utilisateur comme un seul système cohérent.
• Un système distribué ou reparti est un système dont les composants
communiquent et coordonnent leurs actions uniquement par l’échange de
messages.

Autre Définitions
• Un système réparti ou distribué se compose d'un ensemble d'ordinateurs
autonomes joints par un réseau informatique et équipés d ’un logiciel
réparti.
 Systèmes distribués

On déduit des définitions précédentes

• Une absence de base de temps commune;
• Une absence de mémoire commune;
• Les pannes de composants sont indépendantes;
• La communication par messages.

Exemples de systèmes distribués:

• Internet;
• Intranet;
• Les systèmes mobiles.
 Propriétés des Systèmes distribués

• Partage de ressources matérielles et logicielles:

• Chaque ressource est gérée par un gestionnaire de ressources
• Ouverture:
• Permettre l’ajout d ’autres composantes logicielles ou matérielles
• Concurrence:
• Plusieurs processus s’exécutant en parallèle .
• Transparence:
• Données, localisation,…
• Dissimuler la répartition des composantes
• Tolérance aux pannes:
• Pannes détectés et récupérés.
• Redondances matérielles et logicielles
• Mise à l ’échelle:
• Fonctionner efficacement à différentes échelles:
• De quelques postes à un grand nombre reliés par des réseaux (LAN, WAN, internet, …)
• La sécurité
• La confidentialité
• L intégrité des messages échanges et autres

 L’ interopérabilité
 Elle est assurée principalement par des middlewares , CORBA, DCOM, RMI, Service Web,
RPC,..
 Systèmes et applications répartis

• Distinction entre “système” et “application”

• Système : gestion des ressources communes et de l’infrastructure, lié de manière étroite
au matériel sous-jacent
• Système d’exploitation : gestion de chaque élément
• Système de communication : échange d’information entre les éléments
• Caractéristiques communes : cachent la complexité du matériel et des
communications, fournissent des services communs de plus haut niveau
d’abstraction
• Application : réponse à un problème spécifique, fourniture de services à ses utilisateurs
(qui peuvent être d’autres applications). Utilise les services généraux fournis par le
système.
• La distinction n’est pas toujours évidente, car certaines applications peuvent
directement travailler à bas niveau (au contact du matériel).
Exemple : systèmes embarqués, réseaux de capteurs.
 Applications réparties

• Une application informatique et dites réparties, lorsqu’elle met en

jeu des parties qui s’exécute sur plusieurs machines reliées par un
système de communication.
• C'est un ensemble de programmes distribués sur un réseau de
communication qui collabore pour assurer un service.
• Aujourd’hui la plupart des applications informatiques sont répartis,
même si les premières applications ont été développés en utilisant
directement les mécanismes de bas niveau (communication par
message) de nombreuses outils existent à présent.
 Pourquoi une application réparties ?

• Besoin intrinsèque de l’application:

• Les utilisateurs sont répartis (site web);
• Données sont réparties (station météo);
• Partage de données ou informations (P2P);
• Besoin de performance ( grappe de calcul);
• Besoin de disponibilité (redondance);
• Besoin de modularité;

• Exemple : une application de commerce par internet, consultation de

compte bancaire, un calendrier partagé, radio télévision numérique
interactive, téléconférence, moteur de recherche….
 Environment
Client/Serveur
 Archiecture Client/serveur

• Communication réalisée par un dialogue entre

processus : un client et un serveur.
• Le client émet des requêtes et reçoit les réponses.
• Le serveur reçoit les requêtes, les traite et émet des
réponses portant les résultats.
• L’application client/serveur c’est l’application
exploitant des services distants au travers d'échange
de messages plutôt que par un partage de données
(mémoire ou fichiers).
Requête

Application Application
Réseau
cliente serveur

Site Client Réponse Site Serveur

 Points forts de l’architecture client-serveur

• Couplage assez faible ( le serveur n’a pas besoin des clients);

• Maintenance et administration du serveur assez simple;
• Souplesse : possibilité d’ajouter ou supprimer des clients
sans perturber le fonctionnement de l’application;
• Les ressources étant centralisée sur le serveur de
sécurisation simple des données;
• Pas de problèmes d’intégrité ou de cohérence des données.
 Points faibles de l’architecture Client/Serveur

• Un maillon faible : le serveur;

• Coût élevé : le serveur doit être très performant
pour honorer tous les clients;
• Apparition d'architecture de plus en plus
complexes : commerce en ligne, radio/ télévision
numérique interactif, moteur de recherche,…
 Solution aux points faibles de l’architecture C/S
• Répartition de charge (Load Balancing): Paralléliser sur
plusieurs serveurs identiques s’exécutant sur des machines
différentes, le traitement des requêtes concurrentes. Les
requêtes des clients passent par un répartiteur de charge
qu’il les répartit sur N serveurs identiques.
• Exemple: le site Web Yahoo est hébergé simultanément sur
plusieurs serveur Web d’adresses différentes: le serveur de
noms DNS, joue le rôle de répartiteur de charge en
traduisant www.yahoo.com par l’adresse de chacun des
serveurs Web à tour de rôle.
 Points forts et faibles de la répartition de charges
• Points forts:
• Transparent pour les clients;
• Scalable :nombre de serveurs adaptable à la demande ;
• Tolérant aux défaillances : la défaillance d’un serveur n'interrompt
pas le service ;
• Plus besoin de machine très cher : en mettre plusieurs;

• Points faibles :
• Le répartiteur de charge devient le maillon faible;
• Les données ne sont plus centralisées mais dupliquées;

• D’où la solution de l’approche client-serveur avec architecture

multicouches qui s’inspire du développement en couches des protocoles
réseaux et des architectures à base de composants.
 Les architectures multicouches
Principe:
Découper l’application en un ensemble de composants (ou couches)
fonctionnels distincts et faiblement couplés.
• Chaque composant est ainsi plus simple et l’application distribuée reste
faiblement couplée
Les composants communiquent entre eux sur le modèle client/serveur
• Les composants de l’application peuvent être facilement répartis sur plusieurs
machines
 Les architectures multicouches

Chaque couche d’une application multicouches est cliente de ses couches

inférieures et serveur pour les couches supérieures
 Les architectures multicouches

• Son principe et de découper l'application en un ensemble de

composants ( ou couches ) fonctionnelle distincts et faiblement
couplés.
• Chaque composant devient plus simple les applications
distribuées reste faiblement couplé. Les composants
communiquent entre eux sur le modèle client-serveur.
• Les composants de l'application peuvent être facilement
répartis sur plusieurs machines.
 NFE 107 : Urbanisation et architecture des systèmes d'information

Les architectures multicouches

Architecture n-tiers

I. Niveau d’abstraction d’une application

La plupart des applications développées se compose de trois éléments:

Application

1. La couche de présentation: présentation des données et des

résultats des traitements (interface)

2. La logique applicative: traitements sur ces données

3. Les données (persistance)

2008/2009
 Services et interfaces

• Définition
• Un système est un ensemble de composants qui interagissent.
• Un service est “un comportement défini par contrat, qui peut être
implémenté et fourni par un composant pour être utilisé par un autre
composant, sur la base exclusive du contrat”

• Mise en œuvre
• Un service est accessible via une ou plusieurs interfaces
• Une interface décrit l’interaction entre client et fournisseur du service
• Point de vue opérationnel : définition des opérations et structures de données qui
concourent à la réalisation du service
• Point de vue contractuel : définition du contrat entre client et fournisseur
 Définitions d’interfaces

• Fournir un service, mettre en jeu deux interfaces

• Interface requise (côté client)
• Interface fournie (côté fournisseur)
• Le contrat spécifie la compatibilité (conformité) entre ces interfaces
• Au delà de l’interface, chaque partie est une “boîte noire” pour l’autre (principe
d’encapsulation)
• Conséquence : client ou fournisseur peuvent être remplacés du moment que le
composant remplaçant respecte le contrat (est conforme)
• Le contrat peut en outre spécifier des aspects non contenus dans l’interface
• Propriétés dites “non fonctionnelles”, ou Qualité de Service
Quelques interfaces importantes

• Chaque interface cache les interfaces de niveau inférieur

 Architecture n-tiers
Architecture 1-tiers

- Les trois couches applicatives sont intimement liées et

s'exécutent sur le même ordinateur.

- On parle d’informatique centralisé.

- Contexte multi utilisateurs :

-1- application sur site central (mainframe)
-2- Application répartie sur des machines indépendantes
communiquant par partage de fichiers.

2008/2009
 Architecture 1-tiers
1. Application sur Mainframe

- Les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à
l'aide de terminaux passifs.
- 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.

2008/2009
 Architecture 1-tiers
2.Les applications un tiers déployées

- Application un tiers sur plusieurs ordinateurs indépendants.

- 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.
- Ce type de solution est donc à réserver à des applications non critiques exploitées par de petits
groupes de travail.
 Architecture 1-tiers
Avantages

- Mainframe : la fiabilité des solutions sur site central qui gèrent les données de façon
centralisée .
- Un tiers déployé : l’interface utilisateur moderne des applications.

Limites

- Mainframe : interface utilisateur en mode caractères .

- Un tiers déployé : cohabitation d'applications exploitant des données communes peu
fiable au delà d'un certain nombre d'utilisateurs.

Il a donc fallu trouver une solution conciliant les avantages de cette architecture . Pour
se faire, il a fallu scinder les applications en plusieurs parties distinctes et coopérantes :
gestion centralisée des données et gestion locale de l'interface utilisateur.
 Architecture 2-tiers
- Le poste client se contente de déléguer la gestion des données à un service spécialisé.

- L’ensemble des traitements applicatifs par le poste client : client lourd.

- 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
Architecture 2-tiers
 Architecture 2-tiers
Le Middleware :

- Ensemble des couches réseau et services logiciel qui permettent le dialogue entre les
différents composants d'une application répartie.
- Complément de services du réseau permettant la réalisation du dialogue client/serveur :
Prend en compte les requêtes de l’application cliente, les transmet au serveur de
manière transparente et prend en compte les résultats du serveur vers le client.

- 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.
 Architecture 2-tiers
Avantages d’un middleware :
• Fait le lien avec la couche transport.
• Réalise la synchronisation du dialogue entre client et serveur,
• Masque l’hétérogénéité des machines et systèmes
• Masque la répartition des traitements et données
• Fournit une interface commode aux applications (modèle de programmation + API)
• Définit le format des données échangés
• Cache les détails de mécanismes de bas niveau
• Assure l’indépendance vis-à-vis des langages et des plateformes
• Permet de réutiliser l’expérience et parfois le code
• Facilite l’évolution des applications
• Réduit le coût et la durée de développement des applications.

• Exemple : rpc, rmi,ejb,corba,….

 Architecture 2-tiers
• Inconvénients d’un middleware :

• Perte de performance liée à la traversée de couche supplémentaire de logiciel

• Prévoir la formation des équipes de développement.
 Architecture 2-tiers
Importance de la normalisation
• Le développement du “middleware” impose une normalisation des
interfaces
• Logiciel de base
• Domaines spécifiques d’applications
• Nombreux consortiums et standards
• Open Group (ex-OSF) : systèmes, outils de base
• Web Consortium (W3C) : Web et outils associés
• OMG : objets répartis (CORBA, IIOP, etc.)
• ODMG : bases de données à objets
• ODP : organisation “ouverte” des applications
• Workflow Management Coalition : applications à flots de données
• ……
Quelques catégories d’intergiciels :

• A message à partir de 1970, MOM IBM MQ series, Microsoft,

Message Queues Server, JMS …
• De base de données : ODBC…
• À appel de procédure distante à partir de 1984…
• À objets répartis : Corbas 1991, Java RMI 1996…
• À composants EJB 1997 déco campus CCM orientée service (service
Web 2004).
 Architecture 2-tiers
Quelques protocoles au niveau middleware
• Objectif
• Permettre la construction, la composition et l’exécution d’applications réparties
• Fournir des services communs aux applications
• Position
• Utilisent les protocoles de transport des réseaux (souvent via l’interface socket)
• Sont utilisés par les applications finales
• Exemples
• RPC (Remote Procedure Call)
• Java RMI (Remote Method Invocation)
• CORBA : objets répartis hétérogènes
• HTTP : protocole du World Wide Web
• SOAP (au-dessus de HTTP) : services Web
 Architecture 2-tiers

Avantages

- Interface utilisateur riche.

- Appropriation des applications par l'utilisateur.

Limites

- Importante charge du poste client, qui supporte la grande

majorité des traitements applicatifs.
- Maintenance et mises à jour difficiles à gérer.
- Difficulté de modifier l'architecture initiale .
 Architecture 3-tiers
- 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

Tier 1 Tier 2 Tier 3

Serveur
Client BDD
applicatif

Présentation Logique métier Données

Le cœur de l’application (modèle métier) : modèle objet et traitements propres au

domaine de l’application (Analyse et conception OO habituelle).
Les données persistantes (couche d’accès aux données) : Couche basse faisant le lien
entre le modèle métier et stockage physique des données (système de fichier, SGBD…)
L’interface utilisateur (couche de présentation): Interface permettant à l’utilisateur
d’agir sur le modèle métier (interface graphique, interface web…)
 Architecture 3-tiers
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
(client léger)

- Facilité de déploiement

- Sécurité : pas d ’exposition du schéma de la base de données

- La manipulation des données est indépendante du support

physique de stockage

- Il est relativement simple de faire face à une forte montée en

charge, en renforçant le service applicatif.
 Les architectures à 3 couches (3-tiers)
Points forts:
• Découplage logique applicative/interface
• Ce ne sont généralement pas les même équipes de développement.
• Possibilité de changer ou d’avoir plusieurs UI sans toucher à l’application elle-
même.
• Découplage données/logique applicative
• Possibilité d’utiliser des données existantes sans complexifier le modèle métier.
• Possibilité de changer le mode de stockage des données sans modifier la logique
métier.
• Favorise la réutilisation puisque toute la logique propre à l’application est
concentrée dans le modèle métier.
 Architecture n-tiers

• Décomposition des trois couches précédente en sous-couche :

1. Client (présentation)
2. Serveur Web recevant les requêtes http des clients en envoyant des
réponses apach http, internet information services IIS,…
3. Serveur d’application où sont installés les applications utilisés par les
clients ils peuvent se répartir la charge de travail (métier), Apache,
Tomcat, Jboss, GlassFish, Jonas,…
4. Serveur de données communiquant avec les serveurs d’application
concernés ( données).
Architecture n-tiers
 Exemple des architectures

• Un tiers( interface ):Téléphone, PDA, Browser, appelet viewer, client AWT,

SWING, C ou C++,…
• Deux tiers (gestion de la présentation dynamicité ) :serveur http, Server
JSP, CGI, ASP,…
• Troisième tiers ( traitement logique applicative) : EJB, RMI, message
oriented middleware (MOM): JMS
• Quatre tiers (persistance) : gestion des données JDBC, BD objet, moteur
transactionnels.
 Gestion de la distribution
• Communication entre les couches basses
• Appel de méthode à distance (RPC)
Ex : RMI, CORBA, .NET Remoting, Service Web
• Communication par messages asynchrones
Ex : JMS (Java Message System)

• Communication avec le client

• Appel de méthode à distance (RPC)
Ex : Applet JAVA via RMI, Service Web via Soap

• Par l’intermédiaire d’un serveur Web

• Utilisent toujours http
Ex : IIS (Internet Information Services ), MS.net, Apache (PHP), Tomcat (Java), …
 Conception des Applications Distribuées
1. Choix d'une "architecture" d'application: Comment définir le modèle métier?
Qu’est-ce qui est distribué? Persistant? Comment les différentes composantes
communiquent telles?
2. Répertorier les fonctions de traitement:
• Fonctions de l’application
• Identification des acteurs
• Identification des fonctions (cas d’utilisation UML)
3. Quelle technologie ? (socket, RMI, RPC, CORBA,…)
• Critères (interopérabilité, performances, ...)
4. Répartition :
• Identification des sites et/ou types de site
• Rôle de chaque site
• Communication inter-sites
5. Définir les interactions entre ces sites
6. Développer l'application
7. Déployer et administrer l'application