aspose file tools*
The moose likes Distributed Java and the fly likes Does anybody can explain how RMI works? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Does anybody can explain how RMI works?" Watch "Does anybody can explain how RMI works?" New topic
Author

Does anybody can explain how RMI works?

Wojtek Thomas
Greenhorn

Joined: Nov 30, 2005
Posts: 11
Hello,
I have run such a configuration of example RMI application:

Host1:
server.jar - it server application

http://host1.local/classes/library.jar - interface of remote object

Host2:
client.jar - client application

Server runs properly only with such options:
java -cp d:\interface\library.jar;d:\server\server.jar -Djava.rmi.server.codebase=http://host1/classes/library.jar -Djava.security.policy=d:\server\server.policy app.Server

And client with following options (on another host - host2):
java -cp c:\interface\library.jar;c:\client\client.jar -Djava.security.policy=c:\client\client.policy app.Client

With other combinations of options it simply doesn't work.
And now my question:

In Sun's documentation in the codebase folder should be REMOTE OBJECT STUB, but interface IS NOT a stub. So why my example works?

And the next question: since Java 1.5 using rmic to generate remote object stub is no longer needed, so what for is the codebase?

I thought that client can download interface definition from remote server, however it's not true as well. Interface have to be in client classpath.

Remove of codebase option from server causes rise of unmarshall exception.

Can somebody explain me that all?

Regards,
Wojtek
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Wojtek,

In Sun's documentation in the code base folder should be REMOTE OBJECT STUB, but interface IS NOT a stub. So why my example works?

The server remote interface on the client side IS a stub although with current RMI implementations there's nothing very special to it. Sometimes this part is called proxy, too. The counterpart on the server side is called skeleton.
And the next question: since Java 1.5 using rmic to generate remote object stub is no longer needed, so what for is the codebase?

I thought that client can download interface definition from remote server, however it's not true as well. Interface have to be in client classpath.

The code base is exactly for automatic class downloading. Unfortunately the remote interface have to be available on the client side before because you have a compile time dependency on it and your client code won't even compile without it. But other classes which aren't directly needed for compilation are downloaded from this code base. Therefore you get an unmarshall exception at runtime because some class structure is unknown without the possibility of automatic class downloads.

I hope this helps a little bit...

Marco
Wojtek Thomas
Greenhorn

Joined: Nov 30, 2005
Posts: 11
Thanks for short explanation.

Do you know any publicly available documentation about RMI besides Sun's tutorials?

But I must disagree: interface is not a stub. Stub is an object returned by lookup() method that is referenced as interface. Stub must have any code to work as proxy to pass calls and receive results and interface doesn't contain any code.

So I don't understand why interface must be remotely accesible, when it must be accesible in the client classpath as well.

Maybe I am wrong that I try to understand it, and not just use it the way it works ;-)
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Wojtek,

you're right. The stub of an RMI object in fact isn't really the same as the remote interface. To correct this: You only use the remote INTERFACE in your RMI client code and the STUB (and the skeleton on the server side) which implements this interface is generated automatically for you by the RMI framework. So you in practice you'll only have to take care of and use the remote interface.

Unfortunately I don't know of any other RMI documentation besides the documentation you'll also find with Google. But if you don't worry about the internal details of RMI it's really not a big deal with current implementations. Almost all details of the remote communication are hidden from the programmer so you won't need a lot of documentation once you're a little bit more familiar with RMI.

Marco
[ May 28, 2008: Message edited by: Marco Ehrentreich ]
Wojtek Thomas
Greenhorn

Joined: Nov 30, 2005
Posts: 11
Thanks Marco,

So I shouldn't bother about it as long as everything works well.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Of course you are free to dig into the details of the RMI internals if you want to Perhaps it's even easier to use if you have a basic understandig of the internals. But after all RMI was created to simplify remote method calls without knowing all the details...

Marco
 
wood burning stoves
 
subject: Does anybody can explain how RMI works?