Systèmes Répartis

Objectif de ce cours

Etudier les mécanismes de mise en place des services middellware ou

intergiciel permettant la connexion entre deux applications.

 Cas des langages procéduraux

RPC : Remote Procedure Call
 Cas de l'orienté Objet (java)
RMI: Remote Method Invocation

2
Middleware RPC
⚫ Applications structurées en 2 parties
◦ le programme principal
◦ un ensemble de procédures
⚫ Principe de fonctionnement
 programme principal et procédures sont
compilés et liés
 au moment de l’exécution
- le programme principal appelle les
procédures en transmettant des paramètres
d’entrée
- les procédures s’exécutent et retournent
leurs résultats dans les paramètres de
sortie

3
middleware RPC: Analogie avec le
client-serveur
 le programme principal se comporte comme un
client
 l’ensemble des procédures est assimilable à un
ensemble de services disponibles sur un serveur
- Interface d’un service = signature de la procédure
- Interface du serveur = ensemble des signatures des
procédures

4
Middleware RPC
⚫ Assure la transparence de localisation
Le client appelle les procédures comme si elles étaient
locales
 Le middleware assure la communication avec le serveur
 L’interface du serveur est décrite en IDL
Le code de préparation d’une requête (stub client) est
généré automatiquement à partir de la description IDL

5
Middleware RPC
⚫ Exemple : calcul de fonction mathématiques

6
Middleware RPC
 Le client R PC
⚫ Lors de la compilation et de l’édition des liens:
 erreur car les procédures ne sont pas présentes
 procédures émulées par 2 fausses procédures appelées stubs
client
⚫ Le stub client
 procédure qui porte le nom de la vraie procédure qu’il remplace
 donne l’illusion au programme principal que la procédure est
bien locale
 remplace le code de la vraie procédure par un autre code
- Gère la connexion avec le bus middleware
- Transmet les paramètres vers la machine où se trouve la procédure
- Récupère le(s) résultat(s)

7
Middleware RPC

 Le serveur R PC
⚫ Impossible d’avoir un programme exécutable
composé uniquement de procédures
 nécessité d’un programme principal appelé stub
serveur
⚫ Le stub serveur
permet de créer un exécutable contenant les
procédures du serveur
 gère la communication avec les stubs client
- Active la procédure désignée en lui transmettant les
paramètres d’appel
- Retourne les valeurs de résultat au stub client

8
Middleware RPC
 Caractéristiques
Codes du client et du serveur indépendants du système de
communication; le client ne sait pas si la procédure est
locale ou éloignée
Le code du client n’a pas à préparer le message ni à
localiser le serveur => à la charge du middleware RPC
Système de dialogue entièrement externe au client et au
serveur décrit dans un langage spécifique (IDL) à partir
duquel est généré automatiquement le code nécessaire
Structure de communication construite au moment de la
compilation
Communication synchrone  le client attend la réponse à
son appel de procédure avant de continuer son
traitement.

9
Middleware RPC
 Les difficultés ⚫ Appel de procédure à
distance
⚫ Appel de procédure  Appelant et appelé sont
local dans 2 espaces virtuels
 appelant et appelé sont différents
dans le même espace  pannes du client et du
virtuel serveur sont
indépendantes
 même mode de pannes  pannes du réseau de
 appel et retour de communication (perte du
procédure sont des message d’appel ou de
réponse)
mécanismes internes
 temps de réponse du
considérés comme serveur long
fiables - charge du réseau ou
du site serveur 10
Middleware RPC
⚫ Principe de réalisation

A B
C

E D

11
Middleware RPC
 Principe de fonctionnement
⚫ Côté de l’appelant
Le client réalise un appel procédural vers la
procédure talon client
- Transmission de l’ensemble des arguments
⚫ Au point A
- Le talon collecte les arguments et les assemble dans
un message (empaquetage - parameter marshalling)
- Un identificateur est généré pour le RPC
- Le talon transmet les données au protocole de
transport pour émission sur le réseau. Mais où??
- Pb: détermination de l’adresse du serveur
12
Middleware RPC
 Côté de l’appelé
⚫ le protocole de transport délivre le message au service de
RPC (talon serveur/skeleton)
⚫ Au point B
- Le talon désassemble les arguments (dépaquetage -
unmarshalling)
- L’identificateur de RPC est enregistré
- L’appel est ensuite transmis à la procédure distante requise
pour être exécuté (point C). Le retour de la procédure
redonne la main au service de RPC et lui transmet les
paramètres résultats (point D)
⚫ Au point D
- Les arguments de retour sont empaquetés dans un message
- Le talon transmet les données au protocole de transport
pour émission sur le réseau
13
Middleware RPC
⚫ Coté de l’appelant
◦ l’appel est transmis au service de RPC (point
E)
– Les arguments de retour sont dépaquetés
– Les résultats sont transmis à l’appelant lors du
retour de procédure ( un retour habituel de
procédure en mode local)
o Lestalons client et serveur sont créés
(générés automatiquement) à partir
d’une description d’interface
14
Middleware RPC
⚫ Description d’interface
◦ Interface = “contrat” entre client et serveur
 Le contrat
 Formalise le dialogue entre le client et le serveur
- Permet au client et au serveur d’avoir la même
compréhension des échanges effectués
 Répond aux questions
- Que transmet-on ?
- Où envoie-t-on les données ?
- Qui reçoit les données ?
- Comment sait-on que le travail est terminé ?

15
Middleware RPC
⚫ Description d’interface
 Indépendante d’un langage particulier
(adaptée à des langages multiples)
 Indépendante de la représentation des types
 Indépendante de la machine (hétérogénéité)
 Contenu minimal
◦ Identification des procédures (nom, version)
◦ Définition des types des paramètres, résultats
◦ Définition du mode de passage (IN, OUT, IN-
OUT)

16
Middleware RPC
⚫ Exemple de contrat

17
Middleware RPC

18
Middleware RPC
Construction du client et du serveur

19
Middleware RPC
C onstruction
du client et
du serveur

20
Les objets répartis avec Java RMI

21
Introduction
⚫ L’idéalpour tout système distribué c’est d’utiliser la
technologie objet:

◦ Invoquer une méthode d’un objet se trouvant sur une autre

machine exactement de la même manière que s’il se trouvait au
sein de la même machine :

[Link]() ;

◦ Utiliser un objet distant (OD), sans savoir où il se trouve, en

demandant à un service « dédié » de renvoyer son adresse :
objetDistant= [Link]("monObjet");

22
Introduction
⚫ Pouvoirpasser un O D en paramètre d’appel à une
méthode locale ou distante :
resultat=[Link](objetDistant);
resultat=[Link](autreObjetDistant);
⚫ Pouvoir récupérer le résultat d’un appel distant sous
forme d’un nouvel objet qui aurait été créé sur la
machine distante :
ObjetDistant=[Link]() ;

RMI(RemoteMethodInvocation) est un système d’objets

distribués performant destiné au développement d’applications
distribuées entièrement en Java

23
Présentation RMI
⚫ RMIest une API: un ensemble de classes et méthodes
que l’on trouve dans ([Link]) et qui servent à
développer des applications distribuées en Java ayant
la même syntaxe que des applications non distribuées
dans différents processus (en général sur différentes
machines)…

24
Objectifs de RMI

⚫ Rendre transparent l’accès à des objets distribués

sur un réseau : Un appel de méthode sur un objet
distant doit être syntaxiquement le même qu’un
appel de méthode sur un objet local :

 Idée :masquer (au programmeur) les communications nécessaires

dans un objet :

⚫ Faciliter la mise en œuvre et l’utilisation d’objets

distants Java

25
Architecture de RMI
⚫ RMI est essentiellement construit sur une abstraction
en trois couches.
◦ Stubs et Skeletons (Souche et Squelette)
◦ Remote Reference Layer (Couche de référencement distante)
◦ Couche Transport

26
Stubs et Skeletons
⚫ Les stubs sont des classes placées dans la machine du client.
⚫ Lorsque notre client fera appel à une méthode distante, cet
appel sera transféré au stub.
⚫ Le stub est donc un relais du côté du client. Il devra donc
être placé sur la machine cliente.
⚫ Le stub est le représentant local de l’objet distant.
⚫ Il emballe les arguments de la méthode distante et les
envoie dans un flux de données vers le service RMI distant.
⚫ D’autre part, il déballe la valeur ou l’objet de retour de la
méthode distante.
⚫ Il communique avec l’objet distant par l’intermédiaire d’un
skeleton.

27
Stubs et Skeletons

⚫ Le skeleton est lui aussi un relais mais du

côté serveur. Il devra être placé sur la
machine du serveur.
⚫ Il déballe les paramètres de la méthode

distante, les transmet à l’objet local et

emballe les valeurs de retours à renvoyer au
client.
⚫ Les stubs et les skeletons sont donc des

intermédiaires entre le client et le serveur

qui gèrent le transfert distant des données.
⚫ Depuis la version 2 de Java, le skeleton
n’existe plus.
28
Remote Reference Layer
⚫ La deuxième couche est la couche de référence
distante.
⚫ Ce service est assuré par le lancement du
programme rmiregistry du coté du serveur
⚫ Le serveur doit enregistrer la référence de
chaque objet distant dans le service rmiregistry
en attribuant un nom à cet objet distant.
⚫ Du coté du client, cette couche permet
l’obtention d’une référence de l’objet distant à
partir de la référence locale (le stub) en utilisant
son nom rmiregsitry

29
Couche transport
⚫ La couche transport est basée sur les connexions
TCP/IP entre les machines.
⚫ Elle fournit la connectivité de base entre les 2 JVM.
⚫ De plus, cette couche fournit des stratégies pour
passer les firewalls.
⚫ Elle suit les connexions en cours.
⚫ Elle construit une table des objets distants
disponibles.
⚫ Elle écoute et répond aux invocations.
⚫ Cette couche utilise les classes Socket et
ServerSocket.
⚫ Elle utilise aussi un protocole propriétaire R.M.P.
(Remote Method Protocol).

30
Démarche RMI
1. Créer les interfaces des objets
distants
[Link]éer les implémentation des objets
distants
3. Générer les stubs et skeletons
4. Créer le serveur RMI
5. Créer le client RMI
6. Déploiement Lancement
◦ Lancer l’annuaire RMIREGISTRY
◦ Lancer le serveur
◦ Lancer le client
31
Exemple

⚫ Supposant qu’on veut créer un serveur

RMI qui crée un objet qui offre les
services distants suivant à un client RMI:
◦ Convertir un montant de l’euro en D H
◦ Envoyer au client la date du serveur.

32
1- Interface de l’objet distant

33
Interfaces
⚫ La première étape consiste à créer une
interface distante qui décrit les méthodes
que le client pourra invoquer à distance.
⚫ Pour que ses méthodes soient accessibles
par le client, cette interface doit hériter de
l'interface Remote.
⚫ Toutes les méthodes utilisables à distance
doivent pouvoir lever les exceptions de type
RemoteException qui sont spécifiques à
l'appel distant.
⚫ Cette interface devra être placée sur les
deux machines (serveur et client).
34
Implémentation
⚫ Il faut maintenant implémenter cette
interface distante dans une classe. Par
convention, le nom de cette classe aura pour
suffixe Impl.
⚫ Notre classe doit hériter de la classe
[Link] ou de l ’une
de de ses sous-classes.
⚫ La plus facile à utiliser étant
[Link].
⚫ C’est dans cette classe que nous allons

définir le corps des méthodes distantes que

pourront utiliser nos clients
35
Deuxième étape :Implémentation
de l’objet distant

36
Naming Service
⚫ Les clients trouvent les services distants en
utilisant un service d'annuaire activé sur un
hôte connu avec un numéro de port connu.
⚫ Il inclut lui-même un service simple appelé
(rmiregistry).
⚫ Le registre est exécuté sur chaque machine

qui héberge des objets distants (les

serveurs) et accepte les requêtes pour ces
services, par défaut sur le port 1099.

37
Utilisation de RMI
⚫ Un serveur crée un service distant en créant
d'abord un objet local qui implémente ce service.
⚫ Ensuite, il exporte cet objet vers RMI.
⚫ Quand l’objet est exporté, RMI crée un service

d’écoute qui attend qu’un client se connecte et

envoie des requêtes au service.
⚫ Après exportation, le serveur enregistre cet

objet dans le registre de RMI sous un nom public

qui devient accessible de l’extérieur.
⚫ Le client peut alors consulter le registre distant

pour obtenir des références à des objets distants.

38
Le serveur
⚫ Notre serveur doit enregistrer auprès du registre RMI
l’objet local dont les méthodes seront disponibles à
distance.
⚫ Cela se fait grâce à la méthode statique bind() ou
rebind() de la classe Naming.
⚫ Cette méthode permet d’associer (enregistrer)

l’objet local avec un synonyme dans le registre RMI.

⚫ L’objet devient alors disponible par le client.
◦ ObjetDistantImpl od = new ObjetDistantImpl();
◦ [Link]("rmi://localhost:1099/NOM_Servic
e",od);

39
Code du serveur RMI

40
Client
⚫ Le client peut obtenir une référence à un objet distant par l’utilisation
de la méthode statique lookup() de la classe Naming.
⚫ La méthode lookup() sert au client pour interroger un registre et
récupérer un objet distant.
⚫ Elle retourne une référence à l’objet distant.
⚫ La valeur retournée est du type Remote. Il est donc nécessaire de
caster cet objet en l’interface distante implémentée par l’objet distant.

41
Fonctionnement de RMI

42
Lancement du registre
 Lancement du registry
⚫ Windows : > start rmiregistry [port]
◦ En paramètre, on peut préciser un numéro de port :
port d'écoute du registry

⚫ En Java: un objet Java peut à l'exécution lancer un

registry:
public static Registry createRegistry(int port) throws
RemoteException:
◦ Lance un registry localement sur le port d'écoute
passé en paramètre
43
Exercice
Nous voulons définir un objet distant
compte bancaire ainsi que le client qui
invoque ses méthodes via RMI. Cet objet
distant doit exposer les méthodes suivantes:
déposer une somme d'argent, retirer une
somme d'argent, afficher le solde actuel.
Étapes pour la mise en œuvre:

1. Définir une interface distante pour le

compte bancaire.
2. Implémenter cette interface dans une
classe serveurimpl.
3. Mettre en place un serveur RMI pour
enregistrer l'objet distant.
4. Créer un client pour appeler les méthodes
distantes.
Interface distante ([Link])
Implémentation du compte
bancaire
([Link])
Serveur RMI ([Link])
Client RMI
Présentation du Security Manager en Java
Le Security Manager est une fonctionnalité de sécurité en Java qui
contrôle les opérations pouvant être effectuées par les applications en
cours d'exécution. Il impose une politique de sécurité qui restreint
l'accès à certaines ressources (fichiers, réseau, classes système, etc.)
en fonction de règles spécifiées.

Fonctionnalités principales :
1. Contrôle d'accès :
Empêche les applications non autorisées d'exécuter certaines actions (lecture/écriture
de fichiers, connexion réseau, exécution de commandes système).
2. Gestion des politiques de sécurité :
Les règles de sécurité sont définies dans un fichier de politique (par défaut [Link]),
où vous spécifiez les permissions accordées à chaque code source.
3. Protection des environnements sensibles :
Très utilisé dans des contextes où des applications non fiables doivent être exécutées,
comme les applets ou des services distants (exemple : RMI).
Activation d'un Security Manager dans une application Java

1. Définir une politique de sécurité : Créez un

fichier .policy qui définit les permissions
nécessaires pour l'application.
2. Activer le Security Manager : Utilisez
[Link]() pour activer un
Security Manager dans votre application.
Exemple d'intégration dans l'exercice RMI

Étape 1 : Créer un fichier de politique de sécurité

Nom du fichier : [Link]

Explications :
• SocketPermission : Autorise les connexions réseau
nécessaires pour le fonctionnement de RMI.
• FilePermission : Permet au serveur de lire et d'écrire des
fichiers si nécessaire.
• PropertyPermission : Permet de lire certaines propriétés
système comme [Link].
Étape 2 : Modifier le client pour utiliser un Security Manager
Étape 3 : Lancer le client avec la politique de sécurité

1. Méthode 1 : En ligne de commande

java -[Link]=[Link] Client
2. Méthode 2 : Définir dans le code Comme
illustré dans le code du client ci-dessus,
utilisez :
[Link]("[Link]",
"[Link]");
• Lorsque le client démarre, le Security Manager
est activé.
• Si le serveur envoie un objet ou une classe
distante non autorisée par la politique
[Link], le client lève une exception de
type AccessControlException.
• Les opérations distantes fonctionnent
normalement si les permissions sont
correctement configurées.