虽然最初 CORBA 可能被认为提供了当今 Web 服务所提供的功能，但我认为我同意对于这个应用程序 CORBA 似乎已经“迷失”了。
然而，作为一种在多种平台（嵌入式）上受支持、在本机（C++）上运行良好且经过良好测试、并且可用于实现相当高性能的数据传输场景的 RPC 技术，我确实认为 CORBA 仍然有一个优势。重要的利基市场。它与“网络”无关。
直接提到这个问题：我喜欢认为 CORBA“迷失”了，因为与 WebServices 不同，它不是针对当今使用的 Web 的 - 例如：通过端口 80 隧道传输所有内容，在 60% 的网络中运行应用程序浏览器和 40% 在网络服务器等中。
我怀疑一切都是从防火墙问题开始的:CORBA请求是二进制的,正常工作需要多个随机端口,因此CORBA请求和响应在防火墙首次出现时曾被阻止.HTTP和FTP也使用幻像端口,但这些协议的使用范围要广得多,因此很明显防火墙必须配置为允许它们.因此,开发人员不能依赖于在服务器和最终用户PC之间建立CORBA连接的可能性,并且需要使用更多防火墙友好的方法.
与使用单独的网络,IP/MAC过滤,专用防火墙等相比,防火墙在专用服务器之间的通信中出现的问题要少得多.我认为CORBA和JDBC一样,仍然用于在服务器之间传递数据.
它也可能是CORBA消息使用对齐字段的因素(以匹配在C/C++数据结构中使用的边界对齐).派生协议(如Google协议缓冲区)不会仅为了对齐而发送不必要的字节.因此,它们是紧凑的,并且当需要二进制消息和快速预生成的消息解析器时,这些协议可能是优选的.在我看来,类似于CORBA的协议缓冲区(类似IDL的编译器,存根和服务器,二进制消息,语言互操作性)实际上远非衰落,而是在许多Google服务中内部使用.
虽然CORBA框架很复杂,但"正确完成"的Web服务堆栈也不是很简单,所以我不认为标准的复杂性是一个问题.同样,虽然原始的OMG规范文档可能看起来很糟糕,但类似的SOAP/WDSL规范同样复杂,可能难以以易于阅读的方式记录标准.
CORBA协议不是专有的,它们已经在Free软件中实现了很多次,包括JacORB和GNU/Classpath实现(好吧,现在OpenJDK也是免费的).