为什么CORBA失去了人气？

Question

我从来没有听过任何人谈论CORBA的任何东西,除了嘲弄的条款,这是奇怪的,考虑到10多年前它是蜜蜂的膝盖.为什么CORBA会失宠呢？是纯粹的实施是坏的还是有更基本的东西？

Answer 1

它不仅仅是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. 网络是同质的.

所有这一切都适用于本地计算.

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

在分布式系统中,情况并非如此:调用方法本身的行为可能会失败.即从你的结尾看起来你调用了这个方法,但是这个调用实际上已经丢失在网络上并且从未到达过该方法.或者,该方法成功接收了呼叫并执行了操作,但结果在返回给您的路上丢失了.或者方法失败,但错误丢失了.

与延迟类似:在本地,调用方法基本上是免费的.该方法本身可能需要任意长的时间来计算答案,但该呼叫是免费的.通过网络,呼叫可能需要数百毫秒.

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

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

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

因此,使本地和远程调用看起来一样不是问题.使它们看起来像本地电话是.

在CORBA中,问题实际上比这更令人费解.他们实际上确实使本地呼叫看起来像远程呼叫,但由于CORBA是由委员会设计的,因此远程呼叫非常复杂,因为它们必须能够处理一些令人难以置信的荒谬要求.这种复杂性迫使所有人,甚至是本地电话.

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

另一个区别是Erlang区分函数调用,它们只能在进程内发生,因此始终是本地的,而消息发送则发生在进程之间,并且假定它们总是远程的,即使它们不是远程的.在CORBA中,假定所有方法调用都是远程的.

Answer 2

像CORBA和DCOM这样的分布式对象技术存在粒度问题 - 实现往往过于"繁琐"以至于无法在网络上运行 - 并且通常泄露实现细节,这使得解决方案变得脆弱.

服务导向作为对这些问题的反应而受到重视.