我从来没有听过任何人谈论CORBA的任何东西，只有嘲弄的条款，这是奇怪的，考虑到10多年前它是蜜蜂的膝盖。为什么CORBA会失宠呢？是纯粹的实施是坏的还是有更基本的东西？
答案 0 :(得分：142)
这不仅仅是CORBA，它通常是RPC。这包括DCOM，Java-RMI，.NET Remoting等所有内容。
问题基本上是分布式计算从根本上与本地计算不同。 RPC尝试假装这些差异不存在，并使远程调用看起来就像本地调用一样。但是，为了构建一个好的分布式系统，你需要处理这些差异。
Bill Joy，Tom Lyon，L。Peter Deutsch和James Gosling确定了分布式计算的8个谬误，即分布式编程的新手认为是真实的，但实际上这是假的，通常导致项目失败或成本和工作量大幅增加。 RPC是这些谬误的完美体现，因为它建立在同样错误的假设之上：
所有这一切都适用于本地计算。
获取可靠性，例如：如果您在本地调用方法，则调用本身始终成功。当然，被调用的方法本身可能有错误，但方法的实际调用总是会成功。并且将始终返回结果，或者，如果方法失败，将发出错误信号。
在分布式系统中，情况并非如此：调用方法本身的行为可能会失败。即从你的结尾看起来你调用了这个方法，但是这个调用实际上已经丢失在网络上并且从未到达过该方法。或者，该方法成功接收到呼叫并执行了操作，但结果在返回给您的路上丢失了。或者方法失败，但错误丢失了。
与延迟类似：在本地，调用方法基本上是免费的。方法本身可能需要花费任意时间来计算答案，但调用是免费的。通过网络，呼叫可能需要数百毫秒。
这就是为什么几乎所有RPC项目，包括CORBA都失败了。
请注意，另一种方法可以正常工作：如果您只是假装所有调用是远程调用，那么可能发生的最糟糕的事情是您丢失了一点点的性能和你的应用程序包含一些永远不会使用的错误处理代码。这就是Erlang的工作方式，例如。
在Erlang中，进程总是具有单独的堆和单独的垃圾收集器，就像它们在不同大洲的不同机器上运行一样，即使这些进程在同一个CPU上的同一个VM上运行相同的地址空间。如果您将数据从一个进程传递到另一个进程，则该数据始终被复制，就像它必须是，如果进程位于不同的计算机上。调用始终作为异步消息发送。
因此，使本地和远程调用看起来相同的不是问题。使它们看起来像本地调用是。
在CORBA中，问题实际上比这更令人费解。他们实际上做了使本地调用看起来像远程调用，但由于CORBA是由委员会设计的，远程调用难以置信复杂，因为他们必须能够处理一些令人难以置信的荒谬要求。而这种复杂性被迫每个人，甚至是本地电话。
同样，与Erlang相比，复杂性要低得多。在Erlang中，向进程发送消息并不比在Java中调用方法复杂。接口基本相同，只是期望不同：Java中的方法调用预计是瞬时和同步的，在Erlang中，消息发送预期是异步的并且具有可见的延迟。但实际上使用它们并不比简单的本地过程调用更复杂。
另一个区别是Erlang区分函数调用，它们只能在进程内发生，因此总是本地的，而消息发送则发生在进程之间，并且假定它们总是远程的，即使它们不是远程的。在CORBA中，假定所有方法调用都是远程的。
答案 1 :(得分：9)
像CORBA和DCOM这样的分布式对象技术存在粒度问题 - 实现往往过于“繁琐”以至于无法在网络上运行 - 而且通常会泄露实施细节，使解决方案变得脆弱。
服务导向作为对这些问题的反应而受到重视。