Plan du cours
§ Introduction
Systèmes Distribués (1)
Guillaume Hutzler
LaMI (Laboratoire de Méthodes Informatiques)
SyDRA (Systèmes Distribués, Réactifs et Adaptatifs)
hutzler@lami.univ-evry.fr
1 2
Plan du cours
§ Introduction
définitions
problématiques
architectures de distribution
§ Distribution intra-applications
notion de processus
programmation multi-thread
§ Distribution inter-applications et inter-machines
sockets
middlewares par appel de procédures distantes
middlewares par objets distribués (Java RMI, CORBA)
§ Conclusion
3 4
Introduction - Un exemple pour commencer : un agenda [M. Riveil]
Fonctions supplémentaires
§ Liées à la distribution des agendas
Accès depuis n’importe quelle station du réseau
§ Liées à la présence de plusieurs utilisateurs
Consultation d’un agenda par d’autres utilisateurs
Confidentialité de certains agendas
Agendas communautaires i.e. liés à un ensemble
d’individus
– gestion de l’occupation d’une salle
– groupe de travail
Superposition de plusieurs agendas
– participation à plusieurs groupes de travail
Négociation électronique de rendez-vous
– Recherche d’une plage horaire commune
5 6
définitions
problématiques
architectures de distribution
§ Distribution intra-applications
notion de processus
programmation multi-thread
§ Distribution inter-applications et inter-machines
sockets
middlewares par appel de procédures distantes
middlewares par objets distribués (Java RMI, CORBA)
§ Conclusion
Introduction
Un exemple pour commencer : un agenda [M. Riveil]
§ Fonctions de base
Accès interactif à un calendrier
Agenda de rendez-vous personnel
Répétition automatique de certains rendez-vous
Service d’alarmes (fenêtre pop-up ou courrier)
Fonction de recherche pour les rendez-vous
Recherche d’une plage horaire disponible
Introduction - Un exemple pour commencer : un agenda [M. Riveil]
Analyse des besoins (1)
§ Persistance des données
Personnalisation de l’application
– environnement “constant” quelle que soit la station de connexion
Partage séquentiel
– Conservation des agendas entre deux sessions
– Consultation des agendas des autres utilisateurs en cas d’absence
§ Partage des données
Consultation des agendas des autres utilisateurs
Accès aux agendas communautaires
Gestion des accès concurrents
– Consultations / modifications
– Maintien de la cohérence entre plusieurs agendas
– prise de rendez-vous multiples
– mise à jour des superpositions d’agendas
1
 Introduction - Un exemple pour commencer : un agenda [M. Riveil] Introduction - Un exemple pour commencer : un agenda [M. Riveil]
Analyse des besoins (2) Analyse des besoins (3)

§ Distribution § Accès à une horloge ou à un ordonnanceur

Pouvoir “disperser” les agendas Manipulation du temps (date, alarmes, rendez-vous)
Accès aux agendas sans connaître à priori leur localisation Attente du prochain événement
physique
§ Interface utilisateur
Pouvoir dupliquer les agendas
– agendas communautaires Calendrier
Edition des commandes ou des messages
§ Sécurité et protection Personnalisation
Authentification des utilisateurs Fenêtre d’alarme
– Contre les malveillances et les fautes
Définition des droits d’accès pour chaque utilisateur § Tolérance aux pannes
– Confidentialité des agendas ou de certaines plages horaires Disponibilité
§ Ouverture – duplication des agendas

Hétérogénéité des plates-formes

Accès à d’autres applications
– courrier électronique, impression, recherche de plage libre
Accès depuis d’autres applications
7 8

Introduction - Un exemple pour commencer : un agenda [M. Riveil] Introduction

Description sommaire Différentes motivations à la distribution

§ Faire interagir des applications existantes

Communication d'
informations
§ Applications intrinsèquement réparties
Geographiquement, fonctionnellement
§ Augmenter la disponibilité
Redondance du matériel, des informations ou du
traitement
§ Augmenter la performance
Traitements en parallèle de taches
§ Partager des ressources
§ Faciliter le développement et l'évolution

9 10

Introduction Introduction
Différentes formes de distribution Différentes types d’applications

§ Distribution physique § Accès bases de données distantes

fonctionnement en réseaux (LANs, WANs) § Web
architectures multi-processeurs
§ Travail coopératif
§ Distribution structurelle
programmation structurée § Commerce électronique
programmation objet § Systèmes embarqués
programmation par composants
§ Multimédia
programmation par aspects
§ Mondes virtuels
§ Distribution fonctionnelle
décomposition en services indépendants (affichage, calcul, § Téléphonie mobile
stockage de données, etc.) § Cartes à puce
services Web
§ ...

11 12

2
 Introduction Introduction
Différents niveaux de distribution Définition

Systèmes distribués entre différentes machines Environnement § Nombreuses définitions possibles

• machines différentes
hétérogène § Définition retenue
• systèmes d’exploitations différents
• langages différents
Un système distribué est une collection de processus ou
d’ordinateurs indépendants et coopératifs qui apparaissent
entre différentes applications utilisateur comme un seul et unique système cohérent
à l'
• machine unique
contraire = système centralisé
• système d’exploitation unique
• langages différents

Systèmes d’exploitation entre différents processus

multi-tâches • machine unique
• système d’exploitation unique
• langage unique

entre différents objets

• machine unique
• système d’exploitation unique Environnement
• langage unique
• processus unique
homogène
13 14

Introduction Introduction / Objectifs et caractéristiques

Objectifs et caractéristiques Hétérogénéité

§ Hétérogénéité § au niveau des réseaux

§ Ouverture réseaux de différents types

§ Sécurité § au niveau du matériel informatique

codage des données différent suivants les architectures
§ « Scalabilité »
§ au niveau des systèmes d’exploitation
§ Tolérance aux pannes protocoles standards mais APIs différentes d’un OS à l’autre
§ Concurrence § au niveau des langages de programmation
§ Transparence pour l’utilisateur différences pour le codage des caractères ou les structures
de données
§ au niveau des implantations
nécessité de suivre les standards établis

15 16

Introduction / Objectifs et caractéristiques Introduction / Objectifs et caractéristiques

Hétérogénéité – approches possibles Ouverture

§ protocoles standards de communication § Possibilité d’extension ou de ré-implantation

masquent l’hétérogénéite des systèmes ajout et mise à disponibilité de ressources partagées
ex. : standards pour l’Internet TCP/IP accès à d’autres applications
§ utilisation de middlewares accès depuis d’autres applications
modèles de programmation distribuée standardisés et nécessite le libre accès aux spécifications et à la
uniformes accès aux BDs, appel d’objets à distance documentation des APIs pour les programmeurs
– ex. : RFC pour Internet
implémentés au-dessus des standards de l’Internet
ex. : CORBA, Java RMI, Microsoft COM/DCOM, etc. § Avantages
développement collaboratif
§ utilisation de code mobile
permet une indépendance vis-à-vis des constructeurs et
envoyé d’un ordinateur à l’autre éditeurs de logiciels
exécuté sur l’ordinateur distant
ex. : applets Java, agents mobiles

17 18

3
 Introduction / Objectifs et caractéristiques Introduction / Objectifs et caractéristiques
Sécurité Scalabilité
Capacité à assurer la sécurité des données qui transitent, Capacité à rester efficace en cas de forte
l’authentification des participants et à empêcher les intrusions augmentation des ressources et des utilisateurs
§ Sécurité des informations § Adapter le dimensionnement de l’application
Confidentialité ajout/duplication de composants
– protection contre les destinataires indésirables
– ex. : augmentation du nb de clients duplication des serveurs
Intégrité problème = coût de communication/synchronisation lié à
– protection contre l'
altération ou la corruption des données
l’augmentation du nb de processus
Authentification, signature électronique
– identification des partenaires § Implique la prise en compte
– non-déni d’envoi ou de réception
– messages authentifiés
du contrôle du coût des ressources physiques
– respect possible de l’anonymat
– idéalement, pour n utilisateurs, ressources en O(n)
Disponibilité du contrôle de la perte de performance
– protection contre les interférences aux moyens d’accès – idéalement, si volume de données proportionnel au nb d’utilisateurs ou
de ressources, temps d’accès < O(log n)
§ Risques liés à la sécurité de la prévention de la diminution des ressources logicielles
pénétration d’un Intranet via un firewall – ex. : nb d’adresses Internet limité par la représentation sur 32 bits
envoi sécurisé de messages systèmes de cryptage de la prévention des goulots d’étranglement
déni de service – décentralisation nécessaire
sécurité des codes mobiles
19 20

Introduction / Objectifs et caractéristiques Introduction / Objectifs et caractéristiques

Tolérance aux pannes Tolérance aux pannes – approches possibles

Capacité de l’application à s’exécuter en § la détection de pannes

environnement dégradé but = détecter que les données reçues ne sont pas celles
attendues
§ Les pannes ex. : bit de contrôle pour l’envoi de données
généralement partielles et d’origines diverses § le masquage des pannes
– panne d’un composant but = limiter l’impact des pannes
– panne d’un lien de communication entre composants ex. : retransmission de messages, systèmes de cache
pb = limiter les conséquences liées à la panne d’un système § la tolérance aux pannes
matériel (ou logiciel) alerter si panne trop importante pour être corrigée
– éviter une trop forte centralisation
ex. : serveur Web en panne
– éviter d’isoler des fonctions vitales

§ Indicateur de performance = disponibilité § la reprise sur erreur

rétablir les données suite à une panne
proportion de temps pendant laquelle il est disponible pour ex. : systèmes de sauvegardes des données permanentes
utilisation
mesurée en pourcentage
§ la redondance
duplication de composants pour en avoir toujours au moins un de
disponibilité de 99,999% pour les systèmes les plus fiables disponible
ex. : plusieurs chemins entre routeurs, plusieurs BDs
21 22

Introduction / Objectifs et caractéristiques Introduction / Objectifs et caractéristiques

Concurrence Transparence (1)

Capacité de plusieurs processus à s’exécuter en Séparation des composants dans un système

parallèle distribué de manière à ce que l' utilisateur perçoive
ce système comme un tout plutôt que comme une
§ Concurrence interconnexion de composants actifs
accès simultané de plusieurs utilisateurs à la même
ressource matérielle ou logicielle § caractère intégré de l’application, qui permet d’en
ex. : base de données, serveur Web, etc. cacher la complexité à l’utilisateur
ressources
§ Approches possibles moyens de communication
redondance architecture interne organisationnelle
– ex. : duplication d’une base de données
– pb de synchronisation entre les ressources § Le standard ISO identifie huit types de transparences
gestion des ressources par le système d’exploitation La transparence d'
accès
– ex. : accès à un fichier partagé – les ressources locales et distantes doivent pouvoir être accessibles de
la même manière
– pb de synchronisation entre processus utilisation de sémaphores, – ex. : système de montage de volumes Unix
mécanismes de synchronisation de threads
– synchronisation trop forte = risque de « sérialisation »
La transparence de localisation
– les ressources doivent être accessibles quelle que soit leur localisation
physique
– ex. : URL Web
23 24

4
 Introduction / Objectifs et caractéristiques Introduction
Transparence (2) Concepts matériels
La transparence de concurrence § Systèmes Multi-Processeurs (SMP)
– plusieurs processus doivent pouvoir opérer de manière concurrentielle
sans interférences entre eux mémoire partagée avec accès direct pour tous les CPUs
La transparence de réplication mémoire cache pour assurer un accès rapide aux données
– plusieurs instances des ressources doivent être déployées pour assurer et éviter les goulots d’étranglement entre les calculs
la fiabilité du système
§ Machines parallèles homogènes
La transparence de panne
– une panne ne doit pas bloquer le fonctionnement global du système noeuds de calcul montés dans des « racks » reliés par un
La transparence de mobilité réseau d’interconnexion unique et très haute performance
– les ressources et clients doivent pouvoir être mobiles sans affecter le ex. : super-calculateurs, clusters
fonctionnement global
§ Machines parallèles hétérogènes
La transparence de performance
– le système doit pouvoir être reconfigurable pour assurer les montées ordinateurs variés en termes de processeurs, de mémoire,
en charge de bande passante, etc.
La transparence d'
échelle généralement associés à une couche logicielle type
– le système et les applications doivent pouvoir supporter les middleware
changements d' échelles sans modification interne des algorithmes par
exemple

25 26

Introduction Introduction - Modèles d’architecture

Modèles d’architecture logique Le modèle client-serveur (1)
§ Définition § Analogie : le modèle interviewer / interviewé
L'
architecture d' un système est sa structure en termes de communication entre 2 entités
composants spécifiquement séparés, conçue dans le but d' assurer – toute communication concernant les éléments d’un groupe peut être
un bon fonctionnement en fonction des demandes présentes mais décomposée en un ensemble d’échanges entre deux entités
aussi futures
une entité a l’initiative du dialogue (l’interviewer) et l’autre
Le système doit être fiable, gérable, adaptable et tout cela à un
est dans l’attente d’une requête (l’interviewé)
coût réaliste. Un tel modèle est décrit par :
– le placement des entités sur le réseau (distribution des données, charge effective) l’entité interviewée est programmée pour répondre à un
– les relations existantes entre ces entités (rôles fonctionnels, communications) ensemble très précis de requêtes
§ Principales architectures – la liste des requêtes autorisées doit être parfaitement définie
– cette liste est l’interface de l’entité interviewée
client/serveur
– à chaque requête correspond un service
– architectures 2-tiers
– architectures 3-tiers
– architectures n-tiers
§ Le modèle client/serveur
métacomputing l’interviewé fournit des services c’est le serveur
– P2P l’interviewer requiert des services c’est le client
– clusters
– grillles
– agents autonomes

27 28

Introduction - Modèles d’architecture Introduction - Modèles d’architecture – Client-serveur

Le modèle client-serveur (2) Architecture 2-tiers

§ Fonctionnement
serveur serveur
le client émet un message contenant une requête à de BD BD de calcul
destination d’un serveur
le serveur exécute le service associé à la requête émise par tiers serveur
le client tiers client
le serveur retourne au client un message contenant le
résultat du service effectué

client client client terminal X terminal X terminal X

client a
service 1 Autres exemples de serveurs
interface

– serveur de fichiers
Serveur ... – serveur de noms
– serveur Web
client b service n
– serveur d’impression
– etc.

29 30

5
 Introduction - Modèles d’architecture Introduction - Modèles d’architecture
Le modèle client-serveur (3) Le modèle client-serveur – Remarques

§ Du point de vue du client la communication est toujours initiée par le client

– le serveur est en mode réactif
requête mode d’exécution synchrone
service
client
distant chaque entité peut jouer les deux rôles (client et serveur)
réponse on ne se préoccupe pas de la manière dont la
communication est réalisée
§ Du point de vue du serveur – on suppose seulement qu’il existe un moyen d’échanger des
messages
gestion des requêtes (priorité) – la plupart des protocoles classiques (FTP, HTTP, etc.) sont basés sur ce
exécution du service (séquentiel, concurrent) principe
mémorisation ou non de l’état du client l’interface du serveur est un élément essentiel de la
communication
Serveur – définit les requêtes autorisées
concept simple mais base théorique pour des architectures
exécution
interface

requêtes sélection
du service
beaucoup plus compliquées

réponses

31 32

Introduction - Modèles d’architecture – Client-serveur Introduction - Modèles d’architecture – Client-serveur

Architecture 3-tiers Apport des architecture 3-tiers

§ logique métier dans le tiers intermédiaire

serveur performance
de BD – traitement métier proche du tiers de données, quelque soit la
BD
localisation du tiers client
scalabilité
tiers serveur – possibilité d’ajouter des tiers métiers pour satisfaire la demande de
tiers intermédiaire nouveaux clients
modularité
serveur de serveur de – tiers client peut être développé indépendamment du tiers de
traitement traitement données
cohérence et évolutivité
tiers intermédiaire – centralisation de la logique métier dans le tiers intermédiaire
– évite les incohérences liées à des implantations différentes de la
tiers client logique métier dans les différents clients
– permet la prise en compte facile de changements de logique métier

client client client

33 34

Introduction - Modèles d’architecture – Client-serveur Introduction - Modèles d’architecture – Client-serveur

Vers les architecture n-tiers Exemple d’architecture n-tiers : application Web

§ Dans les architectures 3-tiers : serveur

tiers client = présentation de l’application de BD BD

tiers serveur = gestion des données tiers serveur de données

tiers intermédiaire = ensemble de services fournis au client tiers intermédiaire
pour consulter/modifier/etc. les données serveurs
– peut être considéré comme un ensemble de tiers, chacun d’application CGI
correspondant à un service particulier tiers intermédiaire
§ Exemple : application Web tiers intermédiaire
tiers 1 : tiers client = présentation par navigateur Web serveur
Web
tiers 2 : tiers intermédiaire = distribution par serveur Web
tiers 3 : tiers intermédiaire = service par scripts côté serveur tiers intermédiaire
tiers 4 : tiers de données = stockage par BD relationnelle tiers client

client client client

(navigateur Web) (navigateur Web) (navigateur Web)
35 36

6
 Introduction - Modèles d’architecture Introduction - Modèles d’architecture - Modèles du « meta-computing »
Modèles du « meta-computing » P2P et « Internet computing »

super-ordinateur virtuel permettant le partage de § Peer to Peer (P2P)

ressources au travers d' un réseau Peer = entité disposant de capacités similaires aux autres
entités d'un système
§ Schéma opératoire
outils de stockage et d'échange de données
connecter des ressources hétérogènes de manière à
former une très grande capacité de calcul § Principes
ces ressources peuvent être distribuées le long de très éviter les vulnérabilités du réseau par la répartition
grands réseaux, voire sur l'
Internet tout entier découvrir les ressources par un procédé de diffusion
– méta-description qui permettent de les retrouver par des moteurs de
recherche
Caractéristiques P2P Clusters Grilles

§ P2P « purs » et « hybrides »

Type de noeuds PCs de bureau PCs dédiés, racks PCs de bureau, stations de travail, serv eurs
Participants Un, plusieurs Plusieurs Plusieurs
Gestion des utilisateurs Centralisée, décentralisée Centralisée Décentralisée
Gestion des ressources Distribuée Centralisée Distribuée P2P « purs » = tous les noeuds participants sont des Peers et
Allocation / Prév ision
Taille
Décentralisée
M illions
Centralisée
100s
Décentralisée
M illiers à millions
aucun serveur central n' est utilisé pour contrôler,
Capacité en calcul Haute, mais peut varier Garantie Haute, mais peut v arier coordonner ou gérer les échanges entre Peers
Bande passante Basse Très haute Basse
P2P « hybrides » = serveur central qui effectue un certain
nombre de fonctions essentielles

37 38

Introduction - Modèles d’architecture - Modèles du « meta-computing » Introduction - Modèles d’architecture - Modèles du « meta-computing »
Avantages du P2P Clusters
réduction du coût global par répartition ensemble d' ordinateurs complets (processeur, mémoire,
accroissement de la scalabilité et de la sûreté de fonctionnement périphériques d'E/S) en général interconnectés par
– pas d'
autorité centrale
agrégation des ressources et interopérabilité des systèmes l'
intermédiaire d'
un LAN
accroissement de l'autonomie utilisé comme une seule ressource de calcul unifiée
– les utilisateurs ne dépendent pas d'
un seul fournisseur centralisé les composants d' un cluster sont typiquement des stations de
anonymat et respect de la vie privée travail ou des PCs et sont généralement homogènes
très grande dynamicité premier cluster « Beowulf » créé en 1994 pour la NASA
– les ressources entrent et sortent du système de manière totalement continue
– la communication ne s' en trouve généralement pas affectée. § Architecture
§ « Internet Computing » tiers d'
accès = fournit les services d'accès et d'authentification
applications P2P parallélisables tiers de gestion = responsable des fonctionnalités basiques du
– une même tâche est effectuée sur chaque Peer avec différents paramètres cluster (service de fichiers, gestion des sauvegardes, ...)
utiliser les ressources inutilisées des noeuds tiers de calcul = fournit la puissance de calcul du cluster
si un noeud détecte une inactivité, il informe un client maître – travaux exécutés sur un ou plusieurs noeuds
activité complètement transparente pour l' utilisateur deux services critiques
§ Exemples d'implantations – « Batch Queing System » = reçoit les demandes de travaux
P2P pur : KaZaa, FreeHeaven, JXTA, Gnutella, Freenet – « Job Scheduler » = détermine l'
ordre d'exécution des travaux en fonction de la
charge processeur moyenne, la charge mémoire moyenne, ...
P2P hybride : Napster
Internet Computing : SETI@Home, RSA-135
39 40

Introduction - Modèles d’architecture - Modèles du « meta-computing » Introduction - Modèles d’architecture - Modèles du « meta-computing »
Grilles Agents autonomes [Wooldridge]
partage de ressources et de puissance de calcul dans de très § Définition
larges organisations multi-institutionnelles
entités matérielles ou logicielles dotées des propriétés suivantes
infrastructure capable d'unifier diverses ressources – autonomie
met en oeuvre un grand nombre de ressources hétérogènes les agents agissent sans l’intervention directe d’humains ou d’autres agents,
peuvent s' accroître de quelques ressources à plusieurs millions et ont le contrôle de leurs actions et de leur état interne
– capacité sociale
probabilité de ressources défaillantes élevée les agents interagissent avec d’autres agents (et éventuellement des
§ Architecture humains) grâce à des langages de communication agent
– reactivité
une fabrique de grille les agents perçoiv ent leur environnement (le monde physique, un utilisateur
– toutes les ressources (PCs, SANs, clusters,...) distribués géographiquement via une interface graphique, un ensemble d’autres agents, Internet, une
un middleware de grille combinaison de tout cela), et répondent en permanence aux
– offre les services de base (gestion des processus distants, co-allocation des changements qui s’y produisent
ressources, accès au stockage, ...) – pro-activité
un environnement de développement de grille les agents n’agissent pas seulement en réponse aux sollicitations de
– offre des services de très haut niveau permettant aux développeurs de l’environnement mais peuvent exhiber un comportement orienté par un
développer des applications et des brokers agissant de manière globale but en prenant l’initiative d’agir
des applications de grille et des portails de grille § Caractéristiques
ex. : Globus, Legion, CERN Data Grid ou Unicore
à la frontière des systèmes distribués et de l’IA
inspiration sociologique
41 42

7
 Introduction Introduction - Modèle de communication - les middlewares
Modèle de communication - les middlewares Positionnement du middleware

§ But = cacher l'

hétérogénéité des plate-formes mises couche indépendante
– des systèmes d’exploitation
en oeuvre pour les applications – des machines
intergiciel = bus de communication auquel les – du réseau de transmission
applications se connectent par l’intermédiaire d’une repose sur
interface – les structures de communication
Applications
de plus bas niveau telles que les
protocoles réseau (TCP/IP,
application 1 application 2 application 3 DECnet, SNA, etc.) application 1 application 2
– les mécanismes offerts par les
systèmes d’exploitation (gestion
Middleware d’interruptions, etc.)
Application Application
Présentation Présentation
Middleware
application i application ... application n Session Session

Transport Transport
Service de
Réseau Réseau
transport des
données Données Données
Physique Physique

43 44

Introduction - Modèle de communication - les middlewares Introduction - Modèle de communication - les middlewares
Services du middleware Différentes approches possibles
§ Disponibilité sur différentes machines § considérer tous les composants en tant que fichiers
§ Fiabilité du transfert périphérique traités en tant que fichiers : Plan 9
assurance que le message atteindra le destinataire systèmes de fichiers distribués : NFS
en un seul exemplaire pb = transparence limitée à l’échange de fichiers
même en cas de panne d’une machine ou de liens réseau
§ Adaptation au trafic
§ appel de procédures à distance : RPC
variation du nb d’applications, du nb et du type de machines appel d’une fonction dont l’implantation est sur une autre
ressource
§ Support de différents schémas de communication
communication 1-1, 1-n § objets distribués : RMI, CORBA, DCOM, etc.
communication synchrone/asynchrone dissociation entre l’interface et l’implantation
§ Service de nommage seule l’interface est distribuée
conversion d’un nom en adresse physique § échange de messages : JMS
§ Support de la notion de transaction envoi de messages entre les participants
si plusieurs entités appartiennent à une transaction, toutes doivent
pouvoir exécuter leur travail ou alors aucune d’elles § agents mobiles : Aglet, AgentTcl, etc.
§ etc. le code à exécuter et les données se déplacent d’une
ressource à une autre sur le réseau

45 46

Introduction - Modèle de communication - les middlewares Introduction - Modèle de communication - les middlewares
Echange de messages : JMS Appel de procédure à distance : RPC

§ Bus logiciel à messages (MOM) § Remote Procedure Call (RPC)

Birrel et Nelson, 1984
asynchronisme émetteur/récepteur : envoi de messages
basé sur l'échange explicite de messages entre processus
désignation explicite ou anonyme du destinataire capacité de cacher le réseau sous-jacent en permettant à un
connexion 1-1 ou 1 parmi N ou diffusion processus d' appeler une fonction dont l'
implantation se situe sur
une autre ressource
§ Propriétés du bus § Principe
priorité, ordre des messages un processus A appelle une procédure sur une machine B
– le processus appelant sur A est suspendu
durée de vie des messages – les paramètres d' invocation sont transmis à B
filtrage des messages – l'
exécution de la procédure sur B est lancée, le résultat est calculé
– émetteur, type de message, priorité – le résultat est renvoyé au processus appelant
– attributs comme si le processus sur A avait appelé une procédure locale
– contenu aucun échange de message n' est visible pour le programmeur
notification des erreurs § Problèmes
les procédures appelantes et appelées ne partagent pas le
§ Avantage même espace d' adressage mémoire
simplicité du modèle, pas d’interblocage les paramètres doivent absolument transiter en même temps que
l'
appel, ce qui peut poser différents problèmes d'
implantation
problèmes : propagation des erreurs
47 48

8
 Introduction - Modèle de communication - les middlewares Introduction - Modèle de communication - les middlewares
Objets distribués (Java RMI, CORBA, DCOM, etc.) Agents mobiles (Aglet, MOA, AgentTcl, etc.)
§ Objets distribués § Code mobile
encapsulation des attributs et des méthodes programme pouvant se déplacer d’un site à un autre sur
séparation entre les interfaces et les objets les un réseau
implémentant ex. : Postscript, SQL, applets, etc.
l’interface est placée sur une machine tandis que l'
objet lui- caractéristique = code interprétable
même réside sur une autre
§ Principe § Motivations
quand un client s'
associe à un objet distribué rapprocher le traitement des données
– une implantation de l'interface de l'
objet appelée proxy est chargé – réduire le volume de données échangées sur le réseau
dans l'
espace d' adressage du client – partage de charge
– ce proxy assure l'
invocation des méthodes en communiquant avec function shipping versus data shipping
l'
implantation réelle de l'
objet qui peut se trouver n'
importe où dans le
système au moyen d' un squelette agissant comme un médiateur
§ Important
l’état du système n' est pas distribué : il réside sur une machine et
une seule
seules les interfaces des objets rendues disponibles sont
accessibles par les processus tournant sur les autres machines.

49 50

Introduction - Modèle de communication - les middlewares Introduction

Agents mobiles (Aglet, MOA, AgentTcl, etc.) Quelques références

§ Agent mobile § http://rangiroa.essi.fr/cours/

processus, incluant du code et des données, pouvant se collection très importante de supports de cours et liens en
déplacer entre des machines pour réaliser une tâche tous genres sur
Principe de migration (en Java) – la programmation
– sérialisation de l’état de l’agent – les réseaux, Internet
– envoi du code et de l’état de l’agent – les systèmes d’exploitation
– destruction de l’agent sur le site origine – les systèmes répartis et la construction d’applications réparties
– création d’un thread sur le site de destination
– chargement du code de l’agent § http://www-mips.unice.fr/~baude/Systemes-
– dé-sérialisation de l’agent
– exécution Distribues/index.html
systèmes d’exploitation et applications réparties
§ Limites
coût important de la migration § http://spe.univ-corse.fr/bernardiweb/cours.htm
– intéressant si réseaux lents et données à traiter volumineuses supports de cours de
problèmes de sécurité – systèmes distribués
– programmation système
problèmes d’autonomie
– CORBA
gestion de l’état, adressage des agents

51 52