为什么CORBA失去知名度？
我从来没有听说过任何人用除了诡异的词语来谈论CORBA，考虑到十多年前它就是蜜蜂的膝盖。 为什么CORBA从恩典中坠落？ 是纯粹的实施是坏的还是有一些更根本的？
这不仅仅是CORBA，而是一般的RPC。 这包括诸如DCOM，Java-RMI，.NET Remoting以及所有其他的东西。
问题在于分布式计算基本上与本地计算不同。 RPC尝试假装这些差异不存在，并使远程调用看起来就像本地调用。 但是，为了build立一个良好的分布式系统，你需要处理这些差异。
Bill Joy，Tom Lyon，L. Peter Deutsch和James Gosling发现了8 个分布式计算的谬误 ，即分布式编程的新手认为是真实的，但实际上是错误的，这通常会导致项目失败或者显着增加成本和努力。 RPC是这些谬误的完美体现，因为它build立在这些相同的错误假设之上：
- networking可靠。
- 延迟为零。
- 带宽是无限的。
- networking是安全的。
- 拓扑不会改变。
- 有一个pipe理员。
- 运输成本为零。
- networking是同质的。
所有这一切对于本地计算都是正确的。
以可靠性为例，如果您在本地调用某个方法，那么调用本身总是会成功。 当然，被调用的方法本身可能有错误，但方法的实际调用将始终成功。 结果将始终返回，或者，如果方法失败，将会发出错误信号。
在分布式系统中，这不是事实： 调用方法本身的行为可能会失败。 即从你的结尾看起来你称为方法，但电话实际上已经在networking上丢失，从来没有达到的方法。 或者，该方法已成功接到来电并执行了操作，但结果却在返回给您的路上丢失了。 或者方法失败，但是错误丢失了。
与延迟类似：在本地调用方法本质上是免费的。 该方法本身可能需要任意的时间来计算答案，但通话是免费的。 在networking上，通话可能需要几百毫秒。
这就是为什么几乎所有的RPC项目，包括CORBA都失败了。
请注意，其他的方式工作得很好：如果你只是假装所有的调用是远程调用，那么最糟糕的情况是你失去了一点性能，你的应用程序包含一些永远不会被使用的error handling代码。 例如，Erlang就是这样工作的。
在Erlang中，进程总是有单独的堆和单独的垃圾收集器，就好像它们在不同的大陆上的不同机器上运行一样，即使这些进程在相同地址空间中的相同CPU上的相同VM上运行。 如果您将数据从一个进程传递到另一个进程，则该数据总是被复制，就像进程在不同的机器上一样。 调用总是作为asynchronous消息发送。
所以，使本地和远程调用看起来不是问题。 让他们看起来像本地电话是。
在CORBA中，问题实际上比这个更复杂一些。 他们实际上确实使本地调用看起来像远程调用，但由于CORBA是由委员会devise的，所以远程调用非常复杂，因为他们必须能够处理一些令人难以置信的荒唐要求。 而且这种复杂性被强加于每个人 ，即使是本地电话。
与Erlang相比，复杂度要低得多。 在Erlang中，向进程发送消息并不比在Java中调用方法复杂。 接口基本相同，只是期望不同：Java中的方法调用预计是即时的，同步的，在Erlang中，消息发送期望是asynchronous的并且具有可见的延迟。 但实际上使用它们并不比简单的本地过程调用更复杂。
另一个区别是，Erlang区分函数调用，这些函数调用只能发生在进程内，因此始终是本地的，而消息发送是在进程之间发生的，并且假定它们始终是远程的，即使它们不是。 在CORBA中，所有的方法调用被认为是远程的。
像CORBA和DCOM这样的分布式对象技术在粒度方面存在问题 – 实现往往过于“健谈”，无法在networking上很好地执行 – 而且通常会泄露实现细节，使解决scheme变得脆弱。
作为对这些问题的回应，服务导向得到了显着的重视。
在维基百科文章中有一个关于它的问题和批评： http : //en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
