File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Distributed Java and the fly likes RMI - class loading and stubs process Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "RMI - class loading and stubs process" Watch "RMI - class loading and stubs process" New topic
Author

RMI - class loading and stubs process

Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Hi everyone
My question is about the behind the scenes of RMI. It’s just one of those things you start thinking about and then have to have answered or else it drives you crazy even though it really isn’t that important in the long run. Basically I am trying to understand the actual process that goes on behind the scenes when the client gets a remote object.
Could someone let me know if this process is correct:
On a remote system (the client and server are not on the same machine):
The client will use lookup( ) to get a remote reference.
From the registry the client gets a remote reference to an object along with the location of the class definition (the stub class) for the class.
Once the client has the byte code for the class it creates the stub on the heap in its own JVM.
Or
Does the client receive the stub with the initial remote reference it gets from the registry?
And then just place the stub on the clients local heap?
Question 2:
The location of the stub is sent to the client in the marshaled byte stream – is this done each time the client interacts with the server or is it only when the client gets the initial remote reference from the registry.
If these don’t make sense then it most likely my lack of understanding so let me know and I’ll try to clarify them a little more.


Dave
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

Answer 1: what the registry stores is a MarshalledObject; a MarshalledObject contains a serialized stub and a codebase, which hopefully directs you back to a service that the stub can talk to. The client receives these values, and by convention casts the stub back to the interface type implemented by the stub's originating class.
So the client doesn't construct a stub; it deserializes and casts the one given to it.
Answer 2: the registry itself is only a lookup service. We are asking it for a particular stub and a network address we could find its corresponding service. rmiregistry supports only stateless requests, in this context. It does not "confirm" location behind the scenes in an ongoing way (Jini lookup services do), nor does it refresh its awareness of the service's availability (again, Jini does).
Helpful?


Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Thanks Michael
That helps a lot, just to make sure I've got it right...
The client, from the lookup() method gets a MarshalledObject returned from the registry. It then uses the codebase property to get the actual class definition (byte codes) so it knows how much memory and etc to allocate for each object of that type. Then it deserializes the stub object and can use it.
The client will only use the codebase given if it can't find the class locally correct?
My instructor uses the term 'remote reference' is this synonymous with MarshalledObject in the case of the object that is returned from lookup?
Is this in one of the advanced RMI or J2EE books?
thanks again
[ March 07, 2002: Message edited by: Dave Vick ]
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

The client will only use the codebase given if it can't find the class locally correct?
That's right; if you can resolve the reference locally, you should. Dynamic stub downloading is designed not to defeat local classloading, but to make it possible to get the stub for a service you know about on the fly.
RemoteRef is a specific class; I should have used that and said "marshalled object" instead to be more specific.
The book I like that I think will help you the most is right here.
[ March 07, 2002: Message edited by: Michael Ernest ]
(Marilyn fixed url)
[ March 09, 2002: Message edited by: Marilyn deQueiroz ]
Dave Vick
Ranch Hand

Joined: May 10, 2001
Posts: 3244
Thanks again Michael
Looks like a good book - as soon as I get through some of the other ones I've got stacked up I'll probably get it - have to clear it through the wife first though
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI - class loading and stubs process
 
Similar Threads
where's the "sharpen your pencil" answer?
rmiregistry
Need to extend UnicastRemoteObject class
RMI Stubs
Not implementing the RemoteException