CORBA VS Webservices

虽然最初可能认为CORBA提供了今天提供的Web服务，但是我认为我同意CORBA对于此应用程序似乎“丢失了”。 但是，由于RPC技术在各种平台（嵌入式）上均受支持，并且可以在本机（C ++）上进行良好的工作和测试，并且可以用于实现性能优异的数据传输方案，所以我确实认为CORBA仍然具有重要的利基市场。 \“网络\”与它无关。 直接提到这个问题：我喜欢CORBA \\“ lost \\”，因为与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也是Free）。     

我认为说Web服务已经在市场中脱颖而出并不是很容易的事情。 CORBA充其量只是一个小众市场。 网页服务： 更简单，尽管WS- *会增加重量和复杂性 使用HTTP作为有线协议而不是专有协议 可以通过防火墙中的端口80进行隧道传输 服务不完整 CORBA： 需要ORB才能运行 专有供应商或开源 可以使用HTTP，但也可以使用专有协议 提供诸如命名，目录，事务，安全性等服务。     

CORBA的损失主要是由于两件事： 1）缺乏良好的开发/测试工具或IDE插件 2）再次参见（1）