RMI is indeed an old (but useful) technology. It is not common much anymore as such, although I think it's probably embedded into
EJB version 3's RMIIIOP remote bean interface.
It was sort of a parallel to the definitely-dead CORBA, but with some key differences.
1. It was strictly method-oriented. CORBA attempted to present remote access to Object methods as opposed to RMI's procedural methods (this did not end well for CORBA). CORBA also did not play well with firewalls.
2. It was strictly
Java. CORBA was OS and language independent. Java RMI requires that both the client and server be running Java, althought the OS's involved are not important.
3. Most fatally, RMI employs Java Serialization. The problem with the build-in Serialization mechanism of Java is that it is opaque and subject to change. Meaning that if a Java RMI client was running a JVM release that was incompatible with the Serialization encoding of the RMI server, communications would fail. This was a royal pain.
As a better solution to CORBA and RMI,
SOAP was invented. However, SOAP's protocols were heavy (XML) AND onerous to set up. Eventually SOAP was replaced by Web Services, which serialize using simple text formats such as JSON, YAML, or even general text.
RMI remains a viable solution to this day, but only for very limited cases. It's best used strictly for in-house work only. Unlike CORBA, RMI can negotiate firewalls, but since it doesn't use popular ports like port 80, a lot of pathways from client to server might not have the RMI port open (including my own servers!). And then there are its other liabilities, as I described above.