.remoting vs wcf

175 views
Skip to first unread message

Vasily Povalyaev

unread,
Jan 28, 2011, 4:09:16 AM1/28/11
to moscow alt.net
во время ответов на вопросы Юрий Веретельников категорично заявил, что
труъ сетевое взаимодействие возможно только посредством ремоутинга и
никакой дабсиэф тут не годится. если у нас не стоит ограничение вторым
фреймворком, то чем так плох wcf?

Grigory Bushuev

unread,
Jan 28, 2011, 4:20:03 AM1/28/11
to moscow...@googlegroups.com
+1

2011/1/28 Vasily Povalyaev <vpova...@gmail.com>

meowth

unread,
Jan 28, 2011, 6:14:08 AM1/28/11
to moscow alt.net
Юрий Веретельников решил вас немного потроллить, и для этого были
основания :) Давайте уточним по фактам.

WCF позиционируется как новая модель стека взаимодействия между
компонентами распределенного приложения. В том числе -- и как полная
замена .net remoting (особенно часто слышу это от евангелистов MS), с
чем я не согласен.
В реальности WCF не покрывает часть возможностей, которые
предоставляет remoting:
- автоматическое определение контракта (по интерфейсу класса);
- автоматический маршаллинг данных, которого хватает в 99% случаев;
- кейсы типа передачи ссылки на сервис из другого сервиса.

WCF - это по сути взаимодействие "точка-точка" (исключая всякие
federated-конфигурации), в то время как remoting - средство
"прозрачной" реализации распределенного в сетевой среде графа
взаимодействующих объектов. При помощи 2го легко и естественно можно
организовать 1ое, но не наоборот.


On 28 янв, 12:20, Grigory Bushuev <grigory.bush...@gmail.com> wrote:
> +1
>
> 2011/1/28 Vasily Povalyaev <vpovaly...@gmail.com>

Mike Chaliy

unread,
Jan 29, 2011, 2:59:31 AM1/29/11
to moscow alt.net
Через пару лет ты точно также сможеш тролить по поводу того что
ASP.NET MVC не полноценная замена ASP.NET WebForms. И основанием для
этого будет, не что иное как слова какого нибуть еванеглиста...

meowth

unread,
Jan 29, 2011, 11:09:03 AM1/29/11
to moscow alt.net
Конечно, я собираюсь дожить до этого счастливого момента, но
загадывать не стал бы ;)

Vasily Povalyaev

unread,
Jan 31, 2011, 4:12:29 AM1/31/11
to moscow alt.net
Про евангелистов согласен. но речь не о них, а о реальных выгодах от
использования в продакшене

Автоматическое определение контракта конечно хорошо, но от вынужденных
провешиваний OneWay никто не застрахован, потому надписывание
OperationContract не выглядит серьезным недостатком.
К сожалению не понял про автоматический маршалинг; что под этим
подразумевается?
Передача ссылки на сервис из другого сервиса звучит зловеще ) к
сожалению, опять не могу представить этот кейс в реальности.
Client <--> Service1 | Service1 <--> Service2 [клиент ничего не знает об
интерфейсе Service2; и вот тут-то ему проксик на Service2 от Service1
и приходит. тадам! и на фига?]
или кейс в чем-то другом?

граф взаимодействующих объектов организуется и на wcf, и на remoting и
на udp сокетах [было бы желание].

как насчет дуплексных каналов, транзакций, сессий, шифрования трафика
из коробки?

meowth

unread,
Feb 1, 2011, 5:52:44 PM2/1/11
to moscow alt.net

> Автоматическое определение контракта конечно хорошо, но от вынужденных
> провешиваний OneWay никто не застрахован, потому надписывание
> OperationContract не выглядит серьезным недостатком.
Очень хорошо, если вам это не мешает. Мне - мешает очень. Зачастую мне
не нужен контракт общения сервер-клиент, мне нужно прозрачное
взаимодействие между инстансами объектов в сети. Я вот о чем

> К сожалению не понял про автоматический маршалинг; что под этим
> подразумевается?

Для ремотинга не нужен DataContract, достаточно [Serializable] либо
MBR-object.

> Передача ссылки на сервис из другого сервиса звучит зловеще )

Ничего зловещего. Объект может вернуть из метода ссылку на другой
объект, и я не хочу думать, он локальный или удаленный. Remoting
реализует именно такой сценарий.

> к сожалению, опять не могу представить этот кейс в реальности.
> Client <--> Service1 | Service1 <--> Service2 [клиент ничего не знает об
> интерфейсе Service2; и вот тут-то ему проксик на Service2 от Service1
> и приходит. тадам! и на фига?]
> или кейс в чем-то другом?

У меня спрашивали пример на конференции, я озвучу его еще раз.
Предположим, у вас есть сервис, выставляющий API для клиента MMORPG.
Пусть он выглядит схематично так:
service IAnonymousUserApi {
/// логинимся и получаем ссылку на "широкий сервис"
ILoggedUserApi Login(Credentials creds).
}

Научите меня делать такое на WCF, если кто-то знает. В .net 4.0 я не
умею.

> граф взаимодействующих объектов организуется и на wcf, и на remoting и
> на udp сокетах [было бы желание].

Реализуется, конечно. Только у вас не простые объекты, а location-
aware. Т.е. они знают, что есть сервис, знают, куда за ним ходить, и
знают, какие данные ему требуются. Я не хочу service-centric
архитектуру, не хочу в свой домен тащить об этом информацию.

> как насчет дуплексных каналов, транзакций, сессий, шифрования трафика из коробки?

Предпочитаю разделять мухи и котлеты. То, что перечислено, решается и
при использовании remoting.
Шифровать можно не на message-level, а взять IPSec. Дуплексные каналы
легко поддерживаются, коль скоро проксик на клиентский объект можно
передать на сервер. Транзакции и сессии вообще были введены по
аналогии с WS-*, чтобы скрыть факт того, что обмен - request-response
без поддержания постоянного соединения. Прекратите рвать соединение
после каждого вызова и необходимость в сессиях/транзакциях отпадает
сама собой.

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

P.S. WCF себя еще и в плане надежности не очень хорошо показывает (по
крайней мере, то, что вижу я).

hodzanassredin

unread,
Feb 2, 2011, 3:22:31 AM2/2/11
to moscow alt.net
Странный спор, вы сравниваете мух с котлетами. Это две абсолютно
разные вещи. Одна вещь низкоуровневая, вторая высокоуровневая.
Понятно, что с помощью низкоуровневой технологии можно имитировать
высокоуровневую, но надо ли это? Для маленького проекта это может быть
уместно, но если у вас большая корпорация вас выгонят с работы(да в
корпорации могут использовать ремотинг но для тех целей для которых он
предназначен). А то можно и до raw sockets дойти в порыве минимализма
и изобретать новый велосипед.

Прозрачность взаимодействия, если я правильно понимаю о чем идет речь,
то это была больная тема для архитекторов wcf и заслуженно считается
недостатком. Поэтому они сделали все чтобы у wcf ее не было.

Как альтернативщики не будем забывать о zeroc ice, Service Stack,
zeromq. Надо выбирать тулы по вашим конкретным запросам.

P.S. IMHO WCF дерьмо, но у него есть поддержка мс и он является одним
из краеугольных камней платформы, поэтому глупо его игнорировать.

Vasily Povalyaev

unread,
Feb 2, 2011, 11:52:04 AM2/2/11
to moscow alt.net
мнямк.
немного поотвечаю

>Для ремотинга не нужен DataContract, достаточно [Serializable] либо
>MBR-object.

для wcf тоже хватит serializable [с этой точки хрения serializable и
datacontract отличаются только своим взглядом на поля; первый хватает
все, кроме nonserialized; второй - ничего кроме datamember]

>Научите меня делать такое на WCF, если кто-то знает. В .net 4.0 я не
>умею.

действительно, некоторое время просуществовало Shareable, но было
выпилено [имхо зря]. но никто не может вам запретить пользоваться
endpoint'ами.

>...мухи...котлеты...
я о том не спорю. но не скатываться же к голому tcp?

похоже, что я плохо задал вопрос. в результате получил не тот ответ =)
попробую переформулировать.
у меня есть распределенное приложение [местами - одноранговое; местами
- клиент-серверное], которое дышит на remoting'е.
есть ли смысл передвинуть взаимодействие на wcf?
я надеялся получить ответ от человека, который уже реализовывал в
продакшене приложение достаточно сложное для того, чтобы набить себе
шишек.

пока могу подвести промежуточный итог:
1) WCF себя еще и в плане надежности не очень хорошо показывает
[наработка на отказ below 9000?]
2) Если не использовать WCF в проектах в большой компании, то можно
вылететь с работы [modus ponens странен]
3) WCF дерьмо [о5-таки слабый аргумент в споре]

чтобы не холиварить и не евангелировать [самому remoting ближе, потому
как работает и кода там написано достаточно], уточню еще раз:
имел ли кто-то опыт внедрения wcf в продакшен системах пусть даже
низкого уровня критичности?

bkmz

unread,
Feb 3, 2011, 3:54:11 AM2/3/11
to moscow alt.net
> чтобы не холиварить и не евангелировать [самому remoting ближе, потому
> как работает и кода там написано достаточно], уточню еще раз:
> имел ли кто-то опыт внедрения wcf в продакшен системах пусть даже
> низкого уровня критичности?

Я имел. Два веб-приложения клиенты, бэкэнд с простой бизнеслогикой
(crud) в виде фасада на WCF, все это через http транспорт (аля веб-
сервисы). Написали все по канонам, все заработало, за исключением
того, что вдруг внезапно (с) сервис подвисает в момент вызова метода.
В общем, экспериментировали, смотрели, но поведение очень похоже на
гейзенбаг. Хз, почему оно так, я грешу на сервер и его настройки пула
IIS-а, другие товарищи винят WCF.

shelin anton

unread,
Feb 3, 2011, 4:03:29 AM2/3/11
to moscow...@googlegroups.com
натравите на него профайлер увидите где затык а то гадать можно до бесконечности думаю просто /dev/hands

Отправлено с iPad

03.02.2011, в 11:54, bkmz <ilya.ch...@gmail.com> написал(а):

Vitaly Baum

unread,
Feb 3, 2011, 4:03:50 AM2/3/11
to moscow...@googlegroups.com
SharePoint 2010 - вся инфра держится на WCF сервисах: синхронизируется топология, зеркалируются данные, роутятся запросы.
У меня было несколько проектов, где я делал REST-Services с помощью WCF,
 большого количества данных по ним не ходило, поэтому показательным этот опыт не считаю.
Есть некоторые сложности с хостингом сервисов на SharePoint, но чтобы снизить количество головной боли - просто переписываются фабрики.
А ещё отдельная история - траблшутинг WCF, для того, чтобы выяснить, что же упало/пошло не так на первом этапе надо использовать как минимум листенеры.   

2011/2/3 bkmz <ilya.ch...@gmail.com>

Александр Пчелин

unread,
Feb 3, 2011, 4:37:11 AM2/3/11
to moscow alt.net
Очень интересны реальные аргументы против WCF.
Сейчас у нас в компании есть распределенное приложение (Framework 1.1)
инстансы которого общаются через через ремоутинг. Клиентская часть
также общается с сервером через ремоутинг. В данный момент активно
внедряем WCF сервисы для передачи данных в Веб приложения.
В планах поднятие версии Framework нашего приложения и замена
ремоутинга на WCF. Интересно узнать реальные аргументы против WCF, на
какие грабли мы наступим.
Большой плюс в WCF - поддержка транзакций.

> > > крайней мере, то, что вижу я).- Скрыть цитируемый текст -
>
> - Показать цитируемый текст -

Rinat Abdullin

unread,
Feb 11, 2011, 2:38:25 AM2/11/11
to moscow alt.net
Использовал раньше Remoting, SOAP WS, WCF etc. В итоге пришли к
Messaging + REST (POX/JSON/ProtoBuf).

Почему не:

* WCF - RPC, non-durable, coupling. Udi Dahan про них часто говорит,
когда NServiceBus толкает.
* транзакции между consistency boundaries - хорошо описано у Пата
Хэлланда, который DTC и создавал (http://www-db.cs.wisc.edu/cidr/
cidr2007/papers/cidr07p15.pdf)
* SOAPб WS-* - наворочено сверх меры, на практике сложно
использовать при интеграции с другими платформами.
* binary remoting - жесть с контрактами, любой чих ломает интеграцию
между системами, extreme coupling, в итоге очень дорого.

Почему вообще Messaging, а не RPC - http://distributedpodcast.com/2011/episode-3-messaging

All the best,
Rinat

> > > > Я хочу показать, что не все кейсы покрываются WCF. Иногда лучше не...
>
> read more >>

Reply all
Reply to author
Forward
0 new messages