Chapitre 2 :

Applications réparties

ISAMM
2ème ING
37
2022 - 2023

1
Plan

❑ Définitions
❑ Exemples des applications réparties
❑ Qualités requises des applications réparties
❑ Intergiciel ( Middleware)
❑ Middleware RPC
❑ Middleware RMI
❑ Application avec Java RMI

2
Définitions
❑ Système réparti: c’est un ensemble des processus communiquant,
répartis sur réseau de machines le plus souvent hétérogènes, et
coopérant à la résolution d’un problème commun.

❑ Environnement réparti : c’est un environnement permettant la

constriction des applications réparties.

❑ Application répartie : c’est une application découpées en

plusieurs unités (composants) où :
❖ Chaque unité où ensemble d’unités peut être placée sur une
machine différente.
❖ Chaque unité peut s’exécuter sur un système différent.
❖ Chaque unité peut être programmé dans un langage différent.
❑ Construction d’une App. Répartie
Les étapes de construction d’une application répartie sont : 39
1. Identifier les éléments fonctionnels de l’application pour les
regrouper au sein des unités
2. Estimer les interactions entre les unités.
3. Définir le schéma organisationnel de l’application.

App. Monolithique 3
Application Répartie
Exemples des applications réparties

❑Coordination d’activités
▪ Système à flots de données (workflow)
▪ Système multi-agents
❑ Communication et partage d’information
▪ Bibliothèques virtuelles
▪ Collecticiels : pour le travail coopératif : bibliothèque, musées,
Magasins virtuels sur internet, la presse et le commerce
électronique.
❑ Application en temps réel
▪ Contrôle des procédés industriels
▪ Localisation des mobiles

4
Qualités requises des ARs
1. Qualités de service
a. Performance : elle couvre plusieurs aspects essentiels
surtout pour les applications en temps réel. Elle peut être
liée à : la communication telles que :
❖ Borne sur la latence
❖ la gigue
❖ la bande passante.
Elle peut être liée à la vitesse du traitement ou d’accès aux
données.
b. Tolérance aux pannes : nécessité d’identifier les scénarios de
fautes possibles. Ces fautes peuvent être de types :
❖ Matériel
❖ Logiciel
❖ Lié aux système de communication
c. Sécurité : elle comprend :
❖ La confidentialité 42
❖ L’intégrité
❖ l’authentification et le contrôle d’accès.
2.Capacité de croissance: c’est le passage d’échelle (scalability)
Le nombre d’objets, d’utilisateurs, d’appareils et de composants
Logiciels tend à s’augmenter.
→ Les qualités de service des AR ne se dégradent pas avec
l’augmentation de :
▪ Nombre des éléments constituants une application répartie.
▪ Nombre d’utilisateurs
▪ de l’entendue géographique 5
 Qualités requises des ARs(3)

3. Capacité d’évolution : les applications réparties doivent s’adapter

aux changements qui peuvent être en termes de :
❖ besoins fonctionnels
❖ diversité des systèmes et organes de communication.
Pour s’adapter à ces changements, une application répartie doit avoir
une architecture modulaire basée sur des composants faiblement
couplés. Elle doit être documentée au niveau conceptuel ainsi qu’au
niveau d’implémentation.

6
 hases de construction
Les phases d’une
de construction d’uneAR
AR

Les phases de construction d’uneAR sont :

1. Conception de l’architecture de l’application
2. Programmation des composants logiciels
I. Utilisation de mécanismes de communication des composants
répartis, appelés Intergiciel ou middleware, tels que :
Socket, RPC, RMI ou CORBA.
II. Programmation selon le modèle d’exécution adopté.
3. Configuration des entités pour qu’elles puissent communiquer et
Échanger des données .
4. L’installation et le déploiement
5. Administration
▪ Surveillance
▪ Maintenance

7
Intergiciel ( Middleware )

❑ Couche logicielle intermédiaire située entre l'application et le

système d'exploitation de la machine.

Application Application

Intergiciels

SE SE
Matériel Matériel

Machine 1 Machine 2

❑ l’intergiciel est nécessaire pour développer

réparties. Il assure la communication entre
composants d’une manière transparente.

8
Intergiciel | Middleware
Les objectifs d’intergiciel sont :
❑ Masquer la complexité de l'infrastructure sous-jacente
❑ Faciliter la conception, le développement et le déploiement
d'applications réparties
❑ Modèle OSI et le Middleware.

C. Application C. AppCli.cation
Présentation Présentation
Middleware et session
et session
C. Transport C. Transport
C. Réseau C. Réseau
C. Liaison C. Liaison
C. physique C. physique

Il existe principalement deux types de Middleware :

❑ Middleware pour les langages procéduraux de type RPC
RPC : Remote Procedure Call
❑ Middleware pour les langages orientés objets de type RMI
RMI : Remote Method Invocation

RMI = RPC orienté objet.

9
 Middleware RPC
❑ Une application est composée de :
❖ programme principal
❖ un ensemble de procédures
❑Le programme principal et les procédures sont compilés et liés
au moment de l’exécution
❖ le programme principal appelle les procédures en transmettant les
paramètres d’entrée
❖ les procédures s’exécutent et retournent leurs résultats dans les
paramètres de sortie

Programme Principal
ProcédureA()
Début
…………………………. Début
……CA()……………… Fin
…………………………………
Procédure B()
……DB()........................ ......
Début Fin
Fin

❑ 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 10
PC | Analogie avec le client/serveur (2)
❑ 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

11
 PC | principe de communication
Le middleware 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 ( interface definition
language )
❑ le code de préparation d’une requête (stub client) est généré
automatiquement à partir de la description IDL

12
 Middleware RMI
Caractéristiques
❑ L’invocation d’une méthode d’un objet distant est similaire à celui local.
objetDistant.methode();
❑ Utilisation d’un objet distant , sans savoir où il se trouve, en demandant à un
service de nommage de le localiser
objetDistant = ServiceDeNoms.recherche("monObjet");
❑ un OD peut être un paramètre d’appel à une méthode locale ou distante
resultat = objetLocal.methode(objetDistant);
resultat = objetDistant.methode(autreObjetDistant);
❑ Le résultat d’un appel distant peut être sous forme d’un nouvel objet qui a été
créé sur la machine distante
NouvelObjetDistant = ObjetDistant.methode() ;

13
Architecture RMI
Objet serveur ❑ Les amorces stub et skeleton : ce sont
Objet client
des adaptateurs pour le transport
des appels distants.
❑ Pour chaque OD manipulé par
Talon client
un client correspond une référence
Talon serveur
(Stub) Skeleton
d’amorce
❑ Les amorces sont générées par
Couche de références objets
Remote reference layer le compilateur d’amorces : rmic
Couche transport
❑Stub : c’est un représentant local de l’OD qui implémente ses
méthodes « exportées»
❖ il transmet l’invocation distante à la couche inférieure Remote
ReferenceLayer
❖ il réalise le paquetage ("marshalling") des arguments des méthodes
distantes
❖ il réalise le dépaquetage ("demarshalling") des valeurs de retour

14
Architecture RMI (2)
❑ Skeleton :
❖ Réalise le dépaquetage des arguments envoyés par le stub
❖ Fait un appel à la méthode de l’objet distant
❖ Réalise le paquetage de la valeur de retour
❑La couche des références distantes

❖Elle joue le rôle d’annuaire pour les objets distants enregistrés

❖Elle permet l’obtention d’une référence d’objet distant à partir
de la référence locale au Stub
❖ce service est assuré par le lancement du programme
rmiregistery
❑ La couche de transport
❖ Elle connecte les 2 espaces d’adressage (JVM)
❖ Elle écoute et répond aux invocations
❖ Elle construit une table des OD disponibles

15
RMI |Mode Fonctionnel

Rmiregistery
(3)
(5)

Naming (3) Naming

(4) (1)

Objet (2)
(5) Objet
client serveur
(5)
(6) (6) (2)
Stub Skeleton

JVM Client JVM serveur

16
RMI |Mode Fonctionnel (2)

❑ Coté serveur
1. Publication: L’objet serveur s'enregistre auprès du Naming de sa JVM)
(méthode rebind)
2. L’objet skeleton est créé. Il maintient une référence vers l’objet serveur
3. Le Naming enregistre l’objet serveur, et le port de communication
utilisé auprès du serveur de noms
❑ Coté Client
4. L’objet client fait appel au Naming pour localiser l’objet serveur
(méthode lookup)
5. Le Naming récupère les "références" vers l’objet serveur, crée l’objet
Stub et rend sa référence au client
6. Le client effectue l’appel au serveur par appel à l’objet Stub

❑ Principe de Java RMI

❖ Mécanisme permettant l’appel de méthodes des objets répartis sur des JVM
différents ( sur des machines différentes ou sur la même machine).
❖ Utilisation d’un protocole propriétaire : R.M.P. (Remote Method
Protocol)
❑ Objectifs
❖ Rendre l’accès, à des objets distribués sur un réseau, transparent
❖ Faciliter la mise en œuvre et l’utilisation d’objets distants Java
❖ Préserver la sécurité (inhérent à l’environnement Java)
▪ RMISecurityManager
▪ Distributed Garbage Collector (DGC)

17
 Développement d’une application avec Java RMI
❑Les étapes sont :
1. Définir une interface distante (Xyy.java).
2. Créer une classe implémentant cette interface (XyyImpl.java).
3. Compiler cette classe (javac XyyImpl.java).
4. Créer une application serveur (XyyServer.java).
5. Compiler l’application serveur.
6. Créer les classes stub et skeleton à l’aide de rmic (XyyImpl_Stub.java et
XyyImpl_Skel.java)
7. Démarrage du registre avec rmiregistry.
8. Lancer le serveur pour la création d’objets et leur enregistrement dans
rmiregistry.
9. Créer une classe cliente qui appelle des méthodes distantes de l’objet
distribué (XyyClient.java).
10.Compiler cette classe et la lancer.

18
Développement d’une application avec Java RMI
❑ Exemple
Invocation distante de la méthode reverseString() d’un objet
distribué qui inverse une chaîne de caractères fournie par l’appelant.
On définit :
❖ ReverseInterface.java : interface qui décrit l’objet distribué
❖ Reverse.java : qui implémente l’objet distribué
❖ ReverseServer.java : le serveur RMI
❖ ReverseClient.java : le client qui utilise l’objet distribué

❑Coté Client ❑ Coté Serveur

❖ l’interface : ❖ l’interface :
ReverseInterface. ReverseInterface.
❖ le client : ❖ l’objet : Reverse.
ReverseClient. ❖ le serveur d’objets :
ReverseServer.

19
 éveloppement d’une application avec Java RMI
❑ Interface de l’objet distribué
❖ Elle est partagée par le client et le serveur.
❖ Elle décrit les caractéristiques de l’objet.
❖ Elle étend l’interface Remote définie dans java.rmi.
❖ Toutes les méthodes de cette interface peuvent déclencher une exception
du type RemoteException.
❖ Cette exception est levée :
▪ si connexion refusée à l’hôte distant
▪ ou bien si l’objet n’existe plus,
▪ ou encore s’il y a un problème lors de l’assemblage ou le
désassemblage.

20
 éveloppement d’une application avec Java RMI
❑ Implémentation de l’objet distribué
❖ L’implémentation doit étendre la classe RemoteServer de
java.rmi.server.
❖ RemoteServer est une classe abstraite. UnicastRemoteObject étend
RemoteServer.
▪ c’est une classe concrète.
▪ une instance de cette classe réside sur un serveur et est disponible via
le protocole TCP/IP.

21
 éveloppement d’une application avec Java RMI
❑ Le serveur
❖ Programme à l’écoute des clients.
❖ Enregistre l’objet distribué dans rmiregistry
Naming.rebind("rmi://hote:1099/Reverse", rev);.
❖On installe un gestionnaire de sécurité si le serveur est amené à
charger des classes en utilisant le System.setSecurityManager(new
RMISecurityManager());

22
 éveloppement d’une application avec Java RMI
❑ Le client :
❖Le client obtient un stub pour accéder à l’objet par une URL RMI
ReverseInterface ri = (ReverseInterface) Naming.lookup
("rmi://localhost:1099/MyReverse");
❖ Une URL RMI commence par rmi://, le nom de machine, un numéro de
port optionnel et le nom de l’objet distant. rmi://hote:2110/nomObjet
❖ Installe un gestionnaire de sécurité pour contrôler les stubs chargés
dynamiquement : System.setSecurityManager(new
RMISecurityManager());
❖ Obtient une référence d’objet distribué :
ReverseInterface ri = (ReverseInterface) Naming.lookup
("rmi://localhost:1099/MyReverse");
❖ Exécute une méthode de l’objet :
String result = ri.reverseString (« ISAMM");

23
Développement d’une application avec Java RMI

❑ Pour que le client puisse se connecter à rmiregistry, il faut lui fournir un fichier
de règles de sécurité client.policy.
grant {
permission java.net.SocketPermission ":1024-65535", "connect";
permission java.net.SocketPermission ":80", "connect";
};

24
Développement d’une application avec Java RMI

❑ Compiler les sources (interface, implémentation de l’objet, le

serveur et le client ) :
javac *.java
❑ Lancer rmic sur la classe d’implémentation :
rmic -v1.2 Reverse
Démarrer rmiregistry :
rmiregistry -J-D java.security.policy=client1.policy
❑ Lancer le serveur :
java ReverseServer
Serveur : Construction de l’implémentation Objet Reverse lié dans le
RMIregistry
Attente des invocations des clients ...
❑ Exécuter le client :
java –D java.security.policy=client1.policy ReverseClient ISAMM
L’inverse de ISAMM est MMASI

25