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

Ответ 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 для двоичного кодирования и т.д.

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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