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

Question

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

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

Будет ли Мастер и каждый экземпляр Slave иметь свои собственные службы? будет только хозяин хозяина? только раб? Должен ли я использовать контракты обратного вызова? Данные контракты? или просто контракты на обслуживание.

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

Answer 1

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

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

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

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

EDIT: Конечно, другой подход может заключаться в использовании двух очередей сообщений MSMQ; Мастер сбрасывает свой запрос «работа» в очередь, которую ведомый слушает и принимает запрос на работу. Когда подчиненное устройство выполнено, оно, в свою очередь, помещает ответ в очередь ответов, для которой ведущий является слушателем, и получает уведомление о выполняемой таким образом работе.

Марк

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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