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.

reverse engineering: a case study

From CMU's Software Engineering Institute: Into the Black Box: A Case Study in Obtaining Visibility into Commercial Software:

We were recently involved with a project that faced an interesting and not uncommon dilemma. The project needed to programmatically extract private keys and digital certificates from the Netscape Communicator v4.5 database. Netscape documentation was inadequate for us to figure out how to do this. As it turns out, this inadequacy was intentional-Netscape was concerned that releasing this information might possibly violate export control laws concerning encryption technology. Since our interest was in building a system and not exporting cryptographic technology, we decided to further investigate how to achieve our objectives even without support from Netscape. We restricted ourselves to the use of Netscape-provided code and documentation, and to information available on the Web. Our objective was to build our system, and to provide feedback to Netscape on how to engineer their product to provide the capability that we (and others) need, while not making the product vulnerable or expose the vendor to violations of export control laws. This paper describes our experiences peering "into the black box."

Great analysis, very detailed and extremely interesting.