CORBA的兴衰.docxVIP

The rise and fall of CORBA 作者 Michi Henning，2006.6.5 我们可以从CORBA的错误中学到很多 主要历史 在90年代早期，要使不同机器上的程序相互之间通信是一场恶梦，特别是不同的硬件、操作系统和编程语言都存在的环境：程序员要么使用socket靠自己来写整个协议栈，要么他们的程序之间就完全不能通信。（其它早期中间件，如Sun的ONC，Apollo的NCS以及DCE，都是基于C语言和UNIX操作系统的，并不适合于异构的环境）。 CORBA 1.0并不成功，因为它不能互操作，并且只提供C语言的映射。OMG在1997年发布了CORBA 2.0，它提供了标准协议，以及C++语言的映射，1998年提供了Java语言的映射。CORBA 2.0使得开发者可以相对容易地构建异构的分布式应用。CORBA很快就流行起来，很多任务关键的应用都用CORBA来构建。CORBA的前景看上去非常乐观。 在经历了90年代中后期的增长后，一些主要的变化影响了计算的前景，最为著名的就是Java与Web的出现。CORBA提供了Java语言映射，但是并没有涉及到爆炸式增长的Web。商业公司并没有等待CORBA给出解决方案，它们转向了其它技术，并且开始构建他们基于Web浏览器、HTTP、Java和EJB的电子商务基础设施。 除此之外，有经验的CORBA开发者发现编写实用的CORBA应用程序相当地困难。许多API都很复杂，不一致，甚至完全让人感觉神秘，使得开发者必须关注许多细节问题。想比之下，组件模型的简单性，比如EJB，使得编程简单得多（虽然不那么灵活），因此对CORBA组件模型的呼声越来越大。但是组件模型的到来花了很长的时间。始于1996年的工作基于CBOF（通用业务对象设施），但是那个努力因为公司行政策略上的斗争陷入了困境，不久就被放弃了，取而代之的是CORBA组件模型CCM。1999年CCM的规范终于发布，但是很大程度上确成为了雷声大、雨点小的事。 规范巨大而复杂，许多都未曾被实现过，甚至概念性的证明都没做过。阅读文档就可以清楚知道CCM技术上是不成熟的；部分根本不可实现，即使实现，也无法提供可移植性。 非商用的CORBA厂商承担了实现CCM的义务，却使其成为了夭折的孩子。即便在CCM发布的时候实现已经可以获得，也太迟了。机会已经过去了：EJB已经进入了产业，其它技术已经没有机会取得成功。CCM的失利并未增加CORBA客户的信心，这些客户正陷于CORBA复杂技术的泥潭。 同时，工业界对于中间件的需求出现了前所未有的高涨。在使用HTTP、HTML和CGI构建了电子商务系统之后，使用这些方式构建分布式系统出现了明显的严重缺陷。没有适当的类型系统，应用被迫解析HTML来提取语义，这与抓屏一样没什么价值。这导致系统非常脆弱。另一方面，EJB拥有正确的类型系统，但是局限于Java技术，并不适用于许多环境。 商用CORBA实现一般每个开发席位都会花费几千美元左右，加上许多情况下的运行时版税（每个应用部署后收取）。对许多潜在的客户来说，CORBA这样的平台限制对他们来说太昂贵了。 CORBA平台的学习曲线陡峭，技术复杂，不容易正确使用，这些因素导致了开发周期长，易出错。早期的实现常常充满Bug并且受苦于缺乏有质量的文档。公司不容易找到他们需要的有经验的CORBA程序员。微软并没有使用CORBA，取而代之的是推出自己的DCOM。这使得市场要么选择中立要么使用DCOM，但是DCOM未能赢得中间件之战，因为它仅仅能工作在Windows平台上。（Software AG做了一个UNIX的移植，但是没有获得进一步的动力）。微软在几次扩展DCOM应用范围的尝试失利以后，最后放弃了DCOM。那时，中间件市场处于支离破碎的状态，许多技术在竞争，但是没有哪一个技术能够获得足够的份额来统一分布式系统的开发。 另外一个导致CORBA下降的重要因素是XML。90年代后期，XML成为了计算工业新的银弹：几乎所有只要是定义为XML的东西都是好的。在放弃了DCOM之后，微软并没有把电子商务市场留给竞争对手，微软没有再参与一场不可能打赢的战争，而是使用XML来开辟了新的战场。在1999年年末，工业界看到了SOAP的发布。SOAP由微软和DevelopMentor发布，随后提交给W3C作为标准，SOAP使用XML作为远程过程调用的线上编码方式。 SOAP有严重的技术缺陷，但是，作为一种市场策略，它是巧妙的一招。随着大量的厂商都想分一杯羹，并且从CORBA转向萌芽的Web服务市场，市场变得更加的分化。对客户来说，这增加了CORBA生存能力的不确定性，在许多情况下，使得他们更加投资于有把握的技术。 当2002年Internet泡沫破灭时，CORBA遭到了另一个打击。工业