Discussion :

[brainstorm]

Bonjour,

Voilà, je viens de finaliser un petit client/serveur RMI pour me familiariser avec cette technologie. Tout fonctionne en local mais lors du packaging de mes applications client et serveur m'arrive une question toute métaphysique :

Comment puis je faire connaitre l'interface métier implémentée sur le serveur par mon client au niveau des imports ?

Actuellement je travaille sous eclipse et j'ai donc mis une référence au projet Server dans le build path de mon client. Mais je me vois mal mettre en librairie de mon client le jar du serveur uniquement pour cette raison...

Par ailleurs, je ne sait pas si dupliquer sur le client l'arborescence des packages afin de copier sous le bon nom de package mon interface est une solution digne de ce nom.

Comment feriez vous ?

Ps : je me rends bien compte que c'est d'une lisibilité comparable à celle du bilan comptable de fin d'année d'une SSII mais je n'ai pas pu faire mieux sur le moment

Merci d'avance

Edit :

voici quelques sources si jamais ça peut aider. Je prendrais volontiers toutes remarques sur la qualité du code

Code du client :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
package client;
import java.rmi.*;
import server.HelloInterface;

public class HelloClient {
	public static void main(String[] args) {
		setSecurityManager();
		try {
			HelloInterface hello = (HelloInterface)	Naming.lookup("rmi://maMachine:1099/Hello1");
			System.out.println(hello.sayHello());
		} catch (Exception e) {
			System.err.println("Erreur client " + e);
		}
	}
	
	private static void setSecurityManager(){
		System.setProperty("java.security.policy", "client.policy");
		if (System.getSecurityManager() == null)
		System.setSecurityManager(new RMISecurityManager());
	}
}

Code serveur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
package server;
import java.rmi.*;
import java.rmi.registry.LocateRegistry;
 
public class HelloServer {
	public static void main(String[] args) {
		// TODO vérifier qu'on peut bien parmaetrer le security manager en static
		//setSecurityManager();
		try {
			LocateRegistry.createRegistry(1099);
			Naming.bind("Hello1",
					new Hello("Hello world!"));
			System.out.println("Serveur prêt!");
		} catch (Exception e) {
			System.err.println("Erreur serveur " + e);
		}
	}
 
	private static void setSecurityManager(){
		System.setProperty("java.security.policy", "client.policy");
		if (System.getSecurityManager() == null)
		System.setSecurityManager(new RMISecurityManager());
	}
}

Interface métier (localisée dans le jar du serveur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
package server;
import java.rmi.*;
 
public interface HelloInterface extends Remote {
 
	public String sayHello() throws java.rmi.RemoteException;
}

Implémentation de cette interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
package server;
import java.rmi.*;
import java.rmi.server.*;
 
public class Hello extends UnicastRemoteObject implements HelloInterface {
 
	private String message;
 
	/*constructeur*/
	public Hello(String s) throws RemoteException{
		message=s;
	}
	public String sayHello() throws RemoteException {
		return message;
	}
}

Edit 2 : changement de titre car cette problématique peut arriver sur toutes les architectures client serveur.

[gifffftane]

Il est bien evident qu'il ne faut pas mettre les jars serveur dans les jars clients et viceversa.

Il faut séparer les classes communes aux deux et en faire un jar commun. Mais cela fait, de fil en aiguille, un projet à part. J'imagine que c'est ce que tu n'as pas fait ?

Sinon il y a la classe URLClassLoader qui peut aider en ce cas.

[brainstorm]

Merci pour ces différentes pistes.

Quelle approche préfères tu entre ces deux et pourquoi s'il te plait ?

[djo.mos]

Salut,
Perso, je sépare les classes communes dans un projet séparé (donc jar séparé)
http://djo-mos.developpez.com/tutori...oting-hessian/
C'est pas exactement RMI, mais c'est à propos de remoting, et je décris là comment je procède.

[gifffftane]

Ahoulà je ne suis sûr de pas grand chose...

Perso je préfère l'approche 1 : il y a une zone commune entre client et serveur, zone qui fait l'objet d'un projet à part entière. Le problème est que client et serveur sont souvent si interdépendants qu'il est bien difficile de faire l'un sans l'autre, encore plus d'avoir un 3ème projet commun. Bref cette orthodoxie ne fait que compliquer la vie.

J'arrive à peu près à résoudre ce genre de cas grâce aux merveilles de Maven, qui me permet de jongler entre plusieurs projets sans trop de prise de tête. Le problème est de coordonner Maven avec les EDI (Netbeans pour moi), et avec le déploiement (là j'utilise Ant), mais c'est pas très au point, même s'il y a beaucoup de progrès sur ces questions.

Je n'aime pas beaucoup l'approche 2 : ces histoires de class loaders spéciaux m'ont toujours paru réservées aux structures qui ont beaucoup de personnels spécialisés qui se plaisent dans la technologie pointue.

Bref, pour moi, c'est un problème non-résolu

[brainstorm]

Problème résolu !

Je vais adopter l'approche troisième projet aidé d'Ant. Mais je ne peux m'ôter de l'esprit un sentiment de perplexité . Ceci dit, je ne vois pas comment faire autrement, même Chuck Norris serait obligé de faire pareil

Merci bien de votre aide.

[dinobogan]

même Chuck Norris serait obligé de faire pareil

Attention, pas d'hérésie
Chuck Norris serait capable de faire fonctionner le client/serveur sans code, sans machine et surtout sans électricité.
Faut pas critiquer Chuck Norris