Java RMI有什么意义？

Question

Why does Java RMI exist? Who uses it and for what?

My most pressing questions;

• Why would you want to make calls to methods that aren't defined on your machine? Wouldn't it take much longer to execute? I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
• Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides? In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer, then doesn't it get annoying to have manually contact eachother to update the interfaces on both sides for each little change?
• How is this similar or different to a typical web app set up where a client communicates with a server? In my mind, HTTP calls are much easier to understand. Can an RMI Server require some sort of password from RMI clients?
• What kind of applications are typically made using Java RMI? Any hard examples?

Answer 1

Why does Java RMI exist?

Err, because Sun built it? The same Sun that provided Sun-RPC.

Who uses it and for what?

RMI is the basis of J2EE just to name one small example. However the concept of remote method calls dates further back to at least CORBA, and the concept of remote procedure calls to at least the 1970s. Sun provided their implementation of RPC in about 1982 and it is the basis of NFS among other things.

Why would you want to make calls to methods that aren't defined on your machine?

Err, if you wanted them to run on another machine?

Wouldn't it take much longer to execute?

Of course.

I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?

So you've never heard of distributed computing, then?

Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides?

No.

In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer

Did somebody say that was a benefit?

then doesn't it get annoying to have manually contact each other to update the interfaces on both sides for each little change?

There don't tend to be many 'little changes', if you actually design your system before implementing it. But that isn't the only development model anyway. You could have a third person developing the interface. Or the same person developing both sides. Or have the remote interface defined by a specification. Or ...

How is this similar or different to a typical web app set up where a client communicates with a server?

It uses RMI instead of HTTP.

In my mind, HTTP calls are much easier to understand.

You can't get much easier to understand than a remote interface, but obviously your mileage varies.

Can an RMI Server require some sort of password from RMI clients?

Yes, it can use mutually-authenticated SSL for example, or arbitrary authentication protocols implemented via custom socket factories.