systèmes distribués
DESCRIPTION
Systèmes Distribués. Fabrice Huet [email protected]. Thèmes, Évaluation. Thèmes: Introduction aux systèmes distribués Matériel, Logiciel Communications Synchronisation Outils pour la programmation Sockets RPC Java-RMI Introduction aux systèmes Pair-à-Pair Évaluation - PowerPoint PPT PresentationTRANSCRIPT
2Mastère MIAGE, 2006
Thèmes, ÉvaluationThèmes: • Introduction aux systèmes distribués
– Matériel, Logiciel– Communications– Synchronisation
• Outils pour la programmation– Sockets– RPC– Java-RMI
• Introduction aux systèmes Pair-à-Pair
Évaluation• Un mini projet à rendre en binomes• Examen
Mastère MIAGE, 2006
1- Introduction aux Systèmes Distribués
“… no man is an island, entire of itself; every man is a piece of the
continent, a part of the main.”John Donne (1572-1631).
“The network is the computer”Sun Microsystems, 1985.
4Mastère MIAGE, 2006
Petites définitions
• Pleins de définitions possibles pour un SD:– Un système distribué est une collection
d’ordinateurs indépendants qui apparaissent à l’utilisateur comme un unique système cohérent
– Un système distribué est un ensemble de programmes, s’exécutant sur des ordinateurs différents, reliés par un réseau, et s’échangeant des informations pour exécuter une tache.
• Élément d’un SD– Un élément physique d’un SD (par exemple un
processeur) est appelé hôte ou noeud
5Mastère MIAGE, 2006
Identifier un système distribué
• Comment déterminer si un système est un SD ?
est-ce que c’est…..
– La distance géographique entre les nœuds ? – Le nombre de nœuds disponibles ?– Le système d’exploitation, les protocoles, l’api
utilisés ?
6Mastère MIAGE, 2006
La taille ? Non
• Il y en a de toutes les tailles
– Les sondes contrôlées depuis la terre• Millions de kms• Seulement quelques noeuds (Mars Pathfinder,
1997)
– Internet• Milliers de kms,• Millions de noeuds
7Mastère MIAGE, 2006
• Tailles intermédiaires
– Ordinateurs reliés à une imprimante• ~ 10 mètres• ~ 10 nœuds
– Caisse enregistreuse dans un supermarché• ~ 100 mètres• ~ 100 nœuds
La taille ? Non
8Mastère MIAGE, 2006
• Très petits– Home Cinéma
• ~ 1 mètre• 3-5 noeuds (TV, Stéreo, DVD,…)
– Voitures (GPS, ABS, alarme, ...)• Quelques mètres
– Plein de noeuds– 40% du coût d’une voiture moderne est lié à
l’électronique
– Personal Area Networks• ~ 1 mètre• 3-5 noeuds (montre, portable, PDA, lunettes…)
La taille ? Non
9Mastère MIAGE, 2006
SD vs. Systèmes centralisés
• Quelle sont les différences entre un SD et un système centralisé (ou mono-processeur)– Un système centralisé est un système qui
fonctionne toujours si la connexion réseau est coupée
– Exemples:• Compilateur• Traitements de texte• Certains jeux • Systèmes d’exploitation pour ordinateurs familiaux
(mais de moins en moins vrai)
10Mastère MIAGE, 2006
• Différences principales– Plus un unique espace d’adressage
• Un programme sur un nœud ne peut pas accéder directement aux données d’un autre programme sur un autre nœud.
– Les programmes s’exécutent indépendamment
– Vraie parallélisme (et concurrence) entre les programmes
– Pas d’horloge globale, chaque exécution est différente
– Les communications se font en envoyant des informations sur le réseau
– La latence à un impact important– Les pannes sont courantes
SD vs. Systèmes centralisés
11Mastère MIAGE, 2006
• Objectifs:– Transparence
• Masquer la distribution– Dégradation progressive
• Un système devrait continuer à fonctionner aussi correctement que possible si une de ses parties tombe en panne.
• Les systèmes centralisés tombent en panne complètement.
– Passage à l’échelle• Un SD devrait être capable de gérer un grand
nombre de noeuds.– Hétérogénéité
• Les nœuds peuvent être d’architecture différente, avoir des OS différents…
SD vs. Systèmes centralisés
12Mastère MIAGE, 2006
• Le concept de transparence peut-être appliqué à plusieurs aspects– Localisation : où se trouve la
ressource– Migration : déplacement de la
ressource– Réplication : plusieurs ressources– Concurrence : plusieurs utilisateurs– Panne : panne ou réparation– Persistance : sauvegarde de la
ressource
Transparence
13Mastère MIAGE, 2006
• La centralisation limite le passage à l’échelle– Service centralisé : un unique serveur– Données centralisées : unique point d’accès
pour les données– Algorithmes centralisés : nécessite une
connaissance globale du système• La latence est aussi un facteur limitant• Mais il existe de nombreuses techniques
pour contourner ces problèmes– Serveurs multiples (ex: CDN - DNS)– Bases de données réparties (ex: DNS)– Algorithmes utilisant des informations
partielles (ex: P2P)
Passage à l’échelle
14Mastère MIAGE, 2006
• Il est plus facile de se rappeler d’un mot/phrase que d’une série de chiffres…
• Les noms de domaine sont des suites alphanumériques de caractères séparées par des points
• Chaque segment a une taille/valeur arbitraire (mais limitée)
• Le segment le plus significatif (le plus à droite) est normalisé – com, edu, gov, info, org, net, biz…
• La transformation du nom de domaine en adresse IP se fait en contactant un serveur de domaine (DNS)
• Les serveurs DNS sont organisés hiérarchiquement• Au sommet se trouvent les serveurs racine • Chaque organisation peut mettre en place son
serveur
Exemple: Nom de domaine
15Mastère MIAGE, 2006
Nom de domaine - 2
Client
ServeursDNS
Serveur Web
http://www.google.com
IP?
XXX.XXX.X
XX.XXX
•Pour communiquer, un client doit connaître l’IP d’un serveur et un numéro de port
•Cette adresse s’obtient auprès d’un serveur DNS (lookup)
http get
16Mastère MIAGE, 2006
Serveurs DNS
com
.
org gov biz fr
unice free inria
• Une requête DNS est envoyée au serveur du domaine dont dépend la machine
• Si le serveur n’a pas autorité il demande à son parent…
• Les réponses parcourent le chemin inverse et sont mises en cache
amazon
17Mastère MIAGE, 2006
Exemple: CDN• Content Delivery Network • Un (très) gros serveur peut supporter plusieurs
centaines de milliers de connexions par secondes• MAIS:
– Rien pour la latence– Le réseau peut être un goulot d’étranglement (cf.
9/11)
• Solutions: – Avoir le même contenu sur plusieurs serveurs– Diriger un client vers un serveur « proche » – Approcher physiquement le contenu du client
• Problèmes:– Diriger le client– Assurer la synchronisations des miroirs
18Mastère MIAGE, 2006
Routage de contenu• Donner au client le contenu disponible à l’endroit le plus approprié• Plusieurs métriques
– Proximité au sens réseau– Proximité géographique– Temps de réponse– Type d’utilisateur (payant…)
• Routage global par redirection DNS– Sous un même nom sont regroupés plusieurs serveurs– Le serveur DNS retourne au client la « bonne » IP– Mais
• Risque de latence élevée pour le lookup• La requête DNS ne contient pas d’information sur le contenu demandé
• Routage par port TCP– La requête est redirigée par un serveur vers d’autres serveurs suivant le
numéro de port• Routage de niveau 7
– Analyse du contenu de la requête– Une requête peut générer plusieurs sous requêtes transparentes
• Web Cache Communication Protocol– Un routeur intercepte les demandes des clients et les envoient à des caches– Les caches indiquent aux routeurs (avec WCPP) quels protocoles ils servent
19Mastère MIAGE, 2006
Conclusion• Les systèmes distribués viennent
dans toutes les tailles • Caractéristiques:
• Multiples espaces d’adressage• Parallélisme, concurrence et absence
d’horloge globale. • Latences et pannes
Mastère MIAGE, 2006
2- Matériel pour les systèmes distribués
21Mastère MIAGE, 2006
Introduction• En pratique tous les systèmes
distribués sont composés de plusieurs processeurs
• Mais l’organisation varie– Mémoire– Interconnexion– Homogénéité/Hétérogénéité
• Influence– La façon de programmer– La façon de les utiliser– Les performances
22Mastère MIAGE, 2006
Organisation• Mémoire privée (multicalculateurs)
– Chaque processeur à sa propre mémoire • Mémoire partagée (multiprocesseurs)
– L’ensemble des processeurs partagent la mémoire• Interconnexion à bus
– Tous les processeurs utilisent un seul médium pour communiquer
• Interconnexion par commutation – Les processeurs communiquent par un ensemble de
câbles– Les messages se déplacent sur ces câbles et des
décisions de routage sont prises à chaque nœud d’interconnexion
• Homogénéité– La même technologie est utilisée partout
• Hétérogénéité– Des ordinateurs différents sont connectés par des
réseaux différents– Ex: Internet (ATM, IP, Fibre, Ethernet…)
23Mastère MIAGE, 2006
Multiprocesseurs à bus• Tous les processeurs ont accès à la même mémoire à
travers un bus• Exemples:
– Bi-Processeurs – Processeurs multi-cores
• Cohérence– Si le CPU A écrit un mot en mémoire et que le CPU b y
accède ensuite, il aura la bonne valeur• Implémentation naïve peu performante
– 4 ou 5 CPUs saturent le bus• Solution: ajouter du cache au niveau de chaque
processeur– Tous les accès mémoire passent pas le cache– Si hit rate élevé, moins de messages sur le bus– Mais problème de la cohérence des caches
UCCache
UCCache
UCCache
Mémoire
24Mastère MIAGE, 2006
Multiprocesseurs à commutation• Les systèmes à bus ne passent pas à
l’échelle• Pour des systèmes de plus de 256
processeurs, on utilise d’autres techniques
• Réseau d’interconnexion– La mémoire est divisée en modules– Les processeurs y sont reliés par une
matrice de commutation (crossbar switch)– A chaque intersection, le nœud de
commutation (crosspoint switch) peut-être ouvert ou fermé
– L’accès à un module mémoire est synchronisé
• Les demandes sont mises dans une file d’attente
• Inconvénient– Nécessite beaucoup de nœuds
d’interconnexion (n*m)
C
C
C
C
M M M M
Mémoires
UC
25Mastère MIAGE, 2006
Multiprocesseurs à commutation• Alternatives à la matrice
– Réseau oméga– NUMA
• Réseau oméga– Des commutateurs à 2 entrées et 2 sorties– Nécessite de passer par plusieurs pour
atteindre la mémoire– A besoin d’être extrêmement rapide, donc
coûteux• NUMA
– NonUniform Memory Access– Accès hiérarchique à la mémoire
• Les processeurs ont une mémoire locale accessibles rapidement
• L’accès à la mémoire d’un autre processeur est plus lent
– En général plus rapide que l’oméga– Mais plus difficile à programmer
• Bien placer les données est non trivial
C
C
C
C
M
M
M
M
26Mastère MIAGE, 2006
Multicalculateurs• Beaucoup plus facile à construire
qu’un système multiprocesseurs • Mémoire privée donc
communications CPU à CPU (volume plus faible que CPU vers mémoire)
• Multicalculateurs homogènes à bus– Les nœuds sont dans des racks– Et reliés par un réseau rapide (Fast
Ethernet)– Passage à l’échelle problématique
(100 nœuds max)
27Mastère MIAGE, 2006
Multicalculateurs• Multicalculateurs homogènes
commutés– Les messages sont routés à travers un
réseau d’interconnexion• Plusieurs topologies possibles• Grille à 2 dimensions
– Câblage simple– Le chemin le plus long est en
n
28Mastère MIAGE, 2006
Multicalculateurs• Tore
– Extension de la grille– Les processeurs frontières sont reliés à
leurs homologues– Nécessite un câblage plus long
29Mastère MIAGE, 2006
Multicalculateurs• Hypercube
– Cube à n dimensions– 4 dimensions: 2 cubes à 3 dimensions
reliés par les sommets homologues– Complexité du câblage en log(n)– Chemin le plus long en log(n)
30Mastère MIAGE, 2006
IBM BlueGene/L
• 1er au classement mondial• 131072 processeurs et 32768 Go de mémoire• Interconnexion par tore 3D (chaque processeur a 6 voisins)
31Mastère MIAGE, 2006
Cray XT3
• 2000 à 30 000 processeurs Opterons• Reliés par un tore 3D• Actuellement 6eme au classement mondial
avec 10880 processeurs
32Mastère MIAGE, 2006
Multicalculateurs• Les multicalculateurs commutés
sont très variés– Modèles à plusieurs milliers de CPUs
coûtant plusieurs millions d’euros– Clusters: PCs reliés par du matériel
« grand public »• Ce qui les différencie souvent est le
matériel pour l’interconnexion– Faible latence et haut débit sont
coûteux
33Mastère MIAGE, 2006
56x2 Opterons
32x2 Xeons
105x2 Opterons
216x2 Opterons32x2 PowerPC
103x2 Itaniums
64x2 Xeons64x2 Opterons
32x2 Opterons
56x2 Opterons
Grid’5000
Mastère MIAGE, 2006
3- Logiciels pour les systèmes distribués
35Mastère MIAGE, 2006
Systèmes d’exploitations• Le matériel est important, mais c’est le logiciel
qui détermine le système distribué• Ressemblent beaucoup à des systèmes
d’exploitation classiques– Gèrent l’accès au matériel– Permet le partage de ressources (mémoire, CPU…)– Masquent l’hétérogénéité
• Système fortement couplé– L’OS fournit une unique vue des ressources– Souvent appelé Distributed Operation System
• Systèmes multiprocesseurs• Systèmes multicalculateurs
• Système faiblement couplé– Chaque ordinateur a son propre OS– Appelé Network Operating System
36Mastère MIAGE, 2006
Systèmes multiprocesseurs• Dans le cas de plusieurs processeurs
accédant à la même mémoire, les accès doivent être protégés
• Très similaire à un OS monoprocesseur• Difficile de porter un OS mono en multi
– Nécessite souvent des changements profonds
– Les OS modernes sont pensés multiprocesseurs dés le début
• Rend le nombre de processeurs transparents pour l’application
• Protection de la mémoire grâce à des primitives de synchronisation– Sémaphores et moniteurs
37Mastère MIAGE, 2006
Systèmes multicalculateurs• Très différent d’un OS monoprocesseur• Les données nécessaires au fonctionnement global du
système ne sont plus dans une zone de mémoire partagée• Chaque nœud a
– son propre noyau (kernel) responsable de la gestion des ressources locales (mémoire, CPU, disque…)
– Un module pour gérer les communications inter processeurs• Une couche commune au dessus des noyaux implémente
un OS supportant l’exécution parallèle et concurrente de taches
• Services parfois fournis:– Mémoire partagée!– Affectation des taches à certains processeurs– Gestion des pannes
Applications distribuées
Services distribués
noyau noyau noyau
38Mastère MIAGE, 2006
Communications par messages• Si pas de mémoire partagée,
communication par messages• Différences
– Buffers ou non– Blocage ou non
• Bufferisation possible à 2 endroits– Du côté de l’appelant– Du côté de l’appelé
• Bloquage– Dépend de la bufferisation
39Mastère MIAGE, 2006
Communications par messages
• Blocage de l’appelant– S1 : mise en buffer, seulement si plein– S2 : envoie du message– S3 : réception du message– S4 : transmission du message a l’appelé– Si blocage en S2 , S3 ou S4 alors buffer appelant inutile
• Blocage de l’appelé– Possible seulement en S3 : buffer vide ou pas de buffer
• L’appelé peut décider de vérifier périodiquement si des messages sont disponibles (polling) mais
– Fréquence trop rapide signifie gâchis de CPU– Fréquence trop lente, risque de pertes de messages (buffer plein)
Appelant ReceveurS1
S2 S3
S4
40Mastère MIAGE, 2006
Fiabilité des communications• L’émetteur a-t-il une garantie que
son message a bien été reçu ?• Si fiabilité les messages sont
garantis d’arriver en S3
• Si blocage en S1 ou S2 fiabilité non obligatoire
• Si blocage en S3 ou S4, fiabilité obligatoire!
41Mastère MIAGE, 2006
Systèmes distribués à mémoire partagée• Les multiprocesseurs sont plus simples à
programmer que les multicalculateurs– Accéder à des variables partagées est plus
simple que communiquer par messages
• Il est possible d’émuler une mémoire partagée sur les multicalculateurs
• Page-Based Distributed Shared Memory– Unique espace d’adressage virtuel– Les pages physiques sont reparties sur les
différentes machines– Quand un processeur demande une page non
locale, le système d’exploitation la copie localement
42Mastère MIAGE, 2006
Systèmes distribués à mémoire partagée• Pour améliorer les performances, on peut
répliquer les pages en lecture seule– Permet à plusieurs processeurs d’avoir localement la
même page– Limite les chargements
• Réplication de toutes les pages– Possibles lorsqu’elles ne sont que lues– Si modifications, alors il faut prendre des mesures
(avant ou après ?)• Inconsistance
– Il est possible d’abandonner la stricte consistence– Mais rend la programmation beaucoup plus
compliqué • Taille des pages
– Quelle est la bonne taille?– D’où vient le coût d’un transfert?
43Mastère MIAGE, 2006
Network Operating Systems• Ne suppose pas que le système est homogène
et qu’une vue globale doit être fournie• Les machines et leurs OS peuvent être
différents, mais elles sont toutes reliées par un réseau
• Un NOS fournit des mécanismes pour utiliser les services disponibles sur certaines machines
• Exemples:– rlogin, ssh…
Applications distribuées
Services réseau
noyau noyau noyau
Services réseau
Services réseau
44Mastère MIAGE, 2006
Middleware• Un DOS ne gère pas des machines
indépendantes• Un NOS ne donne pas une vue cohérente
de machines• Comment avoir le meilleur des 2 ?• On ajoute une couche au dessus d’un
NOS pour masquer l’hétérogénéité, le middleware
Applications distribuées
Services réseau
noyau noyau noyau
Services réseau
Services réseau
Middleware
Mastère MIAGE, 2006
4- Outils pour la programmation
46Mastère MIAGE, 2006
Outil de base: Sockets
• Introduit dans Berkeley Unix 4.2 (BSD) en 1981
• Représentation point à point d’un flux de données
• Un programme peut – Écrire des données– Lire des données
BAApplication
Socket write
write
read
read
47Mastère MIAGE, 2006
Primitives• Les sockets fournissent un ensemble
d’opérations de base (les primitives)– Socket: création d’une socket– Bind: Attachement de la socket à une
adresse locale– Listen: Annonce l’acceptation des
connexions– Accept: Bloque jusqu’à l’arrivée d’une
demande de connexion– Connect: Demande de connexion– Send: Envoie de données– Receive: Lecture de données– Close: Fermeture
48Mastère MIAGE, 2006
Sockets en Java• Jusqu’à JDK 1.4 : I/Os bloquantes
– Deux classes : java.net.Socket et java.net.ServerSocket
– Beaucoup de classes pour la gestion des streams
– Toutes les opérations (lecture ou écriture) sont bloquantes
– 1 ou 2 threads nécessaires pour chaque socket• Surcoût mémoire et changement de
contexte • available() permet de savoir si des
données sont disponibles mais utilisation du CPU
49Mastère MIAGE, 2006
Nouvelle API pour les Sockest
• Nouveauté dans JDK 1.4: I/Os non bloquantes– 2 nouvelles abstractions de haut niveau
• Buffers: conteneur à données linéaire• Channels: Tube de communication bidirectionnel
supportant des opérations bloquantes et non bloquantes• Une classe Selector pour multiplexer les événements :
base du passage à l’échelle– ServerSocketChannel et SocketChannel– Support d’opérations bas-niveau de gather/scatter – Fichier mappés en mémoire, gestion des buffers…– Package java.nio.*
50Mastère MIAGE, 2006
Limitations des sockets• Description des données (ce qui sera lu et écrit)
– Chaque application doit le définir – L’implémentation doit être identique sur chaque nœud– Problèmes: ordre des bits, symboles spéciaux…
• Protocole de communication (comment lire et écrire)
– Chaque application doit le définir– L’implémentation doit être consistante sur tous les noeuds– Problèmes: taille de buffer, synchronisation, timeouts, ...
• Conséquences– Beaucoup de temps est passé à récrire le même code– Des erreurs sont faciles à faire, mais difficiles à trouver
51Mastère MIAGE, 2006
Sockets vs. Procédures• Probleme: 2 abstractions différentes dans la même
application– Local: structures de données et procédures– Distant: Flux de données et lecture/écriture dans des sockest
• Idée: Pourquoi ne pas tout programmer sous forme de procédures? – Le programmeur n’a plus à se soucier de détails bas-niveau, il
peut se concentrer sur son application. – Première implémentation avec RPC (Remote Procedure Calls)
• Fonctionnement : Un outil génère du code– Code pour convertir des appels de procédure en données
écrite ou lues sur des sockets– Code pour convertir les structures de données en données
compatibles avec les sockets (marshalling / unmarshalling ou Serialization/Deserialization)
52Mastère MIAGE, 2006
Remote Procedure Calls (RPC)• Permet de donner l’impression d’un appel local
pour un appel distant• Code généré
– Du côté appelant: stubs – Du côté appelé: skeletons
• Passage de paramètre par valeur• RPC est fait pour le langage C
– Toujours utilisé aujourd’hui, par exemple pour NFS
BA
Stub Skeleton
Application
RPC
53Mastère MIAGE, 2006
Remote Procedure Calls
• Le rôle du Stub est de: – Transformer les structures de données passées en
paramètres de la procédure en flux d’octets (marshalling)– Écrire ces données dans la socket– Attendre jusqu’à ce que des données soient disponibles en
lecture– Lis les données et les converties en structure
(unmarshalling)– Retourne le résultat à l’appelant comme résultat de son
appel de méthode
A
Stub
54Mastère MIAGE, 2006
Remote Procedure Calls
• Le Skeleton doit – Attendre que des données soient disponibles en
lecture– Lire un flux d’octets et construire la structure
correspondante– Appeler la méthode correspondante sur B avec les
paramètres– Transformer le résultat en flux d’octets – Envoyer ce résultat à l’appelant
B
Skeleton
55Mastère MIAGE, 2006
Remote Procedure Calls • Limitations de RPC
– Peu de transparence• Les machines distantes sont trouvées avec leur adresse
IP et le numéro de port– Pas de nommage symbolique
• Impossible de trouver un service suivant son nom ou son type
– Pas de chargement de code dynamique• Le stub doit être pré installé chez l’appelant, le skeleton
chez l’appelé• Le code pour le marshalling/unmarshalling est
spécifique et doit être présent des 2 côtés– Aucun mécanisme de tolérance aux pannes ou de
gestion des erreurs
56Mastère MIAGE, 2006
Java-RMI• RMI signifie Remote Method Invocation• Introduit dés JDK 1.1• Partie intégrante du cœur de Java• RMI = RPC en Java + chargement dynamique
de code• Même notions de stubs et skeletons• Fonctionne avec l’API de sérialization (utilisée
également pour la persistance) • Possibilité de faire interagir RMI avec CORBA
et DCOM
57Mastère MIAGE, 2006
RMI: Fonctionnalités• Masque pratiquement tout le réseau à
l’application• Très similaire à RPC• Utilisation de l’interface Remote Java• Appels distants bloquants
– L’appelant est bloqué jusqu’à ce que le résultat soit disponible
• Les références vers des objets « normaux »sont passées par copie profonde (deep copy) grâce à la sérialisation
• Les références vers des objets distants sont passées par référence
58Mastère MIAGE, 2006
Implémenter un objet distant• Un objet qui à des méthodes appelables à
distance est appelé objet distant• Les seules méthodes accessibles à distance
seront celles spécifiées dans l’interface Remote– Écriture d’un interface spécifique à l’objet,
étendant l’interface java.rmi.Remote
• Chaque méthode distante doit annoncer lever l’exception java.rmi.RemoteException– Sert à indiquer les problèmes liés à la
distribution
• L’objet devra fournir une implémentation de ces méthodes
59Mastère MIAGE, 2006
Implémenter un objet distantimport java.rmi.Remote;import java.rmi.RemoteException;
public interface MonInterfaceDistante extends
Remote { public void echo() throws
RemoteException;}
• Cette interface indique que l’objet qui l’implémentera aura la méthode echo() appelable à distance
60Mastère MIAGE, 2006
Implémenter un objet distantimport java.rmi.Remote;import java.rmi.RemoteException;import java.rmi.server.UnicastRemoteObject; public class MonObjetDistant extends UnicastRemoteObject { implements MonInterfaceDistante public MonObjetDistant() throws RemoteException {} public void echo() throws RemoteException{ System.out.println(« Echo »); }}
• L’objet distant doit finalement implémenter les méthodes de l’interface
• Hériter de java.rmi.server.UnicastRemoteObject• Et avoir un constructeur sans paramètre levant aussi
l’exception
61Mastère MIAGE, 2006
Utiliser un objet distant• Pour utiliser un objet distant il faut
– Connaître sont interface– Le trouver!– L’utiliser
• RMI fournit un service de nommage permettant de localiser un objet par son nom : le registry– L’objet s’enregistre sous un nom
« bien connu »– Les clients demandent une référence
vers cet objet
62Mastère MIAGE, 2006
Utiliser un objet distantimport java.rmi.RemoteException; public class Client { public static void main(String args) { MonInterfaceDistante mod = ….. // du code pour trouver l’objet try { mod.echo(); } catch (RemoteException e) { e.printStackTrace(); } }}
• Une fois la référence obtenue, il suffit d’appeler la méthode dessus, en prenant garde aux éventuelles exceptions
63Mastère MIAGE, 2006
Trouver un objet distant• L’objet doit s’enregistrer dans le registry
– Programme lancé auparavant sur la même machine que l’objet distant : rmiregistry
– Utilise le port 1090 par defaut– Possibilité de le démarrer depuis l’application
(LocateRegistry)• Il agit comme un service d’annuaire• Les noms ressemblent à des URLs
– protocole://machine:port/nom– Protocole, machine et port sont optionnels– Objet toto sur la machine locale: ///toto
• Les méthodes de gestion sont regroupées dans la classe Naming
• L’objet distant appel Naming.bind• Le client appel Naming.lookup
64Mastère MIAGE, 2006
Générer les stubs et skeletons• Une fois l’objet distant écrit, il est
possible de générer les stubs et les skeletons
• Outils fournit dans Java: rmic• Prends le nom complet de la classe
distante (package+nom)• Génère 2 fichiers ( _Stub et _Skel)• Ne met dans le stub que les méthodes
spécifiées dans l’interface distante• Possibilité de voir le code source avec
l’option –keep
65Mastère MIAGE, 2006
RMI: en résumé1. Écrire l’interface distante2. Écrire le code de l’objet distant
1. Implémenter l’interface2. Ajouter le code pour le registry (en général dans le
main ou le constructeur)3. Compiler4. Générer les stub et skeleton5. Écrire le client
1. Obtenir une référence vers l’objet distant2. Appeler les méthodes
6. Compiler7. Exécuter
1. Démarrer le serveur2. Démarrer le client3. Debugger