This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Distributed Java and the fly likes Need to extend UnicastRemoteObject class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Need to extend UnicastRemoteObject class" Watch "Need to extend UnicastRemoteObject class" New topic
Author

Need to extend UnicastRemoteObject class

carox kaur
Ranch Hand

Joined: Mar 19, 2009
Posts: 52
I have read some of the older posts here to clear my doubts...
http://www.coderanch.com/t/430129/Distributed-Java/java/Small-UnicastRemoteObject
http://www.coderanch.com/t/422569/Distributed-Java/java/UnicastRemoteObject-class-Remote-Interface
In the Sun API also its written that:
Used for exporting a remote object with JRMP and obtaining a stub that communicates to the remote object.


My question is:
1.

When we bind the object of this class in the rmi registry on server side, we do:

This binds the remote object "stub" or simply the remote object with the name "stub_object" in the rmi registry ?

2. On client side when we do:

Here the client gets the stub to the remote object according to the spec. But...
The remote object is obj. We are binding the remote object and not the stub to the registry, so the client should also get the remote object upon lookup. How does the client get the stub to the remote object, upon lookup? At what point of time stub (object) of the remote object is made- while binding the remote object to the registry or when the client does lookup?
I think I am missing something here...

3. When we are explicitly binding the remote object (dunno whether remote object is bound or stub object) to the rmi registry so that all the clients in the network can access this object then why there is need to explicitly export the remote object.
Jeff Storey
Ranch Hand

Joined: Apr 07, 2007
Posts: 230
Carox,

When an object is exported to the registry, the clients get a reference to the object stub, not to the object itself (since the object itself lives on the machine on which it was exported). Methods on the stub send a message (I believe over TCP) back to the actual object (there are a couple of layers in between, but at a high level that's about how it works). This article covers some details http://infolab.stanford.edu/CHAIMS/Doc/Details/Protocols/rmi/rmi_description.html.

Jeff


Jeff Storey
Software Developer
[url]http://jeffastorey.blogspot.com[/url]
carox kaur
Ranch Hand

Joined: Mar 19, 2009
Posts: 52
Thanks Jeff but I am sorry to say my question is still unanswered. I am not getting the right answer, don't know why. Have I asked any wrong question or broken any of ranch rule?
When an object is exported to the registry, the clients get a reference to the object stub, not to the object itself (since the object itself lives on the machine

Ya I know this. But how? when we bind the real remote object to the registry then the client should also get the real object instead of the stub to the remote object.

The remote object is obj. We are binding the remote object and not the stub to the registry, so the client should also get the remote object upon lookup. How does the client get the stub to the remote object, upon lookup? At what point of time stub (object) of the remote object is made- while binding the remote object to the registry or when the client does lookup?

Also,
When we are explicitly binding the remote object (dunno whether remote object is bound or stub object) to the rmi registry so that all the clients in the network can access this object then why there is need to explicitly export the remote object.


 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Need to extend UnicastRemoteObject class