¿Alguien ha comparado WCF y ZeroC ICE?
callback (5)
El 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 comparó? ¿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!
Hice una revisión muy escueta 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 alguna relevancia.
En primer lugar, no es justo comparar WCF con ICE como WCF ya que ICE es un mecanismo de comunicación remota específico y WCF es un marco de comunicaciones remotas de mayor nivel.
Aunque 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 teóricamente se puede usar para comunicaciones de rendimiento entre aplicaciones.
En comparación, ICE es un mecanismo de comunicación remota multiplataforma que utiliza codificación binaria para comunicaciones entre aplicaciones. Es una evolución simplificada de CORBA y se puede comparar más directamente con CORBA, DCOM, .NET Remoting y JNI.
Sin embargo, aunque no hay correspondencia directa entre ICE y WCF, si necesita que su aplicación .NET se comunique de forma remota, ambos son contendientes. Algunos de los puntos de decisión que quizás desee considerar incluyen:
Recursos. Será más fácil encontrar desarrolladores con experiencia WCF que experiencia ICE.
Actuación. Si desea rendimiento, ICE funciona rápidamente, pero WCF también se puede usar en una configuración de rendimiento. Alternativamente, .NET Remoting puede proporcionar muy buen rendimiento, y cualquiera que sea el punto de referencia patrocinado por MS dice que he visto que supera a WCF en un 10%.
Multiplataforma. Si necesita comunicarse con aplicaciones que no son de Windows, entonces tiene limitaciones con las opciones de WCF que puede usar. Además, dado que cada pila de SOAP parece implementar los estándares de manera diferente, puede ser doloroso crear servicios web verdaderamente genéricos (aunque WS-I ayuda)
Si no necesita cada onza de rendimiento desde el primer día, personalmente comenzaría con WCF, y luego consideraría ICE si el rendimiento llega a ser crítico. Incluso entonces podría ser más económico ampliar sus cajas de servicios que trasladarse a ICE, y si no tiene necesidades exóticas multiplataforma, siempre podría ver la reconfiguración de WCF para codificación binaria, etc.
Michi Henning de ZeroC ha publicado recientemente un libro blanco sobre este tema: "Elegir middleware: por qué el rendimiento y la escalabilidad son (y no) importantes". Compara Ice, WCF (binario y SOAP) y RMI con diversas métricas de rendimiento, plataformas, idiomas, etc. Hay más información en el blog de Michi , pero el libro blanco también es bastante legible, con todas las salvedades estándar de cualquier punto de referencia.
Descargo de responsabilidad: He utilizado Ice y RMI extensamente, pero nunca WCF.
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 cuanto a 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.
Apache Thrift es otro contendiente para ICE y WCF. Fue desarrollado y abierto por Facebook. Apache Thrift es agradable de alguna manera porque no solo es extremadamente eficiente en el lado de la codificación, también admite agregar campos a las estructuras sin romper todos los clientes (algo que encontramos extremadamente útil para nuestros proyectos).
Google Protocol Buffers no parece ser realmente un contendiente, ya que no menciona el soporte de .NET en la página de inicio. Sin embargo, algunos complementos de la comunidad admiten C #. Además, ICE proporciona emulación para Buffers de Protocolo de Google si está trabajando con servicios existentes.
Punto de datos: acabamos de convertir un proyecto de devolución de llamada multiplataforma y multi idioma de Ice a Thrift con muy buenos resultados. Ice hace mucho por ti, por lo que tuvimos que implementar escuchas de desconexión, eventos de conexión, etc. Y en un caso obtuvimos algo en el proverbial con un gran bloqueo de objeto que Ice nos permitía salirse con la tuya, esto causó un punto muerto en el servidor Thrift pero fue reparado fácilmente por una codificación menos perezosa en el lado C #.
Acabo de finalizar la evaluación comparativa, y en nuestra aplicación todo lo que empuja grandes cantidades de datos es más rápido que, o está a la altura de Ice. Los mensajes más cortos con más sobreestiramiento (es decir, un "latido" que actualiza un estado sobre el protocolo) es un poco más lento.
El aspecto más importante fue que, para implementar correctamente el servicio de devolución de llamada, tuvimos que ampliar las interfaces Thrift y definir nuestro propio protocolo, junto con un Thrift "Processor" y un callback cliente-servidor. Pero admito que nuestra aplicación es / muy / especial. Los protocolos y servidores existentes deberían ser suficientes. Pero extenderlos, incluso para usar conectores multiplex de .Net, no fue terriblemente difícil.