Remote Method Invocation (RMI)

Transcription

1 Remote Method Invocation (RMI) Pierre Gançarski Mars Présentation L'objectif est de permettre à des applications clientes (s'exécutant localement) d'invoquer des méthodes sur des objets distants, c'est-à-dire localisés dans une autre application (dans une autre JVM de la même machine physique ou sur une autre machine accessible via Internet) communément appelée serveur. RMI constitue un moyen simple pour développer des programmes client-serveur. Le mécanisme proposé permet à une application s'exécutant sur une machine M1 de créer un objet et de le rendre accessible à d'autres applications : cette application (et la machine M1) joue donc le rôle de serveur. Les autres applications manipulant un tel objet sont des clients. Pour manipuler un objet distant, un client récupère sur sa machine une représentation de l'objet appelé proxy/talon/souche/stub. Le proxy (ou objet de communication) est un objet qui va faire le lien entre une interface locale et l'objet distant : c'est via ce talon que le client pourra invoquer des méthodes sur l'objet distant. Une telle invocation sera tranmise au serveur (le protocole TCP est utilisé) an d'en réaliser l'exécution. Du côté du serveur un skeleton/squelette a en charge la réception des invocations distantes, de leur realisation et de l'envoi des résultats. Dans cette conguration, un appel se déroule de la manière suivante : 1. le client dans le machine M1 appelle une méthode de la classe D sur l'objet de communication c'est-à-dire proxy de D. Ce dernier est l'interface locale de l'objet D distant se trouvant dans le machine M2 ; 2. le proxy (stub) emballe l'identiant de la méthode et ses arguments (sérialisation, marshalling) ;. la requête est transmise sur le réseau ; 4. le squelette (skeleton) reçoit et déballe le message (désérialisation) ; 5. la méthode demandée est appelée localement dans le machine M2 ; 6. la méthode renvoie un résultat au squelette (skeleton) ; 7. le squelette emballe ce résultat ; 8. le squelette transmet le résultat vers le proxy (stub) ; 9. le proxy reçoit et déballe le message ; 10. la méthode du proxy retourne le résultat comme une méthode ordinaire. Ainsi, le client a l'illusion de faire un appel local, et l'objet serveur a l'illusion d'être appelé localement. 2 Réalisation d'une application 2.1 Développement Le déroulement typique d'une application utilisant la technlogie RMI est le suivant : 1. Dénition de l'interface d'appel aux objets auquel on veut accéder à distance. L'interface dénit le contrat abstrait liant le serveur et le client. Elle constitue la base sur lequel s'appuie le client pour invoquer une méthode à distance. 2. Programmation d'une implémentation des méthodes correspondant à l'interface des objets.. Développement d'un programme créant des objets qui seront disponibles pour des clients distants éventuels ; 4. Développement de clients qui utilisent les précédants objants par des appels à distance. 1

2 2.2 Exemple Étape 1 : Dénition de l'interface d'accès aux objets adressables à distance, c'est-à-dire la signature des méthodes qui peuvent être appelées. Fichier Message.java 1 import java. rmi. Remote ; 2 import java. rmi. RemoteException ; 4 public interface Message extends Remote { 5 public String messagedistant () throws RemoteException ; 6 } L'interface des objets qui seront accessibles à distance dérivent de la classe java.rmi.remote. Par rapport à un appel local de méthode, un appel à distance peut échouer. Toute méthode accessible à distance peut provoquer l'exception java.rmi.remoteexception an de prévenir l'appelant. Étape 2 : Dénition de la classe implantant le code qui réalisera réellement les opérations dénies dans l'interface Fichier MessageImpl.java 1 import java. rmi. server. UnicastRemoteObject ; 2 import java. rmi. RemoteException ; 4 public class MessageImpl extends UnicastRemoteObject implements Message { 5 public MessageImpl () throws RemoteException { super () ; }; 6 public String messagedistant () throws RemoteException { 7 return (" Message : Salut! ") ;} 8 } L'implémentation de l'interface doit hériter de UnicastRemoteObject (permet de mettre en oeuvre le protocole point à point dédié c'est-à-dire de construire et recevoir les messages transitant sur le réseau). Le constructeur de la classe doit faire appel au constructeur de la classe dont elle hérite. Étape : Écriture du serveur, c'est-à-dire du code du processus qui réalisera les opérations. Fichier Serveur.java 1 import java. net.{*} ; 2 import java. rmi.{*} ; 4 public class Serveur { 5 public static void main ( String {[}{]} args ) { 6 try { 7 MessageImpl objlocal = new MessageImpl () ; 8 Naming. rebind (" rmi :// localhost :1099/ Message ", objlocal ); 9 System. out. println (" Serveur pret ") ; 10 } catch ( RemoteException re ) { System. out. println ( re ) ;} 11 catch ( MalformedURLException e) { System. out. println (e) ; } 12 } 1 } Le serveur crée un objet qui sera accessible à distance. Ensuite, il inscrit cet objet dans le serveur de noms en l'associant à une chaîne de caractère spécique via un service de nomage. Ce serveur permettra aussi au client de retrouver l'objet mis à disposition. Service de nommage : La publication des objets d'un serveur est réalisée via un processus d'enregistrement et de nommage de ces objets, par exemple au sein du programme médiateur rmiregistry (c'est l'équivalent du portmap ou rpcbind des RPC). Cette application fonctionnant sur une machine hôte permet l'enregistrement d'objets par attribution à chacun d'eux d'un nom sous forme d'une chaîne de caractères. Ce nom désigne l'objet pour un programme client désirant y accéder ; celui-ci correspond à un URL. Par exemple, rmi ://m1.u-strasbg.fr :1099/monObjet désigne un objet référencé avec le nom monobjet sur la machine M1. Il est possible d'omettre le nom de la machine et/ou le port à utiliser, les valeurs par défaut étant : localhost pour l'un et 1099 pour l'autre. 2

3 On peut aussi utiliser la classe java.rmi.registry.locateregistry : Fichier Serveur.java 1 import java. rmi. registry. Registry ; 2 import java. rmi. registry. LocateRegistry ; import java. rmi. RemoteException ; 4 import java. rmi. server. UnicastRemoteObject ; 5 6 public class Serveur { 7 public static void main ( String {[}{]} args ) { 8 try { 9 MessageImpl objlocal = new MessageImpl () ; 10 Registry registry = LocateRegistry. getregistry () ; 11 registry. bind (" Message ", objlocal ); 12 System. out. println (" Serveur pret ") ; 1 } catch ( RemoteException re ) { System. out. println ( re ) ;} 14 catch ( MalformedURLException e) { System. out. println (e) ; } 15 } 16 } Il y a possibilité de créer le registry dynamiquement (au lieu de lancer rmiregistry sur la ligne de commande) par : java.rmi.registry.locateregistry.createregistry(8000) ; Autres fonctions disponibles : bind(), rebind(), unbind(), list(), lookup(). Les exceptions RemoteException et MalformedURLException doivent être attrapées. Étape 4 : Compilation et déploiement du serveur. Ce fait par : 1. javac *.java 2. rmic MessageImpl. rmiregistry (sur la machine du serveur) 4. java Serveur (sur la machine du serveur) rmic : Pour l'utilisateur, les connexions semblent s'eectuer directement entre le client et le serveur. Dans la pratique, les données opèrent un parcours à travers un certain nombre de couches. Deux des couches traversées sont le Stub et le Skeleton qui sont utilisés respectivement sur le client avec un rôle de proxy et sur le serveur avec pour rôle la gestion des communications vers le Stub des clients. Ces deux couches prennent la forme de classes Java compilées (générées avec rmic). Le serveur devra avoir accès aux Stubs et aux Skeletons des classes implantées. Seules les Stubs doivent être accessibles aux clients. Les connexions et transferts d'informations sont entièrement pris en charge par Java. La couche TCP/IP est utilisée via un protocole dédié (Java Remote Method Protocol, JRMP). TCP/IP fournit une connexion persistante entre deux machines dénie par des adresses IP et des ports à chaque bout. Le graphe de classes minimum pour une application RMI est le suivant : java.rmi.remote java.rmi.unicastremote Message MessageImpl_Stub MessageImpl_Skel MessageImpl interface classe definie par l utilisateur herite de implemente utilise Client Serveur Étape 5 : Écriture du client

4 Obtention d'un proxy Pour qu'un client puisse appeler une méthode sur un objet distant, il a besoin de disposer d'un objet local, un proxy ou objet de communication connecté à l'objet distant à qui il transmettra les demandes. Pour obtenir ce proxy, deux solutions sont possibles : Utiliser un service de nommage, qui conserve des associations entre objet accessible à distance et nom externe (une chaîne de caractères ou un URL) : le client demande au service de nommage de lui fournir un proxy correspondant à un nom externe donné. Le service de nommage est lui-même un service accessible à distance, localiser sur une machine dénie (classes Naming et LocateRegistry). Avoir appelé une méthode (à distance) qui transmet/renvoie un (autre) objet accessible a distance (cf section 4.1). Fichier Serveur.java 1 import java. net.* ; 2 import java. rmi.* ; import java. net. MalformedURLException ; 4 5 public class Client { 6 public static void main ( String [] args ) { 7 try { 8 Message b =( Message ) Naming. lookup (" rmi ://"+ args [0]+"/ Message ") ; 9 System. out. println (" Le client recoit : "+ b. messagedistant () ); 10 } catch ( NotBoundException re ) { System. out. println ( re ); } 11 catch ( RemoteException re ) { System. out. println ( re ); } 12 catch ( MalformedURLException e) { System. out. println (e); } 1 } 14 } Une référence sur l'objet est récupérée grâce aux services oerts par le service de nom rmiregistry. Les exceptions RemoteException, MalformedURLException et NotBoundException doivent être attrapées. Fonctionnement du proxy Le client récupère donc nalement une référence sur le proxy local de l'objet distant. Ce proxy implémente l'interface de l'objet distant. A chaque appel de méthode sur le proxy, il sait comment contacter le squelette de l'objet sur la machine du serveur grâce à des communications sur le réseau et déclencher à distance la même méthode. Le squelette sait lui-même déclencher une méthode de l'objet du serveur. Étape 6 : Compilation et lancement du serveur. Ce fait par : 1. javac *.java 2. java Client <machine Serveur :numero port> (sur la machine du client) Mécanismes de base de RMI.1 Passage de paramètres En Java monosite, les paramètres sont passés par référence, sauf pour les types primitifs (booléens, entiers, ottants et caractères) qui sont passés par valeur (copie). Lors d'un appel à distance : les valeurs primitives sont passés par valeur (copie) ; les objets sérialisables (implantant java.io.serializable) sont sérialisés (diérent d'avec un appel local de méthode) et passés par copie (sauf les champs static et transient qui ne sont pas copiés an de ne pas avoir d'eet de bord). les objets accessibles à distance (implantant l'interface java.rmi.remote) sont passés par référence ; les objets ni sérialisables, ni accessibles à distance provoquent une exception java.rmi.marshalexception. Tout cela est aussi vrai pour l'objet que peut retourner une fonction accessible à distance. Pourquoi passer par une recopie? On pourrait envoyer du client vers le serveur une référence sur les objets locaux passés en paramètre d'un appel distant. Or la méthode distante va avoir besoin des objets passés en paramètre. Il faudra donc une nouvelle communication du serveur vers le client pour obtenir les infos ou méthodes encapsulée dans les objets. Dans ce cadre les problèmes suivants se posent : 4

5 1. Les temps de latence réseau peuvent rendre tous ces échanges très coûteux. Au niveau des performances, il vaut mieux un échange plutôt que plusieurs. 2. Si l'on suppose sur le serveur traite une requête et ne peut répondre à une autre pendant 0 secondes. Si le client est tué durant ce délai, ou si le réseau tombe en panne, le serveur ne pourra pas du tout traité la demande Une bonne solution consiste à envoyer en simultané : la requête, et une copie des objets locaux passés en paramètre. L'inconvénient est qu'une fois copiées, les deux instances sont complètement indépendantes! De manière similaire à RPC, on doit considérer sémantiquement que le serveur travaille sur une copie de l'objet initial du client..2 Sérialisation La sérialisation consiste à obtenir une représentation linéaire des objets et de leurs relations. Sous cette forme, ils peuvent alors être exportés pour être réutilisés par une autre application. On peut par exemple les sauvegarder dans un chier ou les transmettre par socket. La sérialisation est un procédé apparu depuis la version 1.1 du langage. Elle permet de stocker dans un chier ou de transporter sur le réseau un objet ayant une structure complexe. Elle peut être vue comme un pliage des paramètres d'une structure de données dans un but de transport ou de stockage. Pour sérialiser, il faut instancier la classe ObjectOutputStream. Cette opération consiste à ouvrir un ux en écriture, ux qui possède la capacité de convertir en une suite d'octets l'objet sur lequel s'applique la méthode d'écriture : 1. tous les types primitifs du langage et la plupart des objets instances de classes de l'api standard (comme String, Vector, Properties, Hashtable...) sont sérialisables et désérialisables par simple appel aux méthodes writeobject et readobject ; 2. tout objet dont les variables d'instances sont sérialisables peut être lui même sérialisé, à condition que la classe qu'il instancie implémente l'interface java.io.serializable. Cette interface ne dénit aucune méthode et constitue juste un marqueur à l'attention de la machine virtuelle ;. la sérialisation (comme la désérialisation) concerne uniquement la sauvegarde (et la restauration) des données relatives aux objets eux-mêmes. Les variables de classes (déclarées static i.e. communs à tous les objets d'une classe) ne sont pas concernées par le mécanisme standard de sérialisation mis en oeuvre par l'implémentation de la classe Serializable. Par ailleurs, si une variable d'instance est déclarée à l'aide du modicateur transient, alors elle est considérée comme éphémère ou transitoire ou "non persitante" et, à ce titre, elle n'est pas concernée par la gestion persistante que constituent les mécanismes de sérialisation et désérialisation. Cette variable peut contenir des données temporarires ou alors des données devant être sécurisées (non recopiables) ; 4. pour mettre en place des mécanismes de sérialisation plus spéciques, vous pouvez surcharger les méthodes privées writeobject et readobject (veillez à le faire de façon symétrique). Vous pouvez même forcer vos classes à implémenter l'interface Externalizable, ce qui vous oblige à écrire la totalité du code de lecture et d'écriture sur ux. Rappel : Les tableaux de types primitifs sont des objets. Lorsqu'un tableau est passé en argument d'une méthode accédée à distance, ce tableau est donc sérialisé. La déclaration float [][]mat = new float [][4] déclare une matrice bidimensionnelle. L'initialisation d'une telle matrice peut prendre la forme suivante : for (int i = 0 ; i < mat.length ; ++i) for (int j=0 ; j < mat[0].length ; ++j) mat[i][j] = i-j ; Java vérie automatiquement l'indice lors de l'accès à un élément (comparaison avec les bornes) et peut lever l'exception ArrayIndexOfBoundException. Le package java.util dénit des méthodes pour le tri et la recherche dans des tableaux. Par exemple, Arrays.sort(mat[0]) permet de trier la première ligne de la matrice mat ; Arrays.equals(mat[0], mat[1]) détecte si les deux vecteurs sont identiques ou non.. Divers Les RPC sont basés sur la notion d'appel de procédure, tandis que RMI travaille sur des objets. Quatre packages Java pour l'utilisation des RMI : java.rmi : Dénition des classes, interfaces et exceptions qui concernent le client (accès automatisé à des méthodes distantes). java.rmi.server : Dénition des classes, interfaces et exceptions qui concernent le serveur (création d'objets distants à l'intention de clients). java.rmi.registry : Localisation et dénomination des objets distants (publication des objets distants accessibles). java.rmi.dgc : Ramasse miettes distribué (récupération automatique de la mémoire qui n'est plus utilisée). 5

6 4 Mécanismes ns de RMI En utilisant java.rmi.activation.activatable au lieu de UnicastRemoteObject, cela permet que les objets distants ne soient créés (activés) que lorsqu'un client le demande. Pour utiliser un autre protocole que TCP/IP, on passe par la classe RMISocketFactory.IP. 4.1 Fabrique d'objets et d'interface distantes Il est possible d'assoicer plusieurs interface à un même objet distant. Soit une deux interface dénies par 1 public interface Date extends Remote { 2 public String datedistante () throws RemoteException ; } et 1 public interface Message extends Remote { 2 public String messagedistant () throws RemoteException ; } avec l'implantation suivante : Fichier OperationsImpl.java 1 import java. rmi. server. UnicastRemoteObject ; 2 import java. rmi. RemoteException ; 4 public class OperationsImpl 5 extends UnicastRemoteObject 6 implements Message, Date, java. io. Serializable { 7 8 public OperationsImpl () throws RemoteException { super () ; }; 9 10 public String messagedistant () throws RemoteException { 11 return (" Le message ") ; 12 } 1 14 public String DateDistante () throws RemoteException { 15 return (" Le date ") ; 16 } 17 } Dans le serveur, on crée un seul objet : 1 try { 2 objlocal = new OperationsImpl () ; Naming. rebind (" rmi :// localhost :"+ args [0]+"/ Ops ", objlocal ) ; 4 } catch ( RemoteException re ) { System. out. println ( re ) ; } 5 catch ( MalformedURLException e) { System. out. println (e) ; } } L'appel se fera simplement par : Object obj_distant = Naming. lookup ("//"+ args [0]+"/ Message ") ; Message mess = ( Message ) obj_ distant ; 4 Date date = ( Date ) obj_ distant ; 5 6 System. out. println (" Le client recoit un msg. "+ mess. messagedistant () ); 7 System. out. println (" Le client recoit la date "+ date. DateDistante () );

7 Il est possible d'instantier dynamiquement des objets distants. Fichier Message.java 1 import java. rmi. Remote ; 2 import java. rmi. RemoteException ; 4 public interface Message extends Remote { 5 public String messagedistant () throws RemoteException ; 6 public Message clonage () throws RemoteException ; 7 } La méthode clonage va créer un objet sur le site du serveur et retourner un proxy (un objet de communication) sur celui-ci. Fichier MessageImpl.java 1 import java. rmi. Remote ; 2 import java. rmi. RemoteException ; 4 5 public class MessageImpl 6 extends UnicastRemoteObject 7 implements Message, java. io. Serializable { public String messagedistant () {... } 11 public Message clonage ( String ch ) throws RemoteException { 12 Message new_ mess = new MessageImpl () ; 1 return ( new_mess ); 14 } 15 } Comme on le voit (ligne 1), il est possible de passer une interface comme retour ou comme paramètre d'une méthode. L'appel se fera classiquement dans le client par : Fichier Client.java 1 public class Client { 2 public static void main ( String [] args ) { try { 4 Message b =( Message ) Naming. lookup ("//"+ args [0]+"/ Message ") ; 5 Message c= b. clonage () ; 6 } 7 catch ( NotBoundException re ) { System. out. println ( re ) ; } 8 catch ( RemoteException re ) { System. out. println ( re ) ; } 9 catch ( MalformedURLException e) { System. out. println (e) ; } 10 } 11 } 4.2 Sécurité Lors de l'élaboration d'une application distribuée, il est important de pouvoir restreindre sur chaque site l'accès aux ressources locales. Et ce, d'autant plus que certaines parties de l'application ont pu être chargées dynamiquement et n'ont pas été contrôlées. Un agent de sécurité (RMI Security Manager ) constitue un moyen d'élaborer des stratégies de sécurité. Par défaut, si l'application client n'a pas d'agent de sécurité : les classes ne peuvent pas être chargées depuis le réseau (pas dignes de conance) et l'on n'a accès qu'aux classes disponibles sur le système de chiers local. Le package java.rmi fournit un agent de sécurité par défaut activable avec le code suivant : 1 if ( System. getsecuritymanager () == null ) { 2 System. setsecuritymanager ( new RMISecurityManager () ); } } 7

8 Lorsque cet agent est en place, il requiert un chier de conguration concernant la politique de protection. Ceci est faisable à l'exécution en dénissant la variable java.security.policy, par exemple avec la commande java -Djava.security.policy=< <Application>. 1 cd serveur 2 rmiregistry & java - Djava. security. policy = java. policy Serveur Un chier par défaut est proposé : /usr/lib/jvm/java-6-openjdk/jre/lib/security/java.policy Le chier est éditable avec l'application du JDK : policytool. La syntaxe de ce chier est décrite dans la documentation docs/guide/security/policyfiles.html Un exemple : 1 grant { 2 permission java. net. SocketPermission "*: "," connect, accept, listen, resolve "; 4 permission java. security. AllPermission ; 5 }; Il permet notamment de restreindre l'utilisation du système de chiers ou des communications par socket. 4. Chargement dynamique de classes Des classes peuvent être récupérées dynamiquement à distance via le réseau si elles ne sont pas disponibles localement. Par exemple, un client peut ne pas connaître les classes proxy des objets distants auxquels il veut accéder. Un serveur positionne alors la variable java.rmi.server.codebase=<url> an de spécier à ses éventuels clients où ils pourront récupérer les classes stub des objets qu'il rend disponibles. De cette manière, un client peut être développé en connaissant uniquement l'interface des objets auquel il va accéder mais sans avoir connaissance de leurs implantations eectives. Par défaut, Java dispose d'un chargeur de classes qui est appelé lors de l'appel à la commande java pour provoquer l'exécution d'une application. Il prend automatiquement les classes disponibles dans les répertoires listés dans la variable d'environnement CLASSPATH. Toutes les classes qui apparaissent explicitement dans le code du client sont chargées avec le chargeur par défaut. Mais lors de l'utilisation de RMI, java dispose du chargeur RMIClassLoader pour charger des classes manquantes (par exemple la classe Stub ). Celui-ci cherche à plusieurs endroits les classes dont on peut avoir besoin : 1. dans le CLASSPATH ; 2. pour les objets (distants ou non) passés en argument ou en retour d'appel distant, un URL est transmis permettant de localiser la classe de l'objet ;. Pour le proxy d'objets distants créé localement, l'url spécique dénie par la variable java.rmi.server.codebase. L'URL encodée avec la classe de l'objet lors du passage de paramètre est : 1. l'url depuis laquelle a été chargée l'objet si elle existe. 2. l'url spéciée dans la propriété système java.rmi.server.codebase sinon. Si la propriété système java.rmi.server.usecodebaseonly chargée que depuis l'url spéciée dans codebase. est true, une classe non locale peut uniquement être Il est possible de forcer le chargement d'une classe par le réseau en appelant explicitement le chargement d'une classe avant son utilisation. Pour cela on peut utiliser la méthode loadclass() de la classe RMIClassLoader. Class c = RMIClassLoader.loadClass("http ://machine n ame/classes, MessageImpl ); On peut ainsi télécharger complètement un client en supposant qu'il implémente un interface connue localement (ici Runnable). 1 Class c = RMIClassLoader. loadclass (" http :// machine_ name / CLASSES "," Client ") ; 2 ( Runnable ) client = c. newinstance () ; client. run () ; Seul les URLs de type HTTP et FTP sont supportées par l'implantation actuelle. Il est dommage que la classe java.net.url n'est pas été utilisée dans ce contexte permettant un enrichissement dynamique des méthodes de chargement de classe. Il n'est pas possible de charger depuis le réseau une classe tant qu'aucun gestionnaire de sécurité n'a été mis en place au moyen de System.setSecurityManager(). Les classes chargées par le réseau sont soumises à ce gestionnaire de sécurité. 8

9 Les RMIs propose un gestionnaire de sécurité RMISecurityManager qui par défaut interdit tout ce qu'un SecurityManager peut interdire, sauf la définition de classe. Pour permettre plus de chose il faut écrire son propre gestionnaire de sécurité héritant de RMISecurityManager. Exemple d'un serveur de calcul de complexe ou toutes les classes sont chargées dynamiquement par le client. Le client : 1 public class ComplexCompute { 2 public static void main ( String [] args ) throws Exception { Properties p = System. getproperties () ; 4 p. put (" java. rmi. server. codebase "," http :// dpt - info /~ gancars / CLASSES ") ; 5 System. setproperties (p); 6 System. setsecuritymanager ( new RMISecurityManager () ); 7 ComplexOps obj = ( ComplexOps ) Naming. lookup ("//"+ args [0]+ ":1000/ ComplexOps ") ; 8 Complex c1 = obj. newcomplex (1,1) ; 9 Complex c2 = obj. newcomplex (2,2) ; 10 Complex c = obj. addcomplex (c1, c2 ); } 1 } L'interface de l'objet distant et la classe l'implémentant (le serveur). 1 public interface ComplexOps extends Remote { 2 public Complex newcomplex ( double re, double im ) throws java. rmi. RemoteException ; public Complex addcomplex ( Complex c1, Complex c2 ) throws java. rmi. RemoteException ; 4 } Serveur 1 public class ComplexOpsImpl extends UnicastRemoteObject implements ComplexOps { 2 public Complex newcomplex ( double re, double im ) throws java. rmi. RemoteException { return new ComplexImpl (re, im ); 4 } 5 public Complex addcomplex ( Complex c1, Complex c2 ) throws java. rmi. RemoteException { 6 return new ComplexImpl ( c1. getre () + c2. getre (),c1. getim () + c2. getim () ); 7 } 8 9 public static void main ( String [] args ) throws Exception { 10 Properties p = System. getproperties () ; 11 p. put (" java. rmi. server. codebase "," http :// dpt - info /~ gancars / CLASSES ") ; 12 System. setproperties (p); 1 System. setsecuritymanager ( new RMISecurityManager () ); 14 Naming. rebind (" rmi :// localhost : 1099/ ComplexOps, new ComplexOpsImpl () ); 15 } 16 } L'interface et l'implémentation de l'objet complexe : 1 public interface Complex { 2 public double getre () ; public double getim () ; } 1 public class ComplexImpl implements Complex, Serializable { 2 private double re ; 9

10 private double im ; 4 5 public ComplexImpl ( double re ){ 6 this. re = re ; 7 } 8 public ComplexImpl ( double re, double im ){ 9 this. re = re ; this. im = im ; 10 } } 5 Conclusion Inconvénients de RMI : RMI est la propriété de SUN RMI n'offre la possibilité d'interagir avec des objets d'autres langages (interopérabilité) RMI est plus lent que les implémentations de CORBA Avantages : RMI est simple à mettre en oeuvre RMI étend le garbage collector de java (DGC) RMI permet une gestion de la sécurité (RMISecurityManager) 10