问题
If i want to enable 'two way' communication in my RMI Application (That is, allow the server to invoke methods on the client, as well as the client to invoke methods on the server), is the simplest way to make the client into a Remote class as well?
Also if i intend to pass instances of my client to server as a method parameter, am i correct in thinking that there is no need to add the 'client class' to the rmiregistry?
And one final question, do all of my classes still need to be compiled in the same place? I.E can i compile server and client on two entirely independent machines and expect them to communicate properly?
* EDIT **
One more question, my question makes reference to my client interface (IClient): it has an arraylist (so i have ArrayList<IClient>) to store new instances of the client so the server can keep track of registered clients. When i attempt to compile the server on a different machine, it complains that it cant find IClient - obviously, as IClient is on the client machine. How do i get around this?
回答1:
You're right in all your assumptions.
You don't have to add your remotely callable client classes to the rmi registry but you still have to export them.
The only caveat with the compilation is that they have to be done with the same version of java with the same compiler settings (at least those affecting RMI stub generation).
回答2:
If you have any requirements that the client or server will be behind a firewall in the future deployments, stay away from RMI. You are asking for trouble. Especially if you want the server to call the client.
Here are two alternative solutions that worked well for us:
have the client call the server with the server blocking the call until data is available for the client. This uses up a thread per client (if you don't use NIO), but is easy to implement. Return null once in a while to prevent a long running call from the client to be closed by the firewall (depending on the firewall config, of course)
if you want nice java interfaces to play with, consider Hessian which is very light-weight, runs on top of HTTP and does not bother with an RMI registry or similar stuff
if you intend to open up the server side to other clients, Hessian is still a good choice, but if scaling out is a concern, look into a RESTful architectur style.
回答3:
Re your final question, the remote interface classes and all classes they depend on and so on recursively until closure must be present on both hosts.
来源：https://stackoverflow.com/questions/4808392/java-rmi-making-the-client-a-server