Quelqu'un a-t-il comparé WCF et ZeroC ICE?

Question

ICE de ZeroC (www.zeroc.com) semble intéressant et je suis intéressé à le regarder et à le comparer à notre logiciel existant qui utilise WCF. En particulier, notre application WCF utilise les rappels de serveur (via HTTP).

Quelqu'un qui les a comparés? Comment c'était? Je m'intéresse particulièrement à l'aspect performance, car l'interopérabilité ne nous préoccupe pas beaucoup pour le moment. Merci!

Answer 1

J'ai fait un examen très sommaire d'ICE il y a quelques années et, bien que je ne les aie pas comparées directement auparavant, ayant une connaissance raisonnable de la WCF, mes pensées pourraient avoir une certaine pertinence.

Tout d’abord, il n’est pas parfaitement juste de comparer WCF avec ICE en tant que WCF, car ICE est un mécanisme de communication distant spécifique et WCF est un cadre de communication à distance de niveau supérieur.

Alors que WCF est souvent considéré comme implémentant des services Web SOAP, et qu’il est en fait son utilisation principale à ce jour, il peut également être utilisé pour implémenter des services distants utilisant toutes sortes de codages et de canaux de transport, ce qui signifie qu’il peut être utilisé en théorie. pour les communications performantes entre les applications.

En comparaison, ICE est un mécanisme de communication à distance multiplate-forme qui utilise le codage binaire pour des communications performantes entre applications. C’est un peu une évolution simplifiée de CORBA et plus directement comparable à CORBA, DCOM, .NET Remoting et JNI.

Cependant, même s'il n'y a pas de correspondance directe entre ICE et WCF, si vous avez besoin que votre application .NET communique à distance, ils sont tous deux candidats. Parmi les points de décision à prendre en compte, citons:

• Ressourcement. Il sera plus facile de trouver des développeurs avec une expérience WCF qu'avec une expérience ICE.

• Performance. Si vous voulez des performances, ICE est rapide, mais WCF peut également être utilisé dans une configuration performante. Alternativement, .NET Remoting peut fournir de très bonnes performances, et quels que soient les tests de performance sponsorisés par MS, je les ai vu dépasser de 10% les performances de WCF.

• multiplate-forme. Si vous avez besoin de communiquer avec des applications non-Windows, les options WCF que vous pouvez utiliser sont limitées. De plus, comme chaque pile SOAP semble implémenter les normes différemment, il peut être difficile de créer des services Web vraiment génériques (avec l'aide de WS-I)

Si vous n’avez pas besoin de chaque once de performance du premier jour, je préférerais personnellement que WCF commence, puis je considérerais ICE si les performances devenaient critiques. Même à ce moment-là, il pourrait être moins coûteux de faire évoluer vos boîtiers de services que de migrer vers ICE. Si vous n'avez pas d'exotisme multiplate-forme exotique, vous pouvez toujours envisager de reconfigurer WCF pour le codage binaire, etc.

Answer 2

Michi Henning de ZeroC a récemment publié un livre blanc sur ce sujet - " Choisir un middleware: pourquoi performances et évolutivité faire (et ne pas) la matière " ;. Il compare Ice, WCF (binaire et SOAP) et RMI avec diverses métriques de performance, plates-formes, langues, etc. Pour plus d'informations, reportez-vous à la section Le blog de Michi , mais le livre blanc est également assez lisible, avec toutes les mises en garde standard de tout repère.

Avertissement: j'ai beaucoup utilisé Ice et RMI, mais jamais WCF.

Answer 3

Apache Thrift est un autre candidat à ICE et à WCF. Il a été développé et ouvert par Facebook. Apache Thrift est agréable à certains égards car il est non seulement extrêmement efficace du côté de l'encodage, mais prend également en charge l'ajout des champs aux structures sans casser tous les clients (quelque chose que nous avons trouvé extrêmement utile pour nos projets).

Les tampons de protocole Google ne sembleraient pas vraiment être des candidats, mais pas des candidats. ne mentionnez pas le support .NET sur la page d'accueil. Cependant, certains addons de la communauté prennent en charge C #. En outre, ICE fournit une émulation pour les tampons de protocole Google si vous utilisez des services existants.

Answer 4

Point de données: nous venons de convertir un projet multi-plateforme et multilingue de rappel de Ice à Thrift avec de très bons résultats. Ice fait beaucoup pour vous, nous avons donc dû implémenter nous-mêmes des écouteurs de déconnexion, des événements de connexion, etc. Et dans un cas, nous nous sommes retrouvés dans la proverbiale avec un gros objet verrouillé par Ice, ce qui a entraîné une impasse sur le serveur Thrift, mais le problème a été facilement résolu par un codage moins fainéant du côté C #.

Je viens de terminer l’analyse comparative et, dans notre application, tout ce qui contient de grandes quantités de données est plus rapide ou comparable à Ice. Les messages les plus courts et les plus volumineux (c'est-à-dire un "battement de coeur" qui met à jour un statut via le protocole) sont un peu plus lents.

Le bit le plus important était que pour implémenter correctement le service de rappel, nous devions étendre les interfaces Thrift et définir notre propre protocole, ainsi qu'un Thrift "Processor". et rappel client-serveur. Mais je reconnais librement que notre application est / très / spéciale. Les protocoles et serveurs existants devraient être suffisants. Mais leur extension, même en utilisant des sockets multiplex à partir de .Net, n’était pas terriblement difficile.

Answer 5

Nous utilisons ICE pour intégrer des modules écrits à la fois en C ++, en Java et en C #. La bonne chose est que notre serveur peut également accéder aux composants sur des machines distantes. Ainsi, si nous avons besoin de plus de performances, nous pouvons transférer le traitement sur différentes machines.

J'ai utilisé à la fois WCF et ICE et je dirais qu'ICE est plus propre du côté de la mise en œuvre. ICE dispose également d’une documentation très détaillée et lisible.

ICE prend en charge certaines tâches que WCF n'est pas en mesure de réaliser, telles que l'équilibrage de charge, les mises à jour automatisées des clients distants, etc.