• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Serving RMI without lookup - working, but why?

 
paul wheaton
Trailboss
Pie
Posts: 21678
Firefox Browser IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic