SlideShare une entreprise Scribd logo
1  sur  38
SYSTÈMES RÉPARTIS
heithem.abbes@gmail.com2015-16
Introduction au systèmes
répartis
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
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)
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 »
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
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
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
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
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
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
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
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
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
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
Applications réparties19
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).
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
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
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
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
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
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
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
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
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
Middleware30
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
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
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
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
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
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
Communications38
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
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
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
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

Contenu connexe

Tendances

Base de données distribuée
Base de données distribuéeBase de données distribuée
Base de données distribuéekamar MEDDAH
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveurAmeni Ouertani
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQLLilia Sfaxi
 
Systeme distribue
Systeme distribueSysteme distribue
Systeme distribueAfaf MATOUG
 
Bases de données réparties
Bases de données répartiesBases de données réparties
Bases de données répartiesAbdelouahed Abdou
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPSarah
 
Appels de procédures distants (RPC)
Appels de procédures distants (RPC)Appels de procédures distants (RPC)
Appels de procédures distants (RPC)Heithem Abbes
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiqueOussama Yoshiki
 
applications-reparties
applications-repartiesapplications-reparties
applications-repartiesmourad50
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-CorrectionLilia Sfaxi
 
Cours Base de données relationnelles
Cours Base de données relationnellesCours Base de données relationnelles
Cours Base de données relationnellesAymen Kasmi
 
La technologie des systemes distribués 2 ppt2222.pptx
La technologie des systemes distribués 2 ppt2222.pptxLa technologie des systemes distribués 2 ppt2222.pptx
La technologie des systemes distribués 2 ppt2222.pptxkaoutarghaffour
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceLilia Sfaxi
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Ayoub Mkharbach
 
Systèmes d'Exploitation - chp2-gestion des processus
Systèmes d'Exploitation - chp2-gestion des processusSystèmes d'Exploitation - chp2-gestion des processus
Systèmes d'Exploitation - chp2-gestion des processusLilia Sfaxi
 

Tendances (20)

Base de données distribuée
Base de données distribuéeBase de données distribuée
Base de données distribuée
 
Les architectures client serveur
Les architectures client serveurLes architectures client serveur
Les architectures client serveur
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQL
 
Systeme distribue
Systeme distribueSysteme distribue
Systeme distribue
 
Bases de données réparties
Bases de données répartiesBases de données réparties
Bases de données réparties
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XP
 
Appels de procédures distants (RPC)
Appels de procédures distants (RPC)Appels de procédures distants (RPC)
Appels de procédures distants (RPC)
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
 
Mise en oeuvre des framework de machines et deep learning v1
Mise en oeuvre des framework de machines et deep learning v1 Mise en oeuvre des framework de machines et deep learning v1
Mise en oeuvre des framework de machines et deep learning v1
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
Sockets
SocketsSockets
Sockets
 
applications-reparties
applications-repartiesapplications-reparties
applications-reparties
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
Cours Base de données relationnelles
Cours Base de données relationnellesCours Base de données relationnelles
Cours Base de données relationnelles
 
La technologie des systemes distribués 2 ppt2222.pptx
La technologie des systemes distribués 2 ppt2222.pptxLa technologie des systemes distribués 2 ppt2222.pptx
La technologie des systemes distribués 2 ppt2222.pptx
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de Séquence
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
Systèmes d'Exploitation - chp2-gestion des processus
Systèmes d'Exploitation - chp2-gestion des processusSystèmes d'Exploitation - chp2-gestion des processus
Systèmes d'Exploitation - chp2-gestion des processus
 
Big data
Big dataBig data
Big data
 
Uml classes Par les exemples
Uml classes Par les exemplesUml classes Par les exemples
Uml classes Par les exemples
 

En vedette

Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)Heithem Abbes
 
Java Server Faces (JSF)
Java Server Faces (JSF)Java Server Faces (JSF)
Java Server Faces (JSF)Heithem Abbes
 
Entreprise Java Beans (EJB)
Entreprise Java Beans (EJB)Entreprise Java Beans (EJB)
Entreprise Java Beans (EJB)Heithem Abbes
 
Virtualisation Cloud Computing Saas Open Source
Virtualisation Cloud Computing Saas Open SourceVirtualisation Cloud Computing Saas Open Source
Virtualisation Cloud Computing Saas Open SourceParis, France
 
The Dark Side Of The Cloud
The Dark Side Of The CloudThe Dark Side Of The Cloud
The Dark Side Of The CloudRobert Viseur
 
Introduction to Cloud Computing and Open Source solutions
Introduction to Cloud Computing and Open Source solutionsIntroduction to Cloud Computing and Open Source solutions
Introduction to Cloud Computing and Open Source solutionsAmineAbida
 
De l’open source à l’open cloud
De l’open source à l’open cloudDe l’open source à l’open cloud
De l’open source à l’open cloudRobert Viseur
 
La culture algorithmique
La culture algorithmiqueLa culture algorithmique
La culture algorithmiquelaurence allard
 
Sécurité des Systèmes Répartis- Partie 1
Sécurité des Systèmes Répartis- Partie 1 Sécurité des Systèmes Répartis- Partie 1
Sécurité des Systèmes Répartis- Partie 1 Lilia Sfaxi
 
SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...
SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...
SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...Club Alliances
 

En vedette (20)

Cloud computing
Cloud computingCloud computing
Cloud computing
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
Java RMI
Java RMIJava RMI
Java RMI
 
Servlets et JSP
Servlets et JSPServlets et JSP
Servlets et JSP
 
Java Server Faces (JSF)
Java Server Faces (JSF)Java Server Faces (JSF)
Java Server Faces (JSF)
 
Rapport projet final system reparti
Rapport projet final system repartiRapport projet final system reparti
Rapport projet final system reparti
 
Présentation cloud computing
Présentation cloud computingPrésentation cloud computing
Présentation cloud computing
 
Entreprise Java Beans (EJB)
Entreprise Java Beans (EJB)Entreprise Java Beans (EJB)
Entreprise Java Beans (EJB)
 
Introduction
IntroductionIntroduction
Introduction
 
Chap3 clientsrvr
Chap3 clientsrvrChap3 clientsrvr
Chap3 clientsrvr
 
Virtualisation Cloud Computing Saas Open Source
Virtualisation Cloud Computing Saas Open SourceVirtualisation Cloud Computing Saas Open Source
Virtualisation Cloud Computing Saas Open Source
 
The Dark Side Of The Cloud
The Dark Side Of The CloudThe Dark Side Of The Cloud
The Dark Side Of The Cloud
 
Introduction to Cloud Computing and Open Source solutions
Introduction to Cloud Computing and Open Source solutionsIntroduction to Cloud Computing and Open Source solutions
Introduction to Cloud Computing and Open Source solutions
 
De l’open source à l’open cloud
De l’open source à l’open cloudDe l’open source à l’open cloud
De l’open source à l’open cloud
 
Openstack proposition
Openstack propositionOpenstack proposition
Openstack proposition
 
OpenStack en 10 minutes
OpenStack en 10 minutesOpenStack en 10 minutes
OpenStack en 10 minutes
 
La culture algorithmique
La culture algorithmiqueLa culture algorithmique
La culture algorithmique
 
Sécurité des Systèmes Répartis- Partie 1
Sécurité des Systèmes Répartis- Partie 1 Sécurité des Systèmes Répartis- Partie 1
Sécurité des Systèmes Répartis- Partie 1
 
Mutual exclusion
Mutual exclusionMutual exclusion
Mutual exclusion
 
SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...
SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...
SaaS Cloud Computing Solutions-as-a-Service - Convention des Décideurs IBM - ...
 

Similaire à Introduction aux systèmes répartis

srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdfSamirAwad14
 
Architectures parallèles.pdf
Architectures parallèles.pdfArchitectures parallèles.pdf
Architectures parallèles.pdfYasmineChihab1
 
Introduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).pptIntroduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).pptMahdiHERMASSI1
 
A la découverte d'abus
A la découverte d'abusA la découverte d'abus
A la découverte d'abusThierry Gayet
 
Cours sys 2PPT20.pdf
Cours sys 2PPT20.pdfCours sys 2PPT20.pdf
Cours sys 2PPT20.pdfC00LiMoUn
 
Exposé de SE Systemes distribués
Exposé de SE Systemes distribuésExposé de SE Systemes distribués
Exposé de SE Systemes distribuésYoussouf Saleh Gao
 
Cours6 informatique201801
Cours6 informatique201801Cours6 informatique201801
Cours6 informatique201801wissem hammouda
 
Cours SE linux
Cours SE linuxCours SE linux
Cours SE linuxIdriss22
 
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvamine17157
 
Grid Computing avec Symphony
Grid Computing avec SymphonyGrid Computing avec Symphony
Grid Computing avec SymphonyIn Fine
 
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008guest9dd59e
 

Similaire à Introduction aux systèmes répartis (20)

srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
 
Cour1
Cour1Cour1
Cour1
 
systèmes distribues
systèmes distribuessystèmes distribues
systèmes distribues
 
Architectures parallèles.pdf
Architectures parallèles.pdfArchitectures parallèles.pdf
Architectures parallèles.pdf
 
Grid computing
Grid computingGrid computing
Grid computing
 
Introduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).pptIntroduction aux systèmes d-exploitation (2).ppt
Introduction aux systèmes d-exploitation (2).ppt
 
A la découverte d'abus
A la découverte d'abusA la découverte d'abus
A la découverte d'abus
 
Cours sys 2PPT20.pdf
Cours sys 2PPT20.pdfCours sys 2PPT20.pdf
Cours sys 2PPT20.pdf
 
Exposé de SE Systemes distribués
Exposé de SE Systemes distribuésExposé de SE Systemes distribués
Exposé de SE Systemes distribués
 
Cours6 informatique201801
Cours6 informatique201801Cours6 informatique201801
Cours6 informatique201801
 
Tiny os
Tiny osTiny os
Tiny os
 
Cours SE linux
Cours SE linuxCours SE linux
Cours SE linux
 
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
 
Grid Computing avec Symphony
Grid Computing avec SymphonyGrid Computing avec Symphony
Grid Computing avec Symphony
 
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
Cours Microsoft Windows 2003 Server 1ere Partie 6 Mars 2008
 
chapitre0.pptx
chapitre0.pptxchapitre0.pptx
chapitre0.pptx
 
Chapitre 03
Chapitre 03Chapitre 03
Chapitre 03
 
Architectures bigdata
Architectures bigdataArchitectures bigdata
Architectures bigdata
 
Architecture android
Architecture androidArchitecture android
Architecture android
 
Design patterns
Design patternsDesign patterns
Design patterns
 

Dernier

Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 37
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
Zotero avancé - support de formation doctorants SHS 2024
Zotero avancé - support de formation doctorants SHS 2024Zotero avancé - support de formation doctorants SHS 2024
Zotero avancé - support de formation doctorants SHS 2024Alain Marois
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfRiDaHAziz
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
SciencesPo_Aix_InnovationPédagogique_Bilan.pdf
SciencesPo_Aix_InnovationPédagogique_Bilan.pdfSciencesPo_Aix_InnovationPédagogique_Bilan.pdf
SciencesPo_Aix_InnovationPédagogique_Bilan.pdfSKennel
 
SciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdfSciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdfSKennel
 
SciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdf
SciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdfSciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdf
SciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdfSKennel
 
Pharmacologie des cardiotoniques pour Pharmacie
Pharmacologie des cardiotoniques pour PharmaciePharmacologie des cardiotoniques pour Pharmacie
Pharmacologie des cardiotoniques pour PharmacieLoloshka
 
Bibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdfBibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdfBibdoc 37
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfRiDaHAziz
 
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...NaimDoumissi
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
SciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdfSciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdfSKennel
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 37
 
Presentation de la plateforme Moodle - avril 2024
Presentation de la plateforme Moodle - avril 2024Presentation de la plateforme Moodle - avril 2024
Presentation de la plateforme Moodle - avril 2024Gilles Le Page
 

Dernier (20)

Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
Zotero avancé - support de formation doctorants SHS 2024
Zotero avancé - support de formation doctorants SHS 2024Zotero avancé - support de formation doctorants SHS 2024
Zotero avancé - support de formation doctorants SHS 2024
 
PIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdfPIE-A2-P4-support stagiaires sept 22-validé.pdf
PIE-A2-P4-support stagiaires sept 22-validé.pdf
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
SciencesPo_Aix_InnovationPédagogique_Bilan.pdf
SciencesPo_Aix_InnovationPédagogique_Bilan.pdfSciencesPo_Aix_InnovationPédagogique_Bilan.pdf
SciencesPo_Aix_InnovationPédagogique_Bilan.pdf
 
SciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdfSciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_IA.pdf
 
SciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdf
SciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdfSciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdf
SciencesPo_Aix_InnovationPédagogique_Conférence_SK.pdf
 
Pharmacologie des cardiotoniques pour Pharmacie
Pharmacologie des cardiotoniques pour PharmaciePharmacologie des cardiotoniques pour Pharmacie
Pharmacologie des cardiotoniques pour Pharmacie
 
Bibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdfBibdoc 2024 - Ecologie du livre et creation de badge.pdf
Bibdoc 2024 - Ecologie du livre et creation de badge.pdf
 
PIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdfPIE-A2-P 5- Supports stagiaires.pptx.pdf
PIE-A2-P 5- Supports stagiaires.pptx.pdf
 
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
Potentiel du Maroc en Produits du Terroir et Stratégie Adoptée pour le dévelo...
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
SciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdfSciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdf
SciencesPo_Aix_InnovationPédagogique_Atelier_FormationRecherche.pdf
 
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdfBibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
Bibdoc 2024 - Les maillons de la chaine du livre face aux enjeux écologiques.pdf
 
DO PALÁCIO À ASSEMBLEIA .
DO PALÁCIO À ASSEMBLEIA                 .DO PALÁCIO À ASSEMBLEIA                 .
DO PALÁCIO À ASSEMBLEIA .
 
Presentation de la plateforme Moodle - avril 2024
Presentation de la plateforme Moodle - avril 2024Presentation de la plateforme Moodle - avril 2024
Presentation de la plateforme Moodle - avril 2024
 

Introduction aux 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
  • 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
  • 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
  • 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

Notes de l'éditeur

  1. et accessible par le programme
  2. L’évolution des technologies informatiques au cours des dernières années a entraîné des modifications radicales dans la conception des applications.
  3. Une application répartie est une application dont les éléments s’exécutent dans des processus différents ou sur des machines différentes mais surtout sur des machines différentes. 
  4. La coopération entre les processus correspond à la communication entre eux et la synchronisation de leurs évolutions. Ceci nécessite: la conception d’un modèle d’exécution permettant l’identification des éléments/entités communicants et de leur mode de communication, une interface de programmation et des outils de développement pour l’implémentation du modèle conçu et sa mise en place. La répartition/la distribution peut concerner les données comme les traitements (tâches).
  5. Les réseaux sociaux, Video streaming
  6. Problèmes liés aux applications réparties
  7. Combien de personnes utilisent l’application, qui sont-ils ? Nécessité de se protéger contre les intrusions Nécessité de stocker les accès des clients dans des fichiers journaux Transparence ; L'ISO définit plusieurs transparences accès, localisation, concurrence, réplication, mobilité, panne, performance, échelle Abstraction Séparation interface/réalisation : accès à un service via une interface d’accès en faisant abstraction à son implémentation.
  8. Ce qui marche pour un objet, marchera-t-il pour des millions ?
  9. Un objet = un identifiant + un état + un comportement. Système centralisé: nommage géré par le langage (référence) ou par le système d’exploitation (adressage). (Java Naming and Directory Interface), LDAP : Nommage explicite ou dynamique explicite : l’administrateur se charge de l’ajout d’une nouvelle machine au système dynamique : le système réparti permet un ajout dynamique des machines sans passer par l’administrateur Exemples : DNS, URL, JNDI, LDAP, ...
  10. Intégration de l’existant (Legacy)
  11. 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
  12. Le modèle client-serveur de base met en jeu un processus client, qui demande l’exécution d’un service, et un processus serveur, qui réalise ce service. Client et serveur sont localisés sur deux machines reliées par un réseau de communication. Ce modèle a été introduit pour mettre en œuvre les premières applications réparties (transfert de fichiers, connexion à une machine distante, courrier électronique, etc.), réalisées chacune par un protocole applicatif spécifique. Dans une seconde étape, une construction commune, l’appel de procédure à distance, a été introduite pour fournir un outil général pour la programmation d’applications client-serveur.
  13. MOM, ou Message-Oriented Middleware Les systèmes de communication asynchrones, fondés sur l'envoi de messages, connaissent aujourd'hui un regain d'intérêt dans le contexte des applications réparties sur Internet. En effet, on s'accorde à penser que les modèles de communication asynchrones sont mieux adaptés que les modèles synchrones (de type client-serveur) pour gérer les interactions entre systèmes faiblement couplés. Le couplage faible résulte de plusieurs facteurs de nature spatiale ou temporelle : l'éloignement géographique des entités communicantes, la possibilité de déconnexion temporaire d'un partenaire en raison d'une panne ou d'une interruption de la communication (pour les usages mobiles par exemple). Les modèles de communication asynchrones prennent en compte l'indépendance entre entités communicantes et sont donc mieux armés pour traiter ces problèmes. Aujourd'hui les systèmes de communication asynchrones, appelés MOM (Message Oriented Middleware), sont très largement répandus dans la mesure où ils constituent la base technologique pour la réalisation des classes d'applications suivantes :Intégration de données et intégration d'applications (EAI, B2B, ESB, etc.)
Systèmes ubiquitaires et usages de la mobilité.
Surveillance et contrôle d'équipements en réseau.
  14. Mieux expliquer la communication Publish/subscribe, je pense qu’il faut la déplacer dans le modèle de communication par évènement ! Publish Subscribe (par abonnement) : les applications consommatrices des messages s'abonnent à un topic (sujet, catégorie de messages). Les messages envoyés à ce topic restent dans la file d'attente jusqu'à ce que toutes les applications abonnées aient lu le message. Les environnements : JMS (Java Messenging Service), JORAM (Java Open Reliable Asynchronous Messaging) MOM (Middleware orientés messages ou Message-Oriented Middleware) JORAM: Java Open Reliable Asynchronous Messaging Les différents éléments administrés émettent des messages : changements d'état et de configuration alertes, statistiques Implémentations existantes: TIBCO Rendezvous… Principe d’attachement Association dynamique entre un type d’évènement et une réaction. « Pull » – réception explicite Les clients viennent prendre périodiquement leurs messages sur le serveur. « Push » – délivrance implicite Une méthode prédéfinie (réaction) est attachée à chaque type de message (é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 (changement d’états de configuration, alertes, statistiques)
  15. Objectifs : Replacer le programmeur dans les conditions d’un système centralisé : utiliser un espace mémoire commun pour les communications synchronisation des applications par variables partagées Problématique : Mise en œuvre efficace d’une mémoire partagée distribuée Cohérence des données, localité des codes Exemples d’implémentations : Modèles à espace de tuples (une base de données relationnelle partagée). Modèles à objets dupliqués (un espace d’objets répartis partagés).
  16. Ajouter 1 ou 2 phrases ici. Exemples d’implémentations Beans, EJB (Enterprise JavaBeans), CORBA Component, DCOM (Distributed Component Object Model) EJB: Enterprise Java Bean: Un environnement pour la répartition des objets répartis: un serveur qui gère tous les problèmes de répartitions DCOM: Distributed Component Object Model
  17. permet l’extension des fonctions des serveurs pour des besoins spécifiques Avantages de la mobilité : privilégie les interactions locales minimiser les communications effectuées pour les échanges amener le code aux données plutôt que le contraire Agent mobile : entité logicielle permettant de construire des applications distribuées peut se déplacer d'une machine à une autre sur réseau. s'exécute sur une machine et peut, à tout moment, arrêter son exécution, se déplacer sur une autre machine et reprendre son exécution (à partir de son dernier état) Paradigme: L’activité démarre sur un site (une machine) Migration du code et des données sur un site distant Reprise de l’exécution
  18. Ajouter 1 ou 2 phrases ici
  19. Nécessité de gérer (et de masquer, au moins partiellement) la répartition Le middleware joue un rôle analogue à celui d’un “super-système d’exploitation” pour un système réparti
  20. Ce dialogue se base sur un protocole applicatif commun, défini par l'API du middleware.
  21. Un middleware ou « intergiciel » ou « élément du milieu » est l'ensemble des couches réseau et services logiciel qui permettent le dialogue entre les différents composants d'une application répartie. Positionnement du middleware (couche du milieu)
  22. Objectif 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 transparente
  23. J’ai remplacé : Conversion par Communication Conversion permet la communication entre machines mettant en œuvre des formats différents de données prise en charge par la FAP (Format And Protocol)
  24. permet la transmission des données entre les deux systèmes sans altération. doit gérer la connexion au serveur, la préparation de l'exécution des requêtes, la récupération des résultats et la déconnexion de l'utilisateur. Communication permet la transmission des données entre les deux systèmes
  25. J’ai modifié l’emplacement de Corba de l’orienté objet vers orientés composants
  26. Services offerts par les couches TCP et UDP d’un réseau Couche réseau et couche transport
  27. Même machine : client et serveur sur la même machine