为什么CORBA失去了知名度？[关闭]

我从来没有听过有人说过CORBA，只是嘲讽的意思，考虑到10年前是蜜蜂的膝盖，这很奇怪。为什么CORBA失宠？纯粹是实现不好还是有更根本的东西？

它不仅是CORBA，而且通常是RPC。这包括DCOM，Java-RMI，.NET Remoting等所有其他内容。

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

Bill Joy，Tom Lyon，L。Peter Deutsch和James Gosling指出了分布式计算的8个谬误，即分布式编程新手认为是正确的，但实际上是错误的，通常会导致项目失败或重大失败。增加成本和精力。RPC是这些谬论的完美体现，因为它是基于以下相同的错误假设建立的：

1. 网络是可靠的。
2. 延迟为零。
3. 带宽是无限的。
4. 网络是安全的。
5. 拓扑不会改变。
6. 有一个管理员。
7. 运输成本为零。
8. 网络是同质的。

所有这些对于本地计算都是正确的。

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

在分布式系统中，情况并非如此：调用方法本身的操作可能会失败。即从您的一端看，您好像调用了该方法，但是该调用实际上在网络上丢失了，并且从未到达该方法。或者，该方法成功接收了调用并执行了操作，但是结果在返回您的途中丢失了。或方法失败，但错误丢失了。

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

这就是几乎所有RPC项目（包括CORBA）都失败的原因。

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

在Erlang中，进程始终具有单独的堆和单独的垃圾收集器，就像它们在不同大陆上的不同机器上运行一样，即使这些进程在相同地址空间的同一CPU上的同一VM上运行。如果将数据从一个进程传递到另一个进程，则始终复制该数据，就像进程必须位于不同的计算机上一样。总是在异步消息发送时进行呼叫。

因此，使本地和远程呼叫看起来相同不是问题。使它们看起来像本地电话。

在CORBA中，问题实际上比这复杂得多。它们实际上确实使本地呼叫看起来像远程呼叫，但是由于CORBA是由委员会设计的，因此远程呼叫非常复杂，因为它们必须能够处理一些非常荒谬的要求。这种复杂性被强加给每个人，即使是本地电话也是如此。

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

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

诸如CORBA和DCOM之类的分布式对象技术在粒度方面存在问题-实施往往过于“混乱”，无法在网络上良好地执行-且通常泄漏的实施细节使解决方案变得脆弱。

对这些问题的反应是服务导向。