File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RMI registry and remote object in different machines

 
kendrew
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I learn from the RMI documents that the client, RMI registry and remote
objects can be in 3 different machines. But I searched the web but could not find any real case of this. All tutorials and examples are doing the registry+remote objects in one machine and the client in another (or all 3 in 1 machine). Did anyone really do it in 3 machines successfully?
Ken
 
Ken Krebs
Ranch Hand
Posts: 451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ken,
Welcome to Javaranch.
I haven't done this myself but I think you could do it by:
On the machine where your remote object exists,
1. Use the static method LocateRegistry.getRegistry(host, port) to find the registry you want to bind to on another machine.
2. Call rebind(name, obj) on the returned registry to bind your server object on the other machine's registry.
 
Chris Shepherd
Ranch Hand
Posts: 286
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, thanks Ken #1 for the question, and Ken #2 for the answer. I knew I had seen that ability mentioned somewhere, but I could never figure out how to do it since, as Ken1 said, there isn't much out there on how to actually do it.
Gold star for the both of you!
Chris
 
kendrew
Greenhorn
Posts: 2
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ken and Chris for replies.
But I thought and verified that a program in host A cannot simply bind its object (in host A) to the RMI registry in host B. This is because the RMI registry does not allow binding other than the local host. The exception is:
Exception in thread "main" java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.AccessException: Registry.Registry.rebind disallowed; origin /192.168.0.89 is non-local host
... other exception deleted...
Actaully, there can be a complicated way to get around this:
- In host A (for registry): run the RMI registry, and run a remote object server program, say class MyRegisterImpl, with a remote method, say myRebind(), which provide a binding serice. This object is binded to real RMI registry in host A, and it acts as an agent for the real RMI registry.
- In host B (for remote server): run a remote object server, say class MyServerImpl, which lookup the MyRegisterImpl class and invokes the myRebind() method to bind itself (MyServerImpl) to the RMI registry in host A.
- In host C (for client): run a program, say class Client, which lookup the MyServerImpl object from the RMI registry in host A, and invokes the service.
I tried this in programs, and it worked.
The questions are:
1. Is there an easier way to get around the restriction that RMI registry only allow binding in local host?
2. Is there anyone really do this thing in real systems (i.e. RMI registry, remote server object, client in 3 separate machine)?
3. Does the JNDI server(?) (instead of RMI registry) have such a restriction of only allowing binding in local host?
Ken
 
Chris Shepherd
Ranch Hand
Posts: 286
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, you pretty much arrived at the same conclusion I had before Ken2's post.
I figured that I could just send the IP address of the real server(B) to A to hold and could serve it to C on demand. Host C would then turn around and use the served IP to contact B directly. That should work fine as long as A is on a publicly accesible network(or at least accesible to C).
You could also run a blind server setup which would make B act as the true server to C, but would really pass all requests from C on to A and then hand back the results to C once A had supplied them.
I have never had to use this "3 ring circus" of a setup before, but I can see possible reasons why someone would want to.
Say if A was a database machine that you wanted to keep secure, then you keep it on a private network that B has access to and you run my second solution.
Or, if A was a mobile machine for some reason with a changing IP, then either of the two solutions would work.
Ah well, glad you figured out how to make it work.
Chris
 
Chris Shepherd
Ranch Hand
Posts: 286
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, had another post spark this thought. See if you can use LocateRegistry.getRegistry(<args here> to get a reference on A to the registry on B. Then try your rebind on the returned registry. I think that might work.
Chris
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic