CORBA的兴衰

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遭到了另一个打击。

工业界的金融崩溃使得许多软件公司退出市场，幸存者必须重新集中它们的资源。

结果导致了大量商用CORBA 产品的损耗。

在崩盘之前，几个厂商已经停止或者边缘化了它们的CORBA产品，并且在崩盘后，更多的CORBA产品随之并停止。

在90年代中期到后期一片繁荣景象的许多有竞争力的产品忽然成为了市场的边缘，并且只有极少的厂商、客户和投资者。

那时，可以获得CORBA的开源实现，这部分重建了市场的信心：CORBA不再是业界心爱的孩子。

今天，CORBA大多用于连接公司内部网络的组件，与外部世界的通信由防火墙进行保护。

CORBA也用于实时和嵌入式开发，在这个领域CORBA确实在增长。

整体上说，CORBA 的使用在减少，但是仅仅作为一个适得其所的技术，其它什么也不是。

考虑到仅仅几年前，CROBA被认为是先进的中间件，被提出来革新电子商务，现在令人惊奇的是技术如此快地被边缘化，为此种失利分析其更深层次的原因是有益的。

Technical Issues 技术因素很明显，大量的外部因素导致了CORBA的失利，比如Internet泡沫的破灭以及其它技术的竞争，比如DCOM,EBJ和Web服务。

人们可以说CORBA是工业趋势的受害者。

在计算工业中，特定技术的技术优势常常对其成功贡献很少，份额和市场是更加重要的因素。

但是这篇辩论文并不能完整说明CORBA为何失利。

毕竟，如果技术像原来的设想的一样引人注目，客户不会抛弃它而选择其它的替代技术。

技术优势并不是成功的充分条件，但是，长期来看，它是一个必要条件。

不管有多少工业幻想，如果一种技术有严重的技术缺陷，它最后还是会被放弃的。

这也是我们所发现的CORBA失利的主要原因。

Complexity 复杂性最明显的技术问题就是CORBA的复杂性--特别是，API的复杂性。

许多CORBA的API比起所需要的来说要复杂得多。

例如，CORBA的对象适配器要求大于200行的接口定义，其实30行的定义就可以实现同样的功能--其它170行对于功能来说没什么用，它们只能造成CORBA运行时严重复杂的程序交互。

其它的问题是C++语言的映射。

映射不易使用，包含许多导致bug的缺陷，特别关于线程安全性、异常安全性和内存管理的部分。

大量的其它过度复杂和设计糟糕的API在CORBA规范中随处可见，比如名字服务、交易服务和通知服务，它们提供的API都是易错的、不容易使用的。

类似地，CCM的配置也是如此复杂以致如果没有使用附加工具的支持，难以产生有效的结果。

设计糟糕的接口和语言映射是任何技术非常明显的部分，因为他们是软件开发的“面子”：他们是开发者和平台相会的点，他们的易用性和安全性对于开发时间和错误累计有很重要的影响。

明显地，任何受困于特定复杂性的技术都使得它自己对开发者来说较少具有亲密性，对于管理来说就更是如此了。

复杂性也来源于体系结构的选择。

例如，CORBA的IOR（互操作对象引用）是不透明的实体，内容对于开发者来说是不可见的。

由于以下三个原因，这导致了不利：不透明的引用几乎强制使用名字服务，因为客户端在没有外部服务的帮助时不能创建对象引用。

这不仅复杂化了系统的开发和部署，也将冗余状态引入到了系统中（伴随着状态出错的危险），并且创造出了另外的失效点。

不透明的对象引用在相当的程度上复杂化了API。

例如，CORBA的拦截API应该能够简化很多，对象引用也可以透明。

不透明的对象引用要求远程调用比较对象标识符。

对许多应用来说，这些调用的负载是禁止的。

其它导致复杂的原因是类型系统。

例如，CORBA的接口定义语言提供了大量的类型，比如无符号整型，定点和扩展精度浮点数，有界和无界序列以及数组和能存储任何类型值的Any类型。

支持这些类型复杂化了许多API（特别是，反射和动态调用的接口），导致了微妙的移植性问题。

例如，Java不支持无符号类型，因此当Java客户端与C++服务器端通信时，在接口中使用无符号整数可能导致溢出问题。

类似地，在没有本地定点或双精度浮点数支持的平台上，实现必须模拟这些类型。

模拟难以用跨平台的统一方式实现，它们也需要额外的API。

这导致了更多的复杂性，而且是一个难以诊断的互操作问题的根。

最后，一些OMG的早期对象服务规范，比如生命期规范、查询规范、并发控制、关系和集合服务规范，不仅仅是复杂，而且根本没什么用。

它们仅仅在已经复杂的规范集合上增加了更多的噪音，使得客户迷惑，并且加强了CORBA难以使用的名声。

Insufficient Features 不足的特征CORBA提供了大量丰富的功能，但是没有提供两种核心特征：安全性。

CORBA的流量是不加密的，这使得它容易被窃听以及遭受插入式攻击，而且每个服务都要求防火墙打开一个端口。

这与企业安全策略是相冲突的。

（附带提一下，CORBA的这个缺点是导致SOAP声名鹊起的一个主要原因。

SOAP不需要在企业防火墙上打开一个端口，所以信息都通过80端口传递，这被看做主要优点，尽管这个想法非常幼稚。

）OMG数次努力制定CORBA的安全和防火墙穿透，但是由于技术缺陷以及防火墙厂商的冷漠而放弃了。

版本。

部署商业软件要求中间件可以用后向兼容的方式逐步升级。

CORBA没有提供任何版本机制（除了派生的版本控制，这完全不够）。

升级一个CORBA应用常常会破坏客户端和服务器之间的线上协议。

这强制许多已经部署的应用必须一次性替换，这是不可行的。

（CORBA的这个缺点是导致SOAP流行的另外一个主要原因。

XML所设想的松散耦合本质被视作解决问题的方法，尽管这个想法与通过80端口传输所有通信的想法一样幼稚。

）对于商用的电子商务基础设施来说，缺乏安全和版本控制是相当简单的暂停--许多潜在的电子商务客户仅仅因为这些原因拒绝使用CORBA。

Other Technical Issues 其它问题，大量的其它技术问题折磨CORBA，其中：CORBA互操作协议的设计缺陷使得它不可能建立一个高性能的分布式服务。