Alguém comparou WCF e zeroc ICE?

Question

ICE de zeroc (www.zeroc.com) parece interessante e estou interessado em olhar para isso e comparando-a com o nosso software existente que usa WCF. Em particular, nosso aplicativo WCF usa retornos de chamada do servidor (via HTTP).

Qualquer um que comparou-os? Como foi? Estou particularmente interessado no aspecto de desempenho, uma vez que a interoperabilidade não é muito de uma preocupação para nós no momento. Obrigado!

Answer 1

Eu fiz um comentário muito concisa da ICE, há alguns anos, e embora eu não tenha comparado diretamente antes, ter conhecimento razoável de WCF meus pensamentos pode ter alguma relevância.

Em primeiro lugar, não é entierely justo comparar WCF com o ICE como WCF como ICE é um mecanismo de comunicação remoto específico e WCF é um framework de comunicações remotas de nível superior.

Enquanto WCF é muitas vezes visto como a implementação de serviços web SOAP e que é de fato sua principal utilização até à data, ele pode também ser usado para implementação de serviços remotos usando todos os tipos de codificações e canais de transporte, o que significa que pode, teoricamente, ser usado para comms de elevada performance entre as aplicações.

Em comparação, ICE é um multi-plataforma remota mecanismo communicaton que utiliza codificação binária para comunicações de elevada performance entre as aplicações. É algo de uma evolução simplificada de CORBA e é mais diretamente comparável ao CORBA, DCOM, .NET Remoting, e JNI.

No entanto, mesmo que não há correspondência direta entre ICE e WCF, se você precisar de seu aplicativo .NET para comunicar-se remotamente, em seguida, eles são ambos os candidatos. Alguns dos pontos de decisão que você pode querer considerar incluem:

• Resourcing. Vai ser mais fácil encontrar desenvolvedores com experiência WCF do que a experiência ICE.

• Performance. Se você quiser desempenho, em seguida, executa gelo permanente, mas WCF também pode ser usado em uma configuração de alto desempenho. Alternativamente, .NET Remoting pode fornecer um desempenho muito bom, e quaisquer que sejam os benchmarks MS patrocinados dizer que eu vi ele superar WCF em 10%.

• Cross-plataforma. Se você precisa se comunicar com aplicações não-Windows, em seguida, você está limitado com as opções WCF você pode usar. Além disso, uma vez que cada pilha de SOAP parece implementar as normas de forma diferente pode ser uma dor criação de Web Services verdadeiramente genéricos (embora WS-I ajuda)

Se você não precisa de cada gota de desempenho desde o primeiro dia, então eu pessoalmente engordar para WCF para começar, e então considerar ICE se o desempenho cada vez torna-se crítica. Mesmo assim, pode ser mais barato para escalar suas caixas de serviço do que está a mover-se para ICE, e se você não tem quaisquer necessidades de plataforma cruzada exóticas, então você pode sempre olhar para reconfigurar WCF para binário codificação etc

Answer 2

Michi Henning de zeroc tem rel="noreferrer"> recentemente um papel branco em apenas neste tópico - "Escolhendo Middleware: por Desempenho e Escalabilidade fazer (e não) Matter". Ele compara Ice, WCF (binário e SOAP) e RMI com várias métricas de desempenho, plataformas, linguagens, etc. Não há mais informações sobre o blog de Michi, mas o papel branco também é bastante legível, com todas as ressalvas padrão de qualquer referência.

Disclaimer:. Eu usei Gelo e RMI extensivamente, mas nunca WCF

Answer 3

Apache Thrift é outro candidato a ICE e WCF. Foi desenvolvido e código aberto pelo Facebook. Apache Thrift é bom em alguns aspectos, porque não só é extremamente eficiente no lado de codificação, ele também suporta a adição de de campos para estruturas sem quebrar todos os clientes (algo que achei extremamente útil para os nossos projectos).

Google Protocol Buffers parece não é realmente um candidato como ele doesn 't mencionar suporte .NET na página inicial. No entanto, alguns complementos comunitários de apoio C #. Além disso, ICE fornece emulação para Google Protocol Buffers Se você está trabalhando com os serviços existentes.

Answer 4

ponto de dados: nós só converteu um retorno de chamada multi-plataforma e projeto multi-linguagem de gelo para Thrift com bons resultados bonitas. Ice faz muito por você, por isso tivemos que implementar ouvintes desconexão, eventos de conexão, etc. nós mesmos. E em um caso que temos pouco no proverbial com um grande bloqueio objeto que Ice estava nos deixando fugir com -. Isso causou um impasse no servidor Thrift mas foi facilmente corrigido pelo menos preguiçoso codificação no lado do C #

Eu tenho o benchmarking apenas acabado, e em nossa aplicação qualquer coisa que empurra grandes quantidades de dados é mais rápido do que, ou a par com, Ice. mensagens mais curtas com mais over-cabeça (ou seja, uma "pulsação" que atualiza o status através do protocolo) é um pouco mais lento.

O bit mais importante foi que, a fim de implementar o serviço de retorno de chamada corretamente tivemos que estender interfaces de Thrift e definir o nosso próprio protocolo, juntamente com uma Thrift "Processador" e callback cliente-servidor. Mas admito livremente a nossa aplicação é / muito / especial. Os protocolos e servidores existentes deve ser suficiente. Mas estendendo-os, até mesmo para usar soquetes multiplex da Net, não foi terrivelmente difícil.

Answer 5

Estamos usando ICE para integrar módulos escritos em C ++, Java e C #. O bom é que os nossos componentes de acesso do servidor pode em máquinas remotas, bem, por isso, se precisamos de mais performance que pode mudar o processamento de máquinas diferentes.

Eu usei tanto WCF e ICE, e eu diria que o ICE é mais limpo do lado de implementação. ICE também muito detalhado e documentação legível.

ICE suporta algumas coisas que WCF não pode fazer, incluindo o balanceamento de carga, atualizações do cliente remotos automatizados, etc.