Auf Kriegsfuß mit RMI!

[macsx]

Sers!!

Also irgentwie raff ich das mit dem Rmi nidde. Die Theorie ist soweit klar. Server und RMIRegistry laufen.
Funktionieren tuts auch solange alle Klassen und Interfaces(also Server und Client) im selben Project liegen. Eines kapier ich nur nicht: Wenn ich die Clientklasse in ein anderes Projekt schiebe, funktioniert es nicht mehr.

package testpackage.neu;
import java.rmi.*;



class Client {
    
    public static void main(String[] args) {
        Server server;
        
        try {
            server = (Server)Naming.lookup("rmi://:1234/Server");
            System.out.println(server.getValue());
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }
    }

}

Er sagt mir dann ihm fehlt das Interface "Server", natürlich das liegt ja auch auf dem Server! Braucht der Client also auch das Remote-Interface in Original auf dem Rechner?

Aber es sollte doch funktionieren, weil von einem Rechner zum anderen Rechner es ja auch gehen muss.

Gruß macsx

 

[Wyatt]

Hallo!

Also ich bin kein RMI-Experte, hab bisher auch nur ein paar Tests gemacht...
Allerdings sieht meine main methode etwas anders als bei dir:

public class Client 
{ 
  public static void main( String[] args ) throws RemoteException, NotBoundException 
  { 
    Registry registry = LocateRegistry.getRegistry(); 
    Adder adder = (Adder) registry.lookup( "Adder" ); 
    System.out.println( adder.add( 47, 11 ) ); 
  } 
}

Ich hab das mal aus dem "Java ist auch eine Insel 7" kopiert, da ich mich an dem Beispiel orientiert habe.

Gruß
Felix

 

[Frozenlife]

Ja, wo sollte er denn das Interface "Server" hernehmen, wenn es in einem anderen Projekt liegt. du musst das Interface auch in das neue Projekt kopieren oder in ein eigenes Package geben und dieses Package dann im Server und Client mittels import importieren. Kenn mich zwar mit RMI nicht sonderlich aus, aber habe gerade Remoting (ähnlich wie RMI denk ich - nur in .NET) in Arbeit.

Der Sinn vom Interface liegt ja darin, Serveraktiviere Objekte ohne die Remoteklasse (deshalb leitet sich ja die Remoteklasse vom Interface ab) zu aktivieren bzw. instanzieren. Der Clientprogrammier muss nur wissen, welche Methode ihm zur Verfügung stehen.

mfg Frozenlife

 

[macsx]

Ja dieser Weg ist mir auch bekannt. Bringt soweit ich weiß das Selbe! Das funktioniert ja auch solange ich alles lokal abwickle, also solange Serverklasse und Clientklasse im selben Project liegen. Nur das ist ja nicht Sinn und Zweck von RMI.

Hast du schonmal versucht den Client in einem anderen Project zu speichern als die Serverklasse! Oder hast du gar mal versucht die RMI-Verbindung online aufzubauen, wofür es ja auch gedacht ist?! Also Serverklasse auf nem anderen Rechner.

Wie funktioniert denn die Objektbildung auf der Clientseite?

bei dir:

Adder adder = (Adder) registry.lookup( "Adder" );

bei mir:

server = (Server)Naming.lookup("rmi://:1234/Server");

Bei beiden Varianten birgt sich für mich das Problem, dass ich ja als Client im Besitz der Klasse bzw. des Interface Adder bzw. Server sein muss, um damit ein Objekt bilden zu können! Aber die Klasse/Interface liegt ja auf dem Server!! Un det schnall ich nedde!! :suspekt:

Gruß macsx

 

[macsx]

@Frozenlife

Server server = (Server)Naming.lookup("rmi://:1234/Server");

So sieht aber nun mal die Standard-Herangehensweise aus. Wobei "Server" das Remote-Interface auf der Serverseite darstellt, indem angegeben wird welche Methode zur Verfügung stehen! Und dieses Interface liegt ja nunmal auf dem Server. Der obenstehende Code ist aber für den Clienten. Das mit den import´s ist mir auch soweit bewusst. Nur wie soll ich denn das Project importieren wenn es nicht auf meinen Rechner(Client) sondern auf dem Server liegt?
Ich als Client hole mir dem dem Code:

Naming.lookup("rmi://:1234/Server");

eine Referenz auf das Objekt in der RMI-Registry. Soweit ist alles loggo!

Nur wie speichere ich denn diese Referenz wenn ich das Interface "Server" nicht besitze?!
Vielleicht so:

Object server = (Object)Naming.lookup("rmi://:1234/Server");

Oder wie?

PS.: ich möchte RMI nutzen, um Methoden aufzurufen die auf einem anderen Server liegen!!

 

[Frozenlife]

Ja, das ist mir vollkommen klar ;-). In Remoting muss ich auch das Interface in eine eigene DLL Assembly haun und diese dem Server UND Client zur Verfügung stellen. Du benötigst es - wenn du einen anderen Vorschlag hasst, kannst ihn mir gerne nennen. Nur ich habe bisher nichts gefunden.

Wie sollst du auch ohne dass du die Methoden im Client kennst, diese auch aufrufen. Es könnte zwar unter Umständen gehen, dass du - wie du es gemacht hast - statt Server als Object castest (wenn es überhaupt möglich ist) und dann mittels Reflections die Methoden lädst - damit kenne ich mich aber (noch)nicht aus.

mfg Frozenlife

 

[macsx]

Jetzt hab ich das Gefühl du hast mich verstanden!!

DLL Assembly- ehrlich gesagt sagt mir das nicht viel! In den 6 tutorials und Javabuch5 sowie Java insel 7 steht davon in Bezug auf RMI auch nichts drin. Ich glaub irgentwie nicht, dass das die richtige Lösung ist!
Aber du kannst gerne mal erklären wie's geht. Vielleicht kann ich mir daraus etwas basteln! ;-)

 

[Frozenlife]

Ja. Mittels Reflection kannst du während der Laufzeit eine nicht bekannte Klasse analysieren und deren Methoden, etc. ermitteln (denke ich mal). Ein Beispiel dazu gibts z.B. hier: http://www.java-tips.org/java-se-tips/java.lang.reflect/how-to-use-reflection-in-java.html

Weiß jetzt aber echt nicht, ob es mit RMI funktioniert. Du kannst es aber einmal probieren. Wie man dann die Klassen aufruft bzw. benutzt weiß ich jetzt leider nicht so auf die schnelle - man müsste aber sicherlich bei Google was finden.

mfg

 

[Oliver Gierke]

Lange Rede kurzer Sinn: gemeinsame Interfaces und Datentypen sollten bei Client / Server Architekturen in ein extra Jar und beiden Seiten als Dependency hinzugefügt werden.

Client -> Core (Interfaces, Datentypen) <- Server

REINHAUN!

PS: DLLs heißen in Java Jars

 

[Frozenlife]

Ja, aber mir will er ja nicht glauben das man das Interface benötigt - Und das die in dlls in java jars heißen weiß ich wohl