What is the case for RMI? I used to do RMI before the EJB era.

Mikael Jakobsson

EJBs are (as I am sure you are aware) a framework for distributed components, handling transactions and object pooling and more.
RMI is used in this framework as the mechanism for object distribution.

An EJB application server adds more to distributed components than RMI does. The application server will handle transactions, object pooling, database connection pooling and more. This extra functionality comes at a price, performance-wise, since there are simply more things to check and handle compared to plain RMI where no such functionality exists.

Therefore, when it comes to comparing performance, EJBs can only be slower than a similar construction using RMI directly, due to the overhead introduced by the application server.

Q: But what if you code all the extra functionality yourself?

A: That depends on what your priorities are. There are at least two ways to look at this:

  • The "Pure RMI" solution would probably be faster, since it is likely to be optimized for the problem at hand. The EJB framework is a generic framework that can handle most cases where distributed components are desired. Such generic code needs to perform more checks and needs more layers of logic to handle almost any possible type of problem. These checks and extra layers will introduce some performance overhead. So if your priority is performance, the pure RMI solution will probably be the best solution. To take this to the extreme you could save some extra performance by skipping the (generic) RMI framework and go directly for the Sockets. There is definitely some extra milliseconds to spare there too.
  • The reason for using RMI instead of sockets is often that it is so much easier to distribute components via RMI. The development time is simply much shorter if RMI is used. The same holds true for the EJB vs RMI discussion. If you DO need some functionality that is provided by the application server it is much simpler and quicker to use the existing EJB framework than developing your own functionality for common problems such as DB connection pooling. Using the EJB framework is many times more cost-effective, which is an important parameter in many projects .

I think that there is no "correct answer" to this issue, but I hope the above has added some input in the debate on where and when to use what technology.