.remoting vs wcf
Vasily Povalyaev
труъ сетевое взаимодействие возможно только посредством ремоутинга и
никакой дабсиэф тут не годится. если у нас не стоит ограничение вторым
фреймворком, то чем так плох wcf?
Grigory Bushuev
meowth
основания :) Давайте уточним по фактам.
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>
meowth
загадывать не стал бы ;)
Vasily Povalyaev
использования в продакшене
Автоматическое определение контракта конечно хорошо, но от вынужденных
провешиваний OneWay никто не застрахован, потому надписывание
OperationContract не выглядит серьезным недостатком.
К сожалению не понял про автоматический маршалинг; что под этим
подразумевается?
Передача ссылки на сервис из другого сервиса звучит зловеще ) к
сожалению, опять не могу представить этот кейс в реальности.
Client <--> Service1 | Service1 <--> Service2 [клиент ничего не знает об
интерфейсе Service2; и вот тут-то ему проксик на Service2 от Service1
и приходит. тадам! и на фига?]
или кейс в чем-то другом?
граф взаимодействующих объектов организуется и на wcf, и на remoting и
на udp сокетах [было бы желание].
как насчет дуплексных каналов, транзакций, сессий, шифрования трафика
из коробки?
meowth
> Автоматическое определение контракта конечно хорошо, но от вынужденных
> провешиваний 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
разные вещи. Одна вещь низкоуровневая, вторая высокоуровневая.
Понятно, что с помощью низкоуровневой технологии можно имитировать
высокоуровневую, но надо ли это? Для маленького проекта это может быть
уместно, но если у вас большая корпорация вас выгонят с работы(да в
корпорации могут использовать ремотинг но для тех целей для которых он
предназначен). А то можно и до raw sockets дойти в порыве минимализма
и изобретать новый велосипед.
Прозрачность взаимодействия, если я правильно понимаю о чем идет речь,
то это была больная тема для архитекторов wcf и заслуженно считается
недостатком. Поэтому они сделали все чтобы у wcf ее не было.
Как альтернативщики не будем забывать о zeroc ice, Service Stack,
zeromq. Надо выбирать тулы по вашим конкретным запросам.
P.S. IMHO WCF дерьмо, но у него есть поддержка мс и он является одним
из краеугольных камней платформы, поэтому глупо его игнорировать.
Vasily Povalyaev
немного поотвечаю
>Для ремотинга не нужен 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
> как работает и кода там написано достаточно], уточню еще раз:
> имел ли кто-то опыт внедрения wcf в продакшен системах пусть даже
> низкого уровня критичности?
Я имел. Два веб-приложения клиенты, бэкэнд с простой бизнеслогикой
(crud) в виде фасада на WCF, все это через http транспорт (аля веб-
сервисы). Написали все по канонам, все заработало, за исключением
того, что вдруг внезапно (с) сервис подвисает в момент вызова метода.
В общем, экспериментировали, смотрели, но поведение очень похоже на
гейзенбаг. Хз, почему оно так, я грешу на сервер и его настройки пула
IIS-а, другие товарищи винят WCF.
shelin anton
Отправлено с iPad
03.02.2011, в 11:54, bkmz <ilya.ch...@gmail.com> написал(а):
Vitaly Baum
Александр Пчелин
Сейчас у нас в компании есть распределенное приложение (Framework 1.1)
инстансы которого общаются через через ремоутинг. Клиентская часть
также общается с сервером через ремоутинг. В данный момент активно
внедряем WCF сервисы для передачи данных в Веб приложения.
В планах поднятие версии Framework нашего приложения и замена
ремоутинга на WCF. Интересно узнать реальные аргументы против WCF, на
какие грабли мы наступим.
Большой плюс в WCF - поддержка транзакций.
> > > крайней мере, то, что вижу я).- Скрыть цитируемый текст -
>
> - Показать цитируемый текст -
Rinat Abdullin
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 >>