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?
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!
subject: Serving RMI without lookup - working, but why?