4.7 RMI Remote Method Invocation

Transcription

1 4.7 RMI Remote Method Invocation Appels de méthodes à distance et appels de procédures à distance En quoi un appel de méthode à distance dans un langage orienté objet, comme java, diffère-t-il d'un appel de procédure à distance, dans un langage procédural, comme le C? Procédures, méthodes et objets Les procédures constituent, dans un programme C, un ensemble non structuré: de n'importe où dans le programme, on peut appeler n'importe quelle procédure. Dans un programme, une procédure est uniquement et entièrement identifiée par son nom. En termes d'appels de procédures à distance cela se traduit par une identification des procédures par un numéro de programme (plus un numéro de version) et un numéro de procédure qui seront traduits en numéro de port du serveur par le portmapper (parfois appelé rpcbind), qui n'est autre qu'un service d'annuaire local à la machine du serveur. A part d'éventuelles variables statiques, des fichiers, des stuctures allouées (par malloc() )ou, plus généralement, d'autres ressources conservées après la fin de l'exécution d'une fonction C, situées sur un serveur d'appels de procédures à distance, la procédure sera appliquée à ses paramètres dont les valeurs sont fournies par le client. Par contre une méthode est, le plus souvent, associée à une classe et sera appliquée à un objet de la classe. Cet objet constitue un paramètre implicite de la méthode. Une méthode est identifiée par la classe à laquelle elle appartient, plus par son nom plus par les types de ses paramètres explicites. A la différence des procédures à distance qui ne sont que du code qui peut être utilisé tant que le serveur accepte des requêtes, les objets distants incluent des données et ont une certaine durée de vie. Le serveur sera un serveur d'objets distants et non plus un serveur de procédures. Les objets distants seront implantés sur le serveur et créés, comme n'importe quel objet, grâce à une méthode particulière, le constructeur. Cette création a souvent lieu lors du démarrage du serveur, mais le serveur peut décider quand il l'entend de créer des objets (locaux ou distants; ces derniers sont des objets dont l'interface est une extension de l'interface java.rmi.remote). Comme les RPC, RMI utilise un service d'annuaire local à la machine, comparable au portmapper des RPC. Il s'appelle rmiregistry (port 1099). [si on veut utiliser un autre numéro de port, il suffit de le donner en argument rmiregistry 10099] [si on veut utiliser un autre numéro de port, il suffit de le donner en argument rmiregistry 10099] conserve des associations entre des noms et des références d'objets, ne s'occupe que des objets situés sur le même ordinateur que lui, peut s'occuper de plusieurs clients simultanément (il est "multithreaded"), gère un espace de noms plat (pas de hiérarchie de noms); lorsqu'un serveur enregistre une classe au rmiregistry, celui-ci charge la classe (...impl) et toutes les classes associées (...stub, classes utilisées dans paramètres et résultats): il doit savoir où les trouver et avoir le droit de les charger. Un serveur RMI annonce au rmiregistry les objets distants auquels il offre publiquement l'accès. Le rmiregistry ne va pas conserver indéfiniment un objet disyant dans son annuaire. Si aucun client n'interroge le registry et qu'aucun serveur ne renouvelle l'inscription, le rmiregistry "oubliera l'objet" après un certain temps. Pour éviter cela, il suffit que le serveur réinscrive régulièrement l'objet. Si le client interroge le rmiregistry après que ce dernier ait «oublié» l'objet, il reçoit une Remote exception java.rmi.nosuchobjectexception: no such object in table Si le client interroge le rmiregistry après que ce dernier ait «oublié» l'objet, il reçoit une 1 sur 22 01/06/ :24

2 Remote exception java.rmi.nosuchobjectexception: no such object in table Le serveur RMI ne doit pas forcément publier ainsi tous ses objets distants et peut en garder pour son usage propre ou en offrir l'usage à certains clients seulement en leur passant, comme résultat d'une méthode, une référence à l'objet distant. Cette référence sera en fait une référence vers une souche cliente (aussi appelée "proxy" [proxy: composant logiciel proche, représentant une entité éloignée pour diverses raisons, par exemple, comme ici pour donner l'illusion que l'entité éloignée est locale, mais aussi parfois pour des raisons de sécurité, comme dans certains firewalls. [proxy: composant logiciel proche, représentant une entité éloignée pour diverses raisons, par exemple, comme ici pour donner l'illusion que l'entité éloignée est locale, mais aussi parfois pour des raisons de sécurité, comme dans certains firewalls. ) qui sera automatiquement créé cans le processus client. Notons que si un objet local est passé en paramètre ou en résultat d'un appel de méthode à distance, il est transmis par copie (et avec lui, tous les objets locaux qu'il référence, ce qui peut représenter pas mal de volume et de travail); seuls les objets distants sont transmis par référence à un proxy situé sur l'autre machine. Comme les objets locaux n'ont pas de proxy et ne peuvent donc être utilisés que localement, il faut bien les passer par copie! Notons que si un objet local est passé en paramètre ou en résultat d'un appel de méthode à distance, il est transmis par copie (et avec lui, tous les objets locaux qu'il référence, ce qui peut représenter pas mal de volume et de travail); seuls les objets distants sont transmis par référence à un proxy situé sur l'autre machine. Comme les objets locaux n'ont pas de proxy et ne peuvent donc être utilisés que localement, il faut bien les passer par copie! Cette référence inclut un URL qui permet de retrouver la classe du proxy. ou la classe de l'objet lui-même si c'est un objet local. RMI ne passe pas de classes (pas de code) mais seulement des données sérialisées. Pour trouver le code, il passe un URL, qui peut indiquer un fichier accessible sur la machine destination ou un serveur ftp ou http qui peut fournir la classe (en particulier le code des méthodes). Dans ces deux derniers cas, il y a des aspects de sécurité à considérer (voir plus loin). ou la classe de l'objet lui-même si c'est un objet local. RMI ne passe pas de classes (pas de code) mais seulement des données sérialisées. Pour trouver le code, il passe un URL, qui peut indiquer un fichier accessible sur la machine destination ou un serveur ftp ou http qui peut fournir la classe (en particulier le code des méthodes). Dans ces deux derniers cas, il y a des aspects de sécurité à considérer (voir plus loin). Un objet distant du serveur continuera à exister tant qu'il est utilisé soit localement sur le serveur, soit à distance. Tant qu'un objet distant est enregistré au rmiregistry, il est considéré comme utilisé. Il n'est cependant pas évident, pour le serveur de savoir si un utilisateur distant d'un objet distant non enregistré au rmiregistry l'utilisera encore. Pour un objet local, il suffit de compter les références, mais quand un objet distant n'est plus effectivement référencé c'est soit par ce que le client a annoncé qu'il le déréférençait soit parce que le client ou le réseau est tombé en panne. Pour éviter de conserver des objets auxquels plus personne ne s'intéresse, les références distantes des objets créés sur le serveur mais pas enregistrés au rmiregistry ne sont pas données, mais prêtées pour une durée limitée (durée de bail ou "lease time") aux clients distants. La durée de bail vaut, par défaut, 10 minutes. Le bail est automatiquement renouvelé à chaque appel de l' objet. Si aucun objet du serveur ne référence plus l'objet créé et si le client n'a pas utilisé l'objet depuis un temps supérieur au bail, l'objet est considéré comme déréférencé et pourra être détruit par le ramassemiettes. Si c'est le réseau qui était temporairement en panne, le client peut avoir gardé une référence vers un objet qui n'existe plus, suite à l'action du ramasse-miettes. 2 sur 22 01/06/ :24

3 Si c'est le réseau qui était temporairement en panne, le client peut avoir gardé une référence vers un objet qui n'existe plus, suite à l'action du ramasse-miettes. Le rmiregistry est lui-même un serveur RMI: c'est le mécanisme du ramasse-miette qui lui fait "oublier" les enregistrements des objets inutilisés. La sémantique d'un appel RMI est "au plus une fois" La sémantique sera exactement une fois si la méthode se termine normalement; en cas d'exception, la méthode peut avoir été exécutée entièrement, en partie ou pas du tout. La sémantique sera exactement une fois si la méthode se termine normalement; en cas d'exception, la méthode peut avoir été exécutée entièrement, en partie ou pas du tout. Structure des souches Tout comme dans RPC où la souche serveur et la souche cliente étaient générées automatiquement par RPCGEN, dans RMI, les classes nécessaires, tant sur le client que sur le serveur, à la mise en oeuvre des appels de méthodes à distances sont automatiquement produites par RMIC. Du côté du client, la souche cliente, aussi appélée proxy, n'est plus une procédure locale chargée de passer les paramètres à la procédure distante puis de recevoir les résultats, mais un objet de même interface que l'objet distant et chargé, lui-aussi de passer les requètes d'invocation de méthodes à l'objet distant puis de récupérer les résultats. Dans le cas de JAVA RMI, l'interface (par exemple machin) est une extension de l'interface java.rmi.remote. Côté client, cette interface est implémentée par un objet qui constitue la souche cliente et dont la classe (qui s'appelera machinimpl_stub) est une extension de la classe java.rmi.server.remotestub. Cette classe souche cliente (machinimpl_stub) est automatiquement produite par RMIC. Coté serveur, l'interface sera implémentée par une classe, fournie par le programmeur (qui s'apellera machinimpl). Cette classe étend généralement la classe java.rmi.server.unicastremoteobject. Cette dernière constitue la boucle infinie d'exécution du serveur. Dans JDK1.1, les méthodes de la classe fournie par le programmeur étaient appelées, dans le serveur, par un objet de classe squelette (machinimpl_skel). Cette classe implémentait l'interface java.rmi.server.skeleton qui était utilisé par la classe java.rmi.server.unicastremoteobject. Ainsi, la boucle infinie démarrée lors de la création de l'objet de classe machinimpl (plus précisément lors de la création de la partie de cette classe héritée de java.rmi.server.unicastremoteobject) appelait les méthodes de l'interface java.rmi.server.skeleton, implémentées par machinimpl_skel, qui elles-mêmes appelaient les méthodes propres de machinimpl! Le rôle du squelette était le même que dans RPC: dispatching et sérialisation. Le rôle du squelette était le même que dans RPC: dispatching et sérialisation. La classe squelette (machinimpl_skel) peut être automatiquement produite par RMIC. L'objet de classe squelette contient tout le code généré automatiquement sur mesures pour l'application, tel que l'appel des méthodes de désérialisation des paramètres (l'équivalent des procédures XDR), etc. Dans JDK1.2, il n'y a plus de souche squelette sur mesures mais du code générique inclus dans java.rmi.server.unicastremoteobject. Ce code générique interroge la machine virtuelle JAVA et lui demande les types des objets distants, des paramètres de leurs méthodes, etc. grâce à une API appelée "reflection". L'API «reflection» permet d'obtenir des informations sur les classes, interfaces et objets situés dans la JVM. Elle est principalement destinée à construire des outils tels que des «debuggers». L'API reflection permet de déterminer la classe d'un objet, déterminer les attributs d'une classe (champs, méthodes, constructeurs, superclasses, modificateurs), créer une instance d'une classe dont le nom n'est connu qu'à l'exécution, utiliser un objet dont la classe et ses caractéristiques ne sont connues qu'à l'exécution: exécuter ses méthodes, lire et écrire ses champs, manipuler un array dont la taile et le type des composants ne sont connus qu'à l'exécution. Pour en savoir plus: 3 sur 22 01/06/ :24

4 L'API «reflection» permet d'obtenir des informations sur les classes, interfaces et objets situés dans la JVM. Elle est principalement destinée à construire des outils tels que des «debuggers». L'API reflection permet de déterminer la classe d'un objet, déterminer les attributs d'une classe (champs, méthodes, constructeurs, superclasses, modificateurs), créer une instance d'une classe dont le nom n'est connu qu'à l'exécution, utiliser un objet dont la classe et ses caractéristiques ne sont connues qu'à l'exécution: exécuter ses méthodes, lire et écrire ses champs, manipuler un array dont la taile et le type des composants ne sont connus qu'à l'exécution. Pour en savoir plus: C'est possible puisque la machine virtuelle du serveur contient les objets distants et connaît donc les caractéristiques de leurs classes. Coté client, on ne peut pas se passer d'une souche sur mesures puisque la machine virtuelle JAVA ne contient pas d'implémentation de l'objet distant et n'a donc pas d'informations sur sa classe. Implémentation des souches Tout comme les souches RPC comprenaient des procédures générées sur mesures par RPCGEN, les souches RMI contiennent des objets sur mesures construits par RMIC. Les souches RPC comprenaient aussi des procédures provenant de bibliothèques RPC. Dans le cas de RMI, ce rôle est joué par des méthodes appartenant LI>à la classe java.rmi.server.remotestub qu'étend la classe souche cliente générée par RMIC et à la classe java.rmi.server.unicastremoteobject (qui elle-même étend la classe java.rmi.server.remoteserver, qui, à son tour, étend java.rmi.server.remoteobject), qu'étend la classe qui implémente l'objet distant sur le serveur, par exemple machinimpl. Toutes ces classes qui fournissent les méthodes utilisées pour la mécanique des appels de méthodes à distance sont appelées parfois Remote reference Layer. Les objets des classes de la couche Remote reference Layer sur le client et sur le serveur dialoguent entre elles au moyen d'un protocole. Ce protocole n'est pas normalisé et peut donc varier d'implémentation à implémentation. L'implémentation originelle de SUN et certaines autres utilisent un protocole baptisé JRMP (Java Remote Method protocol). Toutes les composantes d'une application basée sur RMI doivent donc être construites avec les mêmes outils. A priori, ce n'est pas très contraignant, mais cela pourrait le devenir si on voulait réutiliser un serveur d'objet existant dans un projet différent qui serait, pour l'une ou l'autre raison construite avec un outil différent. Une raison pour utiliser un protocole autre que JRMP est de se connecter (comme le permettent certains environnements de développement) à d'autres serveurs d'objets que des serveurs RMI, p. ex. des serveurs CORBA (CORBA permet d'accéder à des serveurs d'objets indépendemment du langage dans lequel ils sont programmés: JAVA, C++, C, voire FORTRAN ou n'importe quoi!) ou DCOM (le service d'accès distant à des objets de Microsoft), Une autre raison est d'avoir réimplémenté soi-même RMI, comme l'université de Berkeley (NinjaRMI). Certains environnements de développement java permettent aussi l'usage du protocole IIOP (Internet Inter Object Protocol), défini dans le cadre de CORBA. On peut ainsi accoupler clients RMI et serveurs CORBA et vice-versa. Un exemple simple: une calculette élémentaire Une application répartie basée sur RMI inclut plusieurs composantes: la définition de l'interface des classes distantes; l'implémentation des classes distantes; le fichier contenant la souche cliente et, si on utilise JDK1.1, celui contenant le squelette. et, si on utilise JDK1.1, celui contenant le squelette. 4 sur 22 01/06/ :24

5 le serveur qui hébergera les classes distantes; un service d'annuaire, rmiregistry; un client; au cas où toutes les classes ne sont pas disponibles sur toutes les machines impliquées, un serveur de classes (p. ex. ftp ou http) et un gérant de la sécurité ("security manager"). Pour simplifier l'exemple, on exécutera client et serveur dans un même répertoire (soit sur la même machine, soit sur des machines partageant leur système de fichiers: on peut ainsi se passer du serveur de classes et ne pas se préoccuper des aspects de sécurité pour le moment). La CLASSPATH est supposé valoir «.:/usr/java/lib». La CLASSPATH est supposé valoir «.:/usr/java/lib». La réalisation proprement dite de l'application RMI comporte alors 6 étapes: 1. écrire en JAVA et compiler l'interface ds classes distantes, 2. écrire et compiler les classes java qui implémentent l'interface, 3. générer la classe souche sur base des classes d'implémentation, 4. écrire et compiler le serveur, 5. écrire et compiler le client, 6. installer et exécuter l'application RMI (au besoin, lancer'abord le rmiregistry). L'interface de la calculette Contenu du fichier Calculator.java: public interface Calculator extends java.rmi.remote { public long add(long a, long b) throws java.rmi.remoteexception; public long sub(long a, long b) throws java.rmi.remoteexception; public long mul(long a, long b) throws java.rmi.remoteexception; public long div(long a, long b) throws java.rmi.remoteexception; Comme annoncé, l'interface étend l'interface java.rmi.remote Comme des problèmes liés à l'éloignement peuvent survenir, il est obligatoire de se préoccuper des RemoteExceptions. Ce fichier doit être compilé: "javac Calculator.java" L'implémentation de la calculette Contenu du fichier CalculatorImpl.java: public class CalculatorImpl extends java.rmi.server.unicastremoteobject implements Calculator { // Implementations must have an explicit constructor // in order to declare the "RemoteException" exception public CalculatorImpl() throws java.rmi.remoteexception { super(); public long add(long a, long b) throws java.rmi.remoteexception { return a + b; public long sub(long a, long b) throws java.rmi.remoteexception { return a - b; public long mul(long a, long b) throws java.rmi.remoteexception { return a b; public long div(long a, long b) 5 sur 22 01/06/ :24

6 throws java.rmi.remoteexception { return a / b; Comme annoncé, l'implémentation étend UnicastRemoteObject A vrai dire, il n'est pas obligatoire d'étendre UnicastRemoteObject: on peut l'utiliser et appeler explicitement la méthode exportobject. On fera cela, par exemple, dans le client, si on veut faire des RMI en retour (même principe que les RPC en retour), c'est-à-dire permettre au serveur de lancer une requète RMI vers le client. D'autre part, on verra plus loin qu'on peut concevoir des applications RMI plus complexes que celles qui étendent UnicastRemoteObject: multicast ou permettant l'activation d'objets distants par le client. A vrai dire, il n'est pas obligatoire d'étendre UnicastRemoteObject: on peut l'utiliser et appeler explicitement la méthode exportobject. On fera cela, par exemple, dans le client, si on veut faire des RMI en retour (même principe que les RPC en retour), c'est-à-dire permettre au serveur de lancer une requète RMI vers le client. D'autre part, on verra plus loin qu'on peut concevoir des applications RMI plus complexes que celles qui étendent UnicastRemoteObject: multicast ou permettant l'activation d'objets distants par le client. L'implémentation doit comporter un constructeur. Celui-ci doit pouvoir lancer ("throw") l'exception RemoteException Comme toujours l'appel du constructeur implique automatiquement l'appel préalable de celui de la classe parente (ici, on l'a mis explicitement en mettant super( )). Ici, la classe parente est UnicastRemoteObject et son constructeur initialise le serveur et lance la boucle d'attente de demandes d'exécutions de méthodes. Ce fichier doit être compilé: "javac CalculatorImpl.java". Création de la souche cliente (et du squelette en JAVA 1.1) Il n'est pas nécessaire d'avoir l'équivalent du fichier de spécification (.x) de RPCGEN: RMIC trouve les informations dont il a besoin dans CalculatorImpl. Après avoir compilé CalculatorImpl, on génère les fichiers suivants par la commande "rmic -keep CalculatorImpl" Calculator_Stub.class Calculator_Skel.class (si on veut être compatible avec JDK1.1, sinon on peut s'en passer) Calculator_Stub.java Calculator_Skel.java Les 2 derniers fichiers ne sont générés que par ce qu'on l'a demandé explicitement par l'argument "-keep". Ce sont des sources et ils ne sont pas nécessaires, mais il est intéressant d'en générer au moins une fois pour voir à quoi ressemblent les souches. La syntaxe de la commande rmic (pour JDK 1.2) est Usage: rmic <options> class names where options includes: -keep Do not delete intermediate generated source files -keepgenerated (same as "-keep") -v1.1 Create stubs/skeletons for JDK 1.1 stub protocol version -vcompat (default) Create stubs/skeletons compatible with both JDK 1.1 and Java 2 stub protocol versions -v1.2 Create stubs for Java 2 stub protocol version only -iiop Generate stubs using iiop protocol rather than jrmp ; see manual for suboptions of -iiop -idl Generate a.idl file including a language-independent specification of the classes (idl is the CORBA equivalent of xdrl); see manual for suboptions of -idl Au contraire de RMI, corba ne peut se passer d'une telle spécification car CORBA est indépendant des langages. RMI, qui ne s'applique qu'à JAVA utilise les déclarations de classes en java comme spécification. Au contraire de RMI, corba ne peut se passer d'une telle spécification car CORBA est indépendant des langages. RMI, qui ne s'applique qu'à JAVA utilise les déclarations de classes en java comme spécification. Unlike RMI, corba cannot do without such a specification because CORBA is language 6 sur 22 01/06/ :24

7 independent. RMI, that only works with JAVA uses JAVA class declarations as specifications. Unlike RMI, corba cannot do without such a specification because CORBA is language independent. RMI, that only works with JAVA uses JAVA class declarations as specifications. -g Generate debugging info -depend Recompile out-of-date files recursively -nowarn Generate no warnings -verbose Output messages about what the compiler is doing -classpath <path> Specify where to find input class files -d <directory> Specify where to place generated class files -J<runtime_flag> Pass argument runtime_flag to the java interpreter les souches IIOP de l'exemple précédent s'appelleraient _CalculatorImpl_stub.class souche cliente (nom dérivé de celui de l'implémentation) _Calculator_tie.class souche serveur (nom dérivé de celui de l'interface) Dans un environnement CORBA, on peut générer des souches compatibles dans d'autres langages que java (p.ex. C++) à partir de la spécification IDL. Un serveur minimal Contenu du fichier CalculatorServer.java: import java.rmi.naming; public class CalculatorServer { public CalculatorServer() { Calculator c = null; c = new CalculatorImpl(); catch (Exception e) { System.out.println("Can't create Calculator: " + e); while(true) { Naming.rebind("rmi://localhost:1099/CalculatorService", c); catch (Exception e) { System.out.println("Can't rebind: " + e); Thread.sleep(60000); //10 min. catch (InterruptedException e) { public static void main(string args[]) { new CalculatorServer(); Le serveur crée l'objet CalculatorImpl qui lance la boucle d'attente de requêtes (dans un thread séparé), s'enregistre au rmiregistry (et le refera toutes les 10 minutes) Il utilise la classe java.rmi.naming Il enregistre l'objet en l'identifiant par un URL Il n'est pas obligatoire d'indiquer que le protocole est rmi: il n'y a pas le choix. On peut aussi ne pas dire quel port utiliser pour le serveur rmiregistry, ce sera alors le port par défaut (justement 1099!) qui sera utilisé. Il n'est pas obligatoire d'indiquer que le protocole est rmi: il n'y a pas le choix. On peut aussi ne pas dire quel port utiliser pour le serveur rmiregistry, ce sera alors le port par défaut (justement 1099!) qui sera utilisé. Il utilise rebind plutôt que bind afin de pouvoir réutiliser le nom (l'url) pour le nouvel l'objet, au cas où le registry avait déjà un objet de ce nom Un serveur plus poli se serait arrangé pour prévenir lorsqu'il se termine: Naming.unbind("url"); A défaut, il faut attendre que le ramasse-miettes détruise l'entrée ou que le prochain rebind de cet URL pour que les clients ne risquent plus d'être dirigés vers un serveur qui n'existe plus. 7 sur 22 01/06/ :24

8 Cette classe contient une méthode main (): il en faut une dans tout programme. Le client Contenu du fichier CalculatorClient.java: import java.rmi.naming; import java.rmi.remoteexception; import java.net.malformedurlexception; import java.rmi.notboundexception; public class CalculatorClient { public static void main(string[] args) { Calculator c = (Calculator)Naming.lookup("rmi://localhost:1099/CalculatorService"); System.out.println( "4-3=" + c.sub(4, 3) ); System.out.println( "4+5=" + c.add(4, 5) ); System.out.println( "3x6=" + c.mul(3, 6) ); System.out.println( "9:3=" + c.div(9, 3) ); catch (MalformedURLException murle) { System.out.println(); System.out.println( "MalformedURLException"); System.out.println(murle); catch (RemoteException re) { System.out.println(); System.out.println( "RemoteException"); System.out.println(re); catch (NotBoundException nbe) { System.out.println(); System.out.println( "NotBoundException"); System.out.println(nbe); catch ( java.lang.arithmeticexception ae) { System.out.println(); System.out.println( "java.lang.arithmeticexception"); System.out.println(ae); Le client interroge le rmiregistry de la machine du serveur: il utilise la classe java.rmi.naming; il identifie l'objet par l'url que le serveur a demandé de lui associer lorsqu'il s'est enregistré au rmiregistry. Le rmiregistry lui renvoie le numéro de port du serveur et lui indique, par un URL, où trouver un stub d'accès à l'objet demandé; Le client utilise les méthodes de l'objet vers lequel il a reçu un stub. Cette classe contient une méthode main (): il en faut une dans tout programme. Si on veut l'essayer Il suffit de compiler les programmes: Les tests ont été fait avec java2se sur SOLARIS9_x86. Il faut veiller à ce que rmic et rmiregistry soient bien ceux de java2se et non ceux de gnu, parfois distribués avec gcc3. Pour s'en assurer: % type -all rmiregistry Ceux de j2se sont des liens symboliques dans /usr/bin et /bin. Au besoin, il faut changer la variable d'environnement pour que le «bon» programme apparaisse le premier. Les tests ont été fait avec java2se sur SOLARIS9_x86. Il faut veiller à ce que rmic et rmiregistry soient bien ceux de java2se et non ceux de gnu, parfois distribués avec gcc3. Pour s'en assurer: % type -all rmiregistry Ceux de j2se sont des liens symboliques dans /usr/bin et /bin. Au besoin, il faut changer la 8 sur 22 01/06/ :24

9 variable d'environnement pour que le «bon» programme apparaisse le premier. javac Calculator.java javac CalculatorImpl.java rmic -keep CalculatorImpl javac CalculatorServer.java javac CalculatorClient.java lancer rmiregistry &, sauf s'il est déjà en service! Sur SOLARIS, si la commande ps -a grep rmi donne un résultat se terminant par rmiregis, c'est que rmiregistry est déjà en service. Sur SOLARIS, si la commande ps -a grep rmi donne un résultat se terminant par rmiregis, c'est que rmiregistry est déjà en service. lancer le serveur java CalculatorServer & lancer le client java CalculatorClient Le tout dans le même répertoire. Téléchargement d'objets Les structures de données membres de l'objet Lorsqu'on passe un objet comme paramètre ou résultat d'une méthode, cet objet sera passé par valeur si c'est un objet local; les objets vers lesquels cet objet local a des références sont aussi copiés; cette façon de faire s'appelle "copie profonde" ("deep copy"). sauf les membres marqués static ou transient, qui ne sont pas transmis: les transient reçoivent une valeur par défaut à l'arrivée; les statiques font partie de l'état de la classe, pas de celui de l'objet individuel. sauf les membres marqués static ou transient, qui ne sont pas transmis: les transient reçoivent une valeur par défaut à l'arrivée; les statiques font partie de l'état de la classe, pas de celui de l'objet individuel. les changements qui seraient apportés ultérieurement à la copie de l'objet ne seront pas répercutés sur l'original; par référence à un proxy si c'est un objet distant, c'est-à-dire si son interface étend java.rmi.remote. Pour qu'un objet puisse être passé en argument ou résultat, sa classe doit implémenter l'interface java.io.serializable, mais c'est le cas de la plupart des classes prédéfinies. Bien entendu, tous les objets référencés par l'objet passé en argument et qui seront passés avec lui doivent aussi être sérialisables (or static ou transient). Bien entendu, tous les objets référencés par l'objet passé en argument et qui seront passés avec lui doivent aussi être sérialisables (or static ou transient). Lorsqu'un objet local passé en argument, contient plusieurs références vers un même objet ou des références en boucle, le même graphe sera automatiquement reconstruit correctement. Seule la première référence vers un objet donne lieu à une copie; les références suivantes sont transmises comme références. Seule la première référence vers un objet donne lieu à une copie; les références suivantes sont transmises comme références. Lorsqu'un même objet local est transmis ou référencé dans deux appels RMI disjoints, celui-ci sera transmis 2 fois par copie. Le code de la classe de l'objet Lorsqu'un objet est passé en argument d'un RMI, le code d'une classe sera nécessaire sur la machine 9 sur 22 01/06/ :24

10 destinataire le code de la classe de l'objet si c'est un objet «local», le code du proxy de l'objet si c'est un objet «distant» (remote). Ce code n'est jamais passé par le protocole avec la valeur ou la référence dans le paramètre ou le résultat d'un appel de méthode; au contraire, c'est un URL (file, ftp ou http), joint à la valeur ou à la référence, qui indiquera au destinataire où il peut trouver la classe nécessaire. Dans l'exemple précédent, on a supposé que tous les fichiers ".class" étaient disponibles aussi bien dans le CLASSPATH du serveur que dans celui du client. Avec une telle hypothèse les URL utilisés sont donc de type "file". Pour que l'émetteur envoie des URL qui renvoient à un serveur ftp ou http, plutôt qu'à des fichiers du répertoire courant, il faut que sa propriété java.rmi.server.codebase soit initialisée à l'url du serveur ftp ou http (ou du répertoire, s'il est accessible, p.ex. en NFS) voulu. (exemple de serveur http de classes java) Cette propriété peut recevoir une valeur dans le code du programme ou comme paramètre de la JVM qui l'exécute java [ -D<propertyname>=<propertyvalue> ] <classfile> Remarque: ce mécanisme peut aussi servir à télécharger la souche cliente Lors de son enregistrement auprès du rmiregistry, le serveur communique à celui-ci la valeur de sa codebase la réponse du rmiregistry à un client qui l'interroge contient une référence vers l'objet souche cliente et la codebase du serveur. Si le client ne trouve pas la souche cliente dans son CLASSPATH, il la charge ou télécharge de l'url spécifiée dans la codebase du serveur, reçue du rmiregistry Pour que le récepteur puisse charger les classes d'un serveur ftp ou http distant ou d'un répertoire désigné par la codebase de l'émetteur, il doit importer la classe java.rmi.server.rmiclassloader. Un récepteur cherche dans l'ordre 1. dans son CLASSPATH 2. dans la codebase reçue de l'émetteur Lorsqu'on ne veut en aucun cas qu'un programme importe du code en provenance d'un serveur dont l'url est reçu dans un paramètre ou un résultat d'appel de méthode à distance, il faut donner la valeur true à la propriété java.rmi.server.usecodebaseonly. Dans ce cas, on ne cherchera de méthodes que dans CLASSPATH ou dans l'url spécifié localement par java.rmi.server.codebase Lorsqu'on ne veut en aucun cas qu'un programme importe du code en provenance d'un serveur dont l'url est reçu dans un paramètre ou un résultat d'appel de méthode à distance, il faut donner la valeur true à la propriété java.rmi.server.usecodebaseonly. Dans ce cas, on ne cherchera de méthodes que dans CLASSPATH ou dans l'url spécifié localement par java.rmi.server.codebase 3. dans sa propre codebase Une codebase peut contenir l'url (http, ftp ou file) d'un répertoire contenant les classes ou des sous-répertoires correspondant aux packages qui contiennent les classes. Cet URL doit se terminer par / l'url d'un fichier jar contenant les classes ou des sous-répertoires correspondant aux packages qui contiennent les classes.cet URL ne peut pas se terminer par / une liste séparée par des blancs d'url des types précédents: exemple: -Djava.rmi.server.codebase=" file://yourstuff.jar" Il est ainsi possible de réaliser les configurations suivantes: fermée: toutes les classes doivent être accessibles localement sur le client et sur le serveur (accessibles par la variable d'environnement CLASSPATH); basée sur le serveur: the client (an applet) and and all the necessary classes are downloaded from a same http server. client dynamique: les classes de base du client sont chargées localement (CLASSPATH); les autres proviennent du serveur ftp ou http spécifié par le serveur RMI; serveur dynamique les classes de base du serveur sont chargées localement (CLASSPATH); les autres proviennent du serveur ftp ou http spécifié par le client RMI; client bootstrap: tout le code du client est téléchargé sauf un petit bootstrap; serveur bootstrap. 10 sur 22 01/06/ :24

11 Depuis JDK 1.3, on peut même charger le code d'une classe non accessible dans la codebase grâce à la méthode RMIclassLoader.loadClass. C'est ce que fait le petit bootsrap ci-dessus. Gestion des versions successives d'une classe lors du téléchargement d'objets (uniquement avec le protocole JRMP) JAVA identifie les classes grâce à leur nom complet et à une signature de 64 bits calculée par une fonction de hâchage (SHA-1). Cette signature est calculée dynamiquement et stockée dans un membre appelé serialversionuid dont la valeur peut aussi être calculée par le programme serialver inclus dans le JDK. La fonction de hâchage est calculée sur base de toutes les propriétés de la classe: nom, nom des interfaces implémentées et signature de tous les membres (structures de données et méthodes). Pour les courieux seulement/ For the curious ones only: The serialversionuid is computed using the signature of a stream of bytes that reflect the class definition. The National Institute of Standards and Technology (NIST) Secure Hash Algorithm (SHA-1) is used to compute a signature for the stream. The first two 32-bit quantities are used to form a 64-bit hash. A java.lang.dataoutputstream is used to convert primitive data types to a sequence of bytes. The values input to the stream are defined by the Java? Virtual Machine (VM) specification for classes. The sequence of items in the stream is as follows: 1. The class name written using UTF encoding. 2. The class modifiers written as a 32-bit integer. 3. The name of each interface sorted by name written using UTF encoding. 4. For each field of the class sorted by field name (except private static and private transient fields): a. The name of the field in UTF encoding. b. The modifiers of the field written as a 32-bit integer. c. The descriptor of the field in UTF encoding 5. If a class initializer exists, write out the following: a. The name of the method,, in UTF encoding. b. The modifier of the method, java.lang.reflect.modifier.static, written as a 32-bit integer. c. The descriptor of the method, ()V, in UTF encoding. 6. For each non-private constructor sorted by method name and signature: a. The name of the method,, in UTF encoding. b. The modifiers of the method written as a 32-bit integer. c. The descriptor of the method in UTF encoding. 7. For each non-private method sorted by method name and signature: a. The name of the method in UTF encoding. b. The modifiers of the method written as a 32-bit integer. c. The descriptor of the method in UTF encoding. 8. The SHA-1 algorithm is executed on the stream of bytes produced by DataOutputStream and produces five 32-bit values sha[0..4]. 9. The hash value is assembled from the first and second 32-bit values of the SHA-1 message digest. If the result of the message digest, the five 32-bit words H0 H1 H2 H3 H4, is in an array of five int values named sha, the hash value would be computed as follows: long hash = ((sha[0] >>> 24) & 0xFF) ((sha[0] >>> 16) & 0xFF) << 8 ((sha[0] >>> 8) & 0xFF) << 16 ((sha[0] >>> 0) & 0xFF) << 24 ((sha[1] >>> 24) & 0xFF) << 32 ((sha[1] >>> 16) & 0xFF) << 40 ((sha[1] >>> 8) & 0xFF) << 48 ((sha[1] >>> 0) & 0xFF) << 56; Pour les courieux seulement/ For the curious ones only: The serialversionuid is computed using the signature of a stream of bytes that reflect the class definition. The National Institute of Standards and Technology (NIST) Secure Hash Algorithm (SHA-1) is used to compute a signature for the stream. The first two 32-bit quantities are used to form a 64-bit hash. A java.lang.dataoutputstream is used to convert primitive data types to a sequence of bytes. The values input to the stream are defined by the Java? Virtual Machine (VM) specification for classes. The sequence of items in the stream is as follows: 1. The class name written using UTF encoding. 2. The class modifiers written as a 32-bit integer. 3. The name of each interface sorted by name written using UTF encoding. 4. For each field of the class sorted by field name (except private static and private transient fields): a. The name of the field in UTF encoding. b. The modifiers of the field written as a 32-bit integer. c. The descriptor of the field in UTF encoding 5. If a class initializer exists, write out the following: a. The name of the method,, in UTF encoding. b. The modifier of the method, java.lang.reflect.modifier.static, written as a 32-bit integer. c. The descriptor of the method, ()V, in UTF encoding. 6. For each non-private constructor sorted by method name and signature: a. The name of the method,, in UTF encoding. b. The modifiers of the method written as a 32-bit integer. 11 sur 22 01/06/ :24

12 c. The descriptor of the method in UTF encoding. 7. For each non-private method sorted by method name and signature: a. The name of the method in UTF encoding. b. The modifiers of the method written as a 32-bit integer. c. The descriptor of the method in UTF encoding. 8. The SHA-1 algorithm is executed on the stream of bytes produced by DataOutputStream and produces five 32-bit values sha[0..4]. 9. The hash value is assembled from the first and second 32-bit values of the SHA-1 message digest. If the result of the message digest, the five 32-bit words H0 H1 H2 H3 H4, is in an array of five int values named sha, the hash value would be computed as follows: long hash = ((sha[0] >>> 24) & 0xFF) ((sha[0] >>> 16) & 0xFF) << 8 ((sha[0] >>> 8) & 0xFF) << 16 ((sha[0] >>> 0) & 0xFF) << 24 ((sha[1] >>> 24) & 0xFF) << 32 ((sha[1] >>> 16) & 0xFF) << 40 ((sha[1] >>> 8) & 0xFF) << 48 ((sha[1] >>> 0) & 0xFF) << 56; Deux versions successives d'une classe seront donc considérées comme deux classes différentes sauf si le proprammeur a imposé lui-même un même svuid (de préférence celui calculé avec serialver pour la première version de la classe. ) %serialver CalculatorImpl static final long serialversionuid = L; Ceci a deux avantages: gain en performance, puisque le svuid ne doit plus être recalculé dynamiquement à l'exécution possibilité de créer des versions successives d'une classe (avec le même svuid). C'est le programmeur qui doit veiller à ce que les versions successives partageant un svuid soient compatibles: les seuls changements permis sont: changer l'ordre des champs de la classe (en JAVA, les champs sont dentifiés par leur noms et pas par leur position), ajouter des champs, changer les types des champs non primitifs par des types compatibles (passer d'un type de classe à celui d'une classe parente). Lorsqu'un nouvel objet est lu par une ancienne version de la classe, les nouveaux champs seront ignorés. Lorsqu'un vieil objet est lu par la nouvelle version de la classe, les nouveaux champs reçoivent une valeur par défaut (false, 0 ou null). Seul le protocole JRMP garantit ce comportement, pas RMI-IIOP. Cette gestion de versions permet de remplacer petit à petit les anciennes copies de la classe par les nouvelles. Une alternative est de n'avoir qu'une seule copie du code de la classe et de le faire télécharger par les applications à chaque usage. Aspects de sécurité du téléchargement de classes A partir de jdk 1.2 (java2), il n'est normalement plus possible de changer quoi que ce soit, si ce n'est du CLASSPATH, sans un fichier explicitant la politique de sécurité ("policy file"). Ce fichier est normalement exploité par la classe RMISecurityManager, qu'il faudra donc importer. La méthode main doit donc inclure if(system.getsecuritymanager() == null) { System.setSecurityManager (new RMISecurityManager()); Rien n'interdit, cependant, de définir son propre gérant de la sécurité et de l'appeler au lieu de RMISecurityManager Il ne faut pas imposer de gérant de sécurité pour les applets car elles utilisent celui du navigateur. Le fichier définissant la politique de sécurité d'un utilisateur (à partir de java2) s'appelle /.java.policy. Le fichier par défaut est /jre/lib/security/java.policy ( vaut souvent /usr/java). Il est chargé avant celui de l'utilisateur. On peut aussi ajouter un fichier de politique de sécurité dans la ligne de commande: java -Djava.security.policy=my_policy_file... On peut aussi spécifier dans la ligne de commande que fichier doit se substituer à tous les autres, plutôt que s'ajouter, en remplaçant = par ==. L'ordre de chargement des policy files peut être modifié dans /lib/security/java.security 12 sur 22 01/06/ :24

13 On peut aussi ajouter un fichier de politique de sécurité dans la ligne de commande: java -Djava.security.policy=my_policy_file... On peut aussi spécifier dans la ligne de commande que fichier doit se substituer à tous les autres, plutôt que s'ajouter, en remplaçant = par ==. L'ordre de chargement des policy files peut être modifié dans /lib/security/java.security Le fichier de politique de sécurité définira ce que chaque classe a le droit de faire, en fonction de l'endroit d'où elle a été chargée et, si la classe était archivée dans un fichier jar signé, en fonction des entitiés qui ont signé ce fichier jar. Pour en savoir plus sur la signature des jar: "man jarsigner". Pour en savoir plus sur la signature des jar: "man jarsigner". Quand une JVM doit faire une opération sensible, comme télécharger du code ou ouvrir un fichier, elle vérifie que toutes les classes dont des méthodes sont en cours d'exécution sur la pile du thread courant ont bien le droit d'effectuer cette opération. En cas d'échec, une exception java.lang.securityexception se produit. Le format général d'un fichier de politique de sécurité est le suivant: Le fichier de sécurité peut être crée avec un éditeur de texte ou avec l'outil policytool. Le fichier de sécurité peut être crée avec un éditeur de texte ou avec l'outil policytool. grant [<grantee>] { <permission>; <permission>;... si <grantee> est absent, les permissions qui suivent sont données à toutes les classes sinon, <grantee> indique l'url d'origine (serveur ou répertoire) et, éventuellement, la signature des classes auxquelles les permissions s'appliquent; pour indiquer l'url: grant codebase " {... //ou ftp ou grant codebase "file:mydirectory/" {... //le dernier / est obligatoire pour aussi indiquer le signataire grant signedby "names" codebase "url" {... //l'ordre des 2 parties de l'identification est sans importance les permissions peuvent s'appliquer à des fichiers: permission java.io.filepermission "/tmp/mylogfile", "read,write,delete"; à des interlocuteurs TCP: permission java.net.socketpermission ".info.ucl.ac.be:1024-", "connect,accept"; etc. (un traitement complet de la sécurité en java2 sort du cadre de cette discussion) la forme générale d'une instruction de permission relative à un interlocuteur est permission java.net.socketpermission "who", "what" où who = (hostname IPaddress ) [:portrange] portrange = portnumber -portnumber portnumber-portnumber portnumberhostname = DNSname DNSname_with_wildcard 'localhost' wildcard = '' what = action action,what action = accept //connections on listed port(s) connect //to listed port(s) listen //on listed port(s) resolve //host names Dans les toutes premières phases de la mise au point on peut utiliser grant codebase "file:mydirectory" { permission java.security.allpermission; qui désactive tout contrôle. C'est évidemment à proscrire dans un programme opérationnel!! les permissions relatives à des interlocuteurs TCP doivent permettre de s'y connecter pour télécharger 13 sur 22 01/06/ :24

14 du code (resolve, connect vers le serveur http ou ftp, ou read pour le contenu du répertoire). les permissions d'un serveur RMI doivent lui permettre d'accepter des connexions (listen, accept les clients RMI) JAVA2 (JDK1.2) inclut la commande policytool pour configurer le fichier de politique de sécurité. Si on n'impose pas de restrictions sur les signataires des jar, la sécurité ne repose que sur l'url de la source du code, ce qui revient à se fier à une adresse IP, donc au réseau lui-même. D'autre part, on n'a discuté jusqu'ici que la "sécurisation" du seul téléchargement de classes. Les interactions entre client et serveur ne sont pas sécurisées. Une solution pour sécuriser ces communications est de remplacer les sockets ordinaires par SSL (Secure Socket Layer), par exemple au moyen de JSSE (Java Secure Socket Extensions). exemple de fichier personnel de politique de sécurité grant { permission java.net.socketpermission ".info.ucl.ac.be:1024-", "listen,connect,accept,resolve"; permission java.net.socketpermission ".info.ucl.ac.be:-1023", "connect,resolve"; permission java.net.socketpermission " ", "listen,connect,accept,resolve"; ; Un exemple plus complet On peut adapter l'exemple du calculateur afin de s'affranchir de l'obligation de placer client et serveur dans un même répertoire. Cet exemple complété incorpore un serveur de classes au serveur RMI. Lorsque le serveur RMI s'enregistre au rmiregistry, il lui communique la codebase initialisée à l'url du serveur de classes ou le client peut télécharger la souche cliente. C'est son propre thread serveur de classes qui répondra à cet URL. 4.7bis RMI addendum Le serveur http de classes JAVA SUN propose un petit serveur de classes utilisant le protocole http ( /class-server.zip). Pour l'exécuter, il faut compiler les 2 fichiers qui le constituent, prélablement placés dans un sous répertoire classserver: javac classserver/classserver.java javac classserver/classfileserver.java Ensuite il faut lancer ce serveur en lui donnant comme paramètres le numéro de port qu'il doit utiliser et le CLASSPATH où le serveur de classes doit trouver les classes qu'il doit offrir en téléchargement, par exemple: java classserver.classfileserver 2001 $HOME/java/2346 & Enfin, il faut lancer le serveur RMI en lui indiquant le serveur de classes. java -Djava.rmi.server.codebase= MyRMIServer Une autre solution est d'incorporer le serveur de classes dans le serveur RMI: il suffit d'importer ClassFileServer et de créer un objet de cette classe. import classserver.classfileserver; //... new ClassFileServer(port, classpath) Il existe aussi des serveurs "commerciaux", beaucoup plus complets et supportant aussi ftp et https, par exemple dans J2EE (Java2 Enterprise Edition). ClassFileServer / Copyright (c) 1996, 1996, 1997 Sun Microsystems, Inc. All Rights Reserved. SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. Minor modifications by ML sur 22 01/06/ :24

15 / package classserver; import java.io.; import java.net.; / The ClassFileServer implements a ClassServer that reads class files from the file system. See the doc for the "Main" method for how to run this server. / public class ClassFileServer extends ClassServer { private String classpath; private static int DefaultServerPort = 2001; / Constructs a classpath the classpath where the server locates classes / public ClassFileServer(int port, String classpath) throws IOException { super(port); this.classpath = classpath; / Returns an array of bytes containing the bytecodes for the class represented by the argument path. The path is a dot separated class name with the ".class" extension the bytecodes for the ClassNotFoundException if the class corresponding to path could not be loaded. / public byte[] getbytes(string path) throws IOException, ClassNotFoundException { System.out.println("reading: " + path); File f = new File(classpath + File.separator + path.replace('.', File.separatorChar) + ".class"); int length = (int)(f.length()); if (length == 0) { throw new IOException("File length is zero: " + path); else { FileInputStream fin = new FileInputStream(f); DataInputStream in = new DataInputStream(fin); byte[] bytecodes = new byte[length]; in.readfully(bytecodes); return bytecodes; / Main method to create the class server that reads class files. This takes two command line arguments, the port on which the server accepts requests and the root of the classpath. To start up the server: java ClassFileServer The codebase of an RMI server using this webserver would simply contain a URL with the host and port of the web server (if the webserver's classpath is the same as the RMI server's classpath): java -Djava.rmi.server.codebase= RMIServer You can create your own class server inside your RMI server application instead of running one separately. In your server main simply create a ClassFileServer: 15 sur 22 01/06/ :24

16 new ClassFileServer(port, classpath); / public static void main(string args[]) { int port = DefaultServerPort; String classpath = ""; if (args.length >= 1) { port = Integer.parseInt(args[0]); if (args.length >= 2) { classpath = args[1]; new ClassFileServer(port, classpath); catch (IOException e) { System.out.println("Unable to start ClassServer: " + e.getmessage()); e.printstacktrace(); ClassServer / Copyright (c) 1996, 1996, 1997 Sun Microsystems, Inc. All Rights Reserved. SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. Minor modifications by ML CopyrightVersion 1.1_beta / package classserver; import java.io.; import java.net.; / ClassServer is an abstract class that provides the basic functionality of a mini-webserver, specialized to load class files only. A ClassServer must be extended and the concrete subclass should define the getbytes method which is responsible for retrieving the bytecodes for a class. The ClassServer creates a thread that listens on a socket and accepts HTTP GET requests. The HTTP response contains the bytecodes for the class that requested in the GET header. For loading remote classes, an RMI application can use a concrete subclass of this server in place of an HTTP ClassFileServer / public abstract class ClassServer implements Runnable { private ServerSocket server = null; private int port; / Constructs a ClassServer that listens on port and obtains a class's bytecodes using the method port the port IOException if the ClassServer could not listen on port. 16 sur 22 01/06/ :24

17 / protected ClassServer(int port) throws IOException { this.port = port; server = new ServerSocket(port); newlistener(); / Returns an array of bytes containing the bytecodes for the class represented by the argument path. The path is a dot separated class name with the ".class" extension the bytecodes for the ClassNotFoundException if the class corresponding to path could not be IOException if error occurs reading the class / public abstract byte[] getbytes(string path) throws IOException, ClassNotFoundException; / The "listen" thread that accepts a connection to the server, parses the header to obtain the class file name and sends back the bytecodes for the class (or error if the class is not found or the response was malformed). / public void run() { Socket socket; // accept a connection socket = server.accept(); catch (IOException e) { System.out.println("Class Server died: " + e.getmessage()); e.printstacktrace(); return; // create a new thread to accept the next connection newlistener(); DataOutputStream out = new DataOutputStream(socket.getOutputStream()); // get path to class file from header BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream())); String path = getpath(in); // retrieve bytecodes byte[] bytecodes = getbytes(path); // send bytecodes in response (assumes HTTP/1.0 or later) out.writebytes("http/ OK\r\n"); out.writebytes("content-length: " + bytecodes.length + "\r\n"); out.writebytes("content-type: application/java\r\n\r\n"); out.write(bytecodes); out.flush(); catch (IOException ie) { return; catch (Exception e) { // write out error response out.writebytes("http/ " + e.getmessage() + "\r\n"); out.writebytes("content-type: text/html\r\n\r\n"); out.flush(); catch (IOException ex) { // eat exception (could log error to log file, but // write out to stdout for now). System.out.println("error writing response: " + ex.getmessage()); ex.printstacktrace(); 17 sur 22 01/06/ :24

18 finally { socket.close(); catch (IOException e) { / Create a new thread to listen. / private void newlistener() { (new Thread(this)).start(); / Returns the path to the class file obtained from parsing the HTML header. / private static String getpath(bufferedreader in) throws IOException { String line = in.readline(); String path = ""; // extract class from GET line if (line.startswith("get /")) { line = line.substring(5, line.length()-1).trim(); int index = line.indexof(".class "); if (index!= -1) { path = line.substring(0, index).replace('/', '.'); // eat the rest of header do { line = in.readline(); while ((line.length()!= 0) && (line.charat(0)!= '\r') && (line.charat(0)!= '\n')); if (path.length()!= 0) { return path; else { throw new IOException("Malformed Header"); 4.7ter RMI addendum le bootstrap pour téléchargement des classes du client JAVA public class URLClientBootstrap { static String codelocation = " //codebase URL static String clientclass = "MyClass"; //client class name public static void main (String[]args) throws Exception { if(system.getsecuritymanager() == null) { System.setSecurityManager (new RMISecurityManager()); Class cl = RMIClassLoader.loadClass (codelocation,clientclass); Runnable client = (Runnable)cl.newInstance(); client.run(); Pour utiliser cette classe, il faut importer les packages dont elle se sert: import java.rmi.rmisecuritymanager; import java.rmi.server.rmiclassloader; 18 sur 22 01/06/ :24

19 Ceci n'est pas la seule façon de créer un bootstrap. On trouvera d'autres propositions dans Pitt & McNiff, section quater RMI addendum exemple de la calculette où le client télécharge le stub du serveur Le serveur RMI a ici un thread qui sert de serveur html de classes pour distribuer les stubs aux clients. Les changements par rapport à l'exemple initial sont en vert Si on veut l'essayer Il suffit de préparer l'expérience Dans le répertoire de travail, on crée 2 répertoires, client et server; dans server, on crée un répertoire classserver, qui contiendra les classes du serveur de classes et un répertoire classes où ce dernier ira chercher les fichiers.class qu'on lui demandera. Dans classserver on copie les deux fichiers ClassServer.java et ClassFileServer.java qui constituent un serveur http de classes java et on les y compile: javac ClassServer.java ClassFileServer.java Dans server, on copie Calculator.java, CalculatorImpl.java et CalculatorServer.java et on les y compile dans cet ordre puis on les copie dans le sous-répertoire classes: javac Calculator.java javac CalculatorImpl.java rmic -keep CalculatorImpl javac CalculatorServer.java cp Calculator.class classes Dans client, on copie Calculator.java et CalculatorClient.java et on les y compile dans cet ordre. javac Calculator.java javac CalculatorClient.java Dans le répertoire de travail, on copie le fichier mypolicy faites l'expérience Dans le répertoire de travail, lancer rmiregistry &, sauf s'il est déjà en service! Attention: on ne peut pas lancer rmiregistry à un endroit où, via son CLASSPATH il peut trouver les classes à envoyer au client, sinon, il n'enverra pas l'url du serveur de classes (qui est ici un thread du serveur RMI). Le plus sûr est de lancer un nouveau shell (p. ex. dans une nouvelle fenêtre) et de lui donnerles commandes: unsetenv CLASSPATH rmiregistry & Dans le répertoire server, lancer le serveur java -Djava.rmi.server.codebase=" -Djava.security.policy="../mypolicy" CalculatorServer & Notez ici que l'url de la codebase se termine par un / car l'url se termine par le nom d'un répertoire et non d'un fichier jar Dans le répertoire client, lancer le client java -Djava.security.policy="../mypolicy" CalculatorClient Le client recevra de rmiregistry non seulement le numéro de port du serveur comme l'aurait fait rpcbind mais aussi l'url où il peut télécharger la classe CalculatorImpl_stub. Il faut que la politique de sécurité en vigueur l'autorise à décharger des classes de ce port (ici 10080) sur cette machine. L'interface de la calculette Contenu du fichier "Calculator.java" (rien de changé): public interface Calculator extends java.rmi.remote { public long add(long a, long b) throws java.rmi.remoteexception; public long sub(long a, long b) throws java.rmi.remoteexception; public long mul(long a, long b) throws java.rmi.remoteexception; 19 sur 22 01/06/ :24

20 public long div(long a, long b) throws java.rmi.remoteexception; L'implémentation de la calculette Contenu du fichier "CalculatorImpl.java" (rien de changé): public class CalculatorImpl extends java.rmi.server.unicastremoteobject implements Calculator { // Implementations must have an explicit constructor // in order to declare the "RemoteException" exception public CalculatorImpl() throws java.rmi.remoteexception { super(); public long add(long a, long b) throws java.rmi.remoteexception { return a + b; public long sub(long a, long b) throws java.rmi.remoteexception { return a - b; public long mul(long a, long b) throws java.rmi.remoteexception { return a b; public long div(long a, long b) throws java.rmi.remoteexception { return a / b; Un serveur qui est aussi serveur http pour distribuer les stubs aux clients On aurait aussi pu créer un programme différent comme serveur de classes. Contenu du fichier CalculatorServer.java: import java.io.; import java.rmi.naming; import java.rmi.rmisecuritymanager; import java.rmi.server.rmiclassloader; import classserver.; public class CalculatorServer { public CalculatorServer() { Calculator c = null; c = new CalculatorImpl(); catch (Exception e) { System.out.println("Can't create Calculator: " + e); while(true) { Naming.rebind("rmi://localhost:1099/CalculatorService", c); catch (Exception e) { System.out.println("Can't rebind: " + e); Thread.sleep(60000); //10 min. catch (InterruptedException e) { public static void main(string args[]) { 20 sur 22 01/06/ :24