¿Alguien ha comparado WCF y ZeroC ICE?

Question

ICE de ZeroC (www.zeroc.com) parece interesante y estoy interesado en verlo y compararlo con nuestro software existente que usa WCF.En particular, nuestra aplicación WCF utiliza devoluciones de llamada del servidor (a través de HTTP).

¿Alguien que los haya comparado?¿Como le fue?Estoy particularmente interesado en el aspecto del rendimiento, ya que la interoperabilidad no es una gran preocupación para nosotros en este momento.¡Gracias!

Answer 1

Hice una revisión muy concisa de ICE hace unos años y, aunque no los he comparado directamente antes, teniendo un conocimiento razonable de WCF, mis pensamientos podrían tener cierta relevancia.

En primer lugar, no es del todo justo comparar WCF con ICE, ya que WCF es un mecanismo de comunicación remota específico y WCF es un marco de comunicaciones remotas de nivel superior.

Si bien a menudo se piensa que WCF implementa servicios web SOAP, y ese es de hecho su uso principal hasta la fecha, también se puede usar para implementar servicios remotos utilizando todo tipo de codificaciones y canales de transporte, lo que significa que, en teoría, se puede usar para comunicaciones de alto rendimiento. entre aplicaciones.

En comparación, ICE es un mecanismo de comunicación remota multiplataforma que utiliza codificación binaria para comunicaciones eficientes entre aplicaciones.Es una especie de evolución simplificada de CORBA y es más directamente comparable a CORBA, DCOM, .NET Remoting y JNI.

Sin embargo, aunque no existe correspondencia directa entre ICE y WCF, si necesita que su aplicación .NET se comunique de forma remota, ambos son competidores.Algunos de los puntos de decisión que quizás desee considerar incluyen:

• Recursos.Será más fácil encontrar desarrolladores con experiencia en WCF que en ICE.

• Actuación.Si desea rendimiento, ICE funciona rápido, pero WCF también se puede usar en una configuración de alto rendimiento.Alternativamente, .NET Remoting puede proporcionar un rendimiento muy bueno y, independientemente de lo que digan los puntos de referencia patrocinados por MS, he visto que supera a WCF en un 10%.

• Multiplataforma.Si necesita comunicarse con aplicaciones que no son de Windows, las opciones de WCF que puede usar están limitadas.Además, dado que cada pila SOAP parece implementar los estándares de manera diferente, puede resultar complicado crear servicios web verdaderamente genéricos (aunque WS-I ayuda).

Si no necesita cada gramo de rendimiento desde el primer día, entonces personalmente elegiría WCF para empezar y luego consideraría ICE si el rendimiento alguna vez se vuelve crítico.Incluso entonces, podría ser más barato ampliar sus cajas de servicios que pasar a ICE, y si no tiene ninguna necesidad multiplataforma exótica, siempre puede considerar reconfigurar WCF para codificación binaria, etc.

Answer 2

Michi Henning de ZeroC recientemente publicado un papel blanco sólo sobre este tema: "Elección de middleware:Por qué el rendimiento y la escalabilidad son (y no) importantes".Compara Ice, WCF (binario y SOAP) y RMI con varias métricas de rendimiento, plataformas, lenguajes, etc.Hay más información sobre el blog de michi, pero el documento técnico también es bastante legible, con todas las advertencias estándar de cualquier punto de referencia.

Descargo de responsabilidad:He usado Ice y RMI ampliamente, pero nunca WCF.

Answer 3

Ahorro Apache es otro contendiente de ICE y WCF.Fue desarrollado y de código abierto por Facebook. Ahorro Apache es bueno en algunos aspectos porque no sólo es extremadamente eficiente en el lado de la codificación, sino que también admite la adición de campos a estructuras sin romper todos los clientes (algo que encontramos extremadamente útil para nuestros proyectos).

Búfers de protocolo de Google No parece realmente un competidor ya que no menciona la compatibilidad con .NET en la página de inicio.Sin embargo, algunos complementos de la comunidad son compatibles con C#.Además, HIELO proporciona emulación para los búferes de protocolo de Google si está trabajando con servicios existentes.

Answer 4

Punto de datos:Acabamos de convertir un proyecto multiplataforma y multilingüe de devolución de llamada de Ice a Thrift con resultados bastante buenos.Ice hace mucho por usted, por lo que tuvimos que implementar oyentes de desconexión, eventos de conexión, etc.nosotros mismos.Y en un caso, nos mordió el proverbial bloqueo de un objeto grande que Ice nos estaba dejando salirnos con la nuestra; esto causó un punto muerto en el servidor Thrift, pero se solucionó fácilmente con una codificación menos diferida en el lado de C#.

Acabo de terminar la evaluación comparativa y en nuestra aplicación, cualquier cosa que impulse grandes cantidades de datos es más rápido que Ice o está a la par con él.Los mensajes más cortos con más gastos generales (es decir, un "latido" que actualiza un estado a través del protocolo) son un poco más lentos.

Lo más importante fue que para implementar correctamente el servicio de devolución de llamada, tuvimos que ampliar las interfaces de Thrift y definir nuestro propio protocolo, junto con un "Procesador" de Thrift y un cliente-servidor de devolución de llamada.Pero admito libremente que nuestra aplicación es /muy/ especial.Los protocolos y servidores existentes deberían ser suficientes.Pero ampliarlos, incluso para utilizar sockets multiplex de .Net, no fue muy difícil.

Answer 5

Estamos utilizando ICE para integrar módulos escritos en C++, Java y C#.Lo bueno es que nuestro servidor también puede acceder a componentes en máquinas remotas, por lo que si necesitamos más rendimiento podemos cambiar el procesamiento a diferentes máquinas.

He usado tanto WCF como ICE, y diría que ICE es más limpio en el lado de la implementación.ICE también tiene documentación muy detallada y legible.

ICE admite algunas cosas que WCF no puede hacer, incluido el equilibrio de carga, actualizaciones automatizadas de clientes remotos, etc.