WCF usando como um modelo de comando mestre-escravo

Question

Estou desenvolvendo um modelo de comando mestre-escravo pelo qual alguma aplicação "Master" envia comandos para processos homogêneos chamados "Slave" para fazer alguma tarefa e, em seguida, responder de volta com o status completo fracasso ou processo. eles também devem expor alguns dados para o mestre disponíveis a pedido.

O que seria este modelo olhar como em WCF?

iria dominar e cada instância de anfitrião Slave vários daqueles serviços próprios? seria único mestre anfitrião? única Slave? Deveria eu estar usando Contratos de retorno de chamada? Contratos de dados? ou contratos apenas de Serviços.

Como uma nota lateral, esta é uma largura de banda baixa, baixa intensidade, projeto somente distribuição interna utilizada para testes de produtos e não deve ser considerado como um projeto "grande alta demanda".

Answer 1

Você vai definitivamente ter contratos de serviços - uma obrigação - de alguma forma ou formulário. Isso só define o seu serviço e as operações (métodos) sobre ele (OperationContract).

Se é um sistema interno "behind-the-firewall", você pode olhar para um duplex de ligação, por exemplo, tem a chamada Mestre Escravo, eo relatório de volta Slave em um canal duplex quando ele é feito. Fora da caixa, há apenas o WSDualHttpBinding para duplex apoio, mas já que você é interno, behind-the-firewall, você pode querer olhar para criar a sua própria duplex de ligação (não é tão difícil como pode parecer à baseadas em TCP em primeiro lugar!).

Neste cenário, ambos os aplicativos envolvidos são realmente o servidor eo cliente, ao mesmo tempo.

Você terá DataContracts de alguma maneira, forma ou formulário para definir os dados que está a ser movimentados entre mestre e escravo -. Então, novamente, sim, você terá que ter contratos de dados

EDIT: Claro, outra abordagem seria usar duas filas de mensagens MSMQ; o Mestre deixa cair seu "trabalho" pedido em uma fila, que o escravo escuta e pega a solicitação de trabalho. Quando o escravo é feito, por sua vez, cai uma resposta para a fila de resposta ao que o Mestre é um ouvinte, e é notificado do trabalho que está sendo feito dessa forma.

Marc

Answer 2

Eu concordo com Jeremy aqui .. O que você está descrevendo não precisa da complexidade dos contratos de retorno de chamada. Os nós do trabalhador poderia simplesmente expor um serviço WCF (ou mesmo um WSDL ou serviço web REST para essa matéria ...) e, em seguida, o controlador iria simplesmente precisa saber as URLs de cada um dos nós filhos e enviar mensagens para os nós do trabalhador.

Se você quer que o controlador seja capaz de transmitir uma única mensagem e têm tudo do trabalhador (Eu realmente não gosto da analogia master / slave ... Eu há muito tempo mudou para chamando-controller / trabalhador) nós fazer algo em resposta e postar seu progresso de volta para o grupo, então você pode querer usar o canal P2P muitas vezes subestimado disponível dentro WCF. Isso permite que um grupo de serviços escritos em WCF para falar uns com os outros de uma só vez como pares com URLs sendo usado quase como separadores tópico / conversação.

Assim, por exemplo, você pode emitir comandos no net.p2p: // laboratórios / comandos canal. Apenas o controlador envia comandos nesse canal, mas todos os nós do trabalhador ouvir. Quando terminar de fazer as suas coisas de forma assíncrona, eles podem relatar o progresso de volta no net.p2p: // laboratórios / status canal. Um benefício adicional desta abordagem é que (se você precisar deste recurso), os trabalhadores individuais ganharia a capacidade de saber o que todos os outros trabalhadores estão fazendo.

Tenha em mente, no entanto que se você usar P2P, então você vai ter que lidar com a afirmação - você pode acabar com 2 nós aceitar o mesmo comando. Se isso é bom, então P2P é a sua ferramenta. Se você precisar de comandos a serem emitidas e só pegou em série por nós individuais como eles se tornam livres (um cenário mais provável quando dizendo nós remotos para executar scripts de teste individuais, etc), então você pode usar um MSMQ de ligação em vez de P2P. Em seguida, todos os trabalhadores tornam-se clientes que recebem mensagens da fila e você pode mais facilmente neutralizar a situação de vários trabalhadores aceitar o mesmo pedido.

Para referência adicional: Um blog post que escrevi um tempo atrás sobre Peer Canal .

peer Cenários canal no MSDN - Isso é bom porque você pode ir a partir daqui to peer conceitos canal para o guia de referência.

peer Canal Equipe Blog

Answer 3

Se o processamento escravo vai levar um longo tempo, então contratos de retorno de chamada pode estar em ordem. Caso contrário, você poderia simplesmente bloquear na espera mestre para o escravo completo (que você pode ter que ajustar a configuração do cliente WCF para que ele não faz time out).

Com base na sua descrição, eu acho que você realmente só precisa hospedar o serviço WCF nos nós de escravos e o Mestre poderia ser apenas um cliente consumir os serviços WCF expostas pelos escravos.