corba - 为什么 CORBA 不受欢迎？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




10年前关闭。




我从来没有听过任何人谈论过 CORBA，只是带有 mock 意味，考虑到 10 多年前它是蜜蜂的膝盖，这很奇怪。为什么 CORBA 失宠了？纯粹是因为实现不好还是有更基本的东西？

Answer 1

这不仅仅是 CORBA，它是一般的 RPC。这包括像 DCOM、Java-RMI、.NET Remoting 和所有其他的东西。

问题基本上是分布式计算与本地计算根本不同。 RPC 试图假装这些差异不存在，并使远程调用看起来就像本地调用一样。但是，为了构建一个好的分布式系统，您需要处理这些差异。

Bill Joy、Tom Lyon、L. Peter Deutsch 和 James Gosling 确定了分布式计算的 8 个谬误，即分布式编程的新手认为是正确的，但实际上是错误的，这通常会导致项目失败或重大损失增加成本和工作量。 RPC 是这些谬论的完美体现，因为它建立在同样的错误假设之上:

网络是可靠的。

延迟为零。

带宽是无限的。

网络是安全的。

拓扑不会改变。

有一名管理员。

运输成本为零。

网络是同质的。

所有这些都适用于本地计算。

以可靠性为例:如果你在本地调用一个方法，那么调用本身总是成功的。当然，被调用的方法本身可能有错误，但方法的实际调用总是会成功的。结果将始终返回，或者，如果该方法失败，则会发出错误信号。

在分布式系统中，情况并非如此:调用方法本身的行为可能会失败。 IE。从您的角度来看，您似乎调用了该​​方法，但该调用实际上在网络上丢失了并且从未到达该方法。或者，该方法成功接收调用并执行操作，但结果在返回给您的途中丢失了。或者方法失败，但错误丢失了。

与延迟类似:在本地，调用方法本质上是免费的。该方法本身可能需要任意时间来计算答案，但调用是免费的。通过网络，一个调用可能需要数百毫秒。

这就是为什么几乎所有的 RPC 项目，包括 CORBA 都失败了。

请注意，相反的方式工作得很好:如果你只是假装所有的调用都是远程调用，那么可能发生的最糟糕的事情就是你会失去一点性能并且你的应用程序包含一些永远不会使用的错误处理代码.例如，这就是 Erlang 的工作方式。

在 Erlang 中，进程总是有单独的堆和单独的垃圾收集器，就像它们运行在不同大陆的不同机器上一样，即使这些进程运行在相同地址空间的相同 CPU 上的相同 VM 上。如果您将数据从一个进程传递到另一个进程，那么该数据总是被复制，就像如果进程在不同的机器上一样。调用总是在异步消息发送时进行。

因此，使本地和远程调用看起来相同不是问题。让他们看起来像本地电话是。

在 CORBA 中，问题实际上比这更令人费解。他们实际上确实让本地调用看起来像远程调用，但是由于 CORBA 是由委员会设计的，远程调用非常复杂，因为它们必须能够处理一些非常荒谬的要求。这种复杂性强加给每个人，即使是本地电话。

同样，与 Erlang 相比，复杂性要低得多。在 Erlang 中，向进程发送消息并不比调用 Java 中的方法复杂。接口(interface)基本相同，只是期望不同:Java 中的方法调用期望是即时和同步的，在 Erlang 中，消息发送期望是异步的并且具有可见的延迟。但实际使用它们并不比简单的本地过程调用更复杂。

另一个区别是 Erlang 区分了函数调用，它只能发生在进程内部，因此总是本地的，以及消息发送，发生在进程之间，并且被假定总是远程的，即使它们不是。在 CORBA 中，所有方法调用都假定为远程调用。