ZeroC的ICE（www.zeroc.com）看起来很有趣，我有兴趣查看它并将其与使用WCF的现有软件进行比较。特别是，我们的WCF应用程序使用服务器回调（通过HTTP）。
有人比较过这些吗？怎么回事？我对性能方面特别感兴趣，因为互操作性现在并不是我们关注的问题。谢谢！
答案 0 :(得分：13)
几年前我对ICE进行了非常简短的回顾，虽然我之前没有直接对它们进行过比较，但是对WCF有了合理的了解，我的想法可能会有一些相关性。
首先，将WCF与ICE作为WCF进行比较并不公平，因为ICE是一种特定的远程通信机制，而WCF是一种更高级别的远程通信框架。
虽然WCF通常被认为是实现SOAP Web服务，并且它确实是迄今为止的主要用途，但它也可以用于使用各种编码和传输通道实现远程服务，这意味着它理论上可以使用适用于应用程序之间的高效通信。
相比之下，ICE是一种跨平台远程通信机制，它使用二进制编码进行应用程序之间的高性能通信。这是CORBA的简化演变，可以直接与CORBA，DCOM，.NET Remoting和JNI进行比较。
然而，即使ICE和WCF之间没有直接的对应关系，如果您需要.NET应用程序进行远程通信，那么它们都是竞争者。您可能需要考虑的一些决策点包括：
资源化。找到具有WCF经验而不是ICE经验的开发人员会更容易。
性能。如果您需要性能，那么ICE执行速度很快，但WCF也可用于高性能配置。另外，.NET Remoting可以提供非常好的性能，无论MS赞助的基准测试如何，我都看到它比WCF高出10％。
跨平台。如果您需要与非Windows应用程序通信，那么您可以使用可以使用的WCF选项。此外，由于每个SOAP堆栈似乎都以不同的方式实现标准，因此创建真正通用的Web服务会很麻烦（尽管WS-I有帮助）
如果你从第一天开始就不需要每一盎司的性能，那么我个人就会选择WCF，然后考虑ICE，如果性能变得至关重要的话。即便如此，扩展服务盒可能比迁移到ICE更便宜，如果您没有任何异乎寻常的跨平台需求，那么您可以随时查看重新配置WCF以进行二进制编码等。
答案 1 :(得分：11)
来自ZeroC的Michi Henning最近published a white paper就这个话题进行了讨论 - “选择中间件：为什么性能和可伸缩性做（而且不做）很重要”。它将Ice，WCF（二进制和SOAP）和RMI与各种性能指标，平台，语言等进行了比较。有关Michi's blog的更多信息，但白皮书也非常易读，所有标准注意事项都是任何基准。
免责声明：我广泛使用过Ice和RMI，但从未使用过WCF。
答案 2 :(得分：2)
Apache Thrift是ICE和WCF的另一个竞争者。它是由Facebook开发和开源的。 Apache Thrift在某些方面很不错，因为它不仅在编码方面非常高效，而且还支持在不破坏所有客户端的情况下向结构添加字段（我们认为这对我们的项目非常有用）。
Google Protocol Buffers似乎不是真正的竞争者，因为它没有在主页上提到.NET支持。但是，一些社区插件支持C＃。此外，如果您正在使用现有服务，ICE会为Google协议缓冲区提供仿真。
答案 3 :(得分：1)
数据点：我们刚刚将一个回调的多平台和多语言项目从Ice转换为Thrift，效果非常好。 Ice为你做了很多，所以我们必须自己实现断开连接侦听器，连接事件等。在一个案例中，我们在谚语中得到了一个巨大的对象锁定，Ice让我们逃脱了 - 这导致了Thrift服务器的死锁，但很容易通过C＃端的不那么懒的编码来解决。
我刚刚完成基准测试，在我们的应用程序中，推送大量数据的任何内容都比Ice更快或者与之相提并论。具有更多开头的较短消息（即，＃34;心跳＆＃34;通过协议更新状态）稍慢。
最重要的一点是，为了正确实现回调服务，我们必须扩展Thrift接口并定义我们自己的协议，以及Thrift＆＃34;处理器＆＃34;和回调客户端 - 服务器。但我承认我们的申请是/非常/特殊的。现有协议和服务器应该足够了。但扩展它们，即使使用.Net的多路套接字也不是非常困难。
答案 4 :(得分：0)
我们正在使用ICE来集成用C ++，Java和C＃编写的模块。好消息是我们的服务器也可以访问远程机器上的组件，因此如果我们需要更高的性能，我们可以将处理转移到不同的机器上。
我已经使用了WCF和ICE，我会说ICE在实现方面更清洁。 ICE还有非常详细和可读的文档。
ICE支持WCF无法做的一些事情，包括负载平衡，自动远程客户端更新等。