First of all I should point out that whilst I've used RMI on a few projects and know a bit about it I'm no RMI expert.
1) The remote object actually never comes in picture whenever remote method invocations are being done.
I mean only stubs and skeletons are stealing the show (at least till Java 5). As far as i understand ,Stubs are
implementations of the Remote interface . Not sure on skeletons though. What is the advantage or reason of
providing the client with the Remote interface's stubs ? What are skeletons ? In the link mentioned they haven't
mentioned what exactly are skeletons.
The remote object is the object with the code that is run when an RMI call is made. The stub and skeleton just provide the underlying mechanism to enable you to make a remote method call and optionally to return a value.
The stub provides a local object with the same interface as the remote object. When your local code calls one of stub's methods the stub handles the communication with the remote object (possibly via a skeleton) marshaling all the parameters and unmarshaling the return value if there is one.
The skeleton is on the remote machine and provides the other end of the RMI communication. ie it unmarshals the parameters passing them to the remote object, then marshals the return value if there is one passing it to the stub.
2) Since, JAVA 2 skeletons were eliminated
(referenced from : http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/spec/rmi-arch2.html ).
If there are no skeletons to handle the incoming client requests, what is actually in place ?
It would be great if you could point me to a document link or something else.
I'm not sure of the reason as to why the skeleton is no longer needed other than the communication protocol was changed in Java 1.2.
3) Can a single registry running on a single different JVM bind to multiple remote objects running on their
respective JVM's ?
I assume you mean can remote objects on multiple JVM's all register themselves with one registry.
The simple answer is I don't know. I would have thought you could do this, the danger is though that if the JVM that created the Registry terminates then so does the Registry so you would lose RMI communication with all the remote objects in the other JVM's even though they are still running. Also you would have to make sure every attempt to bind a remote object used a unique name.