Hat jemand WCF und ZeroC ICE verglichen?

Question

ZeroCs ICE (www.zeroc.com) sieht interessant aus und ich bin daran interessiert, es anzuschauen und es mit unserer bestehenden Software, die WCF verwendet, zu vergleichen. Insbesondere verwendet unsere WCF-App Server-Callbacks (über HTTP).

Wer hat sie verglichen? Wie ist es gelaufen? Ich bin besonders an der Performance interessiert, da Interoperabilität für uns momentan keine große Rolle spielt. Vielen Dank!

Answer 1

Ich habe vor ein paar Jahren eine sehr knappe Rezension von ICE gemacht, und obwohl ich sie nicht direkt vorher verglichen habe, mit vernünftigen Kenntnissen von WCF meine Gedanken könnten etwas Relevanz haben.

Erstens ist es nicht fair, WCF mit ICE als WCF zu vergleichen, da ICE ein spezieller Fernkommunikationsmechanismus ist und WCF ein übergeordnetes Fernübertragungs-Framework ist.

Während WCF oft als Implementierung von SOAP-Webdiensten betrachtet wird, und das ist tatsächlich seine Hauptverwendung, kann es auch für die Implementierung von Remote-Diensten mit allen Arten von Codierungen und Transportkanälen verwendet werden, was theoretisch bedeutet Wird für performante Kommunikation zwischen Anwendungen verwendet.

Im Vergleich dazu ist ICE ein plattformübergreifender Fernkommunikationsmechanismus, der die binäre Codierung für die performante Kommunikation zwischen Anwendungen verwendet. Es ist eine vereinfachte Version von CORBA und ist direkter mit CORBA, DCOM, .NET Remoting und JNI vergleichbar.

Auch wenn es keine direkte Korrespondenz zwischen ICE und WCF gibt, wenn Sie Ihre .NET-App benötigen, um aus der Ferne zu kommunizieren, dann sind beide Konkurrenten. Einige der Entscheidungspunkte, die Sie in Erwägung ziehen sollten, sind:

• Resourcing. Es wird einfacher sein, Entwickler mit WCF-Erfahrung als ICE-Erfahrung zu finden.

• Leistung. Wenn Leistung gewünscht wird, wird ICE zwar schnell ausgeführt, WCF kann jedoch auch in einer performanten Konfiguration verwendet werden. Alternativ kann .NET Remoting eine sehr gute Leistung bieten, und was auch immer die von MS gesponserten Benchmarks sagen, ich habe gesehen, dass es WCF um 10% übertroffen hat.

• Plattformübergreifend. Wenn Sie mit Nicht-Windows-Anwendungen kommunizieren müssen, sind Sie mit den WCF-Optionen eingeschränkt, die Sie verwenden können. Da darüber hinaus die Standards jeder SOAP-Stack scheint anders zu implementieren kann es ein Schmerz wirklich generische Web Services zu schaffen sein

(obwohl WS-I hilft) Wenn Sie jedes Quäntchen Leistung von Tag nicht brauchen ein Dann würde ich mich persönlich für WCF entscheiden und dann über ICE nachdenken, wenn die Leistung jemals kritisch wird. Selbst dann könnte es günstiger sein, Ihre Service-Boxen zu skalieren, als in ICE zu wechseln, und wenn Sie keine exotischen plattformübergreifenden Anforderungen haben, können Sie WCF immer für die Binärcodierung umgestalten.

Answer 2

Michi Henning von ZeroC hat kürzlich publisheda white paper zu genau diesem Thema - "Middleware wählen: Warum Leistung und Skalierbarkeit (und nicht) wichtig". Es vergleicht Ice, WCF (binär & SOAP) und RMI mit verschiedenen Leistungsmetriken, Plattformen, Sprachen, usw. Es gibt mehr Informationen über Michi's blog, aber das White Paper ist auch gut lesbar, mit allen üblichen Vorbehalte jedes Benchmarks.

Haftungsausschluss: Ich habe Ice und RMI ausgiebig verwendet, aber niemals WCF.

Answer 3

Wir verwenden ICE, um Module in C++, Java und C# zu integrieren. Das Schöne ist, dass unser Server auch auf Komponenten auf entfernten Maschinen zugreifen kann. Wenn wir mehr Leistung benötigen, können wir die Verarbeitung auf verschiedene Maschinen verlagern.

Ich habe sowohl WCF und ICE verwendet, und ich würde sagen, dass ICE auf der Implementierungsseite sauberer ist. ICE hat auch sehr detaillierte und lesbare Dokumentation.

ICE unterstützt einige Dinge, die WCF nicht tun können, einschließlich Load-Balancing, automatisiertes Remote-Client-Updates usw.

Answer 4

Apache Thrift ist ein weiterer Anwärter auf ICE und WCF. Es wurde von Facebook entwickelt und offen gelegt. Apache Thrift ist in mancher Hinsicht schön, weil es nicht nur extrem effizient auf der Codierungsseite ist, sondern auch das Hinzufügen von Feldern zu Strukturen unterstützt, ohne alle Clients zu zerstören (was wir für unsere Projekte als äußerst nützlich fanden).

Google Protocol Buffers würde nicht wirklich ein Anwärter scheinen, wie es .NET Unterstützung auf der Homepage nicht erwähnt. Einige Community-Addons unterstützen jedoch C#. Darüber hinaus bietet ICE eine Emulation für Google-Protokollpuffer, wenn Sie mit vorhandenen Diensten arbeiten.

Answer 5

Datenpunkt: Wir haben gerade ein Callback-Multi-Plattform- und Multi-Language-Projekt von Ice zu Thrift mit ziemlich guten Ergebnissen umgewandelt. Eis macht viel für Sie, also mussten wir selbst Unterbrechungshörer, Verbindungsereignisse usw. implementieren. Und in einem Fall waren wir etwas sprichwörtlich mit einer großen Objektverriegelung, mit der Ice uns davonkommen ließ - dies verursachte einen Deadlock im Thrift-Server, aber er wurde leicht durch weniger faules Codieren auf der C# -Seite behoben.

Ich bin gerade mit dem Benchmarking fertig, und in unserer Anwendung ist alles, was große Datenmengen transportiert, schneller als Ice oder auf Augenhöhe mit Ice. Kürzere Nachrichten mit mehr Overhead (d. H. Ein "Herzschlag", der einen Status über das Protokoll aktualisiert) sind etwas langsamer.

Das wichtigste war, dass wir, um den Callback-Dienst korrekt zu implementieren, Thrift-Schnittstellen erweitern und unser eigenes Protokoll zusammen mit einem Thrift "Processor" und Callback-Client-Server definieren mussten. Aber ich gebe gerne zu, dass unsere Bewerbung sehr/besonders ist. Die vorhandenen Protokolle und Server sollten ausreichen. Aber sie zu erweitern, selbst Multiplex-Sockets von .Net zu verwenden, war nicht besonders schwierig.