wood burning stoves 2.0
The moose likes Distributed Java and the fly likes Serving RMI without lookup - working, but why? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Serving RMI without lookup - working, but why?" Watch "Serving RMI without lookup - working, but why?" New topic

Serving RMI without lookup - working, but why?

paul wheaton

Joined: Dec 14, 1998
Posts: 20965

Another developer in my group has demonstrated serving up dozens of RMI objects with only one lookup. I look at the code and it is extremely simple. I have a hard time believing that it works. Can someone explain it to me?
He sets up an RMI object on the client and server the normal way. Let's call it RemoteControl. Inside of that is a method called getUserControl(). Inside that method is the line "return new UserControl();"
That's it! I would think it would serialize the server side implementation and the client wouldn't have a matching object, so it would croak. Instead, using this object on the client does make all the server stuff work off of the server.
Why? How?

permaculture Wood Burning Stoves 2.0 - 4-DVD set
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
These type of classes which instantiate new objects in RMI methods are called 'factory classes' and is a general industry practice. This way you avoid creating too many RMI objects on the server side.
Lucy C
Ranch Hand

Joined: Feb 09, 2000
Posts: 53
Yep, factory classes mean that you only have to register a single object with the rmiregistry. A factory class has, as you describe, at least one method that returns a server object. As this is an RMI server object, it must implement at least one interface that extends Remote. The clever bit depends on how RMI handles remote method parameters and return types: if a Remote object is returned from an RMI remote method call, what's actually returned to the caller is a stub for that object (if the returned object was Serializable, the caller would get a serialized copy instead). So when the client calls the remote getUserControl() method, it gets back a stub for the remote UserControl created on the server, just like it would get back from the rmiregistry by calling lookup. The client can then use this stub to call methods on the UserControl. Ta da!
I agree. Here's the link: http://aspose.com/file-tools
subject: Serving RMI without lookup - working, but why?
It's not a secret anymore!