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

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

Во-первых, не совсем честно сравнивать WCF с ICE, поскольку WCF - это особый механизм удаленной связи, а 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 для двоичного кодирования и т. д.

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

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

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

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

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

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

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

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

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

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