Кто-нибудь сравнивал WCF и ZeroC ICE?

Question

ICE ZeroC (www.zeroc.com) выглядит интересно, и мне интересно посмотреть на него и сравнить его с нашим существующим программным обеспечением, использующим WCF. В частности, наше приложение WCF использует серверные обратные вызовы (через HTTP).

Кто-нибудь их сравнивал? Как прошло? Я особенно заинтересован в аспекте производительности, так как совместимость сейчас нас не сильно беспокоит. Спасибо!

Answer 1

Я провел очень краткий обзор ICE несколько лет назад, и хотя я не сравнивал их непосредственно раньше, имея разумные знания о WCF, мои мысли могут иметь какое-то отношение.

Во-первых, не совсем справедливо сравнивать WCF с ICE как WCF, так как ICE - это особый механизм удаленной связи, а WCF - инфраструктура удаленной связи более высокого уровня.

Хотя WCF часто рассматривается как реализация веб-сервисов SOAP, и это действительно его основное применение на сегодняшний день, его также можно использовать для реализации удаленных сервисов с использованием всевозможных кодировок и транспортных каналов, что означает, что его можно использовать теоретически. для связи между приложениями.

Для сравнения, ICE - это кроссплатформенный механизм удаленной связи, использующий двоичное кодирование для эффективной связи между приложениями. Это что-то вроде упрощенной эволюции CORBA и более сравнимо с CORBA, DCOM, .NET Remoting и JNI.

Однако, хотя прямой связи между ICE и WCF нет, но если вам нужно, чтобы ваше приложение .NET осуществляло удаленный обмен данными, они оба являются соперниками. Некоторые из решений, которые вы можете рассмотреть, включают:

• ресурсообеспечения. Будет проще найти разработчиков с опытом WCF, чем с ICE.

• Производительность. Если вам нужна производительность, то ICE работает быстро, но WCF также можно использовать в конфигурации с высокой производительностью. В качестве альтернативы .NET Remoting может обеспечить очень хорошую производительность, и, как говорят тесты, спонсируемые MS, я видел, что он превосходит WCF на 10%.

• Кросс-платформенный. Если вам нужно общаться с приложениями, отличными от Windows, вы ограничены опциями WCF, которые вы можете использовать. Кроме того, поскольку каждый стек SOAP, по-видимому, реализует стандарты по-разному, может возникнуть сложность при создании действительно общих веб-служб (хотя WS-I помогает)

Если вам не нужны все унции производительности с первого дня, то я бы лично начал с WCF, а затем рассмотрел бы ICE, если производительность когда-нибудь станет критической. Даже в этом случае может быть дешевле масштабировать ваши сервисные блоки, чем переходить на ICE, и если у вас нет каких-либо экзотических кроссплатформенных потребностей, вы всегда можете посмотреть на перенастройку WCF для двоичного кодирования и т. Д.

Answer 2

Мичи Хеннинг из ZeroC недавно опубликовал официальный документ только на эту тему - «Выбор промежуточного программного обеспечения: почему производительность и масштабируемость имеют (и не имеют) значение». Он сравнивает Ice, WCF (двоичный и SOAP) и RMI с различными показателями производительности, платформами, языками и т. Д. В блоге Мичи * есть дополнительная информация, но технический документ также вполне читабелен со всеми стандартными предостережения от любого ориентира.

Отказ от ответственности: я широко использовал Ice и RMI, но никогда не пользовался WCF.

Answer 3

Apache Thrift - еще один претендент на ICE и WCF. Он был разработан и открыт с помощью Facebook. Apache Thrift хорош в некоторых отношениях, потому что он не только чрезвычайно эффективен на стороне кодирования, но также поддерживает добавление полей к структурам, не нарушая всех клиентов (что мы сочли чрезвычайно полезным для наших проектов).

Буферы протокола Google , похоже, на самом деле не претендент, поскольку не упоминает о поддержке .NET на домашней странице. Однако некоторые дополнения сообщества поддерживают C #. Кроме того, ICE обеспечивает эмуляцию для буферов протокола Google, если вы работаете с существующими службами.

Answer 4

Точка данных: мы только что преобразовали мультиплатформенный и многоязычный проект с обратным вызовом из Ice в Thrift с довольно хорошими результатами. Ice многое для вас делает, поэтому нам пришлось самим реализовывать прослушивание разрыва соединения, события подключения и т. Д. И в одном случае мы попали в пословицу с большой блокировкой объектов, с которой Ice позволил нам обойтись - это вызвало тупик на сервере Thrift, но это было легко исправить с помощью менее ленивого кодирования на стороне C #.

Я только что закончил бенчмаркинг, и в нашем приложении все, что выталкивает большие объемы данных, быстрее, чем Ice, или наравне с ним. Более короткие сообщения с большим объемом служебной информации (т. Е. «Пульс», который обновляет состояние по протоколу) немного медленнее.

Наиболее важным моментом было то, что для правильной реализации службы обратного вызова нам пришлось расширить интерфейсы Thrift и определить собственный протокол, а также Thrift-процессор и клиент-сервер обратного вызова. Но я свободно признаю, что наше приложение является / очень / особенным. Существующих протоколов и серверов должно быть достаточно. Но расширить их, даже для использования мультиплексных сокетов из .Net, было не очень сложно.

Answer 5

Мы используем ICE для интеграции модулей, написанных на C ++, Java и C #. Приятно то, что наш сервер также может получать доступ к компонентам на удаленных компьютерах, поэтому, если нам нужна более высокая производительность, мы можем перенести обработку на другие машины.

Я использовал и WCF, и ICE, и я бы сказал, что ICE более чист на стороне реализации. ICE также имеет очень подробную и удобочитаемую документацию.

ICE поддерживает некоторые вещи, которые WCF не может сделать, включая балансировку нагрузки, автоматические обновления удаленного клиента и т. Д.