Rapport

Clément AUDAM
Héloïse ROMET
2A
IL
Rapport intermédiaire
PIDR
Table des matières
Introduction ............................................................................................................................................. 2
Fonctionnement de Java RMI.................................................................................................................. 3
Sources de java rmic : ............................................................................................................................. 6
Simgrid : .................................................................................................................................................. 8
Introduction
Dans le cadre du projet de recherche et développement de deuxième année de
TELECOM Nancy nous avons choisi de travailler avec l'équipe Algorille du Loria et plus
particulièrement Martin Quinson sur le projet de modifier la bibliothèque java RMI (Remote
Method Invocation) pour qu'elle puisse interagir avec l'outil de recherche Simgrid.
Étant tous deux en spécialisation Ingénierie Logicielle, ce projet nous permet de mieux
appréhender les applications réparties.
Fonctionnement de Java RMI
Java RMI est un outil pour faire un dialogue client-serveur. Il fonctionne de la façon suivante : Le
client peut exécuter une méthode d'un objet du serveur. Pour faire cela un stub et un skeleton sont
créés. Le stub se trouvera du coté du client et le skeleton sera du coté serveur. Tous deux dérivent de la
même classe java. C'est grâce au stub que les appels seront lancés. Ils seront réceptionnés par le
skeleton.
Pour faire fonctionner Java Rmi, nous sommes d'abord partis de tutoriels sur le net. Le démarrage a été
plutôt délicat. Le premier problème qui s'est présenté a été celui de la sécurité. Quelque soit la forme
de notre fichier sécurité, linux ne voulait rien savoir et n'autorisait pas RMI à faire son travail. Il
s'agissait in fait d'un problème d'option au lancement de la compilation.
Un premier exemple, basique :
Il nous a également fallu faire face à un problème de version de rmic, qui ne s'est pas présenté sous
cette forme. En effet le lancement de rmic se faisait par défaut avec l'option -v1.2 et ne générait que le
stub. Il fallait en fait mettre l'option -vcompat, qui correspond à une version de compatibilité, qui
permet de générer le stub et le skeleton. À partir de là, les test simples proposés par les différents
tutoriels et adaptés fonctionnaient. Il a seulement fallu penser au fait que les sources de TP utilisaient
un port en particulier pour le préciser dans le lancement de rmiregistry.
Première partie du TP :
2ème partie du TP :
Dernière partie du TP :
Pour faire fonctionner java RMI sur deux pc, il a simplement fallu installer la même version de linux.
Voici le code de compilation auquel nous sommes arrivés :
Sources de java rmic :
Après avoir réussi à trouver les sources de java rmic, nous nous somme attelé a la tache de décortiquer
tout ce code java pour trouver les méthodes de création de stub et de skeleton.
Nous allons a présent analyser la méthode de création du stub à l'aide d'un diagramme de séquence.
On part donc à l'intérieur de la méthode WriteStub pour comprendre ce qu'elle fait :
D'un point de vu global, cette méthode réécrit les sources passées par l'utilisateur.
Tout d'abord elle réécrit le nom et toute l'entête
l'entête du futur stub, elle ajoute ensuite les variables et objets
locaux puis écrit un constructeur classique.
C'est le writeStubMethod qui semble être le plus important. Il réécrit toutes les méthodes du code
source mais en les modifiants pour faire des « invokes » sur l'objet qui sera sur le serveur.
C'est donc vers les writeStubMethod qu'il faut creuser pour comprendre comment modifier java rmic.
Simgrid :
Simgrid est un outil qui permet de modéliser tout types de réseaux pour applications distribué. Le
réseaux est décrit dans un fichier xml. Par exemple :
(documents originaires de http://simgrid.gforge.inria.fr )
Voici les classes java permettant de créer le maître et les ouvriers.
L'étape suivante est donc d'écrire des méthodes du même types que celles de java rmic pour que les
invokes passent à travers Simgrid et de les intégrés à la copie du fichier qui sera mit
m sur le serveur.
En partant d'une classe qui faisait une copie profonde (nous avions d'abord pensé à sérialisé l'objet
mais cela était lourd et n'apportait rien de plus), nous avons modifié le code pour ajouter à cette copie
profonde le code qui permet à Simgrid d'intercepter les instructions RMI et de gérer la simulation.
Au lieu de créer un stub et un skeleton, nous créons un seul fichier puisque les autres ordinateur sont
modélisés par Simgrid et que tout se passe sur une seule machine. Ce fichier unique
unique est nommé
SGRMI.
Au lieu d'avoir séparément un naming.rebind et un naming.lookup, c'est donc ce fichier SGRMI qui
gère le transfert de fichier par des set et des get.
De plus le client et le serveur sont lancés par le main et non lancés séparément.
séparément