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>
Автоматическое определение контракта конечно хорошо, но от вынужденных
провешиваний OneWay никто не застрахован, потому надписывание
OperationContract не выглядит серьезным недостатком.
К сожалению не понял про автоматический маршалинг; что под этим
подразумевается?
Передача ссылки на сервис из другого сервиса звучит зловеще ) к
сожалению, опять не могу представить этот кейс в реальности.
Client <--> Service1 | Service1 <--> Service2 [клиент ничего не знает об
интерфейсе Service2; и вот тут-то ему проксик на Service2 от Service1
и приходит. тадам! и на фига?]
или кейс в чем-то другом?
граф взаимодействующих объектов организуется и на wcf, и на remoting и
на udp сокетах [было бы желание].
как насчет дуплексных каналов, транзакций, сессий, шифрования трафика
из коробки?
> К сожалению не понял про автоматический маршалинг; что под этим
> подразумевается?
Для ремотинга не нужен 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 себя еще и в плане надежности не очень хорошо показывает (по
крайней мере, то, что вижу я).
Прозрачность взаимодействия, если я правильно понимаю о чем идет речь,
то это была больная тема для архитекторов wcf и заслуженно считается
недостатком. Поэтому они сделали все чтобы у wcf ее не было.
Как альтернативщики не будем забывать о zeroc ice, Service Stack,
zeromq. Надо выбирать тулы по вашим конкретным запросам.
P.S. IMHO WCF дерьмо, но у него есть поддержка мс и он является одним
из краеугольных камней платформы, поэтому глупо его игнорировать.
>Для ремотинга не нужен 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 в продакшен системах пусть даже
низкого уровня критичности?
Я имел. Два веб-приложения клиенты, бэкэнд с простой бизнеслогикой
(crud) в виде фасада на WCF, все это через http транспорт (аля веб-
сервисы). Написали все по канонам, все заработало, за исключением
того, что вдруг внезапно (с) сервис подвисает в момент вызова метода.
В общем, экспериментировали, смотрели, но поведение очень похоже на
гейзенбаг. Хз, почему оно так, я грешу на сервер и его настройки пула
IIS-а, другие товарищи винят WCF.
> > > крайней мере, то, что вижу я).- Скрыть цитируемый текст -
>
> - Показать цитируемый текст -
Почему не:
* 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 >>