the significance of java RMI please?
You really should not be using RMI for any application you build today, basically for the reasons you just laid out.
In some cases (diving into legacy or "enterprise" applications) you just have no choice.
However, if you are starting a new project, other options are:
REST + JSON over HTTP
The de-facto standard for communicating to remote services. The biggest advantage it has it that it is lightweight and easy to grasp the concept.
In theory it should require more work than RMI because you have to manually craft the available URL's, accepted verbs in each URL etc. In practice, I would say that RMI's boilerplate does not really help anybody.
Sticking with java, Jersey is a brilliant library to write your own RESTful web services.
If you want a batteries included solution for RESTful web services with java, Dropwizard by the nice guys at Yammer gives you a full server and framework ready to just plug in your business logic, and provides logging, database connectivity, serialization, request routing, and even metrics gathering out of the box.
SOAP
The previous standard for communicating to remote services. Unless you have a reason to use it, I would stick to REST.
Thrift
Thrift will create a client and a server stub, basically doing much of the work. The communication is in an efficient binary protocol. It's gaining popularity in the Java world as it is used by many open source projects in the "Big Data" field. Examples, Cassandra, HBase (switching to Avro). Scrooge is a twitter project to create idiomatic thrift stubs for scala.
Akka actors
Akka is framework that implements the Actor model for Scala and Java. Includes provisions for inter-service communication, and takes care of many of the details under the hood. I
Depending on your needs, some will be more suitable than others.
RMI is for exactly the opposite case, where you want tight binding, so tight as to appear to be a local method call. If you don't want that, don't use it. The whole RPC paradigm isn't for everybody, including me, even though I wrote a book on RMI, but every tool has its uses. Java EE is built on the RMI model for example.
You are right, RMI is an example of way too-tight coupling between the service provider and service consumer. And it's even worse than it looks like at first glance: you never know what exception you may get pushed to the client side, resulting in a ClassNotFoundException that masks the real error that occurred. RMI, and similarly, EJB, are technologies of the past, a past which believed in the delusion of "transparently distributed objects".
Today's remote services are based on the complete opposite of RMI's approach: REST and JSON.
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).