TECHNIQUES DE PROGRAMMATION JAVA PAR OBJETS DISTRIBUÉS

Transcription

1 1 DÉFINITIONS : TECHNIQUES DE PROGRAMMATION JAVA PAR OBJETS DISTRIBUÉS Objet Distribué (OD) : c est un objet à exécution distante rendu accessible à des applications clientes (OD-clients) par le biais d une interface depuis un serveur (ODserveur). Plus techniquement, c est une appellation abstraite qui rassemble plusieurs entités : - Côté serveur : un objet physique (l Objet métier Distribué) un serveur proxy (Skeleton = amorce serveur ou squelette) - Côté client : une interface de l objet physique (l Interface métier Distribuée) un client proxy (Stub = amorce cliente, souche ou talon) Attention : les termes client et serveur ne réfèrent pas aux appellations classiques de programme client ou programme serveur. OD-client : c est un programme, une classe ou un objet en relation avec des OD. OD-serveur : c est un programme, une classe ou un objet fournissant des OD. Comme il arrive souvent que des programmes (i.e. des objets) aient à s échanger mutuellement des objets, chacun des programmes (i.e. des objets) est souvent à la fois OD-client et OD-serveur. On peut également parler d OD-classe, d OD-objet, d OD-méthode, d OD-interface, d OD-référence, d OD-exception, etc. Les appellations ne sont pas limitées. LA PROGRAMMATION DISTRIBUÉE PERMET : - Côté client : - de récupérer des OD-références depuis un ou plusieurs OD-serveurs, - de faire s exécuter les OD-méthodes distantes sur les OD-serveurs, - de passer les paramètres des OD-méthodes distantes en tant que : - OD (passés par référence), - types primitifs (passés par valeur), - objets (passés par valeur). - de récupérer localement les valeurs de retour des OD-méthodes distantes en tant que : - OD (reçus en passage par référence), - types primitifs (reçus en passage par valeur), - objets (reçus en passage par valeur). - Côté serveur : - de déclarer l exportation des OD instanciés sur le serveur, - de procéder à l exécution locale des OD-méthodes par appel distant, - de retourner les valeurs de retours des OD-méthodes à l appelant distant.

2 2 En Java, il existe 2 manières principales d implémenter des objets distribués : - à l aide de CORBA* (de OMG ) : destiné à des applications distribuées faisant interagir des objets Java avec d autres objets d autres langages (C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python et IDLscript). Il utilise un langage de définition d interface (IDL) qui définit les OD indépendamment des langages d origine. - à l aide de RMI* (core API Java depuis le JDK 1.1) : système d objets distribués destiné aux applications distribuées entièrement en Java. Du fait qu il est purement Java, RMI est plus simple et plus performant que CORBA. RMI est développé par JavaSoft (et non SunSoft ), il est gratuit et 100% Java. - il existe aussi d autres implémentations alternatives (souvent open-source) : NinjaRMI (de Berkley ) ou Jeremy (de ObjectWeb ). * CORBA = Common Object Request Broker Architecture * RMI = Remote Method Invocation

3 3 LE FRAMEWORK : REMOTE METHOD INVOCATION LE FRAMEWORK RMI : C est un système d objets et d outils permettant l appel de méthodes entre objets Java s exécutant sur des Machines Virtuelles Java (JVM) différentes. INFORMATIONS GÉNÉRALES : - un couple (OD-client, OD-serveur) communique par l intermédiaire de : - deux instances de JVM sur une même machine (processus différents), - deux instances de JVM sur 2 machines distantes (via un réseau) ; - les espaces d adressage des JVM sont distincts (gestion mémoire et GC distincts) ; - les échanges réseau se font à l aide d un protocole propriétaire qui utilise la sérialisation sur le port 1099 : JRMP (Java Remote Method Protocol) ; - RMI utilise directement les sockets ; les communications sont acheminées via des url spécifiques dites url-rmi (syntaxe : rmi://<nomserveurrmi>:<port> (par défaut : 1099) LA SUITE DE DÉVELOPPEMENT RMI : - le Framework RMI : - java.rmi (classes et une interface pour les OD-clients accès aux OD) - java.rmi.server (classes et interfaces pour les OD-serveurs création des OD) - java.rmi.activation (classes et interfaces pour l activation d OD) - java.rmi.dgc (ramasse-miettes réparti qui tient compte des OD client et serveur) - java.rmi.registry (classes et interfaces pour le service de résolution de noms enregistrement et localisation des OD) - outils et services du Framework RMI : Principalement : - un générateur d amorces (rmic) (outils qui génère des amorces de classes pour les OD ; ces amorces sont des serveurs proxy qui encapsulent les OD-objets) - un serveur de noms (rmiregistry) (outils et service de résolution de noms qui enregistre, maintien et fournit les références distantes aux OD) - un démon d activation (rmid) (service d activation d OD, démon qui permet de n activer des OD qu au moment où leurs OD-méthodes sont invoquées par un OD-client) - un RMI garbage collector (dgc) (service de ramasse-miettes étendu aux OD, démon qui permet de maintenir les objets en vie tant qu il existe au moins une référence soit du côté OD-serveur, soit du côté OD-client) et aussi : - un protocole réseau RMI (JMRP) (service de protocole pour les échanges réseau RMI ; utilise le protocole propriétaire (Java Remote Method Protocol) sur le port 1099 par défaut) - une architecture de liaison RMI (UnicastRemoteObject) (architecture RMI qui supporte la liaison de type POINT à POINT, i.e. unicast) - un service de sécurité RMI (RMISecurityManager) (service qui gère la sécurité des accès aux OD-objets) - un service de téléchargement RMI (RMIClassLoader) (service de téléchargement dynamique de byte-code depuis les OD-serveurs vers les OD-clients)

4 4 ARCHITECTURE RMI OD-client OD-serveur Amorce client Stub* Couche de transport (Socket + Protocole JMRP) Amorce serveur Skeleton* Service de résolution de noms rmiregister (sous JNDI) * Génération dynamique depuis JDK 1.5 Les amorces (Stub/Skeleton) Pour chaque OD, elles définissent les SERVICES NÉCESSAIRES À L OBJET DISTANT, ce qui incorpore les propriétés de son OD-interface et de leurs implémentations : - Côté client : le Stub est un serveur proxy qui : - représente la classe vraie de l OD (invisible du client car l OD ne peut être vu qu au travers de son OD-interface), - permet que soit invoqué une OD-méthode sur lui-même avec une signature identique à celle de l objet métier, - effectue le pliage (marshalling) des paramètres d appel de l OD-méthode, - transmet l appel distant via java.lang.reflect.method, - retourne le résultat via un ObjectInput après dépliage, - peut générer des exceptions RemoteException (NoSuchMethodException, UnexpectedException ou UnmarshalException). - Côté serveur : le Skeleton est un serveur proxy qui : - représente une classe intermédiaire d invocation de l OD-méthode (invisible du serveur qui ne peut voir que l OD-interface ou l OD-classe), - effectue le dépliage des paramètres d appel de l OD-méthode, - invoque l appel distant via une table de méthodes associée à l ODinterface, - récupère lé résultat de l OD-méthode et en effectue le pliage, - retourne le résultat via un ObjectOutput, - peut générer des exceptions RemoteException (SkeletonMismatchException, MarshalException ou UnmarshalException).

5 5 À PROPOS DE LA SÉRIALISATION (marshalling/unmarshalling, pliage/dépliage) : Pour que des objets puissent passer via un flux de données ObjectStream, il leur faut implémenter soit l interface java.io.serializable (qui sérialise automatiquement) soit l interface java.io.externalizable (qui effectue sa propre sérialisation). Ce doit être le cas pour : tous les OD, tous les paramètres des OD-méthodes, et pour tous les objets retournées par les OD-méthodes. La plupart des classes de java.lang et java.util. sont Serializable. À PROPOS DES EXCEPTIONS (java.rmi.remoteexception) : Toutes les OD-méthodes doivent être déclarées comme throws RemoteException au niveau de leurs interfaces, sinon la génération des amorces échouera. GÉNÉRATION DES AMORCES À L AIDE DE L OUTIL rmic : Pour générer les amorces, il faut partir de la classe compilée de l OD-objet : amorces : >rmic -d $HOME/classes ODInterfaceImpl.class Doit avoir accès à l OD-interface compilée : ODInterface.class Remarque : Les amorces sont générées dynamiquement par la JVM depuis la version 1.5 : (ATTENTION : information non vérifiée ; voir la doc Java de la classe UnicastRemoteObject) si la propriété système java.rmi.server.ignorestubclasses est vraie, les amorces sont construites dynamiquement.

6 6 Le service de résolution de noms (rmiregistry) CE SERVICE EST ASSURÉ PAR LE PROGRAMME rmiregistry (disponible avec le JDK). Son rôle est de maintenir un catalogue des OD (exportés par l OD-serveur) qu il gère dans un espace de noms. Il associe les OD aux références distantes. Il utilise le protocole JMRP (Java Remote Method Protocol) qui utilise le port 1099 par défaut. IL POSSÈDE UNE INTERFACE DE SERVEUR DE NOMS : public interface Registry extends Remote { // accessible à distance // méthodes pour l OD-serveur void bind (String name, Remote obj) ;// enregistre la référence distante obj sous name void rebind (String name, Remote obj) ; // écrase l ancien enregistrement void unbind (String name) ; // supprime l enregistrement // méthodes pour l OD-client Remote lookup (String name) ; String[] list () ; // renvoie une référence distante // liste les OD présents LE DÉMARRAGE DU SERVICE : Il ne doit être lancé qu une seule fois par JVM pour tous les OD. Il doit être lancé avant les OD-serveur et OD-client : - soit manuellement : >rmiregistry& ou >rmiregistry <port>& - soit par programme : à l aide de la classe java.rmi.registry.locateregistry try { // rattraper les exceptions qui peuvent survenir // Créer un service de résolution de noms pour la JVM courante LocateRegistry.createRegistry (1099) ; // Port par défaut catch (RemoteException e) {

7 7 RETROUVER UN SERVICE DE RÉSOLUTION DE NOMS ET L UTILISER : Il y a deux méthodes : 1) avec la classe LocateRegistry qui fournit aussi des méthodes getregistry en static pour retrouver le service, try { // Retrouver le service de résolution de noms de RMI Registry registry = LocateRegistry.getRegistry (hostname) ; // Si côté SERVEUR, on peut ENSUITE enregistrer une référence distante // Enregistre la référence distante (Stub) dans le service de résolution registry.bind ("Bob", odcompte) ; // Si côté CLIENT, on peut ENSUITE demander une référence à l OD distant // Demande une référence à l OD distant vers le compte de Bob ODCompte odcompte = (ODCompte) registry.lookup ("Bob") ; // cast! catch (RemoteException e) { 2) (PLUS SIMPLE) avec la classe Naming de java.rmi qui fournit les mêmes méthodes que Registry mais en static et qui ne nécessite pas de retrouver le service avant. try { // Si côté SERVEUR, on peut IMMÉDIATEMENT enregistrer une référence distante // Enregistre le nom et la référence distante (Stub) dans le service de résolution Naming.rebind ("rmi://" + hostname + "/Bob", odcompte) ; // url-rmi*/nomod! // Si côté CLIENT, on peut IMMÉDIATEMENT demander une référence à l OD distant // Demande une référence à l OD distant vers le compte de Bob ODCompte odcompte = (ODCompte) Naming.lookup // cast! ("rmi://unemachine/bob") ; // url-rmi*/nomod! catch (RemoteException e) { * Une url-rmi est de la forme : rmi://<nomserveurrmi>:<port> (port par défaut = 1099) À MÉDITER : Tout OD-serveur qui utilise le Registry est client du Registry! La couche de transport réseau TCP Elle transporte un message entre deux JVM.

8 8 Un exemple d OD-serveur 1) ÉCRITURE D UNE OD-INTERFACE DE SERVICE - Interface Java normale - Doit étendre java.rmi.remote - Toutes les méthodes doivent lever java.rmi.remoteexception import java.rmi.remote ; import java.rmi.remoteexception ; public interface ODCompte extends Remote { // accessible à distance public String gettitulaire ( ) throws RemoteException ; public double solde ( ) throws RemoteException ; 2) ÉCRITURE D UNE OD-CLASSE IMPLÉMENTANT L OD-INTERFACE - Classe Java normale - Les constructeurs doivent lever java.rmi.remoteexception (au minimum, un constructeur vide qui lève java.rmi.remoteexception) public class ODCompteImpl implements ODCompte { private String proprietaire ; private double solde ; public ODCompteImpl (String proprio, double solde) throws RemoteException { this.proprietaire = proprio ; this.solde = solde ; public String gettitulaire ( ) throws RemoteException { return this.proprietaire ; public double solde ( ) throws RemoteException { return this.solde ; 3) LANCEMENT DE L OD-SERVEUR - hostname est le nom de machine sur lequel se trouve le serveur de noms - ATTENTION : Le programme tourne tant que odcompte est enregistré dans rmiregistry! Pour qu il s arrête, il faut supprimer tous les enregistrements d OD : UnicastRemoteObject.unexportObject ( odcompte, false) ; où false : attend la fin du traitement des requêtes ; true : immédiat public class ODCompteServeur { // lance l OD-serveur public static void main (String[] args) { // Création et installation du manager de sécurité System.setSecurityManager (new RMISecurityManager ( )) ;

9 9 try { ODCompte odcompte = new ODCompteImpl ("Bob",5000.0) ; // créer l OD-objet (car ODCompteImpl n est pas UnicastRemoteObject) // Exporte odcompte dans rmiregistry UnicastRemoteObject.exportObject (odcompte) ; ou directement avec : // Trouve le service de résolution de noms de RMI Naming.bind ("rmi://" Registry registry = LocateRegistry.getRegistry (hostnameserver) ; + hostnameserver // Enregistre le nom et la référence distante (Stub) dans le service de résolution + "/Bob", odcompte) ; registry.bind ("Bob", odcompte) ; catch (Exception e) { // Exception si bind(), RemoteException si rebind() * Une url-rmi est de la forme : rmi://<nomserveurrmi>:<port> (port par défaut = 1099) Remarque : ON PEUT SE PASSER D AVOIR À ENREGISTRER odcompte, il faut alors que ODCompteImpl dérive la classe UnicastRemoteObject comme ceci : public class ODCompteImpl extends UnicastRemoteObject implements ODCompte { idem Un exemple d OD-client 4) TROUVER ODCompte et INTERAGIR AVEC LUI - hostname est le nom de machine sur lequel se trouve le serveur de noms public class ODClient { // lance l OD-client public static void main (String[] args) { // Création et installation du manager de sécurité System.setSecurityManager (new RMISecurityManager ( )) ; try { ou directement avec : Naming.lookup ("rmi://" + hostnameserver + "/Bob") ; // Trouve le service de résolution de noms de RMI Registry registry = LocateRegistry.getRegistry (hostnameserver) ; // Demande une référence à l OD distant vers le compte de Bob ODCompte odcompte = (ODCompte) registry.lookup ("Bob") ; // cast! // Utilise le compte System.out.println ("Bob possède " + odcompte.solde() + " euros") ; catch (Exception e) { // et non RemoteException à cause de lookup()

10 10 Compilation CÔTÉ SERVEUR : 1- Compiler les 3 fichiers normalement - OD-interface : >javac ODCompte.java - OD-classe : >javac ODCompteImpl.java - OD-serveur : >javac ODCompteServeur.java Options : classpath ${INPUT DIR FILE d ${OUTPUT DIR FILE -verbose 2- (si JDK < 1.5) Créer les amorces à partir de la classe compilée de l OD-objet : amorces : >rmic ODCompteImpl Doit avoir accès à ODCompte.class ; il génère le fichier ODCompteImpl_Stub.class Ne pas donner le nom complet ODCompteImpl.class mais ODCompteImpl Options : classpath ${INPUT DIR FILE d ${OUTPUT DIR FILE -verbose Non nécessaire si le STUB est chargé dynamiquement (cf. Chargement dynamique des amorces). 3- Lancer le service de résolution de noms sur la machine hostname : rmiregistry : >rmiregistry& Doit avoir accès à ODCompte.class Option : <Numéro de port>, ex : rmiregistry 1099& 4- Lancer l OD-serveur sur n importe quelle machine : OD-serveur : >java ODCompteServeur Doit avoir accès à ODCompte.class, ODCompteImpl.class et ODCompteServeur.class Option : classpath ${INPUT DIR FILE CÔTÉ CLIENT : 5- Recopier le fichier ODCompteImpl_Stub.class sur la machine hostname : Il doit être placé dans les dossiers correspondant à ses packages sur le serveur depuis la racine des packages de l application cliente. Non nécessaire si le STUB est chargé dynamiquement (cf. Chargement dynamique des amorces). 6- Lancer le service de résolution de noms sur la machine hostname : rmiregistry : >rmiregistry& Doit avoir accès à ODCompte.class Option : <Numéro de port>, ex : rmiregistry 1099& 7- Lancer l OD-client sur n importe quelle machine : OD-client : >java ODClient Doit avoir accès à ODClient.class et ODCompte.class et ODCompteImpl_Stub.class Option : classpath ${INPUT DIR FILE ATTENTION : si une application Java contient des packages, il faut que : - ${INPUT DIR FILE et ${OUTPUT DIR FILE soient les répertoires racines des packages - les noms des fichiers à compiler ou à exécuter soient donnés sous leur forme complète, i.e. avec leur chemin de package

11 11 ATTENTION : si le port n'est pas autorisé, l'application peut terminer avec les messages suivants : * access denied (java.net.socketpermission :1099 connect,resolve) * access denied (java.net.socketpermission :1XXX accept,resolve) SOLUTION : >>> DANS UN DES FICHIERS suivants : * ${java.home/lib/security/java.policy ou ${user.home/.java.policy (attention au point devant!) >>> AJOUTER les deux lignes en gras : //default permissions granted to all domains grant {...CONSERVER CE QUI EST DÉJÀ PRÉSENT ICI... // allows ME to accept, connect, resolve on privileged ports permission java.net.socketpermission "localhost:1024-", "accept,connect,resolve"; ;

12 12 Passage des paramètres et des valeurs de retour Des transferts d objets entre OD-client et OD-serveur surviennent lorsque le client invoque un appel à une OD-méthode : - celui-ci fournit des paramètres, - puis il récupère une valeur de retour. Des règles régissent le type de passage de ces données. Java choisit automatiquement si un paramètre ou une valeur de retour est passé par copie ou par référence selon le principe suivant : - PASSAGE PAR COPIE si c est : - un type primitif (int, float, double, boolean, ), - un objet qui implémente soit l interface java.io.serializable soit l interface java.io.externalizable, et sans implémenter java.rmi.remote. - PASSAGE PAR RÉFÉRENCE si c est : - un objet (OD) qui implémente java.rmi.remote. ATTENTION : dans tous les autres cas, une exception MarshalException est levée (ni type primitif, ni Remote, ni Serializable, ni Externalizable). CONSÉQUENCES : - tout OD qu il soit receveur, paramètre ou encore valeur de retour d un OD-message, est partagé entre l OD-serveur et ses OD-clients (en particulier, toute modification d un OD sera immédiatement répercutée durablement sur l OD-serveur lui-même et sur tous les OD-clients) - tout paramètre ou valeur de retour non-od est recopié avant d être transmis (l OD-serveur et les OD-clients travaillent donc sur des versions locales de ses données. En particulier, toute modification d une telle donnée NE SERA PAS répercutée durablement chez les OD-appelants) OD-méthodes vues par les OD-clients Les OD-clients ne voyant leurs OD-objets qu au travers d OD-interfaces ne peuvent accéder qu aux OD-méthodes de l OD-interface. Par exemple, les OD-clients n accèdent pas aux méthodes de java.lang.object de leurs OD-objets qui n auraient pas été masquées par l OD-interface. Lorsque la nécessité s en fait sentir, il faut procéder au masquage dans l OD-interface même s il ne s agira d invoquer que la super-méthode à l aide de super() dans les implémentations. Par contre, il n y a aucune restriction pour un OD-serveur d invoquer ces méthodes si ce n est qu il lui faudra préalablement effectuer une coercion (cast) sur la classe de son OD-object.

13 13 Architecture de liaison UnicastRemoteObject Actuellement, l architecture RMI n est prévue que pour supporter une liaison de type POINT à POINT, i.e. unicast. La classe UnicastRemoteObject supporte le référencement «point à point» d objets distribués (à travers l invocation, les paramètres et les résultats des OD-méthodes) utilisant des flux TCP. LANCEMENT d un RMISecurityManager CÔTÉ SERVEUR // Création et installation du manager de sécurité System.setSecurityManager (new RMISecurityManager ( )) ; IL FAUT COMMENCER PAR LANCER UN SERVICE DE RÉSOLUTION DE NOMS : - soit manuellement : >rmiregistry& ou >rmiregistry <port>& - soit par programme : à l aide de la classe java.rmi.registry.locateregistry // Créer un service de résolution de noms pour la JVM courante LocateRegistry.createRegistry () ; // Port par défaut : 1099 ou LocateRegistry.createRegistry (portserveur) ; // Port par défaut SI L OD-OBJET EST UN UnicastRemoteObject : Il est automatiquement exporté. Un constructeur adéquat de l OD-objet permet de choisir comment il sera exporté en fonction de l invocation du super constructeur (similairement à l encadré ci-dessous). SI L OD-OBJET N EST PAS UN UnicastRemoteObject : Il faut commencer par l exporter : // Exporte odcompte dans rmiregistry UnicastRemoteObject.exportObject (odcompte) ; ou UnicastRemoteObject.exportObject (odcompte, portserveur) ; Remarque : l usage de la méthode UnicastRemoteObject.exportObject(Remote od, int port) permet de bénéficier du chargement dynamique du STUB de l OD (même avec le port 1099) à la condition qu un RMISecurityManager ait été lancé côté serveur. Il n est donc plus nécessaire de le compiler à l aide de rmic. Si le port 0 est fourni, un port anonyme (aléatoire et libre) est utilisé. À l inverse, la méthode UnicastRemoteObject.exportObject(Remote od) assume que le STUB de l OD ait été compilé par rmic et soit accessible sur le serveur. ENSUITE L OD-OBJET PEUT ÊTRE ENREGISTRÉ : - Soit directement à l aide de la classe Naming :

14 14 // Enregistre le nom et la référence distante dans le service de résolution directement! Naming.bind ("rmi://" + hostname[:portserveur] + "/Bob", odcompte) ; REMARQUE : Il peut être judicieux de donner le nom de l OD avec une racine spécifique (ex : "/samplecomptes.bob"). Ceci pour éviter les conflits de noms dans le registry. -Soit à l aide du Registry et de la classe LocateRegistry : // Trouve le service de résolution de noms de RMI Registry registry = LocateRegistry.getRegistry () ; ou Registry registry = LocateRegistry.getRegistry (portserveur ) ; // Enregistre le nom et la référence distante (Stub) dans le service de résolution registry.bind ("Bob", odcompte) ; CÔTÉ CLIENT IL FAUT COMMENCER PAR LANCER UN SERVICE DE RÉSOLUTION DE NOMS : - soit manuellement, soit par programme (comme précédemment mais avec le portclient). UNE RÉFÉRENCE à L OD-OBJET PEUT ÊTRE RÉCUPÉRÉE : - Soit directement à l aide de la classe Naming : // Demande une référence à l OD distant vers le compte de Bob ODCompte odcompte = (ODCompte) Naming.lookup ("rmi://" + hostname[:portserveur] + "/Bob") ; -Soit à l aide du Registry et de la classe LocateRegistry : // Trouve le service de résolution de noms de RMI Registry registry = LocateRegistry.getRegistry () ; ou Registry registry = LocateRegistry.getRegistry (portclient ) ; // Demande une référence à l OD distant vers le compte de Bob ODCompte odcompte = (ODCompte) registry.lookup ("rmi://" + hostname[:portserveur] + "/Bob") ; Le RMISecurityManager GESTIONNAIRE DE SÉCURITÉ DU RMI (java.rmi.rmisecuritymanager) : C est le gestionnaire de sécurité par défaut pour RMI. - il doit être absolument utilisé pour les APPLICATIONS JAVA STANDALONE. - pour les APPLETS, c est l AppletSecurityMAnager (par défaut) qui s en charge. RÔLE DU RMISecurityManager : - il vérifie la définition des classes et autorise seulement les passages des arguments et des valeurs de retour des OD-méthodes. - il ne prend pas en compte les signatures éventuelles des classes

15 15 Chargement dynamique des amorces DISPONIBILITÉ DES AMORCES À LA COMPILATION : Un OD-client ne peut utiliser un OD-objet qu au travers des amorces. Mais RMI permet l utilisation des OD-objets dont les amorces ne sont pas disponibles au moment de la compilation. À l exécution, RMI réclamera à l OD-serveur l amorce cliente manquante et la téléchargera dynamiquement (byte-code). Le RMIClassLoader n autorise pas le téléchargement dynamique d amorces tant que l application serveur n utilise pas de SecurityManager pour les vérifier. Remarque : l usage de la méthode UnicastRemoteObject.exportObject(Remote od, int port) permet de bénéficier du chargement dynamique du STUB de l OD (même avec le port 1099) à la condition qu un RMISecurityManager ait été lancé côté serveur. Il n est donc plus nécessaire de le compiler à l aide de rmic. Si le port 0 est fourni, un port anonyme (aléatoire et libre) est utilisé. A l inverse, la méthode UnicastRemoteObject.exportObject(Remote od) assume que le STUB de l OD ait été compilé par rmic et soit accessible sur le serveur. Chargement dynamique des autres fichiers de classes PLUS GÉNÉRALEMENT : RMI permet le téléchargement dynamique : - des classes d amorces distantes - des interfaces distantes des arguments des OD-méthodes - des classes distantes des arguments des OD-méthodes - des classes distantes des valeurs de retour des OD-méthodes SERVICE DE CHARGEMENT DYNAMIQUE DE CLASSES : RMI est doté d un chargeur dynamique de classes pour réaliser les opérations de téléchargement : java.rmi.server.rmiclassloader. SÉCURITÉ DU RMIClassLoader : Le RMIClassLoader n autorise pas le téléchargement dynamique de classes tant que l application serveur n utilise pas de SecurityManager pour les vérifier. Dans ce cas, seules les classes situées dans le CLASSPATH peuvent être récupérées.

16 16 Un dernier exemple : un service de calculatrice L INTERFACE : 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; L IMPLÉMENTATION : public class CalculatorImpl extends java.rmi.server.unicastremoteobject implements Calculator { // When deriving UnicastRemoteObject, // implementations must have an explicit constructor // in order to declare the RemoteException exception public CalculatorImpl() throws java.rmi.remoteexception { super(1099); 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; LE SERVEUR : public class CalculatorServer { public CalculatorServer() { try { Calculator c = new CalculatorImpl(); Naming.rebind("rmi://localhost:1099/CalculatorService", c); catch (Exception e) { System.out.println("Trouble: " + e); public static void main(string args[]) { new CalculatorServer();

17 17 LE CLIENT : public class CalculatorClient { public static void main(string[] args) { try { Calculator c = (Calculator) Naming.lookup( "rmi://localhost:1099/calculatorservice"); System.out.println( c.sub(4, 3) ); System.out.println( c.add(4, 5) ); System.out.println( c.mul(3, 6) ); System.out.println( c.div(9, 3) ); catch (MalformedURLException murle) { System.out.println("MalformedURLException"); System.out.println(murle); catch (RemoteException re) { System.out.println("RemoteException"); System.out.println(re); catch (NotBoundException nbe) { System.out.println("NotBoundException"); System.out.println(nbe); catch ( java.lang.arithmeticexception ae) { System.out.println("java.lang.ArithmeticException"); System.out.println(ae); LA COMPILATION : LE LANCEMENT : Rmiregistry 1099 java c CalculatorServer java c CalculatorClient LA SORTIE : si tout va bien, cela produit la sortie suivante :

18 18 EXERCICE Voici deux OD-interfaces : package credit.rmiserveur; import java.rmi.*; public interface CreditCard extends Remote { public float getcreditline () throws RemoteException; public void makepurchase (float amount, int signature) throws RemoteException, InvalidSignatureException, CreditLineExceededException; package credit.rmiserveur; import java.rmi.*; public interface CreditManager extends Remote { /** recherche le compte bancaire d une personne (le crée s il n existe pas) */ public CreditCard findcreditaccount (String customer) throws RemoteException, DuplicateAccountException ; public CreditCard newcreditaccount (String newcustomer) throws RemoteException; Créez une application de gestion de compte bancaire de sorte qu un responsable, placé sur une machine distante, puisse gérer plusieurs comptes clients tandis que ceux-ci sont interrogés et manipulés par les clients. Vous utiliserez deux packages : credit.rmiserveur et credit.rmiclient.