Middleware Matters

Over in his new blog, Don comments on what he thinks CORBA got wrong. This might surprise you, but I wholly agree with him, and in fact I would state some of what he said even more strongly. Now, don't get me wrong -- I haven't turned into some sort of CORBA turncoat or traitor, spewing FUD about it like there's no tomorrow (like one guy I know). There is simply no denying that CORBA has succeeded wildly and remains a viable solution for problems requiring high-performance and flexible custom integration, nor is there any use in denying that the distributed computing world has advanced considerably due to CORBA. Rather, I think it's just generally useful to fairly and objectively analyze and criticize technologies so we can learn and improve.

Specifically, I agree with Don about the programming model issue. We CORBA types have been saying for years that there's no such thing as a "one size fits all" solution, and yet we insist that there's only one way to write a CORBA application in any given language. That doesn't make sense. Don uses the term "yuck" when referring to the CORBA C++ mapping, and while I don't think it's as bad as people make it out to be, it certainly leaves much to be desired. The bottom line is that C++ is a multiparadigm language, so there should be multiple ways to use it with CORBA. That's unlikely to happen, unfortunately, but still, things might be improving soon. Right now there's a group in the OMG who are setting a foundation for a new CORBA C++ mapping. I hope they succeed, and above all, I hope they keep it simple. I spoke informally with C++ experts Kevlin Henney and Nicolai Josuttis recently at JAOO about what a new CORBA C++ mapping might look like, and we all agreed that basing it on ISO C++ and the standard library should mean that it could be rather simple.

In terms of programming models, I think Tim gets it completely right when he says that programmers should be allowed to choose the way requests and messages are accessed. I have believed for a long time that that's precisely how things should be done.

Something else that Don doesn't mention about what CORBA (and DCOM and others) got wrong is something that drove Don to help create SOAP in the first place: the need for the same infrastructure at each end of the wire. Not only the same infrastructure, but in some cases, the same heavyweight infrastructure. The more details you force to be the same on all nodes in the network, the lower your chances of scaling well, and in fact the lower the likelihood that your system will actually prove useful on enough of those nodes to make the system worthwhile. The need for a ubiquitous distributed object model, for example, is nice on a small scale, but it simply doesn't scale up. Such a model can also interfere with integration details in large-scale systems; you can end up fighting the model instead of focusing on the real-world problems you're trying to solve.

A reduction in the need for shared details and a focus on the message is what modern service orientation brings to the picture. And no, it isn't a reinvention of the wheel; rather, it's simply a case of learning from the past and improving on it.