有人比較過WCF和ZeroC ICE嗎？

Question

ZeroC的ICE（www.zeroc.com）看起來很有趣，我有興趣查看它並將其與我們現有使用WCF的軟件進行比較。特別是，我們的WCF應用程序使用服務器回調（通過HTTP）。

誰比較他們？它是如何去的？我對性能方面特別感興趣，因爲互操作性對我們來說並不是很重要。謝謝！

Answer 1

幾年前，我對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以實現二進制編碼等。

Answer 2

Michi來自ZeroC的Henning最近剛剛就此主題發表了publisheda white paper - 「選擇中間件：爲什麼性能和可伸縮性能夠（而不是重要）」。它將Ice，WCF（二進制& SOAP）和RMI與各種性能指標，平臺，語言等進行了比較。有關Michi's blog的更多信息，但白皮書也非常易讀，並提供了任何基準測試的所有標準警告。

聲明：我已經廣泛使用Ice和RMI，但從來沒有使用過WCF。

Answer 3

我們正在使用ICE來集成用C++，Java和C＃編寫的模塊。好的是我們的服務器也可以訪問遠程機器上的組件，所以如果我們需要更多的性能，我們可以將處理轉移到不同的機器上。

我已經使用了WCF和ICE，並且我會說ICE在實現方面更加清晰。 ICE也有非常詳細和可讀的文檔。

ICE支持一些事情，WCF不能做的，包括負載均衡，自動遠程客戶端更新等

Answer 4

Apache Thrift是另一個競爭者ICE和WCF。它是由Facebook開發和開源的。 Apache Thrift在某些方面不錯，因爲它不僅在編碼方面非常高效，還支持在不破壞所有客戶端的情況下爲結構添加字段（我們發現對我們的項目非常有用的東西）。

Google Protocol Buffers似乎並不是真正的競爭者，因爲它沒有提到主頁上的.NET支持。但是，一些社區插件支持C＃。此外，如果您正在使用現有服務，則ICE可爲Google協議緩衝區提供仿真。

Answer 5

數據點：我們剛剛將一個回調多平臺和多語言項目從Ice轉換爲Thrift，結果相當不錯。 Ice爲你做了很多事情，所以我們必須自己實施斷開連接的聽衆，連接事件等。在一個案例中，我們用一個大的對象鎖定了Ice，這讓我們可以避開 - 這導致了Thrift服務器的死鎖，但是它可以通過在C＃端進行不太懶惰的編碼來修復。

我剛剛完成了基準測試，在我們的應用程序中推動大量數據的任何事情都比Ice更快或者與Ice相提並論。具有更多頭頂的更短的消息（即，更新協議狀態的「心跳」）稍慢。

最重要的是，爲了正確地實現回調服務，我們必須擴展Thrift接口並定義我們自己的協議以及Thrift「Processor」和回調客戶端 - 服務器。但我坦率地承認我們的申請是/非常/特殊的。現有的協議和服務器應該足夠了。但是擴展它們，甚至使用.Net的多路複用套接字並不是非常困難。