ASP.NET Logo Back to WebMatrix Home

 

Exemples de programmes Java RMI

 

Les fichiers suivants contiennent plusieurs exemples de programmes Java RMI. L'objectif est de mesurer dans différentes situation le coût d'un appel entre un client et un serveur.

Le Client et le Serveur sont dans 2 JVM distinctes sur la même machine simplement pour des facilité de mise en oeuvre.

Scénario 1 : le client effectue des appels vides

Scénario 2 : le client passe en paramètre un objet local qu'il a créé. Le serveur demande à l'objet reçu d'afficher son état.

Remarque : comme il s'agit d'un objet local, celui doit être sérialisable et une copie de cet objet est transmis au serveur. Pour que cette copie puisse s'effectuer, le client et le serveur doivent connaître la classe implémentant l'objet local (ObjetLocal). Le serveur demande l'affichage de l'état de l'objet reçu en paramètre et la fenêtre dans laquelle l'affichage s'effectue atteste de la JVM qui contient l'objet.

Scénario 3 : le client passe en paramètre un objet distant qu'il a créé. Le serveur demande à l'objet reçu d' afficher son état.

Remarque : comme il s'agit d'un objet distant, celui n'a pas à être sérialisable mais il doit étendre UnicastRemoteObject. Le client et le serveur partagent cet objet. Seul le client connaît la classe qui implémente l'objet distant (ObjetDistant) puisque c'est lui qui cré cet objet. Cet objet distant n'est pas enregistré dans le service de nom, sa référence est transmise en paramètre par le client au le serveur. Le serveur ne connaît et manipule que l'interface du service (ObjetDistant_itf). Le serveur demande l'affichage de l'état de l'objet reçu en paramètre et la fenêtre dans laquelle l'affichage s'effectue atteste de la JVM qui contient l'objet.

Scénario 4 : le client passe en paramètre un objet distant précédement créé qui existe dans une troisième JVM. Le serveur demande à l'objet reçu d' afficher son état.

Remarque : comme il s'agit d'un objet distant, celui n'a pas à être sérialisable mais il doit étendre UnicastRemoteObject. Le client et le serveur partagent cet objet. Le client et le serveur ne connaissent et manipulent que l'interface du service (ObjetDistant_itf). LLe serveur demande l'affichage de l'état de l'objet reçu en paramètre et la fenêtre dans laquelle l'affichage s'effectue atteste de la JVM qui contient l'objet. Pour ce troisième objet le stub n'est pas sur le site du client, ni sur celui du serveur, ils vont le chercher sur le serveur web de l'ESSI dans lequel le stub a été précédemment déposé.

Voici les différentes classes

et un fichier de propriété

Ces classes seront réparties dans les trois répertoires suivant :

Pour installer l'ensemble

Pour compiler l'ensemble

  • compilation du client :
    javac Client.java
    Compile ce qui est nécessaire au client : Client.java, Serveur_itf.java, ObjetLocal.Java, ObjetDistant.Java, ObjetDistant_itf.java et ObjetStubInconnu_itf.java
  • compilation du serveur :
    javac Serveur.java
    Compile ce qui est nécessaire au serveur : Serveur.java, Serveur_itf.java, ObjetLocal.Java, ObjetDistant_itf.java et ObjetStubInconnu_itf.java
    rmic Serveur
    Génère les stub/skeleton du Serveur
  • génération des stub/skeleton de l'objet distant :
    rmic ObjetDistant
    Génère les stub/skeleton de l'ObjetDistant
  • compilation de l'objet Distant présent dans la troisième JVM :
    javac ObjetStubInconnu
    Compile ce qui est nécessaire à l'ObjetStubInconnu : ObjetStubInconnu.Java et ObjetStubInconnu_itf.java
    rmic ObjetStubInconnu
    Génère les stub/skeleton de l'ObjetDistant

Pour exécuter l'ensemble

  • ajouter un fichier policy.all dans les répertoires client, serveur et osi
    grant {
    // permettre les connexions socket sur les ports 2000 à 2100 utilisés
    permission java.net.SocketPermission "*:2000-2100", "accept, connect";
    // permettre les connexions socket sur le port 80 utilisé par http
     permission java.net.SocketPermission "*:80", "connect";
    // permettre tous les appels de méthodes
    permission java.security.AllPermission "", "";
    };
  • ATTENTION :
    Quelques mouvements de code sont nécessaires :
    • déplacer Serveur_stub.class du répertoire du serveur vers celui du client
    • déplacer ObjetDistant_stub.class du répertoire du client vers celui du serveur
    • ces déplacements sont pris en charge par les scripts d'installation
  • depuis repertoire serveur :
    java -Djava.security.policy=policy.all Serveur
    crée le service de désignation, crée l'objet serveur et l'enregistre dans le service de désignation
  • depuis le répertoire osi :
    java -Djava.security.policy=policy.all  -Djava.rmi.server.codebase=http://www.essi.fr/~riveill/myclasses/
    ObjetStubInconnu
    crée l'objet distant dont les stub seront chargés par http
    Vous pouvez changer l'adresse si vous voulez charger vos propres stub.
  • depuis le répertoire client : 
    java -Djava.security.policy=policy.all Client
    crée l'objet client, joue les scénarios 1, 2, 3 et 4.
  • ATTENTION :
    L'ensemble du code a été écrit pour s'exécuter sur la même machine qui s'appelle 'localhost'. Pour utiliser les mêmes programmes sur différentes machines vous pouvez soit mettre le numéro IP, soit mettre le nom de la machine.
Remarque : depuis la version 1.2, les skeleton ne sont plus nécessaires (utilisation du package java.reflect). On peut activer rmic avec une option permettant de ne pas générer les fichiers skeleton.

A faire : travailler le pb lié au passage du stub entre client et serveur dans le cadre de l'objet distant afin d'éviter la recopie (actuellement copie du fichier), permettre l'activation