下载本文的 PDF 版本 PDF

CORBA 的兴衰

我们可以从 CORBA 的错误中吸取很多教训。

MICHI HENNING，ZeroC

从开始计算的时间点来看，CORBA 大约有 10-15 年的历史。在其生命周期中，CORBA 从早期采用者的前沿技术，发展成为流行的中间件，再到相对默默无闻的小众技术。研究一下 CORBA——这个曾经被誉为“下一代电子商务技术”的技术——为何会遭受这种命运，是很有启发意义的。CORBA 的历史是计算机行业多次见证的历史，而且目前的中间件努力，特别是 Web 服务，似乎很可能会重演类似的历史。

简史

在 90 年代初期，说服不同机器上的程序相互通信简直是一场噩梦，特别是当涉及到不同的硬件、操作系统和编程语言时：程序员要么使用套接字并编写整个协议栈，要么他们的程序根本无法通信。（其他早期的中间件，如 Sun ONC、Apollo NCS 和 DCE，都与 C 和 Unix 绑定，不适用于异构环境。）

在 CORBA 1.0 的错误开端之后，由于它不具备互操作性，并且只提供了 C 映射，OMG（对象管理组）于 1997 年发布了 CORBA 2.0。它提供了标准化的协议和 C++ 语言映射，Java 语言映射紧随其后，于 1998 年发布。这为开发人员提供了一种工具，使他们能够相对轻松地构建异构分布式应用程序。CORBA 迅速普及，许多关键任务应用程序都是使用该技术构建的。CORBA 的未来看起来确实一片光明。

在 90 年代中期和后期 CORBA 的增长阶段，重大变化影响了计算领域，最显著的是 Java 和 Web 的出现。CORBA 提供了 Java 语言映射，但它没有与迅速发展的 Web 合作。公司没有等待 CORBA 提供解决方案，而是转向其他技术，开始基于 Web 浏览器、HTTP、Java 和 EJB（企业 Java Bean）构建其电子商务基础设施。

此外，已经获得 CORBA 经验的开发人员发现，编写任何重要的 CORBA 应用程序都出奇地困难。许多 API 复杂、不一致且完全神秘，迫使开发人员关注很多细节。相比之下，组件模型（如 EJB）的简单性使编程变得更加简单（如果灵活性较差），因此对 CORBA 组件模型的呼声越来越高。然而，组件模型的出现经历了漫长的时间。1996 年启动了 CBOF（通用业务对象设施）的工作，但由于政治内讧而陷入困境，最终被放弃，取而代之的是 CCM（CORBA 组件模型）。CCM 的规范最终于 1999 年底发布，但结果证明基本上是一场空

CCM 的失败并没有提高 CORBA 客户的信心，他们仍然受困于其复杂的技术。

与此同时，行业对中间件的需求比以往任何时候都更加强烈。在使用 HTTP、HTML 和 CGI 的电子商务系统获得一些经验后，很明显以这种方式构建分布式系统存在严重的局限性。在没有适当类型系统的情况下，应用程序沦为解析 HTML 以提取语义，这几乎等同于屏幕抓取。结果得到的系统非常脆弱。另一方面，EJB 具有适当的类型系统，但仅限于 Java，因此不适用于许多情况。CORBA 的药膏中也有一些苍蝇

微软从未接受 CORBA，而是选择推广其自己的 DCOM（分布式组件对象模型）。这使得大部分市场要么处于观望状态，要么转而使用 DCOM，但 DCOM 也无法赢得中间件之战，因为它仅在 Windows 上运行。（Software AG 将 DCOM 移植到 Unix 的尝试从未获得成功。）在多次尝试扩展 DCOM 失败后，微软最终放弃了 DCOM。到那时，中间件市场已经处于非常分散的状态，多种技术相互竞争，但没有一种技术能够获得足够的关注度来统一分布式系统开发。

CORBA 衰落的另一个重要因素是 XML。在 90 年代后期，XML 已成为计算机行业新的灵丹妙药：几乎按照定义，如果是 XML，那就是好的。在放弃 DCOM 后，微软不打算将全球电子商务市场拱手让给竞争对手，而是没有打一场它无法赢得的战斗，而是使用 XML 创建了一个全新的战场。1999 年底，业界看到了 SOAP 的发布。SOAP 最初由微软和 DevelopMentor 开发，然后提交给 W3C 进行标准化，它使用 XML 作为远程过程调用的在线编码。

SOAP 存在严重的技术缺陷，但作为一种市场策略，它是一记妙招。它导致了进一步的分裂，因为众多供应商争夺市场份额，并将他们的努力从 CORBA 转移到蓬勃发展的 Web 服务市场。对于客户而言，这增加了对 CORBA 可行性的更多不确定性，并在许多情况下促使他们暂停对该技术的投资。

2002 年初，互联网泡沫破裂时，CORBA 遭受了又一次打击。行业的金融崩溃将许多软件公司赶出了市场，并迫使幸存者重新调整他们的努力方向。结果是商业 CORBA 产品的数量大幅减少。在崩溃之前，一些供应商已经放弃或不再强调他们的 CORBA 产品，而在崩溃之后，更多的供应商效仿。90 年代中期至后期，曾经是一个蓬勃发展的市场，拥有许多竞争产品，突然变成了边缘市场，供应商、客户和投资都少得多。到那时，CORBA 的开源实现已经可用，部分弥补了商业供应商的离开，但这不足以恢复失去的关注度并重塑市场的信心：CORBA 不再是行业的宠儿。

今天，CORBA 主要用于连接在公司网络内部运行的组件，在这些网络中，通信受到防火墙的保护，免受外部世界的侵害。它也用于实时和嵌入式系统开发，CORBA 在这个领域实际上正在增长。然而，总的来说，CORBA 的使用正在下降，现在只能称之为小众技术。

考虑到就在几年前，CORBA 还被认为是承诺彻底改变电子商务的中间件的最前沿，看到这项技术如此迅速地被边缘化令人惊讶，研究导致衰落的一些更深层的原因是很有启发意义的。

技术问题

显然，许多外部因素促成了 CORBA 的衰落，例如互联网泡沫的破裂以及与其他技术（如 DCOM、EJB 和 Web 服务）的竞争。人们还可以认为 CORBA 是行业趋势和时尚的受害者。在计算机行业中，特定技术的技术卓越性通常与其成功关系不大——关注度和营销可能更重要的因素。

然而，这些论点无法完全解释 CORBA 受欢迎程度的下降。毕竟，如果这项技术像最初设想的那样引人注目，那么客户不太可能放弃它而选择替代方案。

技术卓越不是成功的充分必要条件，但从长远来看，它是必要的先决条件。无论行业炒作多么强烈，如果一项技术存在严重的技术缺陷，最终都会被抛弃。这就是我们找到 CORBA 失败的主要原因的地方。

复杂性

最明显的技术问题是 CORBA 的复杂性——特别是其 API 的复杂性。CORBA 的许多 API 都比必要的要大得多。例如，CORBA 的对象适配器需要超过 200 行接口定义，即使相同的功能可以在大约 30 行中提供——其他 170 行对功能没有任何贡献，但严重复杂化了程序与 CORBA 运行时的交互。

另一个问题领域是 C++ 语言映射。该映射难以使用，并且包含许多导致错误的陷阱，尤其是在线程安全、异常安全和内存管理方面。在 CORBA 规范中可以找到许多其他过于复杂和设计不佳的 API 示例，例如命名、交易和通知服务，所有这些服务都提供了容易出错且难以使用的 API。同样，CCM 配置非常复杂，以至于在没有额外工具支持的情况下无法有效地使用它。

设计不佳的接口和语言映射是任何技术非常可见的一部分，因为它们是软件开发的“煤矿”：它们是开发人员和平台相遇的点，它们可用性和安全性对开发时间和缺陷计数有重大影响。显然，任何遭受地方性复杂性困扰的技术都无助于赢得开发人员的好感，更无助于赢得管理层的好感。

复杂性也源于架构选择。例如，CORBA 的 IOR（可互操作对象引用）是不透明的实体，其内容应该对开发人员保持隐藏。这很不幸，原因有三

复杂性的另一个来源是类型系统。例如，CORBA 的接口定义语言提供了大量的类型，其中包括无符号整数、定点和扩展精度浮点数、有界和无界序列以及数组，以及可以存储任意类型值的“Any”类型。

支持这些类型使许多 API（特别是用于内省和动态调用的接口）复杂化，并导致微妙的可移植性问题。例如，Java 不支持无符号类型，因此在接口中使用无符号整数可能会导致 Java 客户端与 C++ 服务器通信时出现溢出问题。同样，在没有对定点或双精度浮点数提供本机支持的平台上，实现必须模拟这些类型。模拟很难实现，以使其在不同平台上的行为完全相同，并且它们需要额外的 API。这增加了进一步的复杂性，并且是难以诊断的互操作性问题的根源。

最后，OMG 的一些早期对象服务规范，例如生命周期、查询、并发控制、关系和集合服务，不仅复杂，而且没有任何有用的功能。它们只是为已经很复杂的规范套件添加了噪音，让客户感到困惑，并加强了 CORBA 难以使用的声誉。

功能不足

CORBA 提供了相当丰富的功能，但未能提供两个核心功能

安全性。CORBA 的未加密流量容易受到窃听和中间人攻击，并且它需要为每个服务在公司防火墙中打开一个端口。这与公司安全策略的现实相冲突。（顺便说一句，CORBA 的这个缺点是 SOAP 兴起的主要因素。不必在公司防火墙中打开端口并通过端口 80 发送所有内容被视为一个主要优势，尽管这个想法很幼稚。）OMG 曾多次尝试为 CORBA 指定安全性和防火墙穿越，但由于技术缺陷和防火墙供应商缺乏兴趣而被放弃。

版本控制。已部署的商业软件需要中间件，该中间件允许以向后兼容的方式逐步升级软件。CORBA 没有提供任何此类版本控制机制（除了派生版本控制，这完全不足）。相反，对 CORBA 应用程序进行版本控制通常会破坏客户端和服务器之间的在线合同。这迫使已部署应用程序的所有部分必须一次性更换，这通常是不可行的。（CORBA 的这个缺点是 SOAP 兴起的另一个主要因素。XML 据称的松散耦合性质被视为解决了这个问题，尽管这个想法与通过端口 80 传输所有通信一样幼稚。）

对于商业电子商务基础设施而言，缺乏安全性和版本控制简直是致命的缺陷——许多潜在的电子商务客户仅仅因为这些原因就拒绝了 CORBA。

其他技术问题

许多其他技术问题困扰着 CORBA，其中包括

此问题列表只是一个示例，可以大大扩展。这些问题仅影响少数客户，但它们加剧了 CORBA 的负面新闻并限制了其市场。

程序问题

技术问题是 CORBA 衰落的核心。这就提出了一个问题，即由世界上最大的软件联盟生产的技术怎么可能遭受如此多的缺陷。事实证明，技术问题是症状，而不是原因。

OMG 是一个基于共识发布技术的组织。本质上，成员投票决定发布规范的 RFP，成员公司提交草案规范作为回应，成员投票决定接受哪个草案作为标准。理论上，这种民主过程是公平公正的，但实际上，它不起作用

参与标准化过程没有准入资格。一些贡献者是该领域的专家，但坦率地说，许多成员几乎不了解他们正在投票的技术。这多次导致采纳了具有严重技术缺陷的规范。

RFP 通常要求采用未经证实的技术。OMG 成员大致可以分为两类：技术用户和技术供应商。通常，是用户希望扩展 CORBA 以添加解决特定问题的能力。这些用户希望供应商能够响应并提供解决他们问题的方案，从而推动 RFP 的发布。然而，用户通常对 CORBA 实现的内部结构知之甚少。充其量，这会导致 RFP 包含难以实现或对性能产生负面影响的要求。最坏的情况是，RFP 几乎等同于要求供应商施展魔法。此类 RFP 不是标准化最佳现有实践，而是试图在没有事先实践经验的情况下进行创新。

即使供应商知道 RFP 存在技术缺陷，他们也会响应 RFP。这可能看起来令人惊讶。毕竟，供应商为什么要为已知存在技术问题的产品提出标准？原因是供应商为了客户而相互竞争，并且不断地争夺地位。即使很明显 RFP 包含严重问题，承诺响应 RFP 有时也会被用来赢得用户的好感（并希望获得合同）。

供应商在标准化方面存在利益冲突。对于供应商而言，标准化是一把双刃剑。一方面，标准化很吸引人，因为它使技术更容易销售。另一方面，过度的标准化被认为是有害的，因为供应商希望保持对其产品与竞争对手产品区分开来的功能的控制权。

供应商有时会试图阻止对任何需要更改其现有产品的产品的标准化。这导致应该标准化的功能仍然是专有的，或者被指定得过于模糊而无法使用。一些供应商也忽略了区分标准功能和专有功能，因此客户在没有警告的情况下误入特定于实现的领域。因此，将 CORBA 应用程序移植到不同供应商的实现可能出奇地昂贵；尽管进行了所有标准化，客户经常发现自己被锁定在特定产品中。

RFP 通常由几个草案规范回答。OMG 成员通常不会选择其中一个竞争规范，而是要求提交者将其功能合并到一个规范中。这种做法是导致 CORBA 复杂性的主要原因。通过合并功能，规范最终变成了每个人都想到的每个功能的厨房水槽。这不仅使规范比必要的更大更复杂，而且还往往会引入不一致之处：单独来看完全合理的不同功能可能会微妙地相互作用并导致语义冲突。

主要供应商偶尔会拖延程序，除非他们的宠物功能被纳入合并后的标准中。这会导致技术流程退化为政治内讧，迫使达成糟糕的妥协，并造成延误。例如，组件模型的第一次尝试是这种内讧的受害者，C++ 映射的第一次尝试也是如此。这两项努力都陷入困境，以至于不得不放弃并在稍后重新开始。

OMG 不要求在采用规范之前提供参考实现。这种做法为空中楼阁式的规范打开了大门。OMG 曾多次发布标准，但结果证明由于严重的技术缺陷，这些标准部分或全部无法实现。在其他情况下，可以实现的规范在实践中无法使用，因为它们施加了不可接受的运行时开销。当然，此类事件的重复发生令人尴尬，并且无助于提高客户的信心。参考实现的要求将迫使提交者实施他们的提案，并且本可以避免许多此类事件。

总的来说，OMG 的技术采纳过程必须被视为 CORBA 衰落的核心原因。该过程鼓励委员会设计和政治操纵，以至于难以实现技术平庸，更不用说技术卓越了。此外，不连贯的功能的添加导致了架构愿景的逐渐侵蚀。（例如，不透明引用的架构概念在 2000 年的规范更新中被忽略了。最终结果是引用不再是不透明的，但 API 仍然背负着将它们视为不透明的包袱。）

CORBA 的众多技术缺陷已经积累到难以修复或添加任何东西而不破坏其他东西的地步。例如，CORBA 互操作性协议的每个修订版都必须进行不兼容的更改，并且由于与随着时间推移添加的功能的意外交互，许多修复和澄清必须多次返工。

我们可以从过去吸取教训吗？

像 OMG 这样的民主过程非常不适合创建好的软件。然而，尽管存在已知的程序问题，但行业更倾向于依靠大型联盟来生产技术。Web 服务是当前中间件的灵丹妙药，它使用的流程与 OMG 的流程非常相似，并且据许多人说，它也遭受内讧、分裂、缺乏架构连贯性、委员会设计和功能臃肿的困扰。Web 服务似乎不可避免地会重演与 CORBA 非常相似的历史。

我们应该采取哪些步骤才能最终获得更好的标准流程和更好的中间件？鉴于程序失败是技术失败的根本原因，我至少提出以下建议

标准联盟需要铁定的规则，以确保他们标准化现有的最佳实践。标准中没有创新的空间。尽管出于好意，但加入“只是那个额外的小功能”不可避免地会导致意想不到的技术问题。

在没有参考实现的情况下，不应批准任何标准。这为正在标准化的内容提供了第一道健全性检查。（没有人足够聪明，可以查看规范并确定它不包含隐藏的缺陷，而无需实际实施它。）

在没有用于实施一些具有实际复杂性的项目的情况下，不应批准任何标准。这对于消除不良 API 是必要的：API 的实施者往往从不实际使用他们自己的接口，这对可用性造成了灾难性的后果。

有趣的是，开源社区在遵守这些规则方面比行业联盟做得好得多。

开源创新通常受制于达尔文式的选择过程。不同的开发人员实施他们对事物应该如何工作的想法，其他人尝试使用该功能并进行评论或改进。这样，软件经过广泛的审查和测试，只有“最适合”的版本才能生存下来。（许多开源项目通过交替的实验性和生产性版本来形式化此过程：实验性版本充当试验台和进化过滤器。）

要创建高质量的软件，说“不”的能力通常比说“是”的能力重要得多。开源在可以称为“仁慈的独裁”中体现了这一点：即使许多人为整体努力做出贡献，但单个专家（或少数专家集团）最终会拒绝或接受每个提出的更改。这保留了最初的架构愿景，并阻止了谚语所说的“厨师太多，反而烧坏了粥”。

这些开源实践的核心是两个基本先决条件：合作和信任。没有合作，进化过程就无法运作；没有信任，任何专家集团都不能充当最终仲裁者。然而，这正是软件联盟发现其厄运的地方。将竞争对手供应商和客户放入联盟中并期望他们提出高质量的产品是幼稚的——商业现实确保合作和信任是参与者最不可能考虑的事情。

当然，软件联盟对进化过程的贡献与开源项目一样多。但正是商业市场充当了试验台和进化过滤器，而正是客户用他们的钱包充当了（通常不是那么仁慈的）独裁者。这几乎等同于一个行业抛出灵丹妙药，而客户像旅鼠一样跳下悬崖追逐它们。在我们改变这个过程之前，通用电子商务中间件的时代还遥遥无期。

Michi Henning ([email protected]) 是 ZeroC 的首席科学家。从 1995 年到 2002 年，他作为 OMG 架构委员会的成员以及 ORB 实现者、顾问和培训师从事 CORBA 工作。他与 Steve Vinoski 合著了《Advanced CORBA Programming with C++》（Addison-Wesley，1999 年）。自加入 ZeroC 以来，他一直致力于 ZeroC 的下一代中间件 Ice 的设计和实现，并于 2003 年与人合著了《Distributed Programming with Ice》。他拥有澳大利亚昆士兰大学计算机科学荣誉学位。

acmqueue

最初发表于 Queue 第 4 卷，第 5 期—
在 数字图书馆中评论本文




更多相关文章

Satnam Singh - 使用容器对容器进行集群级日志记录
本文介绍了如何使用开源工具实现集群级日志记录基础设施，并使用与用于组合和管理正在记录的软件系统相同的抽象来部署该基础设施。收集和分析日志信息是运行生产系统以确保其可靠性并提供重要的审计信息的重要方面。已经开发了许多工具来帮助聚合和收集特定软件组件（例如，Apache Web 服务器）在特定服务器（例如，Fluentd 和 Logstash）上运行的日志。（


Peter Kriens - OSGi 如何改变了我的生活
在 1980 年代初期，我发现了 OOP（面向对象编程），并深深地爱上了它。像往常一样，这种爱意味着说服管理层投资这项新技术，最重要的是，送我去参加酷炫的会议。所以我向我的经理推销了这项技术。我向他描绘了美好的未来，有一天我们将从现成的类中创建应用程序。我们将从存储库中获取这些类，将它们组合在一起，瞧，一个新的应用程序就诞生了。今天，我们或多或少地认为对象是理所当然的，但如果我诚实地说，我在 1985 年向我的经理所做的推销从未真正实现。


Len Takeuchi - ASP：集成挑战
使用 ASP 和向 ASP 提供增值产品的第三方供应商的组织需要与它们集成。ASP 通过提供基于 Web 服务的 API 来实现这种集成。通过 Internet 与 ASP 集成和与本地应用程序集成之间存在显着差异。在与 ASP 集成时，用户必须考虑许多问题，包括延迟、不可用性、升级、性能、负载限制和缺乏事务支持。


Chris Richardson - 解开企业 Java
关注点分离是计算机科学中最古老的概念之一。这个术语由Dijkstra在1974年1提出。它之所以重要，是因为它简化了软件，使其更易于开发和维护。关注点分离通常通过将应用程序分解为组件来实现。然而，存在横切关注点，这些关注点跨越（或横跨）多个组件。这些类型的关注点无法通过传统的模块化形式处理，并可能使应用程序更加复杂和难以维护。



© 版权所有。

© . All rights reserved.