Les systèmes répartis sont constitués de machines interconnectées qui coopèrent pour accomplir des tâches, sans centralisation de la mémoire. Ils présentent des défis tels que la tolérance aux pannes, l'hétérogénéité, et nécessitent des modèles de communication adaptés comme le modèle client/serveur ou le modèle orienté services. Le middleware joue un rôle crucial en masquant la complexité et en permettant la communication entre les différentes entités du système.

1. SYSTÈMES RÉPARTIS
heithem.abbes@gmail.com2015-16

2. Introduction au systèmes
répartis

3. Système centralisé
4
 Tout est localisé sur la même machine
 1 processeur : une horloge commune
 1 mémoire centrale : un espace d’adressage
commun
 1 système d’exploitation
 Gestion centralisée des ressources
 Etat global du système facilement reconstiuable
 Accès local aux ressources

4. Emergence du réparti
 Evolution technologique
 machines
 de plus en plus performantes avec une baisse des
prix
 Équipement réseau
 de plus en plus rapides
5
 Regroupement des machines
 Puissance de calcul et de stockage
 Moins de centralisation : accès multiples + partage
de ressources
 Flexibilité : facilité d’extension du système (matériels,
logiciels)

5. Systèmes répartis (1/3)
 "Un ensemble de machines connectées par un
réseau, et équipées d’un logiciel dédié à la
coordination des activités du système ainsi
qu’au partage de ses ressources."
6
 "Un système réparti est un système qui
s’exécute sur un ensemble de machines sans
mémoire partagée, mais que pourtant
l’utilisateur voit comme une seule et unique
machine."
« Coulouris et al. »
« Tanenbaum »

6. Systèmes répartis (2/3)
7
 Types de ressources
 Calcul
 Stockage
 Electronique
 capteur, satellites, scanneurs, …
 Architecture
 Plusieurs processeurs  plusieurs horloges
 Plusieurs mémoires  pas de mémoire partagée
 Réseau d’interconnexion et de communication

7. Systèmes répartis (3/3)
 Fonctionnement collaboratif: des traitements
coopérants sur des données réparties pour
réaliser une tâche commune
 La coopération entre les processus correspond à la
communication entre eux et la synchronisation de
leurs évolutions.
 La répartition peut concerner les données comme
les traitements (tâches).
8

8. Caractéristiques (1/2)
9
 Absence d’état global
 Pas de référence spatiale commune à cause de
l’absence (dans la majorité des cas) d’une
mémoire partagée
 Pas de référence temporelle commune à cause
de l’existence de plusieurs processeurs ayant
chacun sa propre horloge
 Existence d’un réseau
 non géré par le système d’exploitation
 le comportement du système réparti dépend de
l’état du réseau

9. Caractéristiques (2/2)
10
 Architecture matérielle
 Multi-processeurs à mémoire
partagée
 Clusters (grappes) d’ordinateurs
 Ordinateurs puissants (serveurs
dédiés) et indépendants
 Ordinateurs PC en réseau
 Architecture logicielle (système)
 Entités logicielles séparées
s’exécutant en parallèle

10. Exemples
 Commerce électronique
 Partage de fichiers (P2P)
 Réseaux sociaux
11
 Grilles informatiques
 Ensemble de ressources hétérogènes et
dé-localisées
 Cloud Computing (Informatique en
nuage) :
 Accès via le réseau, à la demande et en
libre-service, à des ressources virtualisées
et mutualisées

11. Tolérance aux pannes
 Un système réparti doit tolérer la panne des machines :
 Une machine tombe en panne
 Une machine envoie des informations erronées
 Une machine n’est plus atteignable (problème réseau)
Hétérogénéité
 Comment s’affranchir des différences matérielles et
logicielles des ressources du système ?
 Sources d’hétérogénéité
 machines (architecture matérielle)
 systèmes d'exploitation
 langages de programmation
 protocoles de communications
Propriétés
12

12. Sécurité
 Confidentialité, Intégrité : Droits d’accès, Pare-Feu
 Non-répudiation (s'assurer qu’un contrat signé via
internet, ne peut être remis en cause par l’une des
parties)
 Authentification
 Identification des applications partenaires
 Messages authentifiés
Disponibilité
 Prêt à l’utilisation et toujours disponible
Transparence
 Propriété fondamentale : Tout cacher à l’utilisateur
 La répartition doit être non perceptible : une ressource
distante est accédée comme une ressource locale
 Cacher l'architecture et le fonctionnement du système
Propriétés
13

13. Passage à l’échelle (scalability) :
 paramètre primordial pour la durabilité du
système et sa capacité d’évolution en fonction
des besoins
 un système réparti doit montrer une capacité
acceptable de passer à l’échelle:
 Ce qui marche pour un utilisateur, marchera-t-il pour
des milliers (voir des millions) ?
 Ce qui marche pour un site, marchera-t-il pour des
milliers ?
 Ce qui marche pour un objet, marchera-t-il pour des
millions ?
Problèmes
16

14. Nommage et accès
 Comment identifier les ressources distantes et les
retrouver?
 Système centralisé: nommage géré par le système
d’exploitation (adressage).
 Système réparti: utilisation d’annuaires et de
services de nommage
Intégration de l’existant
 Connexion sur toutes les ressources d’une
entreprise
 Interopérabilité des applications
Problèmes
17

15. Déploiement des applications
 Comment installer tous les composants logiciels
de l’application sur les différentes machines?
 La modification d’un service ou l’ajout d’un autre,
nécessite la recompilation, et/ou redéploiement
de l’application?
 Est il possible de reconfigurer automatiquement
le redéploiement ?
Problèmes
18

16. Applications réparties19

17. Système vs application
20
 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).

18. Modèles de répartition
21
 Modèle Client/Serveur
 Modèle de communication par messages
 Modèle de communication par événements
 Modèle à mémoire partagée
 Modèle à base de composants
 Modèle à base d’agents mobiles
 Modèle orienté service

19. Modèle Client/Serveur
22
 Client : processus demandant l’exécution d’une
opération à un autre processus
 Serveur : processus accomplissant une opération
sur demande d’un client, et lui transmettant le
résultat
 Modèle Requête/Réponse :
 Requête : message transmis par un client à un serveur
décrivant l’opération à exécuter
 Réponse : message transmis par un serveur à un
client suite à l’exécution d’une opération, contenant le
résultat de l’opération
 Mode de communication synchrone
 Le client envoie la requête et attend la réponse.
 Emission bloquante

20. Modèle de communication par messages
(1/2)
23
 Une application produit des messages (producteur)
et une application les consomme (consommateur)
 Le producteur (l’émetteur) et le consommateur
(récepteur) ne communiquent pas directement
entre eux mais utilisent un objet de communication
intermédiaire (boîte aux lettres ou file d’attente)
 Communication asynchrone :
 Les deux composants n'ont pas besoin d'être
connectés en même temps grâce au système de file
d'attente
 Emission non bloquante: l’entité émettrice émet son
message, et continue son traitement sans attendre que
le récepteur confirme l'arrivée du message
 Le récepteur récupère les messages quand il le
souhaite

21. Modèle de communication par messages
(2/2)
24
 Adapté à un système réparti dont les éléments
en interaction sont faiblement couplés :
 éloignement géographique des entités
communicantes
 possibilité de déconnexion temporaire d’un
élément
 Deux modèles de communication :
 Point à point: le message n’est lu que par un seul
consommateur. Une fois lu, il est retiré de la file
d'attente
 Multi-points : le message est diffusé à tous les
éléments d’une liste de destinataires

22. Modèle de communication par événements
25
 Mode de communication asynchrone et anonyme
 indépendance entre le producteur et les (consommateurs d’un événement
 Concepts de base
 Evénement = changement d'état survenant de manière asynchrone (par
rapport aux clients)
 Réaction = exécution d’une opération prédéfinie liée à l’événement
 Modèle Publish/Subscribe (par abonnement) :
 les applications consommatrices des messages s'abonnent à un topic
(sujet)
 Les messages envoyés à ce topic restent dans la file d'attente jusqu'à
ce que tous les abonnées aient lu le message
 Deux modes de consommation :
 « Mode Pull » - réception explicite : les consommateurs viennent
prendre régulièrement leurs messages
 « Mode Push » - délivrance implicite : une méthode prédéfinie est
attachée à chaque type de message et elle est appelée automatiquement
à chaque occurrence de l’évènement. La réception d'un événement
entraîne l'exécution de la réaction associée
 Exemple : surveillance des systèmes

23. Modèles à mémoire partagée
26
 Objectif:
 Replacer le programmeur dans les conditions d’un
système centralisé :
 utiliser un espace mémoire commun pour les
communications
 Avantages:
 transparence de la distribution pour le développeur
 efficacité de développement (utilisation des
paradigmes usuels de la programmation concurrente)
 Inconvénient:
 Complexité de mise en œuvre efficace d’une mémoire
partagée distribuée

24. Modèle à base de composants
27
 Composant : module logiciel autonome et
réutilisable
 possède des entrées/sorties déclarées pour
permettre les connexions entre plusieurs composants
 possède des propriétés déclarées permettant de
configurer le composant
 Objectif: Simplifier la conception et le
développement des applications :
 Réutilisabilité
 Indépendance
 autonomie

25. Modèle à base d’agents mobiles
28
 Code mobile : programme se déplaçant d’un
site à un autre sur le réseau
 Exemple : une applet incluse dans une page
HTML et qui s’exécute sur la machine qui
télécharge la page.
 Avantages de la mobilité :
 minimiser les communications effectuées pour les
échanges
 amener le code aux données plutôt que le contraire
 Agent mobile : entité logicielle
 peut se déplacer d'une machine à une autre sur
réseau
 s'exécute sur une machine et peut arrêter son

26. Modèle orienté service
29
 Un modèle d'interaction basé sur la notion de
service
 Un service est un composant logiciel exécuté
par un producteur à l'attention
d'un consommateur
 Une nouvelle vision dans la conception des
applications réparties

27. Middleware30

28. Motivations
31
 L’interface fournie par les systèmes
d’exploitation et de communication est encore
trop complexe pour être utilisée directement
par les applications:
 Hétérogénéité (matérielle et logicielle)
 Complexité des mécanismes (bas niveau)
 Nécessité de gérer la répartition
 Solution
 Introduire une couche logicielle intermédiaire
(répartie) entre les niveaux bas (systèmes et
communication) et le niveau haut (applications) :
c’est l’intergiciel ou Middleware

29. Middleware
33
 Un middleware (ou intergiciel) permet le
dialogue entre les différentes entités d'une
application répartie
 Représente l’élément le plus important de tout système
réparti
Site 1 Site 2

30. Middleware - Fonctions
34
 Masquer l’hétérogénéité (machines,
systèmes, protocoles de communication)
 Fournir une API (Application Programming
Interface) de haut niveau
 Permet de masquer la complexité des échanges
 Facilite le développement d'une application
répartie
 Rendre la répartition aussi invisible
(transparente) que possible
 Fournir des services répartis d’usage courant

31. Services du middleware
35
 Communication
 permet la communication entre machines mettant
en œuvre des formats différents de données
 prise en charge par la FAP (Format And
Protocol)
 FAP : pilote les échanges à travers le réseau :
 synchronisation des échanges selon un protocole de
communication
 mise en forme des données échangées selon un
format connu de part et d'autre

32. Middleware
36
 Nommage
 permet d'identifier la machine serveur sur laquelle
est localisé le service demandé afin d'en déduire
le chemin d'accès.
 fait, souvent, appel aux services d'un annuaire.
 Sécurité
 permet de garantir la confidentialité et la sécurité
des données à l'aide de mécanismes
d'authentification et de cryptage des informations

33. Types de middleware
37
 Middleware RPC (Remote Proceedure Call)
 RPC de SUN
 Middlewares orientés objets distribués
 Java RMI, Corba
 Middlewares orientés composants distribués
 EJB, Corba, DCOM
 Middlewares orientés messages
 JMS de Sun, MSMQ de Microsoft, MQSeries de IBM
 Middlewares orientés sevices
 Web Services (XML-RPC, SOAP)
 Middlewares orientés SGBD
 ODBC (Open DataBase Connectivity), JDBC de Sun
 Middlewares transactionnels
 JTS de Sun, MTS de Microsoft

34. Communications38

35. Présentation
39
 Elément fondamental d’un système réparti
 Plusieurs systèmes séparés physiquement
 Reliés par un réseau
 Définit leur interconnexion
 Leur permet de communiquer entre eux

36. Outils de communication
40
 Problématique
 Réaliser un service réparti en utilisant l’interface de
transport (TCP, UDP)
 Mise en œuvre
 Bas niveau
 Utilisation directe de la couche transport
 Sockets : mécanisme universel de bas niveau, utilisable
depuis tout langage (exemple : C, Java)
 Haut niveau
 Utiliser les services offerts par les middlewares (Services plus
complexes
 Appel de procédure à distance (RPC), dans un langage particulier ;
exemple : C
 Appel de méthode à distance, dans les langages à objets ;
exemple : Java RMI

37. le réseau vu de l’utilisateur
41
 Schéma Client/Serveur
 Machines différentes : client demande un service
fournit par un serveur sur une autre machine
 Un service est souvent désigné par un nom symbolique (email,
http://..., telnet, etc.).
 Ce nom doit être converti en une adresse interprétable par les
protocoles du réseau.
 La conversion d’un nom symbolique (http://www.google.com) en
une adresse IP (216.239.39.99) est à la charge du service DNS

38. le réseau vu de l’utilisateur
42
 Le serveur (machine physique) peut comporter différents services:
 L’adresse IP du serveur ne suffit pas,
 il faut préciser le service demandé au moyen d’un numéro de port, qui
permet d’atteindre un processus particulier sur la machine serveur.
 Un numéro de port comprend 16 bits (0 à 65 535).
 Les numéros de 0 à 1023 sont réservés, par convention, à des
services spécifiques.
 Exemples :
 22 : ssh, 23 :telnet (connexion à distance)
 80 : serveur web, 25 : mail, 21: FTP