Upload
axelle-poncet
View
144
Download
0
Embed Size (px)
Citation preview
Cours 12
Contenu du cours :
RMI : a quoi ca sert Comment ca marche La RMIRegistry Créer un serveur RMI La sérialisation Créer un client RMI Deploiement d’une application RMI Téléchargement des Stubs & Securite Références
Remote Method Invocation
Le RMI permet à des objets distants de communiquer par appels de méthodes.Il permet de construire des applications java distribuées ,
reposant sur des composants (objets) interopérables.
A quoi ça sert ?
2
Remote Method InvocationLes composants
Une application distribuée en RMI comprend :
Une (ou plusieurs) RMIregistry : Ce composant logiciel (inclus dans la jdk) agit comme un service de nommage (annuaire) entre les différents composants des applications RMI. Il maintient une structure de noms arborescente. Les objets désirant proposer leurs services (serveurs) à des clients distants s'inscrivent dans cette structure (opérations de bind-rebind). Les objets désireux d'utiliser ces services (clients) demandent à la registry de leur trouver un serveur adéquat ( opérations de lookup ).
Un (ou plusieurs) serveur(s) : Un serveur propose ses services/méthodes à des objets distants, c'est dans la création des serveurs que l'effort de programmation est le plus important.
Un (ou plusieurs) client(s) : Un client requiert les services (appelle les méthodes) d'un serveur distant, ces appels de méthodes sont aussi simples que s'il s'agissait de manipuler des objets locaux.
3
Remote Method InvocationComment ça marche ?
JVM B JVM AObjet ClientObjet Serveur
RMI registry
2-Le client demande à la registry un serveur.
1-Le serveur s'enregistre auprès de la registry.
3-Le client appelle des méthodes du serveur.
Le schéma d'utilisation typique (et le plus simple ) de RMI,est basé sur ces 3 étapes.
4
Remote Method InvocationLa RMI registry (reggie)
La RMI registry est une application (RMI :) )créant un processus qui écoute et accepte les connexions (par défaut, sur le port 1099),
elle maintient une structure de noms hiérarchisée.
racine
nomObjet1 objet1
nomRepertoire1
nomObjet2
nomObjet3
objet2
objet3
Ici, l'objet1 est associé au nom : "/nomObjet1" l'objet2 est associé au nom : "/nomRepertoire1/nomObjet2" l'objet3 est associé au nom : "/nomRepertoire1/nomObjet3"
5
Objet Serveur
Remote Method InvocationCréer un serveur
Le but de l'intéropérabilité est de pouvoir exécuter les méthodes d'un objet distant.
Un client n'est pas intéressé par l'implémentation propre des méthodes du serveur, c'est le coeur de la notion de services.
Un serveur peut vouloir cacher son implémentation des services qu'il publie, pour des raisons de sécurité.
Un serveur n'est jamais téléchargé sur le poste client.
Un serveur est décrit par une interface, c'est à travers cette interface que ses méthodes sont accessibles aux clients.
6
JVM BJVM AObjet Client Interface du
serveur
Remote Method InvocationCréer une interface pour un serveur
Le package java.rmi etles sous packages contiennent l'API RMI.
Les interfaces décrivant les serveurs RMI doivent étendre java.rmi.Remote.Cette interface est un marqueur.
Seules les méthodes décrites dans l'interface d'un serveur RMI seront accessibles à distance.
Les interfaces des serveurs RMI doivent dériver de java.rmi.Remote,cette interface est un marqueur : elle ne contient ni méthode ni constante.
Chaque méthode de l'interface déclare une RemoteException dans sa clause throws
Toutes les méthodes des interfaces de serveurs doivent déclarer une RemoteException dans leur clause Throws.
7
Remote Method InvocationContraintes sur les méthodes distantes
Les arguments et types de retour des méthodes publiées en RMI sont soumis à des contraintes , ils peuvent être :
des types primitifs (ie int, long, boolean...)des objets distants (ie UnicastRemoteObject et classes filles)des objets sérialisables
et c'est tout !
Les objets sérialisables sont ceux qui implémentent l'interface marqueur java.io.Serializable .Ces objets sont marqués comme étant capables de se convertir en un flux d'octets auto-decrits.
A peu près toutes les classes de java sont sérialisables, même les classes de swing !Seul un nombre restreint de classes ne sont pas sérialisables, il faut alors trouver des moyens détournés pour les transmettre sur le réseau (socket, etc..)
En RMI, tous les arguments sont transmis par copie, cela signifie qu'un objet n'est pas modifié localement au retour d'un appel de méthode distant
lorsqu'il est passé en argument de cette méthode.
8
Remote Method InvocationCréer un serveur qui implémente l'interface
Le package java.rmi.server contient les classes utilisées par les serveurs RMI.
Chaque méthode publiée (dont le constructeur) d'un serveur RMI doit déclarer une RemoteException dans sa clause throws.
Chaque serveur RMI doit implémenter son interface.
Les serveurs RMI doivent dériver de java.rmi.server.UnicastRemoteObject pour hériter du comportement de serveur RMI.
Les serveurs héritent de UnicastRemoteObject et implémentent leur interface.Le constructeur des serveurs RMI doit déclarer une RemoteException
dans sa clause throws, tout comme chacune de ses méthodes.
9
Remote Method InvocationConstructeur par défaut des serveurs
Le constructeur des serveurs RMI doit déclarer une RemoteException dans sa clause throws car la classe UnicastRemoteObject en déclare une et
l’héritage nous force à redéfinir un constructeur pour traiter l’exception.
Java.rmi.server.UnicastRemoteObject
+ public UnicastRemoteObject() throws RemoteException
Server0Impl
+ public Server0Impl(){ super();}
Server0Impl
+ public Server0Impl()throws RemoteException{ super(); //optionel}
Server0Impl
+ public Server0Impl() throws RemoteException
Server0ImplPas de raitement de l’exception avec le constructeur implicite
Nous devons définir un construceur qui traite l’exception
Server0Impl
Server0Impl
+ public Server0Impl() { try { super(); } catch(Exception ex){…}}
10
Remote Method InvocationDéclarer un serveur RMI dans la RMIregistry
Les serveurs RMI doivent être déclarés à la RMIregistry afin de rendre publics leurs services (aux clients RMI). Pour cela, on utilise la méthode
statique rebind de la classe java.rmi.Naming .
l'objet serveur est enregistré dans la registry.
On utilise la méthode rebind ou bind pour associer un objet distant à un nom dans la structure de nom de la registry.
11
Remote Method Invocation
Naming.Rebind(“rmi://localhost/ServeurDeZero”, obj); <protocole>://<nom d'hôte>:<port>/<chemin de l'objet>
<protocole> : le protocole «rmi» est indiqué optionnellemnt
<nom d'hôte> : représente le nom réseau de l'hôte hébergeant la registry du RMI. En pratique l’hôte est toujours locahost car un serveur RMI ne peut pas faire de rebind sur une registry distante pour des raisons de sécurité.
<port> : représente le port de la registry, défaut à 1099.
<chemin de l'objet> : représente le nom de l'objet dans la structure de noms hiérarchisée de la registry.
Les urls de la registry sont toutes basées sur le même schéma.Reggie est, elle-même, un objet distribué RMI,
dont les méthodes sont accessibles à des objets distants....
12
Les urls de reggie
Remote Method InvocationLe client
La méthode lookup retourne un java.lang.Object qui doit donc être converti en "l'interface du serveur".(!ET PAS EN SERVEUR!)(cf acétates 16)
On utilise la méthode statique lookup de la classe java.rmi.Naming pour obtenir une instance de serveur RMI. Ensuite, les appels distants de
méthodes sont aussi simples que les appels locaux.
13
Appel distant de méthode
14Remote Method InvocationLes Stubs (talons) et les Skeletons (squelettes)
JVM BJVM AObjet Client Objet Serveur
Le modèle d’application distribuéehérité de CORBA
Stub
Les clients n'appellent pas directement les méthodes du serveur distant, ils passent par une classe de proxy (prestataire)
qui s'occupe de l'aspect réseau de l'appel (timeout, sérialisation, socket,etc..).
14
Skel
Appel local
Appel distant
Appel localréseau
ordi
Remote Method InvocationModèle d’application distribuée de java2
JVM BJVM AObjet Client Objet Serveur
3-Le client appelle des méthodes du serveur par l'intermédiaire d'un proxy
: le stub du serveur.
Stub
Dans la plate-forme java2, il n’y a plus de Skeletons. Le Stub est le seul intervenant entre le client et le Serveur.
15
Remote Method InvocationLes Stubs
Classe Stub Classe Serveur
Interface Serveur
La classe de Stub implémente l’interface du Serveur tout comme la classe du Serveur elle-même.
C’est le Stub et NON le serveur qui est renvoyé par reggie.
16
Renvoyé par la registry
Remote Method InvocationCompilation
Les stubs sont des classes java générées par le compilateur RMI : rmic.rmic génère un stub pour chaque classe désirant exporter ses méthodes
(UnicastRemoteObject)
L'option 1.2 est requise car ....
Réglez le classpath comme pour javac
Le nom complet de la classe à compiler avec rmic.
Le stub généré par rmic.
17
Génération des stubs
Il faut d’abord compiler toutes les classes avec javac
Remote Method InvocationCompilation
Exécution windows :
exemple> compileAll
exemple> rmiServer
Exécution linux :
exemple> ./compileAll.sh
exemple> ./rmicServer.sh
18
Remote Method InvocationExécution (1/3)
On peut exécuter localement toutes les classes d’une application RMI.Ce mode de déploiement est trop simple et ne reflète pas la réalité.
Côté serveur (tout est sur une seule ligne )
java -cp <classpath> <nom de la classe du serveur>
RMI registry : "registry &" ou "start rmiregistry“ (sous windows)
19
Côté client
java cp <classpath> <nom de la classe du serveur>
Remote Method InvocationExécution (1/3)
Exécution windows :
exemple> startreggie
exemple> executeServer-1
exemple> executeClient-1
Pour tuer reggie :
Fermer sa fenêtre
Exécution linux :
exemple> ./startreggie.sh
exemple> ./executeServer-1.sh
exemple> ./executeClient-1.sh
Pour tuer reggie, :
Killall –9 rmiregistry
20
Remote Method InvocationCritiques de l’exécution (1/3)
*Le mode de déploiement proposé précédemment est trop simple.
*Il ne rend pas compte de l’aspect « distribué » de l’application car le client et le serveur sont au même endroit.
*De plus, le Stub du serveur doit être déployé avec le serveur. Ce qui est trop statique…et peut être évité.
21
Remote Method InvocationTéléchargement automatique des stubs
StubJVM BObjet Serveur
RMI registry
bind
codebase
StubStub
Stub
StubStub
StubStub
StubStub
StubStub
StubStub
Stub
Lorsqu’un client veut utiliser un serveur mais qu’il ne possède pas le Stub du serveur, le stub peut être télécharger automatiquement
à partir du codebase donné par le serveur.
Côté serveur
Lookup
JVM BObjet Client
RMI registryStub
Côté client
22
Remote Method InvocationUn client sécuritaire
Lorsqu’une JVM désire télécharger du code depuis une autre JVM,elle doit mettre en place une politique de sécurité.
La politique de sécurité sera indiquée à la JVM avec l’option –Djava.security.policy
grant { permission java.net.SocketPermission "*:1024-65535", "connect,accept"; }
Mise en place d’un gestionnaire de sécurité
Définition de la politique de sécurité dans un fichier texte
Un gestionnaire de sécurité applique une politique de sécurité.
23
public class ClientSecure
Remote Method InvocationExécution (2/3)
Ce mode de déploiement va simuler deux machines différentes sur un même ordinateur. Chaque répertoire pourrait se trouver sur un ordinateur différent.
Côté serveur
/tmp/A/package cours12.client
package cours12.server
24
Côté client
/tmp/B/package cours12.client
security.policy.file
Remote Method InvocationExécution (2/3)
On peut exécuter localement toutes les classes d’une application RMI.En placant les fichiers dans des répertoires différents, on simule deux ordinateurs.
Côté serveur (tout est sur une seule ligne )
java -Djava.rmi.server.codebase=<URL du stub = file:/tmp/A/ > -cp <classpath> <nom de la classe du serveur>
RMI registry : "registry &" ou "start rmiregistry"
25
Côté client (tout est sur une seule ligne )
java -Djava.security.policy=<chemin du fichier policy> cp <classpath> <nom de la classe du serveur>
Remote Method InvocationExécution (2/3)
Exécution windows :
exemple> start
exemple>deploy-2
A>startReggie
A> executeServer-2
A>cd ..\B
B> executeClient-2
Pour tuer reggie :
Fermer sa fenêtre
Pour supprimer les fichiers de déploiement:
exemple>deleteDeploy
Exécution linux :
exemple> ./deploy-2.sh
exemple> cd tmp/A
A> ./startreggie.sh
A> ./executeServer-2.sh
A> cd ../B
B> ./executeClient-2.sh
Pour tuer reggie, :
Killall –9 rmiregistry
Pour supprimer les fichiers de déploiement:
exemple>./deleteDeploy.sh
26
Remote Method InvocationCritiques de l’exécution (2/3)
*L’application n’est pas encore totalement distribuée, le client et le serveur doivent être sur la même machine.
*Le Stub du serveur est maintenant téléchargé dynamiquement par le client lorsqu’il se connecte à reggie. Ce qui impose au client l’utilisation d’une politique de sécurité : security.policy.file
27
Remote Method InvocationExécution (3/3)
Ce mode de déploiement va simuler deux machines différentes sur un même ordinateur. Chaque répertoire pourrait se trouver sur un ordinateur différent.
Côté serveur
/tmp/A/package cours12.client
package cours12.server+
reggie
28
Côté client
/tmp/B/package cours12.client
security.policy.file
Serveur web
Code téléchargeable -Soit une arborescence de classes -Soit un fichier jar
Remote Method InvocationExécution (3/3)
Côté serveur (tout est sur une seule ligne )
java -Djava.rmi.server.codebase=<URL du stub =URL du serveur web >
-cp <classpath> <nom de la classe du serveur>
RMI registry : "registry &" ou "start rmiregistry"
29
Côté client (tout est sur une seule ligne )java -Djava.security.policy=<chemin du fichier policy> cp <classpath> <nom de la classe du serveur>
Serveur Web : Contient le fichier http://s-java.ift.ulaval.ca/~steff/rmi-deploy.jar jar cvf rmi-deploy.jar -C <classpath> cours12/server/Server0Impl_Stub.class -C <classpath> cours12/client/Server0.class
Remote Method InvocationExécution (3/3)
Exécution windows :
exemple> start
exemple> jarAll
exemple>deploy-3
A>startReggie
A> executeServer-3
A>cd ..\B
B> executeClient-3
Pour tuer reggie :
Fermer sa fenêtre
Pour supprimer les fichiers de déploiement:
exemple>deleteDeploy
Exécution linux :
exemple> ./deploy-3.sh
exemple> cd tmp/A
A> ./startreggie.sh
A> ./executeServer-3.sh
A> cd ../B
B> ./executeClient-3.sh
Pour tuer reggie, :
Killall –9 rmiregistry
Pour supprimer les fichiers de déploiement:
exemple>./deleteDeploy.sh
30
Remote Method InvocationExécution distribuée
*Modifier la classe ClientSecure afin que son URL de lookup pointe vers une autre machine qui héberge une registry et un serveur0.
*Ensutie, recompilez le programme et exécuter le client de nouveau.
*Notre application est désormais totalement distribuée.
31
Remote Method InvocationUn mot sur l'organisation des fichiers et la sécurité
D'une manière générale , on essaye de faire en sorte que le client ne connaisse pas directement les classes du serveur et que le serveur ne connaisse pas les classes du clients.Il est très judicieux de placer les interfaces utilisées par le client et le serveur dans un package séparé de ceux du client et du serveur.
L'un des avantages de RMI sur Corba réside dans la possibilité, pour un client, de télécharger les stubs des serveurs avant de les utiliser.De la même manière, un "serveur" peut télécharger certaines classes depuis un client lorsque ces classes sont inconnues de la jvm du serveur.
Cette technologie, transparente pour l'utilisateur et le programmeur, imposent des contraintes très fortes au niveau de la sécurité, puisqu'il s'agit de donner le droit à du code ”étranger" de s'exécuter sur un hôte qui ne les connait pas.
Le modèle de sécurité de la jdk1.2 impose l'utilisation de fichiers "policy" définissant les permissions données à du code ”étranger" , en voici un exemple :grant { permission java.net.SocketPermission "*:1024-65535", "connect,accept"; permission java.io.FilePermission "c:\\home\\ann\\publihtml\\classes\\-", "read"; permission java.io.FilePermission "c:\\home\\jones\\publihtml\\classes\\-", "read"; };
32
Les fichiers de sécurité peuvent être générés par policytool
Un excellent tutorial de sun :http://java.sun.com/docs/books/tutorial/rmi/
Un deuxième :http://java.sun.com/j2se/1.4/docs/guide/rmi/getstart.doc.html
La page de RMI :http://java.sun.com/products/jdk/rmi/http://java.sun.com/j2se/1.4/docs/guide/rmi/index.html
Téléchargement dynamique de code :http://java.sun.com/j2se/1.4/docs/guide/rmi/codebase.html
Le formats des fichiers de sécurité de la jdk :http://java.sun.com/j2se/1.4/docs/guide/security/PolicyFiles.htmlhttp://java.sun.com/j2se/1.4/docs/guide/security/permissions.html
Remote Method Invocationréférences
Les tutoriaux et leur FAQs sont une aide précieuse pour les développeurs d'application RMI.
33
Remote Method InvocationL’Activation des serveurs RMI
Les objets serveurs RMI doivent être maintenus en vie aussi longtemps qu’un client peut les utiliser.
Mais cette technique a des inconvénients : - Un serveur qui n’est utilisé que rarement doit rester en vie tout le temps et donc consommera des ressouces inutilement.- Le coût de maintenir de nombreux objets serveurs en vie peut être prohibitif en terme de ressources et dégrader considérablement les performances du serveur.
Il serait bon de pouvoir activer les objets uniquement lorsqu’ils sont utilisés.Lorsqu’un objet est inutilisé, il devrait pouvoir se désactiver et ne plus consommer de ressouces
C’est précisément ce que permet l’activation.
34
Remote Method InvocationL’Activation des serveurs RMI
35
Les acteurs de l’activation :
-rmid : le démon d’activation, est un logiciel qui est responsable d’activer les objets lorsqu’une demande d’invocation de méthode leur est destiné.
-Les groupes d’activations : sont les jvms qui vont hébergés les objets activés.
-L’application de démarrage : enregistre l’objet dans le framework d’activation.
-L’objet activable : est le serveur RMI que l’on désire activer au besoin.
-( Les descripteurs d’activation : sont des classes qui contiennent toute l’information nécessaire à l’activation d’un objet.)
Le framework d’activation fait intervenir plusieurs entités pour assurer l’activation des objets. Ces entités ont des rôles très distincts.
Remote Method InvocationL’Activation des serveurs RMI
Descripteur de groupe d’activation
Descripteur d’ objet activable
rmid
Groupe d’activation
Groupe d’activation
Objet activé
Objet activé
Enr eg ist re m
e ntA
ct iva ti on
36
37Remote Method InvocationL’Activation des serveurs RMI
Transformer un serveur RMI en objet activable est enfantin.Il suffit de lui appliquer ces deux transformations mineures.
Il faut hériter de Activatable pour
Rendre activable notre objet.
Cette transformation nous oblige à définir
un constructeur à deux paramètres qui
appelera un des constructeurs de la
classe mère.
38Remote Method Invocation
Les applications de démarrage suivent toujours le même schéma.
Installer un gestionnaire de sécurité
Créer un desc. de groupe
Enregistrer le groupe
Créer un desc. d’objet
Enregistrer le serveur
On récupère un stub que l’on peut placer dans reggie.
39Remote Method InvocationExécution de l’application de démarrage
Côté serveur (tout est sur une seule ligne )
java -Djava.rmi.server.codebase=<URL du stub =URL du serveur web > -Djava.security.policy=<fichier policy> -cp <classpath> <nom de la classe du serveur>
RMI registry : "registry &" ou "start rmiregistry"
Côté client (tout est sur une seule ligne )
java -Djava.security.policy=<fichier policy> cp <classpath> <nom de la classe du serveur>
Serveur Web : Contient le fichier http://s-java.ift.ulaval.ca/~steff/activ-deploy.jar
RMI activation daemon : “rmid –J-Djava.security.policy=<fichier policy>l &" ou "start rmid –J-Djava.security.policy=<fichier policy>"
Remote Method InvocationActivation-Exécution
Exécution windows :
exemple> start
exemple> rmicServer-2
exemple> jarAll-2
exemple>deploy-4
A>startRmid
A>startReggie
A> executeServer-4
A>cd ..\B
B> executeClient-4
Exécution linux :
exemple> ./rmicServer-2.sh
exemple> ./jarAll-2.sh
exemple> ./deploy-4.sh
exemple> cd tmp/A
A> ./startreggie.sh
A> ./startrmid.sh
A> ./executeServer-4.sh
A> cd ../B
B> ./executeClient-4.sh
40