Michi's little critique of CORBA has been stirring up a lot of press, and some good email discussions. It has made people think.

Michi co-wrote the Advanced CORBA Programming in C++ book with Steve Vinoski. This is a lovely book; it really explains what it is and how to use it. You don't come away with the same bad feelings you would get from reading a book on, say EJB2.x, which was clearly wrong. The limitations of CORBA were more subtle.

1. The standards group focused on IDL and a compatible API first, interop second. There's lots of historical reasons there, but today, does anyone care whether an early orb used Apollo/DCE or SunOS XRPC? A cross-orb solution from the outset would have been better
2. The CORBA to C++ binding of the era of Advanced CORBA Programming is pretty dated. IDL strings map to #define strings, not const string classes, the generated C++ predates generics. This is exactly the same failing that COM has. It is not fundamental with the technology; the CORBA working groups and Microsoft could each update their own bindings and IDL compilers.
3. CORBA came with too many extra complex services, some of which clearly never worked. There are other standards bodies which appear to be repeating this antipattern. We need implementation-first standards with test suites released simultaneously with the specifications, otherwise the first implementations come out without being tested properly, and the specification itself may prove to have untestable parts to it.
4. CORBA's exception model is different. Its not quite that of C++, its not that of Java. Any attempt to map seamlessly from native faults to COM isnt going to work. But that's OK, because that isnt done.
5. Persistent object routing turns out not to work well over time. It makes for great demos, but in practise once an object starts moving around, it becomes harder and harder to locate.

But wait a minute, what was the alternative of the time? DCOM. Let's look at that. (I would include links to the MSDN topics, but msdn2.microsoft.com is returning Server is too busy errors. Hosted on Dell junk, I guess, or someone is running a DDoS attack.)

1. IDL mapping to C++ sucks. Yes indeed. MFC: very bad. ATL, slightly better, but not updated for six years. Last time I did it, I used xslt mappings from our constants.xml file to generate proper constatnts and not the #defines the IDL would generate. No const classes; no namespace support. This is early nineties C++ here, not modern C++.
2. Comes with extra services, some of which never get used. Distributed Link Tracking? Sure, it comes with every NT box has it turned on, but its one of the first services to turn off at tuning-time
3. Lacks fundamental features. Like a centralised registry of things. You can configure HKEY_CLASSES_ROOT\CLSID mappings on a machine-by-machine basis to redirect to remote DCOM bindings. Yes, that's clever. Hard code remote locations for object creation, object creation that gets called by local clients expecting local objects to be returned. I bet sysadmins and developers like fielding support call related to that. Try asking an end user over the phone whether their CLSID for excel documents is mapped to a remote factory and see if you can get any useful answer.
4. Atrocious error handling. HRESULT is it for pure COM. OLE automation adds EXCEPINFO information, which you can get filled in by an extra call to an IDispatch interface. But what happens if you are trying to talk IDispatch over the wire to a DCOM object that your registry has bound to a remote machine, and it is the network that is failing. You cannot call IDispatch to get the info, because that will just try and talk over the wire. There is no way to get error info back from the transport layers than just HRESULTS. and that is just useless. Every time you see an IIS server print an 0x80001234-style number as its sole bit of diagnostics, you, the end user, get reminded about how bad COM/DCOM error handling is.

If you want an example of how bad this stuff can be, go use Outlook 2000, the one that would crash if the laptop went out of wireless range of the server. That wasnt even DCOM, it was DCE RPC, but it acts as a glorious showcase for why the MS stacks were no better than the CORBA ones, just more broadly used in mass market applications.

Out there in the intra-organisation land, you either have REST, relatively simple SOAP (no WSRF, WS-Eventing, etc), or something custom, invariably HTTP based or at least tunneling over port 8080. What do we have behind the firewall? A complete mess. There's the DCE based win16 app for filling in travel expenses (trams- enemy of EU employees!), there's all the SAP based stuff you have to deal with when you are a project manager, the apps that tell you your budget and how much there is left. Then there's the various web sites to do things that somehow talk behind their back to each other. And there is stuff like Jabber, which, whatever it uses, doesn't accept ::CreateFile(8) as a valid password, even though the rest of the organisation does. Its a mess. But does that matter? And if it does, what would you standardise on, if not CORBA? You wouldn't go single platform, so RMI and WCF are out, despite the benefits that single platformness gives you. That leaves SOAP, REST on HTTP, WSRF/N/Eventing, ICE, maybe XMPP.

One issue is whether distributed objects are the right metaphor for distributed computing. CORBA, DCOM, ICE, RMI, .NET remoting and WSRF all implement the idea that you are talking to instances of stateful things at the end, with operations to read/write state, and verbs/actions/method calls to tell the remote thing to do something. These protocols invariably come up against the object lifetime problem, the challenge of cleaning up instances when callers go away, without flooding the network with too much traffic to indicate client health. They also have the dealing with change problem, in which both ends of the system (assuming callbacks) have to handle the possibility that either end of the system may be suddenly replaced by an upgraded version, possibly with a changed interface, possibly with changed semantics. This is hard to deal with. REST handles it best by freezing the set of verbs to a low number, only allowing one way links, but at a price, the price of no easy mapping between REST resources and native classes, no two-way links and (currently) not very easy APIs. The question is, when will the Enterpriseys notice that this is the only thing that has been shown to work.