Any time you have a function that requires some large centralized computing power or some expensive resource (a huge database for example), but your output needs to be many places where such a workload can't be deployed then you would look at Remote Method Invocation. Consider the web, you don't have a copy of Google on your desktop for any search you may want to compute, you remotely invoke Google's servers the instant you want a result. RMI is a protocol/system for distributing your application across servers and separating out clients that need access to the results of that code.
RMI can also act as a way to secure aspects of your application (like a proprietary algorithm). RMI is not the only approach, you can also use HTTP, SOAP, etc. Many of these other approaches offer other things like true language transparency, easier and more efficient implementations, and better decoupling.
Here is the stated goals of RMI from the documentation
The goals for supporting distributed objects in the Java programming
language are:
- Support seamless remote invocation on objects in different virtual machines
- Support callbacks from servers to applets
- Integrate the distributed object model into the Java programming language in a natural way while retaining most of the Java programming
language's object semantics
- Make differences between the distributed object model and local Java platform's object model apparent
- Make writing reliable distributed applications as simple as possible
- Preserve the type-safety provided by the Java platform's runtime environment
- Support various reference semantics for remote objects; for example live (nonpersistent) references, persistent references, and lazy
activation
- Maintain the safe environment of the Java platform provided by security managers and class loaders Underlying all these goals is a
general requirement that the RMI model be both simple (easy to use)
and natural (fits well in the language).
