aspose file tools*
The moose likes Distributed Java and the fly likes RMI Registry location Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "RMI Registry location" Watch "RMI Registry location" New topic
Author

RMI Registry location

Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Hi every body,
Is it mandatory that the RMI registry run on the same machine on which the RMI implementation is running ?
If it is actually the case, this is very bad for distributed computing.
Regards


Omar IRAQI Houssaini
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Even though many examples of using RMI assume this, there is no requirement that the RMI registry and RMI "server" implementation reside on the same machine.


-Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
NO SIR.
I have double checked for it. Now I am sure that Sun Implementation of the RmiRegistry actually does have this limitation.
If you try to bind an implementation with a remote RMIRegistry, a java.rmi.AccessException is thrown.
Please next time, when you are not sure of something, just don't reply.
Regards
[ October 16, 2002: Message edited by: Omar IRAQI ]
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12788
    
    5
Since RMI is used all over the place in J2EE where there are commonly multiple machines, and since I see plenty of references to remote registries just browsing through the RMI docs, I don't see how you came to that conclusion.
Ref: java.rmi.registry JavaDocs
Bill
Junaid Bhatra
Ranch Hand

Joined: Jun 27, 2000
Posts: 213
From the javadocs (java.rmi.AccessException):
"An AccessException is thrown by certain methods of the java.rmi.Naming class (specifically bind, rebind, and unbind) and methods of the java.rmi.activation.ActivationSystem interface to indicate that the caller does not have permission to perform the action requested by the method call. If the method was invoked from a non-local host, then an AccessException is thrown."
This is misleading & confusing. What this basically means is that the client program which binds your remote object must be on the same host as the RMI Registry. There is absolutely no limitation that the actual RMI object be on the same host as the RMI Registry. These are two very different things.
For eg:,
RMI Registry --> running on host X
Client program which binds the remote object --> must run on host X
Actual RMI object which is bound --> can be on host Y (need not be on X).
I hope this clears up the confusion!
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

These forums are open to all interested contributors. Posting a response is not formally limited only to people who can answer questions with certainty and authority.
Please try to accept any responses with the spirit in which they were intended. If you don't find a post helpful or accurate, respond with an example that clarifies or proves your point. We're all here to learn, and that process is not aided by admonishing others to keep quiet.
Sincerely,
The Management
[ October 16, 2002: Message edited by: Michael Ernest ]

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

Joined: Jul 06, 2001
Posts: 54
Salam all,
To William: J2EE uses a naming service that is completly different from the basic RMI naming service (RMIRegistry). This naming service is JNDI. So J2EE is a bad example.
To Junaid: Can you tell me how you can do this magical binding of a remote implementation from a different host?
You seem to have deep troubles in undrestanding the basics of Java, processes, address spaces, and RMI.
Regards
[ October 17, 2002: Message edited by: Omar IRAQI ]
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

JNDI is not a naming service. It is an API that masks a naming service implementation with a generic user API. A closer look will show you that Sun hooks its RMI registry through a service-provider interface (SPI) into JNDI. J2EE, in summary, is a fine example of what we are discussing here.
I also find Junaid's comments on point. In theory, there's no reason one shouldn't be able to bind a service object from one machine to an rmiregistry on a remote machine. In practice, Sun's implementation disallows this as a security risk.
Coming into this forum with bad manners and wrong facts must be worse than coming in with reasonable interpretations and good intentions. You'd think you wouldn't have to explain that to people.
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
Here is what Junaid has said:
On host X we have some process that does this :
Naming.bind("somename", someImplementation);
On host Y, we have some other process that instantiates the object someImplementation !!!
How can you find this comment on point ???
Now about the JNDI, thank u for correcting me. This is how we can improve our level, and advance.
But If we were so picky about words (services vs API to those services ...), The list of confusions from your own comments would have been "long long"
cheers
[ October 17, 2002: Message edited by: Omar IRAQI ]
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

Originally posted by Omar IRAQI:
Here is what Junaid has said:
On host X we have some process that does this :
Naming.bind("somename", someImplementation);
On host Y, we have some other process that instantiates the object someImplementation !!!
How can you find this comment on point ???

My interpretation of Junaid's is more liberal than yours, that's all. Perhaps because I know what he's trying to say I have a different view on it.
Your interpretation, by the way, is not outside the realm of reason. Jiro has a feature that allows for remote object instantation by extending the core features of RMI.

Now about the JNDI, thank u for correcting me. This is how we can improve our level, and advance.
But If we were so picky about words (services vs API to those services ...), The list of confusions from your own comments would have been "long long"

I hope it was clear that it was possible to correct your assumptions without questioning your understanding or intelligence. And without any actual "list of confusions" from you that I could try to clear up, I'll just assume you didn't like being corrected anyway. Sorry.
Junaid Bhatra
Ranch Hand

Joined: Jun 27, 2000
Posts: 213
"To Junaid: Can you tell me how you can do this magical binding of a remote implementation from a different host?"
The same way that you "magically" lookup a remote implementation running on a different host.
Ok let me try to simplify it for you.
RMI Registry --> running on host X.
Actual RMI object --> instantiated in a VM on host Y
RMI Object --> contacts a client proxy program running on host X which takes your remote object & registers it for you on your behalf in the registry
Ofcourse such a proxy circumvents the security of the registry disallowing remote bind() calls! But it's definitely possible, even in Sun's implementation today.
If you take the time & effort to read the RMI specs, nowhere does it say that the RMI implemenation must reside on the same host as the RMI Registry. That would be pretty lame in the paradigm of distributed computing. All it says is that remote bind() calls are disallowed.
There are lots of ways I can question your intelligence here, but I will refrain from doing that. I sincerely do hope that you take the sheriff's advice seriously.
[ October 17, 2002: Message edited by: Junaid Bhatra ]
Omar IRAQI
Ranch Hand

Joined: Jul 06, 2001
Posts: 54
To Junaid, Michael, and William
I am really sorry.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI Registry location