Now blogging at diego's weblog. See you over there!

in praise of RMI

I meant to write this sooner; now I'm running a long test on an algorithm and I've got some time; so here it goes.

Ever since Java RMI got released, it was derided by critics at all levels. Too slow, they said. Hides too many of the details, they said. Does not hide enough, said others. And everyone hated those checked RemoteExceptions. In my experience, however, all of those complaints are baseless, or simplymiss the point.

Not to boast >grin< but I was one of the first people to actually write a useful application in RMI (See this Sun list of applications--the one I wrote was the real time collaboration server for dynamicobjects' perspectives, and btw, dynamicobjects was not a corporation, it was a development group of me and three friends, but we were labeled as a "corporation" for some reason). When I wrote the application RMI had just been released, and, even then, it just worked. And it worked well. Of course, the context in which it worked was a LAN. Forget about the internet--too much latency. Problems with firewalls. Etcetera.

Since then, RMI has become a lot better: IIOP interoperability, proxies, and a very cool automatic fallback mechanism that defaults to using RMI-over-HTTP when a firewall is preventing TCP communication.

The "Internet problem" still remains, though. Latencies over TCP are an issue, the marshalling/unmarshalling of the objects is partially an issue (since it increases data transfer requirements through serialization), and the fact that RMI hides so many of the connection details from the developer means that it's more difficult to create a "controlled environment" that deals properly with firewall situations, etc.

Even so, RMI is still the best choice for two tasks:

  • Prototyping of any Java networked application. Creating a network application with RMI is by far the fastest and more reliable method for getting it up and running quickly. Often, a first shot at an idea is enough to udnerstand the issues involved. Then, if the design was correct in the first place, you can just rewrite the transport mechanisms maybe even using Serialization directly over TCP sockets. This is exactly what I did recently when working on clevercactus collaboration (though it hasn't been released yet), and the process worked really well for me.
  • LAN-only applications. If the application to be deployed is LAN-only, then there is no question that RMI is the way to go. RMI is easier to debug and maintain, and it performs really well over fast, low-latency networks without firewalls.
So, in conclusion: RMI is not for everything (and no one claimed it would be, but I think a lot of the criticism comes from the misplaced expectation that it should be good for everything), but, in many cases, it's exactly what is required.

Posted by diego on August 12 2003 at 12:53 PM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37