CORBA revaluado (respuesta a Michi Henning)

En noviembre pasado dediqué algunas líneas a un artículo de Michi Henning sobre el "surgimiento y caída de CORBA" , que fuera bastante comentado en el ambiente de middleware, tanto por su impacto en CORBA, como por sus puntos de contacto y diferencias con servicios web. En particular a mí me interesaron también sus apuntes sobre el peso de la forma en que se construyeron sus estándares, que también representan patrones de desarrollo de estándares en software que hemos visto repetidamente.
Pero también es de interés la respuesta a Henning desde el campo de CORBA. Una detallada respuesta (sin firma) existe en The ORBZone, sitio de la comunidad CORBA:

Michi Henning’s recent article entitled “The Rise and Fall of CORBA” provided a very interesting insight into the history of the standardisation of CORBA from someone who was a core part of that process. While some of the technical limitations he addresses are correct, others are taken out of context or even from outdated specifications. CORBA is alive and well and applicable today in more industry verticals than it was in its heyday of the 90’s. Airline reservations, e-commerce back-ends, telco transactions and financial systems all deliver millions of messages per second powered by CORBA. The truth is that the most vocal CORBA detractors are CORBA competitors, with products that are derivatives of CORBA.

Justamente, las observaciones de Henning sobre la construcción del estándar motivan la primera respuesta:

It is unfortunate that a lot of the attacks have been aimed at the CORBA standardization process, and by extension, the OMG itself. It is relatively easy to sit alone and develop a proprietary solution that fits exactly what a single company wants to achieve. It’s much harder to develop a standard that suits every voting member. Arguments, blockages, concessions and complications are all part of this process. Does that mean the multi-vendor standardization process is flawed? Not at all! In fact, I would argue just the opposite. A standard that has the approval of all interested parties in that space has a far greater chance of acceptance and survival than does the rogue standard created by a single, uncooperative vendor. CORBA is just one example of a consensus-derived standard; the W3C and SCA have also been extremely successful with their efforts as well. And even Sun, who developed and standardized J2EE single-handedly, had to eventually introduce the JCP. The argument is that it’s much easier to create a bug-free specification without the hindrance of a consortium. But let’s be realistic here – no specification is perfect. Consortium-derived specifications often seem buggier simply because of their increased scrutiny and multi-vendor implementations as opposed to single-vendor specifications which are usually implemented only by that same vendor. And as far as standardization goes, the single-vendor specification still has to gather industry support and public acceptance to become a recognized standard. This means that at some point the specification will be put through the same arguments, concessions, blockages, bug issues and cooperation as the consensus-based effort. CORBA achieved consensus and usage which is why there are so many battle hardened CORBA systems working today. Companies that can co-operate on a standard prove that they are mature enough to be able to co-operate for the benefit of customers. The alternative is domination by one vendor which either has a monopoly and charges excessively or is too small to sustain themselves for the long lifecycles which will be demanded of infrastructure products.

La crítica se extiende luego en detalle defendiendo el estándar de los argumentos de Henning, sobre complejidad del API y de la documentación, y la seguridad.
Lateralmente, el sitio OrbZone ofrece un punto de encuentro de CORBA, y su alcance actual. También se menciona allí el grupo sobre el tema en Google.