использование WCF в качестве модели команд «главный-подчиненный»

Question

Я разрабатываю модель команд «главный-подчиненный», согласно которой некоторое приложение «Главное» отправляет команды однородным процессам, называемым «Подчиненный», для выполнения некоторой задачи, а затем отвечает обратно со статусом завершения или сбоем процесса.они также должны предоставлять мастеру некоторые данные, доступные по запросу.

Как будет выглядеть эта модель в WCF?

будут ли Master и каждый экземпляр подчиненного устройства размещать свои собственные службы?будет ли только Мастер-хозяин?только раб?Стоит ли мне использовать контракты обратного вызова?Контракты данных?или просто контракты на обслуживание.

В качестве примечания: это проект с низкой пропускной способностью, низкой интенсивностью и внутренним распространением, используемый для тестирования продукта, и его не следует рассматривать как проект с «крупным высоким спросом».

Answer 1

У вас обязательно будут контракты на обслуживание – обязательно – в той или иной форме.Это просто определяет ваш сервис и операции (методы) над ним (OperationContract).

Если это внутренняя система «за брандмауэром», вы можете посмотреть на дуплексную привязку, например.пусть Мастер вызовет Ведомое, а Ведомое сообщит по дуплексному каналу, когда это будет сделано.В стандартной комплектации есть только WsDualHttpBinding для поддержки дуплексного режима, но поскольку вы находитесь внутри, за брандмауэром, вы можете захотеть создать собственную дуплексную привязку на основе TCP (это не так сложно, как может показаться на первый взгляд). первый!).

В этом сценарии оба задействованных приложения действительно одновременно являются сервером и клиентом.

У вас будут контракты данных в той или иной форме, чтобы определять ДАННЫЕ, которые перемещаются между главным и подчиненным устройствами - так что опять же, да, вам понадобятся контракты данных.

РЕДАКТИРОВАТЬ:Конечно, другим подходом может быть использование двух очередей сообщений MSMQ;Мастер помещает свой запрос на работу в очередь, которую Подчиненный прослушивает и принимает запрос на работу.Когда ведомое устройство завершает работу, оно, в свою очередь, помещает ответ в очередь ответов, которую прослушивает ведущее устройство, и таким образом получает уведомление о выполнении задания.

Марк

Answer 2

Здесь я согласен с Джереми..То, что вы описываете, не требует сложности контрактов обратного вызова.Рабочие узлы могут просто предоставить службу WCF (или даже веб-службу WSDL или REST, если уж на то пошло...), и тогда контроллеру просто нужно будет знать URL-адреса каждого из дочерних узлов и отправлять сообщения рабочим узлам.

Если вы хотите, чтобы контроллер мог транслировать одно сообщение и иметь всех рабочих (мне очень не нравится аналогия главного/подчиненного...Я давно перешел на название этого контроллера/работника) узлы делают что-то в ответ и сообщают о своем прогрессе обратно в группу, тогда вы можете захотеть использовать часто недооцененный канал P2P, доступный в WCF.Это позволяет группе служб, написанных на WCF, одновременно взаимодействовать друг с другом как одноранговые узлы, при этом URL-адреса используются почти как разделители тем и разговоров.

Так, например, вы можете подавать команды на net.p2p://labs/команды канал.Только контроллер отправляет команды по этому каналу, но все рабочие узлы слушают.Когда они закончат свою работу в асинхронном режиме, они смогут сообщить о прогрессе на net.p2p://labs/status канал.Дополнительным преимуществом этого подхода является то, что (если вам нужна эта функция) отдельные работники получат возможность знать, что делают все остальные работники.

Однако имейте в виду, что если вы используете P2P, вам придется иметь дело с конфликтами — вы можете получить 2 узла, принимающих одну и ту же команду.Если все в порядке, то P2P — ваш инструмент.Если вам нужно, чтобы команды выдавались и подхватывались только последовательно отдельными узлами по мере их освобождения (более вероятный сценарий, когда удаленным узлам сообщают о необходимости запуска отдельных тестовых сценариев и т. д.), тогда вы можете использовать привязку MSMQ вместо P2P.Тогда все рабочие становятся клиентами, которые получают сообщения из очереди, и вам будет легче противодействовать ситуации, когда несколько рабочих принимают один и тот же запрос.

Для дополнительной справки:Сообщение в блоге, которое я написал некоторое время назад на Peer Channel..

Сценарии одноранговых каналов на MSDN - Это хорошо, потому что отсюда можно перейти к концепциям Peer Channel и справочному руководству.

Блог команды Peer Channel

Answer 3

Если подчиненная обработка займет много времени, возможно, контракты обратного вызова будут в порядке.В противном случае вы можете просто заблокировать ведущее устройство, ожидая завершения подчиненного устройства (возможно, вам придется настроить конфигурацию клиента WCF, чтобы время ожидания не истекло).

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