Qualcuno ha confrontato WCF e ZeroC ICE?

Question

ICE di ZeroC (www.zeroc.com) sembra interessante e sono interessato a guardarlo e confrontarlo con il nostro software esistente che utilizza WCF.In particolare, la nostra app WCF utilizza i callback del server (tramite HTTP).

Qualcuno che li ha confrontati?Com'è andata?Sono particolarmente interessato all'aspetto prestazionale, dal momento che l'interoperabilità non è una grande preoccupazione per noi in questo momento.Grazie!

Answer 1

Ho fatto una recensione molto concisa di ICE alcuni anni fa e, sebbene non li abbia mai confrontati direttamente prima, avendo una conoscenza ragionevole di WCF, i miei pensieri potrebbero avere una certa rilevanza.

In primo luogo, non è del tutto corretto confrontare WCF con ICE come WCF poiché ICE è un meccanismo di comunicazione remota specifico e WCF è un framework di comunicazione remota di livello superiore.

Sebbene WCF sia spesso pensato come un'implementazione di servizi Web SOAP, e questo è in effetti il ​​suo utilizzo principale fino ad oggi, può anche essere utilizzato per implementare servizi remoti utilizzando tutti i tipi di codifiche e canali di trasporto, il che significa che può teoricamente essere utilizzato per comunicazioni performanti. tra le applicazioni.

In confronto, ICE è un meccanismo di comunicazione remota multipiattaforma che utilizza la codifica binaria per comunicazioni efficienti tra le applicazioni.Si tratta di un'evoluzione semplificata di CORBA ed è più direttamente paragonabile a CORBA, DCOM, .NET Remoting e JNI.

Tuttavia, anche se non esiste una corrispondenza diretta tra ICE e WCF, se hai bisogno che la tua app .NET comunichi in remoto, sono entrambi contendenti.Alcuni dei punti decisionali che potresti prendere in considerazione includono:

• Risorse.Sarà più facile trovare sviluppatori con esperienza WCF che con esperienza ICE.

• Prestazione.Se desideri prestazioni, ICE funziona velocemente, ma WCF può essere utilizzato anche in una configurazione performante.In alternativa, .NET Remoting può fornire prestazioni molto buone e, qualunque cosa dicano i benchmark sponsorizzati da MS, l'ho visto sovraperformare WCF del 10%.

• Multipiattaforma.Se devi comunicare con applicazioni non Windows, le opzioni WCF che puoi utilizzare sono limitate.Inoltre, poiché ogni stack SOAP sembra implementare gli standard in modo diverso, può essere difficile creare servizi Web veramente generici (anche se WS-I aiuta)

Se non hai bisogno di ogni grammo di prestazioni fin dal primo giorno, personalmente consiglierei WCF per iniziare, e poi prenderei in considerazione ICE se le prestazioni dovessero mai diventare critiche.Anche in questo caso potrebbe essere più economico ampliare le tue caselle di servizio piuttosto che passare a ICE e, se non hai esigenze esotiche multipiattaforma, potresti sempre provare a riconfigurare WCF per la codifica binaria, ecc.

Answer 2

Michi Henning di ZeroC l'ha fatto di recente pubblicato un foglio bianco proprio su questo argomento: "Scelta del middleware:Perché prestazioni e scalabilità contano (e non contano).Confronta Ice, WCF (binario e SOAP) e RMI con vari parametri di prestazione, piattaforme, linguaggi, ecc.Ci sono più informazioni su Il blog di Michi, ma il white paper è anche abbastanza leggibile, con tutte le avvertenze standard di qualsiasi benchmark.

Disclaimer:Ho utilizzato ampiamente Ice e RMI, ma mai WCF.

Answer 3

Apache parsimonia è un altro contendente a ICE e WCF.È stato sviluppato e reso open source da Facebook. Apache parsimonia è carino in un certo senso perché non solo è estremamente efficiente dal punto di vista della codifica, ma supporta anche l'aggiunta di campi alle strutture senza interrompere tutti i client (qualcosa che abbiamo trovato estremamente utile per i nostri progetti).

Buffer del protocollo Google sembrerebbe non proprio un contendente in quanto non menziona il supporto .NET nella home page.Tuttavia, alcuni componenti aggiuntivi della community supportano C#.Inoltre, GHIACCIO fornisce l'emulazione per i buffer di protocollo di Google se lavori con servizi esistenti.

Answer 4

Punto dati:abbiamo appena convertito un progetto callback multipiattaforma e multilingue da Ice a Thrift con risultati piuttosto buoni.Ice fa molto per te, quindi abbiamo dovuto implementare ascoltatori di disconnessione, eventi di connessione, ecc.noi stessi.E in un caso siamo rimasti colpiti dal proverbiale blocco di un grosso oggetto con cui Ice ci stava permettendo di farla franca: questo ha causato un deadlock nel server Thrift ma è stato facilmente risolto con una codifica meno pigra sul lato C#.

Ho appena finito il benchmarking e nella nostra applicazione tutto ciò che invia grandi quantità di dati è più veloce o alla pari di Ice.I messaggi più brevi con più sovraccarico (ad esempio un "battito cardiaco" che aggiorna uno stato tramite il protocollo) sono un po' più lenti.

La cosa più importante è stata che per implementare correttamente il servizio di callback abbiamo dovuto estendere le interfacce Thrift e definire il nostro protocollo, insieme a un "processore" Thrift e un client-server di callback.Ma ammetto liberamente che la nostra applicazione è /molto/ speciale.I protocolli e i server esistenti dovrebbero essere sufficienti.Ma estenderli, anche per utilizzare prese multiplex di .Net, non è stato poi così difficile.

Answer 5

Utilizziamo ICE per integrare moduli scritti sia in C++, Java e C#.La cosa bella è che il nostro server può accedere anche a componenti su macchine remote, quindi se abbiamo bisogno di maggiori prestazioni possiamo spostare l'elaborazione su macchine diverse.

Ho utilizzato sia WCF che ICE e direi che ICE è più pulito dal punto di vista dell'implementazione.L'ICE dispone inoltre di una documentazione molto dettagliata e leggibile.

ICE supporta alcune operazioni che WCF non può eseguire, tra cui il bilanciamento del carico, gli aggiornamenti automatizzati dei client remoti e così via.