Partage
  • Partager sur Facebook
  • Partager sur Twitter

petit Probléme avec RMI

Sujet résolu
22 janvier 2012 à 11:49:53

Bonjour,
j'ai un petit problème avec RMI :

j'ai deux packages client et server,
le package client contient une interface "I_object" :
package client;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface I_object extends Remote {  
    public int Add(int a,int b) throws RemoteException;
}


et une class main_client :
package client;
import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.NotBoundException;
import java.rmi.RemoteException;

/**
 *
 * @author marwen
 */
public class main_client {
    
    
    public static void main(String [] args) throws NotBoundException, MalformedURLException, RemoteException{
   
     I_object obj_distant=(I_object) Naming.lookup("rmi://localhost:1000/exemple");
   
     System.out.println(obj_distant.Add(5, 9));    
        
    }
}



pour le package server j'ai une implementation de l'interface I_object, impl_object:
package server;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;


/**
 *
 * @author marwen
 */
public class impl_object  extends UnicastRemoteObject implements I_object {
 
    public impl_object() throws RemoteException
    {}
    
    public int Add(int a,int b) throws RemoteException{
    return a+b;
    }
    
}




et enfin un main_server :
package server;

import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.NotBoundException;
import java.rmi.RemoteException;

/**
 *
 * @author marwen
 */
public class main_server {
    
    public static void main(String [] args) throws NotBoundException, MalformedURLException, RemoteException{
        impl_object obj=new impl_object();
       
       java.rmi.registry.LocateRegistry.createRegistry(1000);
      
       Naming.rebind("rmi://localhost:1000/exemple", obj);
       
    System.out.println("server is running");
    }
}


http://img15.hostingpics.net/pics/482194ddd.jpg

Mon problème ce n'est pas avec le code , mais plutot avec l'interface "I_object" , si vous avez remarqué dans l’implémentation de cette interface , "impl_object " j'ai pas mis un "import client.I_object;" pourquoi ??
justement si je met un import vers le package client , le server donc sera "lié" a ce client(cad on doit mettre toujours le package client pré le package server pour que le server puisse connaitre la structure de I_object...)
MAIS lorsque je sépare le client et le server (je met le server sur un ordinateur distant et le client chez moi ) ????
PAR CONTRE si je met "import client.I_object;" dans impl_object ça marche trés bien....
voila quelqu'un peut m'expliquer , j'ai tort ?

Merci
  • Partager sur Facebook
  • Partager sur Twitter
22 janvier 2012 à 13:43:32

Salut.

En fait comme tu l'as dit le client et le serveur doivent au moins connaitre les méthodes qui peuvent être appelées sur l'objet distant, pour ça ils doivent au moins avoir tous les deux l'interface qu'implémente ton objet distant. Après seul le serveur (celui qui appelle effectivement les méthodes sur l'objet) doit connaitre l'implémentation de l'objet et donc la classe impl_object.

Pour bien faire tu peux par exemple faire en plus de tes packages client et serveur un package "commun", que tu intègrera à la fois au client et au serveur lors du déploiement de ton application et qui contiendra toutes les interfaces de tes objets distants.

Petit détail, tu devrais lire le sujet concernant les conventions de nommage en Java.
  • Partager sur Facebook
  • Partager sur Twitter
22 janvier 2012 à 14:35:03

salut j'ai ajouté "import client.I_object;" dans la classe impl_object , j'ai démarrée le server ensuite le client et ça marche bien, a ce moment je suis sous netbeans la classe impl_object connaitre l'interface "I_object"(puisque j'ai rajouté "import client.I_object;") , Mais imaginer lors de déploiement de mon application je vais "séparer" les deux packages(aprés la génération de *.class ou *.jar) , je met par exemple le package serveur chez mon ami , et le client chez moi , mais la le serveur lorsqu'il arrive au niveau de "import client.I_object;" hop une exception est levée :colere2: . c'est ça mon soucis.



Citation : iM@x

Salut.

un package "commun", que tu intègrera à la fois au client et au serveur lors du déploiement de ton application et qui contiendra toutes les interfaces de tes objets distants.



et comment je puisse les séparer lors le déploiement ??
  • Partager sur Facebook
  • Partager sur Twitter
22 janvier 2012 à 18:31:19

Par exemple en créant 2 programmes (2 projets Netbeans), 1 client et 1 serveur, et dans ce cas avec les packages tu n'auras aucune difficulté à faire ces deux programmes distincts.

Sinon il doit être possible de spécifier quels packages intégrer au programme quand on crée un jar.

L'idée est juste d'avoir des programmes aussi légers que possible, sans classes inutiles, mais si tu fais des petits programmes pour découvrir RMI ce n'est pas un vrai problème.
  • Partager sur Facebook
  • Partager sur Twitter
22 janvier 2012 à 22:37:04

Bonsoir,
bon aprés des heures de recherche et de tests , j'ai trouvé la réponse , je partage la sol pour ceux qui ont le même pb:

on peut créer un seul projet contient deux packages Client/serveur (c'est mon cas déjà), et lors de déploiement :
pour le serveur on a besoin de( la class main de serveur , l'interface de l'objet distant , l'implémentation de l'interface ) tu peut supprimer les autre *.class (comme par exemple le XXXstub.class et la class main du client ) ,
#MAIS attention il faut garder l'emplacement de ces fichiers aprés la compilation, sinon tu aura une erreur qui insulte en anglais ^^
pour le client( la class main du client , l'interface du l'objet distant et le xxxstub.class).

j'ai testé ceci localement sur une seul JVM , j'ai pas un autre pc pour le moment...
quelle sont les problèmes qu'ils peut me rencontrer ??
c'est quoi le " policy file " ? ce fichier est obligatoire ou c'est une question de sécurité ??*


MERCI pour le support ^^


EDIT: résolu ^^
  • Partager sur Facebook
  • Partager sur Twitter