ICE от ZeroC (www.zeroc.com) выглядит интересным, и мне интересно взглянуть на него и сравнить с нашим существующим программным обеспечением, использующим WCF. В частности, наше приложение WCF использует обратные вызовы сервера (через HTTP).
Кто-нибудь их сравнивал? Как прошло? Меня особенно интересует аспект производительности, так как совместимость сейчас не очень важна для нас. Спасибо!
Я сделал очень краткий обзор 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 для двоичного кодирования и т. Д.
Мичи Хеннинг из ZeroC недавно опубликовала официальный документ только по этой теме - «Выбор промежуточного программного обеспечения: почему производительность и масштабируемость не важно". Он сравнивает Ice, WCF (двоичный и SOAP) и RMI с различными показателями производительности, платформами, языками и т. Д. Дополнительная информация доступна на Блог Мичи, но технический документ также вполне читаем со всеми стандартными оговорками любого теста.
Отказ от ответственности: я широко использовал Ice и RMI, но никогда не использовал WCF.
Apache Thrift - еще один претендент на ICE и WCF. Он был разработан Facebook с открытым исходным кодом. Apache Thrift в некотором смысле хорош, потому что он не только чрезвычайно эффективен со стороны кодирования, но и поддерживает добавление полей в структуры, не нарушая работу всех клиентов (что мы нашли чрезвычайно полезным для наших проектов).
Google Protocol Buffers, похоже, не является конкурентом, поскольку в нем не упоминается Поддержка .NET на домашней странице. Однако некоторые надстройки сообщества поддерживают C #. Кроме того, ICE обеспечивает эмуляцию буферов протокола Google, если вы работаете с существующими службами.
Данные: мы только что преобразовали мультиплатформенный и многоязычный проект обратного вызова с Ice на Thrift с довольно хорошими результатами. Ice многое делает для вас, поэтому нам пришлось самостоятельно реализовать прослушиватели отключения, события подключения и т. Д. И в одном случае мы укусили в пословице с большой блокировкой объекта, которую Ice позволил нам уйти - это вызвало тупик на сервере Thrift, но это было легко исправлено менее ленивым кодированием на стороне C #.
Я только что закончил тестирование, и в нашем приложении все, что обрабатывает большие объемы данных, работает быстрее, чем Ice. Более короткие сообщения с большим количеством служебных данных (т. Е. «Пульс», который обновляет статус по протоколу) немного медленнее.
Самым важным моментом было то, что для правильной реализации службы обратного вызова нам пришлось расширить интерфейсы Thrift и определить наш собственный протокол вместе с «процессором» Thrift и клиент-сервером обратного вызова. Но я открыто признаю, что наше приложение / очень / особенное. Существующих протоколов и серверов должно хватить. Но расширить их, даже чтобы использовать мультиплексные сокеты из .Net, было не так уж и сложно.
Мы используем ICE для интеграции модулей, написанных на C ++, Java и C #. Приятно то, что наш сервер также может получать доступ к компонентам на удаленных машинах, поэтому, если нам нужна более высокая производительность, мы можем перенести обработку на другие машины.
Я использовал как WCF, так и ICE, и я бы сказал, что ICE чище с точки зрения реализации. ICE также имеет очень подробную и удобочитаемую документацию.
ICE поддерживает некоторые вещи, которые WCF не может сделать, включая балансировку нагрузки, автоматические обновления удаленных клиентов и т. Д.
