Jyotsna,
RMI allows you to invoke methods on objetcs remotely. One of the benefits of RMI is an illusionary, transparent networking. You can invoke methods on remote objects just as you would invoke a method on any other
java object. In fact, RMI completely masks whether the object you're invoking on is local or remote. So called local/remote transparency..
To mask the fact that you're invoking on an object residing on a remote host, RMI needs to somehow simulate a local object that you can invoke on. This local object is called a "Stub", and it's responsible for accepting method calls locally and delegating those method calls to their actual object implementations, which are possible located across the network.
Just as a client invokes on a stub that is local to that cleint, your remote object needs to accept calls from a skeleton that is local that remote object. Skeletons are responsible for receiving calls over the network and delegating that call to the remote object implementation (Server).
Briefly...stub acts as a proxy on behalf of the client and communicates with the Server object. And Skeleton talks on behalf of Server and hence stub and skeleton communicate with each other on behalf of client and server on network.
I don't know..whether this has cleared your doubt or raised more doubts...
Thanks,
Neelima.