Deciding which framework to use really boils down to answering the following two questions:
Will the application need to communicate with applications or pieces of code that aren’t written in Java?
Would the extra CORBA infrastructure be very useful?
If the answers to both of these are strongly positive, then the application ought to be built using CORBA. If the answers to both of these are strongly negative, then RMI is the natural choice for a distribution framework.
However, there are a great deal of intermediate cases. For example, suppose that most of the application will be written in Java. It’ll have a few C++ components, either for speed or because that logic already exists, but the bulk of the code will be written in Java.
In this scenario, RMI is almost the right tool. RMI is easier to use than CORBA, has a much gentler learning curve, and is a much better fit than CORBA for most of the application. But you might wind up using CORBA anyway because you will need to integrate those C++ components somehow.
Two more reasons why you may want to use CORBA are programming language and vendor lock-in. Using RMI involves assuming that all future code that needs to communicate with your servers will also be written in Java. As much as I like Java, I find this assumption really implausible.
This scenario is one of the big motivating forces behind RMI/IIOP. The idea is this: keep as much of RMI as possible, which replaces JRMP, the RMI native protocol, ...