applications-reparties

1. Chapitre 2 :
Applications réparties
1
ISAMM
3ème année Informatique Multimédia
2017-2018

2. 2
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

3. ISAMM | 3ème année Informatique Multimédia | 2017-2018
3
 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.
Définitions

4. 4
 Construction d’une App. Répartie
Les étapes de construction d’une application répartie sont :
1. Identifier les éléments fonctionnels de l’application pour le
regrouper
au sein des unités
2. Estimer les interactions entre les unités.
3. Définir le schéma organisationnel de l’application.
Application Répartie
App. Monolithique
Définitions (2)

5. 5
Coordination d’activités
 Système à flots de données (workflow)
 Système è 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
Exemples des applications réparties

6. 6
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
Qualités requises des ARs

7. 7
c. Sécurité : elle comprend :
 La confidentialité
 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
Qualités requises des ARs(2)

8. 8
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.
Qualités requises des ARs(3)

9. 9
Les phases de construction d’une AR 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
Phases de construction d’une AR

10. 10
Intergiciel ( Middleware )
 Couche logicielle intermédiaire située entre l'application et le
système d'exploitation de la machine.
Machine 1 Machine 2
 l’intergiciel est nécessaire pour développer des applications
réparties. Il assure la communication entre leurs différents
composants d’une manière transparente.
Application
Intergiciels
SE
Matériel
Application
SE
Matériel

11. 11
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. Transport
C. Réseau
C. Liaison
C. physique
C. Application
C. Transport
C. Réseau
C. Liaison
C. physique
Présentation
et session
C.
Présentation
et session
Middleware

12. ISAMM | 3ème année Informatique
Multimédia | 2017-2018 12
Types de Middlewares
Il existe 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.

13. 13
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
Début
………………………….
……CA()…………………
…………………………………
……DB()...............................
Fin
Procédure A()
Début
Fin
Procédure B()
Début
Fin

14. ISAMM | 3ème année Informatique
Multimédia | 2017-2018
14
21/12/2017
RPC | 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

15. 15
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
RPC | principe de communication

16. 16
RPC | Principe de réalisation

17. 17
Middleware RMI
 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() ;
Caractéristiques

18. 18
Architecture RMI
Talon client
(Stub)
Couche de références objets
Remote reference layer
Couche transport
Talon serveur
Skeleton
Objet client
Objet serveur  Les amorces stub et skeleton : ce sont
des adaptateurs pour le transport
des appels distants.
 Pour chaque OD manipulé par
un client correspond une référence
d’amorce
 Les amorces sont générées par
le compilateur d’amorces : rmic
 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
Reference Layer
 il réalise le paquetage ("marshalling") des arguments des méthodes
distantes
 il réalise le dépaquetage ("demarshalling") des valeurs de retour

19. 19
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

20. ISAMM | 3ème année Informatique Multimédia | 2017-2018 20
Rmiregistery
Objet
client
Naming
Stub
Objet
client
Naming
Skeleton
JVM Client JVM serveur
(1)
(2)
(2)
(3)
(3)
(4)
(5)
(5)
(5)
(6) (6)
RMI |Mode Fonctionnel

21. 21
 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
RMI |Mode Fonctionnel (2)

22. 22
 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 transparent l’accès à des objets distribués sur un réseau
 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)
Java RMI | principe et objectifs

23. 23
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.vallet — 12/41 Programmation
Développement d’une application avec Java RMI
Les étapes sont :

24. 24
 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é
Développement d’une application avec Java RMI
Coté Client Coté Serveur
 l’interface :
ReverseInterface.
 le client :
ReverseClient.
 l’interface :
ReverseInterface.
 l’objet : Reverse.
 le serveur d’objets :
ReverseServer.

25. 25
Dé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.

26. 26
Dé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.

27. 27
Dé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());

28. 28
Dé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");

29. 29
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";
};

30. 30
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
Développement d’une application avec Java RMI