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

Question

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Буферы протокола Google казалось бы, не совсем претендент, поскольку в нем не упоминается.Поддержка сети на домашней странице.Однако некоторые дополнения сообщества поддерживают C #.Кроме того,, ЛЕД обеспечивает эмуляцию буферов протокола 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 не может выполнять, включая балансировку нагрузки, автоматическое обновление удаленных клиентов и т.д.