RMI, CORBA and DCOM

Gregg Wonderly brings out a clear distinction among RMI, CORBA and DCOM usage in one of the tech discussion forums:

I really find it interesting that people continue to bash RMI as something to
put in the same space as CORBA and DCOM. Clearly people have used RMI in much
different/worse systems than I. Based on some of the arguments we've had here,
it seems that the biggest problems people have had with RMI are based on
misunderstandings of the technology and hence misuse of the features. A lot of
people seem to have just made every object extends UnicastRemoteObject, or used
that class to export everything, instead of looking closer and granularity. The
other falling off point is serialVersionUID and versioning overall.

One of the key things about the RMI programming model is that version #1, had
many limitations. Version #2 is present in the Jini platform, created by the
engineers who were part of the CORBA system design and development as well as
RMI. So, they know all of the issues that people waved in their faces over the
years.

The predominate arguments against RMI are always based on "granularity". With
RMI programming, you can design systems that pass big objects, no objects, small
objects, lots of text, or whatever you want. What Jini gives you in an RMI
programming model, is the ability to (with published specs and standards), plug
in any endpoint or invocation technology that you need. Thus, you can take
advantage of all the features of the Jini platform while still providing outward
interfaces using other technologies such as the web or WS-*.

CORBA is a invocation layer technology. DCOM is an operating system specific
invocation layer technology. RMI might be considered an invocation layer
technology. But, it is actually a programming model which includes something
much larger and that's mobile code. Jini expands the RMI programming model with
more features and provides services that use the underlying technologies to
really expand the possibilities.

Lumping RMI in with CORBA and DCOM, I think, really hides the power of what is
available in that programming model. In particular versioning is greatly easier
to deal with when you can exploit mobile code to allow clients to continue to
see an old version of the interface while the implementation is actually much
different. Providing this level of flexibility is what makes it possible to
grow a service with more features and still maintain backward compatibility.

Google-Maps is a great example of the use of mobile code for version control. I
have old google-maps which use old versions of their interface. I haven't had
to convert those to the new system because I download mobile javascript code
that manages that issue for me.

At some point, they might retire that support and I'll have to switch. But, the
point is that there's not an instantaneous moment where I have to be compatible
just so that they can move on to create a better system. They can do it
continuously.